System and method for actively scanning a computer system

Abstract

The present invention relates to the field of cybersecurity, and more particularly to the penetration testing of computer systems. According to the present active scanning method, first an exploit and an exploit activation schedule are received. The exploit is then verified by comparing same with verified exploits. If the exploit matches at least one of said verified exploits, the exploit and the schedule are transmitted to a scheduler. Otherwise, the exploit is subjected to further verification. An approved exploit is transmitted to the scheduler with a schedule. The approved exploit is then transmitted to a scanning infrastructure in accordance with the schedule. After this, the exploit is run by the scanning infrastructure, and the results produced by the exploit are obtained. The present method makes it possible to perform active scanning using any user exploits while maintaining scanning safety.

Description

H04L 9 / 40 G06F 21 / 00 SYSTEM AND METHOD FOR ACTIVE SCANNING OF A COMPUTER SYSTEM Field of technology

[0001] The present invention relates to the field of cybersecurity, namely to penetration testing of computer systems. State of the art

[0002] Penetration testing (pentesting) is a method for assessing the security of computer systems or networks by simulating a malicious attack. The goal of pentesting is to identify vulnerabilities in the target computer system's security that could be exploited by attackers. Early identification of computer system vulnerabilities allows for their timely remediation.

[0003] Companies can conduct penetration tests of their computer systems in a variety of ways, depending on their goals and resources. Specifically, companies can hire penetration testing specialists (pentesters) who write exploits to find vulnerabilities in the company's systems, applications, network, and infrastructure. However, this is a labor-intensive and expensive process, so not all companies can afford to pay for such services or hire a dedicated pentesting specialist.

[0004] Alternatively, various automated testing platforms and tools are available. These allow you to perform penetration testing of your computer system without extensive cybersecurity expertise. These tools can automate many processes, such as scanning for common vulnerabilities, SQL injections, or XSS vulnerabilities. This allows organizations to conduct penetration tests more frequently and at a lower cost. However, automated tests may not detect all complex vulnerabilities that can only be found by an experienced pentester. This is partly because pentesting platforms and tools typically restrict user access to certain exploits and techniques to prevent abuse and ensure security.

[0005] A system for conducting autonomous distributed cybersecurity testing is known from the prior art, disclosed in patent application No. US2024291848A1 (published: August 29, 2024; IPC: H04L 9 / 40). The autonomous cybersecurity testing system includes a scanning module adapted to convert the results of scanning a target computing device or network into machine-readable form. The scanning module includes an input module that processes the scan results to create nodes representing target ports, port states, and vulnerabilities. A command module includes a plurality of nodes representing facts, rules, actions, and checks associated with one or more vulnerabilities identified by the scanning module. The command module is configured to determine whether to launch an attack.The attack module is configured to assign an attack based on one or more vulnerabilities upon receiving instructions from the command module. The verification module is configured to determine the success or failure of the assigned attack and return a success or failure indicator to the command module.

[0006] In addition, systems, a method, and a device for providing proactive cyber defense are known, described in application No. US2016134650A1 (published: May 12, 2016; IPC: H04L 29 / 06). The system for automatically detecting vulnerabilities in a secure network uses an external communication channel to interact with external network assets. The system includes a device with a database containing executable code and a processor for performing automated operations, including performing communication scans with attempts to communicate with network assets via various protocols, creating log files for each attempt, and performing pentesting using adaptive methods to detect vulnerabilities, with the test results recorded in log files containing information about the vulnerabilities found and the characteristics of access to the secure network.

[0007] Both of the above-mentioned alternatives prevent users from uploading their own exploit scripts, nor do they disclose user-defined script settings. Therefore, these alternatives are unable to detect more complex and hidden vulnerabilities.

[0008] A user-defined system and method for detecting and exploiting vulnerabilities are also known, as disclosed in Patent for Invention No. CN117097513B (published: November 29, 2024; IPC: H04L 9 / 40). The system includes an interactive module, a script management module, and a script execution module. The interactive module provides user interaction, allowing the user to invoke a pinpoint scanning interface based on stored vulnerability detection settings. The script management module automatically generates scripts for detecting or exploiting vulnerabilities based on the transmitted data, saves them in a script directory and database, and transmits new vulnerability identifiers to the interactive module. The script execution module provides script execution, scanning, and the display of detailed attack information.

[0009] In this alternative, the exploit testing script is automatically generated based on user-input data (vulnerability data, vulnerability detection data, or attack data). However, as with previous alternatives, the user cannot upload their own script. Furthermore, this alternative does not check the generated exploit scripts for potential harm to the computer system, although automatically generated scripts can be just as dangerous as downloaded ones.

[0010] Application No. CN117201158A describes a method for penetrating an industrial internet security research platform (published: 08.12.2023; IPC: H04L 41 / 16; H04L 9 / 40). The method involves collecting system data through open networks and practical training, simulating target systems with identical parameters, and using various attack methods (Wi-Fi hijacking, DDoS, SQL injection, etc.) to identify vulnerabilities. The collected data is analyzed to create an attack rule base, after which a classification system is applied for effective and ineffective attacks. Using artificial intelligence, new attack codes are generated and integrated into the system, and the attack rule base is updated in regular cycles to improve penetration methods and enhance security. [UN] In its analog form, the exploit's verification script is generated automatically based on collected data (data on the attack target, data on the computer system). The script is generated using artificial intelligence. Users cannot upload their own script. The essence of the invention

[0012] The objective of the present invention is to develop a system and method for actively scanning a computer system, allowing users to upload their own exploits while ensuring the safe launch of such user exploits.

[0013] The technical result that the present invention is aimed at achieving is to ensure the ability to conduct active scanning using any user exploit scripts while maintaining the security of such scanning.

[0014] This technical result is achieved by actively scanning a computer system. According to this method, an exploit and its activation schedule are first obtained through the user interface. Then, an initial check of the obtained exploit is performed by comparing it with verified exploits contained in a database of verified exploits. If the obtained exploit matches at least one of the verified exploits, the obtained exploit and schedule are transferred to the scheduler. Otherwise, an additional check of the obtained exploit is performed. Exploits approved as a result of this additional check are added to the database of verified exploits and transferred to the scheduler along with the obtained schedule. The verified exploit is then transferred to the scanning infrastructure in accordance with the received schedule.After this, the tested exploit is launched using the scanning infrastructure and the results of the tested exploit are obtained.

[0015] The ability to obtain exploits through the user interface allows users to upload any exploits, which in turn increases the effectiveness of vulnerability detection. Furthermore, the fact that user-uploaded exploits undergo two stages of verification prevents any actual damage to the target infrastructure, as well as to the computer system of the user deploying the scanning infrastructure. Furthermore, over time, the database of verified exploits will be updated with new ones, reducing the time required to perform checks. Thus, this method improves vulnerability detection by enabling active scanning using any user-defined exploit scripts while maintaining the security of such scanning.

[0016] If, during the comparison stage of the obtained exploit with verified exploits, a partial match with at least one of the verified exploits contained in the exploit database can be detected, the following can be done. First, the number of mismatched strings can be counted for each of the verified exploits. Then, the verified exploit with the fewest mismatched strings can be selected. The obtained exploit and the number of mismatched strings relative to the selected exploit can then be submitted for additional verification. This will simplify and speed up the additional verification process.

[0017] Additionally, during the initial validation of the obtained exploit, the attacked addresses in the obtained exploit can be compared with the addresses contained in the database of authorized addresses. This ensures that the user-defined exploit script does not attempt to attack illegitimate addresses and prevents damage caused by the exploit's actual maliciousness.

[0018] During the additional verification phase, the resulting exploit may be checked for at least commands to generate the target address, commands to obtain the target address from external sources, memory leaks, and signs of exploit malware. This also helps prevent attackers from attempting to launch an attack using the scanning infrastructure of the active scanning provider.

[0019] Before passing a received exploit to the scheduler, it can be assigned a marker classifying it as one of the following types: "port scan," "brute force," "web fuzzing," or "other." The resulting exploits can then be stored in the scheduler according to the marker assigned to the exploit. This allows, firstly, for active scanning with various exploit types and, secondly, for efficient distribution of different exploits among the scanning infrastructure modules.

[0020] Received port scanning exploits can be passed to the port scanning launcher according to a schedule stored in the scheduler. Upon receiving an exploit, the port scanning module can divide the list of hosts to scan contained in the received exploit. A scan request can then be sent to the message broker for each network and / or address. The scan requests can then be distributed among network scanners, which in turn scan the list of hosts contained in the received exploit using network scanners. This can then generate port scanning results, allowing attackers to identify ports through which they can access the computer system.

[0021] Obtained brute-force exploits can be passed to the protocol brute-force module according to a schedule stored in the scheduler. Upon receiving an exploit, they can send a scan request to the protocol brute-force module containing the IP address, port, protocol, and a list of logins and passwords. The logins and passwords can then be brute-forced using the protocol brute-force module. This can then produce brute-force results. This allows for identifying accounts that can be accessed by brute-forcing passwords.

[0022] Obtained web fuzzing exploits can be passed to the web fuzzing module according to a schedule stored in the scheduler. Upon receiving an exploit, a scan request containing the web resource address and a list of fuzzing inputs can be sent to the web fuzzing module. The web resource hosted at the received address can then be fuzzed using the received list of inputs using the web fuzzing module. Scan results can then be obtained. This allows for the detection of vulnerabilities in web applications before attackers do, thereby improving the security and stability of applications.

[0023] Other exploits received can be passed to the exploit launcher according to a schedule stored in the scheduler. The exploit launcher can listen to the message broker using multiple container engines. When an exploit is received by the message broker, it can be retrieved using one of the available container engines. The resulting exploit can then be launched using the container engine. Ultimately, the exploit's results can be obtained. This allows for penetration testing using other types of exploits, not just port scanning, web fuzzing, and brute-force attacks.

[0024] Using a scheduler, updates to the task list can be checked periodically. When a new task appears, it can be launched in a coroutine and written to the task dictionary. If updates are available, the old task can be stopped and a new one created. This allows for efficient distribution of scanning tasks among elements of the scanning infrastructure. Furthermore, using a coroutine allows the entire system to operate asynchronously, executing multiple tasks independently and simultaneously. This also reduces the load on the system's hardware resources.

[0025] The technical result is also achieved by a system for actively scanning a computer system. The system includes a user interface configured with the ability to load an exploit and schedule exploit activation; a database of verified exploits; a primary verification module receiving exploits from the user interface and connected to the database of verified exploits, wherein the primary verification module is configured with the ability to compare the received exploit with exploits from the database of verified exploits; an additional verification unit for checking exploits other than the exploits contained in the database of verified exploits and configured with the ability to load approved exploits into the database of verified exploits;a scheduler that includes a message broker and receives exploits and an exploit activation schedule from a primary verification module when the exploit matches at least one of the verified exploits from a database of verified exploits, and receives approved exploits and an exploit activation schedule from an additional verification unit; and a scanning infrastructure that receives exploits from the scheduler in accordance with a downloaded schedule and is configured to scan a computer system using the received exploit.

[0026] The ability to obtain exploits through the user interface allows users to upload any exploits, which in turn increases the effectiveness of vulnerability detection. Furthermore, the fact that user-uploaded exploits undergo two stages of verification prevents any actual damage to the target infrastructure, as well as to the computer system of the user deploying the scanning infrastructure. Furthermore, over time, the database of verified exploits will be updated with new ones, reducing the time required to perform checks. Thus, this method improves vulnerability detection by enabling active scanning using any user-defined exploit scripts while maintaining the security of such scanning.

[0027] The primary validation module may be a static validator configured to: (1) count the number of mismatched strings between the received exploit and each of the validated exploits; (2) select the validated exploit with the fewest mismatched strings; (3) submit the received exploit and the number of mismatched strings relative to the selected validated exploit for further validation.

[0028] The system may further include a database of authorized addresses, and the primary verification module may be configured to compare the attacked addresses from the obtained exploit with the addresses contained in the database of authorized addresses.

[0029] The additional verification block may be configured to check the obtained exploit for at least the presence of: (1) commands to generate the attacked address; and / or (2) commands to obtain the attacked address from external sources; and / or (3) memory leaks; and / or (4) signs of maliciousness of the exploit.

[0030] Each exploit may contain a marker that classifies the exploit as one of the following types: "port scan", "brute force", "web fuzzing", or "other", and the resulting exploits may be stored in the scheduler in accordance with the marker assigned to the exploit, and the scanning infrastructure may include a port scan launcher, a protocol brute force module, a web fuzzing module, and an exploit launcher.

[0031] The scheduler may be configured to transmit exploits with the "port scan" marker to the port scan launcher in accordance with a schedule stored in the scheduler, wherein the port scan module may include a message broker and a plurality of network scanners and be configured to: (1) divide the list of hosts to be scanned contained in the received exploit; (2) send a separate request for each network and / or for each address to be scanned to the message broker; (3) the message broker is configured to distribute the scanning requests between the network scanners. The network scanners, in turn, may be configured to scan the hosts from the list of hosts and send the scanning results to the message broker.

[0032] The scheduler may be configured to transmit exploits with the "brute force" marker to the protocol brute force module in accordance with a schedule stored in the scheduler, wherein the scheduler's message broker may be configured to generate and send scan requests containing the IP address, port, protocol, and list of logins and passwords to the protocol brute force module. The protocol brute force module may be configured to: (1) perform login and password guessing; (2) send the brute force results to the scheduler's message broker.

[0033] The scheduler may be configured to transmit exploits with the "web fuzzing" marker to the web fuzzing module according to a schedule stored in the scheduler, wherein the scheduler's message broker may be configured to generate and send scan requests containing the address of a web resource and a list of input data for fuzzing to the web fuzzing module. The web fuzzing module may then be configured to: (1) perform fuzzing of the web resource located at the received address using the received list of input data; (2) send the fuzzing results to the scheduler's message broker.

[0034] The scheduler may be configured to submit exploits with the "other" marker to the exploit launcher in accordance with a schedule stored in the scheduler. The exploit launcher may include a plurality of container engines configured to: (1) listen to the scheduler's message broker queue; (2) receive exploits from the scheduler's message broker; (3) launch the received exploit; and (4) send the results of the exploit launch to the scheduler's message broker.

[0035] The scheduler can be configured to check for updates in the task list at regular intervals; when a new task appears, the scheduler can be configured to start a new task in the coroutine and write the new task to the task dictionary, and if there are updates, to stop the old task and create a new task. Description of drawings

[0036] The subject matter of the present invention is described point by point and clearly expressed in the claims. The above-mentioned objectives, features, and advantages of the invention are apparent from the following detailed description, taken in conjunction with the accompanying drawings, which show:

[0037] Fig. 1 is a schematic view of a system for conducting active scanning of a computer system in accordance with the present invention.

[0038] Fig. 2 is a schematic view of a system for conducting active scanning of a computer system with an additional database of resolved addresses in accordance with the present invention.

[0039] Fig. 3 is a schematic view of a system for conducting active scanning of a computer system with output of results to a user interface in accordance with the present invention.

[0040] Fig. 4 is a schematic view of the interaction between the scheduler and the scanning infrastructure in accordance with the present invention.

[0041] Fig. 5 is a schematic view of the interaction between the scheduler and the port scanning module in accordance with the present invention.

[0042] Fig. 6 shows a schematic view of the interaction between the scheduler and the protocol brute force module in accordance with the present invention.

[0043] Fig. 7 shows a schematic view of the interaction between the scheduler and the web protocol fuzzing module in accordance with the present invention.

[0044] Fig. 8 shows a schematic view of the interaction between the scheduler and the exploit launcher module in accordance with the present invention.

[0045] These Figures are explained by the following positions: Position 1 - user interface; Position 2 - database of verified exploits; Position 3 - primary verification module; Position 4 - additional check block; Position 5 - scheduler; Position 51 - scheduler message broker; Position 6 - scanning infrastructure; Position 611 - port scanning module; Position 612 - Port Scan Module Message Broker; Position 613 - network scanner; Position 621 - protocol brute force module; Position 631 - web fuzzing module; Position 641 - Exploit Launcher Module; Position 642 - container engine; Position 7 - the attacked computer system; Position 8 - database of resolved addresses; Position 101 - Getting the exploit and schedule from the user interface; Position 102 - Obtaining verified exploits for comparison; Position 103 - transfer of a fully matching exploit and its launch schedule to the scheduler; Position 104 - Submitting a mismatched or partially matching exploit for additional verification; Position 105 - adding the approved exploit to the database of verified exploits; Position 106 - transferring the approved exploit and its launch schedule to the scheduler; Position 107 - transferring the exploit to the scanning infrastructure in accordance with the schedule; Position 108 - launching an exploit on the attacked computer system; Position 109 - getting a list of allowed addresses; Position 11 - database of exploit results; The software position is to obtain the results of the exploit's operation on the attacked computer system; Position 111 - loading the results of exploits into the exploit results database; Position 112 - transfer of the results of the loaded exploit to the user interface; Position 161 - sending scanning requests for each network and each address from the list of addresses to be scanned by network scanners; Position 162 - distribution of scanning requests between network scanners; Position 163 - transfer of scan results to the message broker; Position 164 - transferring scan results to the port scanning module; Position 171 - listening to the message broker queue and fetching the exploit for launch. Detailed description of the invention

[0046] The following detailed description of the invention includes numerous implementation details to provide a clear understanding of the present invention. However, one skilled in the art will readily understand how the present invention may be used with or without these implementation details. In other instances, well-known methods, procedures, and components have not been described in detail to avoid unnecessarily obscuring the features of the present invention.

[0047] Furthermore, it is clear from the foregoing description that the invention is not limited to the embodiment described. Numerous possible modifications, changes, variations, and substitutions, while preserving the spirit and form of the present invention, are apparent to those skilled in the art.

[0048] The terms “module”, “component”, “element”, “block” and similar terms used in the description of the technical solution are used to designate computer entities that may be hardware / equipment (e.g., a device, instrument, apparatus, apparatus, component part of a device, such as a processor, microprocessor, integrated circuit, printed circuit board, including an electronic printed circuit board, breadboard, motherboard, etc., a microcomputer, etc.), software (e.g., executable program code, a compiled application, a service, a program module, a part of software or program code, etc.) and / or microprogram (in particular, firmware).For example, a component may be a process running on a processor (a processor), an object, executable code, program code, a file, a program / application, a function, a method, a (software) library, a subroutine, a coroutine, and / or a computing device (e.g., a microcomputer or a computer), or a combination of software or hardware components. For example, in a particular case, an application running on a server may be a component / module, and the server, in turn, may be a component / module. It is worth noting that at least one component / module may be part of a process. A component / module may be located on a single computing device (e.g., a microcomputer, a microprocessor, a printed circuit board, etc.) and / or may be distributed / partitioned among multiple computing devices.

[0049] Fig. 1 shows a schematic view of a system for conducting active scanning of a computer system 7 in accordance with the present invention. The system includes a user interface 1 configured with the ability to download an exploit and schedule the activation of an exploit; a database of verified exploits 2; a primary verification module 3 receiving exploits from the user interface 1 and connected to the database of verified exploits 2, wherein the primary verification module 3 is configured with the ability to compare the received exploit with exploits from the database of verified exploits 2; an additional verification unit 4 for checking exploits other than the exploits contained in the database of verified exploits 2 and configured with the ability to download approved exploits to the database of verified exploits 2;a scheduler 5, including a message broker 51 and receiving exploits and an exploit activation schedule from a primary verification module 3 when the exploit matches at least one of the verified exploits from a database of verified exploits 2, and receiving approved exploits and an exploit activation schedule from an additional verification unit 4; and a scanning infrastructure 6, receiving exploits from the scheduler 5 in accordance with the loaded schedule and configured with the ability to scan a computer system 7 using the received exploit.

[0050] The system described above and shown in Fig. 1 can operate in accordance with the method for conducting active scanning of a computer system 7 according to the present invention. According to the method, an exploit and an exploit activation schedule are first obtained via the user interface 1. Then, an initial check of the obtained exploit is performed by comparing the obtained exploit with the verified exploits contained in the verified exploit database 2. If the obtained exploit matches at least one of the verified exploits, the obtained exploit and schedule are transmitted to the scheduler 5. Otherwise, an additional check of the obtained exploit is performed. In this case, the exploits approved as a result of the additional check are added to the verified exploit database 2 and transmitted to the scheduler 5 together with the obtained schedule. Then, the verified exploit is transmitted to the scanning infrastructure 6 in accordance with the received schedule.After this, the tested exploit is launched using the scanning infrastructure 6 and the results of the tested exploit are obtained.

[0051] The ability to obtain exploits through user interface 1 allows users to upload any exploits, which in turn increases the efficiency of vulnerability detection. Furthermore, the fact that user-uploaded exploits undergo two stages of verification prevents any actual damage to the target infrastructure 7, as well as to the computer system of the user deploying the scanning infrastructure 6. Furthermore, over time, the database of verified exploits 2 will be updated with new verified exploits, thereby reducing the time required to perform checks. Thus, this method improves the efficiency of vulnerability detection by enabling active scanning using any user-defined exploit scripts while maintaining the security of such scanning.

[0052] As noted previously, an advantage of the present invention is the ability to upload custom code for penetration testing. Users can access a user interface to submit their exploit to the infrastructure of the company organizing the pentest. This can include both uploading a custom exploit and selecting and configuring an exploit from the database of verified exploits 2. Along with the exploit script, the user also needs to submit a schedule for its activation, so that scheduler 5 on the pentest organizer's side can submit the exploit to scanning infrastructure 6 at the appropriate time. This is important both for distributing tasks among the components of the organizer's infrastructure and for the user wishing to test their computer system 7.

[0053] Because an attacker could gain access to upload exploits to the organizer's infrastructure, or an ordinary user could unknowingly attempt to use a real malicious exploit for a penetration test, exploits uploaded by users must be thoroughly verified. In the context of this invention, such verification involves two important stages: primary verification and secondary verification.

[0054] During the initial verification stage, the received exploit is verified by comparing it with verified exploits contained in the verified exploit database 2. This allows for a reduction in the queue of exploits for additional verification, since if the exploit uploaded by the user is a complete match to one of the verified exploits, then there is no need to conduct additional verification for this uploaded exploit.

[0055] The system may additionally include a database of authorized addresses 8, as shown in Fig. 2. This database 8 may be connected to the primary verification module 3. In this case, the primary verification module 3 may be configured to compare the attacked addresses from the obtained exploit with the addresses contained in the database of authorized addresses 8. This will ensure that the exploit's user script does not attempt to attack illegitimate addresses and avoid damage caused by the exploit's actual maliciousness. The database of authorized addresses 8 may contain the client identifier and the hosts authorized for attack or scanning. In particular, all clients may be granted access only to attack or scan their hosts, or to a truncated list of their hosts.It's important that the list of allowed addresses for a specific client does not contain addresses of other parties, including competitors or the address of the penetration test organizer. Therefore, the initial verification may involve verifying addresses along with comparing the obtained exploit with verified exploits.

[0056] A static validator can be used for initial validation. This allows the resulting exploit to be analyzed without executing it. To compare the resulting exploit with the verified exploit, a line-by-line analysis of the resulting exploit can be performed. This analysis will be performed separately for each verified exploit.

[0057] If a complete match is found between the exploit received (downloaded by the user) and one of the verified exploits from the database of verified exploits 2, the obtained exploit and its launch schedule are sent to scheduler 5.

[0058] If no match is found, the resulting exploit is sent for further verification. Similarly, if a partial match with one of the verified exploits is found, that exploit is also sent for further verification. In the latter case, the following steps can be taken. First, the number of non-matching strings can be counted for each of the verified exploits. Then, the verified exploit with the fewest non-matching strings can be selected. The resulting exploit and the number of non-matching strings relative to the selected exploit can then be sent for further verification. This will simplify and speed up the additional verification process.

[0059] Additional verification is necessary to identify the presence of code that could damage unauthorized targets, as well as errors. This can be performed either programmatically or manually by a code analyst. If the additional verification is performed manually by a code analyst, exploit comments may be generated during the initial verification using artificial intelligence. In the case of manual exploit verification, additional verification block 4 may refer to the code analyst's personal computer or any other computing device, where they will be able to review the code, test it in a safe environment, and approve or disapprove the code.

[0060] Additional verification is necessary to ensure the complete security of penetration testing. This is because the exploit uploaded by the user may (a) generate the address of the infrastructure being attacked; (b) obtain the address from other sources (e.g., the internet), etc. Therefore, since during the initial verification stage, exploits can only be checked for the direct presence of addresses not found in the database of authorized addresses, to ensure security, the resulting exploit must also be verified for the presence of received / generated addresses. For example, an exploit may contain commands for dynamic address generation, the use of variables or templates (which are populated based on the execution context (e.g., based on how addresses are determined in the runtime environment, or based on DNS queries)), commands for address generation based on the environment, or a response to the system response.Furthermore, teams can use web requests, DNS queries, public APIs, parse HTML pages to extract information, send requests to the server to obtain a list of targets, etc.

[0061] Furthermore, a user-uploaded exploit may contain memory leaks, which will increase the load on the scanning infrastructure. 6 Therefore, it is advisable to also check the code for such leaks during additional verification. This may be indicated by the presence of unhandled pointers or references, the absence of a memory release step after the completion of a function or process, or the use of unsafe or inefficient memory management functions.

[0062] Another dangerous type of user-downloaded exploit is malicious exploits (e.g., viruses and miners). Such exploits can harm both the attacked computer system7 and the scanning infrastructure6. To achieve this, the exploit may use obfuscation, modify system files or registries, connect to remote servers, download or insert additional malicious code, etc.

[0063] Such signs can be searched for in an exploit programmatically using various types of analysis.

[0064] Thus, during the additional verification stage, the resulting exploit can be checked at least for the presence of commands to generate the target address, and / or commands to obtain the target address from external sources, and / or memory leaks, and / or signs of exploit malware. This also helps prevent attackers from launching an attack using the scanning infrastructure of the active scanning organizer, as well as from attacking the organizer itself.

[0065] If no such signs are detected in the exploit uploaded by the user, the resulting exploit is approved. It is then passed to scheduler 5 along with the schedule and added to the verified exploit database 2. Adding to the verified exploit database 2 eliminates the need to perform additional checks of the same scripts multiple times, reducing the load on additional check block 4. Furthermore, if additional checks are performed manually, this significantly speeds up the process of checking exploits uploaded by users.

[0066] Otherwise (if the exploit script is not approved during additional verification), the user may be notified of errors in the code through user interface 1.

[0067] In general, the scanning results, as well as error notifications, can be supplied to the user interface 1 via the scheduler 5, as shown in Fig. 3. For this purpose, the system can additionally include a database of scanning results 11. Storing all results in the database 11 will allow the results of checks or error notifications to be output to the user interface 1 several times upon request by the user, so that he can analyze them at any time convenient for him.

[0068] Because exploits for pentesting come in various types, it is preferable for the scanning infrastructure to include several different modules capable of executing different types of exploits. Specifically, scanning infrastructure 6 may include a port scanning module 611, a protocol brute-force module 621, a web fuzzing module 631, and a general exploit launcher module 641, as shown in Fig. 4. Then, before passing the obtained exploit to the scheduler, the obtained exploit can be assigned a marker that classifies the exploit as one of the following types: “port scanning” (for port scanning module 611), “brute force” (for protocol brute force module 621), “web fuzzing” (for web fuzzing module 631), or “other” (for exploit launcher module 641), while the obtained exploits can be stored in the scheduler in accordance with the marker assigned to the exploit (in different fields and structures).This allows, firstly, to conduct active scanning with various types of exploits, and, secondly, to effectively distribute different exploits between the modules of the scanning infrastructure.

[0069] Port scanning module 611 allows port scanning, searching for open ports, and detecting the presence of software on such ports. For scanning, module 611 can use a space with multiple network scanners. Network scanners can be implemented as wrappers for masscan. Masscan is a fast network scanner capable of scanning a wide range of IP addresses and ports. Specifically, port scanning module 611 can be implemented as shown in Figure 5.

[0070] The module 611 shown in Fig. 5 can operate as follows. Received port scanning exploits can be transmitted to the port scanning module 611 in accordance with the schedule stored in the scheduler 5, via the message broker 51. To receive these exploits, the module 611 can continuously listen to the queue in the message broker 51. Moreover, upon receiving an exploit, the list of hosts for scanning, contained in the received exploit, can be divided using the port scanning module 611. The necessity of division is related to the fact that each network scanner 613, implemented as a wrapper over masscan, can accept only one line as input, and not a slice of hosts. Then, for each network and / or for each address, a scanning request can be sent to the message broker 612. After this, the scanning requests can be distributed between the network scanners 613, which, in turn, scan the list of hosts contained in the received exploit.As a result, they can obtain port scan results. This allows them to identify ports through which attackers can access the computer system.

[0071] Distribution of scanning requests can be carried out on a first-response basis with network scanner 613. For this purpose, each network scanner 613 continuously listens to the queue in message broker 612 of port scanning module 611. Network scanners 613 send the results of the scan to message broker 612.

[0072] The 621 protocol brute-force module performs a brute-force attack against logins and passwords to identify accounts for which an attacker could brute-force the login and password in a similar manner. Module 621 supports the following protocols: SSH, FTP, MSSQL, Telnet, SMB, SNMP, Postgres, SMTP, IMAP, POP3, MYSQL, VMAuthd, Asterisk, VNC, MongoDB, NNTP, Oracle, TeamSpeak, XMPP, RDP, Redis, Elasticsearch, and others. Module 621 can be implemented using the brutespray utility.

[0073] The protocol brute-force module 621 can interact with the scheduler 5, as shown in Fig. 6, and operate as follows. Obtained brute-force exploits can be transmitted to the protocol brute-force module 621 in accordance with a schedule stored in the scheduler 5, via the message broker 51. Moreover, upon receiving an exploit, a scanning request can be sent to the protocol brute-force module 621, containing the IP address, port, protocol, and a list of logins and passwords (to be used for the brute-force attack). The logins and passwords can then be brute-forced using the protocol brute-force module 621. Finally, the brute-force results can be obtained. The results of the brute-force attack are sent to the message broker 51 for subsequent output to the user interface 1.

[0074] The 631 web fuzzing module enables fuzzing of host directories. Fuzzing is a software testing technique using garbage data. It involves feeding an application incorrect, unexpected, or random data as input, revealing, among other things, vulnerabilities that can be exploited to conduct a real attack, as well as various software errors and unhandled exceptions. For fuzzing, the 631 module can use the Ffuf utility.

[0075] The web fuzzing module 631 can interact with the scheduler 5, as shown in Fig. 7, and operate as follows. The obtained web fuzzing exploits can be transmitted to the web fuzzing module 631 in accordance with the schedule stored in the scheduler 5, via the message broker 51. Moreover, upon receiving an exploit, a scanning request can be sent to the web fuzzing module 631, containing the address of the web resource and a list of input data for fuzzing (wordlist). Then, fuzzing of the web resource located at the received address can be performed, using the received list of input data, with the help of the web fuzzing module 631. Finally, the scanning results can be obtained. This allows for the detection of vulnerabilities in web applications before attackers do so, and thus improves the security and stability of applications. The results of the performed fuzzing are sent to the message broker 51 for subsequent output to the user interface 1.

[0076] Additionally, before sending fuzzing results to message broker 51, the results can be saved to RAM using module 631. The obtained results can then be converted into structures suitable for scheduler 5 by trimming unnecessary fields and adding fields with the user ID and the date and time of the fuzzing run. The converted results can then be sent to message broker 51 of scheduler 5. This will convert the obtained results into a format suitable for scheduler 5.

[0077] Exploit launcher 641 can be used for other types of exploits (except for port scanning, web fuzzing, and brute force). It can be represented by multiple container engines 642, which can be implemented using a Kubernetes pod with a Go microservice. Exploit launcher 641 can operate as shown in Fig. 8. Container engines 642 listen to the queue in message broker 51 of scheduler 5 and, upon receiving a task to check an exploit, launch the exploit, read the container output, and pass the output (the results of the launch) to scheduler 5. Distribution of exploit launch tasks can be performed on a first-come, first-served basis.

[0078] One example of an exploit assigned the "other" marker is EternalBlue. However, this could be any other exploit, with the exception of port scanning, web fuzzing, and brute-force exploits, that can be launched using container engines.

[0079] Scheduler 5 is a crucial element for the efficient distribution of exploit launch tasks by scanning infrastructure 6, especially for multi-user systems. Scheduler 5 is required to distribute exploits to the scanning infrastructure according to the user-uploaded schedule. Since multiple users may upload the same launch schedule, it is preferable for Scheduler 5 to launch tasks in a coroutine (specifically, a goroutine).

[0080] Scheduler 5 can interact with scanning infrastructure 6, as shown in Fig. 4. RabbitMQ can be used as message broker 51 in scheduler 5, as well as in other elements of the described system. Elasticsearch can also be used to store scan results, schedules, and scan data. Elasticsearch is an open-source, distributed data management and search system based on the Apache Lucene search engine.

[0081] Scheduler 5 can operate as follows. Scheduler 5 can check for updates to the task list at regular intervals (e.g., every 10 minutes) by pulling data from Elasticsearch. When a new task appears, it can be launched in a coroutine and written to the task dictionary for execution monitoring. If updates are available, the old task can be stopped and a new task created. If there are no updates, Scheduler 5 can go to sleep until the next scheduled execution. This will reduce the load on the system's computing power.

[0082] Internally, goroutines can create messages to message broker 51. Messages can include the following data: (1) the identifier of the client that requested the task to be executed; (2) the type of scan to run (exploit marker); and (3) any data required for the scan (e.g., scan targets, scan settings, etc.).

[0083] In parallel to periodically pulling tasks from Elasticsearch, scheduler 5 can listen to message broker queue 51 for scan results. Then, when a scan result is received, scheduler 5 can retrieve it and store it in Elasticsearch for subsequent delivery to user interface 1.

[0084] In this description, any databases can be replaced with Elasticsearch, just as any elements that use Elasticsearch can be replaced with databases.

[0085] It is important to note that any additional elements and functions of the active scanning system described above may be used individually, simultaneously, or in any combination. Implementing the system with any additional element will lead to the achievement of additional technical results described in the present invention, in addition to the primary technical result. Furthermore, any of the additional features of the system may be interpreted as an additional feature of the active scanning method. Similarly, any of the additional features of the active scanning method may be interpreted as an additional feature of the active scanning system in accordance with the present invention.

[0086] These application materials present a preferred disclosure of the implementation of the claimed technical solution, which should not be used as limiting other, particular embodiments of its implementation that do not go beyond the scope of the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims

Invention formula 1. A method for conducting active scanning of a computer system, according to which: - receive the exploit and the exploit activation schedule through the user interface; - perform a primary check of the obtained exploit by comparing the obtained exploit with verified exploits contained in the database of verified exploits; if the received exploit matches at least one of the verified exploits, the received exploit and schedule are transferred to the scheduler; otherwise, an additional check of the received exploit is carried out, and exploits approved as a result of the additional check are added to the database of verified exploits and transferred to the scheduler along with the received schedule; - transfer the verified exploit to the scanning infrastructure in accordance with the received schedule; - launch a verified exploit using the scanning infrastructure; - obtain the results of the verified exploit.

2. The method according to paragraph 1, characterized in that if, at the stage of comparing the obtained exploit with the verified exploits, a partial match is detected with at least one of the verified exploits contained in the database of verified exploits, then: - count the number of mismatched lines with each of the tested exploits; - select the tested exploit with the smallest number of mismatched lines; - send the obtained exploit and data on the number of mismatched lines relative to the selected verified exploit for additional verification.

3. The method according to paragraph 1 or paragraph 2, characterized in that, in addition, at the stage of the initial verification of the obtained exploit, the attacked addresses from the obtained exploit are compared with the addresses contained in the database of allowed addresses.

4. The method according to paragraph 1, characterized in that at the stage of additional verification, the obtained exploit is checked, at least, for the presence of: - commands for generating the attacked address; and / or - commands to obtain the attacked address from external sources; and / or - memory leaks; and / or - signs of maliciousness of the exploit.

5. The method according to claim 1, characterized in that before transmitting the obtained exploit to the scheduler, the obtained exploit is assigned a marker classifying the exploit as one of the following types: “port scanning,” “brute force,” “web fuzzing,” or “other,” and the obtained exploits are stored in the scheduler in accordance with the marker assigned to the exploit.

6. The method according to item 5, characterized in that the obtained port scanning exploits are transmitted to the port scanning launch module in accordance with a schedule stored in the scheduler, and upon receiving an exploit: - divide the list of hosts to scan, contained in the obtained exploit, using the port scanning module; - for each network and / or for each address, a scanning request is sent to the message broker; - distribute scanning requests between network scanners; - scan the list of hosts contained in the obtained exploit using network scanners; - receive scanning results.

7. The method according to item 5, characterized in that the obtained brute force exploits are transmitted to the protocol brute force module in accordance with a schedule stored in the scheduler, and upon receiving an exploit: - send a scanning request to the protocol brute-force module, containing the IP address, port, protocol, and a list of logins and passwords; - carry out brute force attacks on logins and passwords using a protocol brute force module; - receive brute force results.

8. The method according to item 5, characterized in that the obtained web fuzzing exploits are transferred to the web fuzzing module in accordance with a schedule stored in the scheduler, and upon receiving an exploit: - send a scanning request to the web fuzzing module, containing the address of the web resource and a list of input data for fuzzing; - carry out fuzzing of the web resource located at the received address, using the received list of input data, using the web fuzzing module; - receive scanning results.

9. The method according to paragraph 5, characterized in that other obtained exploits are transferred to the exploit launcher module in accordance with a schedule stored in the scheduler, and in the exploit launcher module: - listen to the message broker using multiple container engines; - when an exploit is received by the message broker, the received exploit is retrieved using one of the free container engines; - launch the resulting exploit using the container engine; - receive the results of the exploit's operation.

10. The method according to paragraph 1, characterized in that the scheduler is used to check for updates in the task list at a certain frequency, and when a new task appears, it is launched in a coroutine and written to the task dictionary, and if there are updates, the old task is stopped and a new task is created.

11. A system for conducting active scanning of a computer system, including: - a user interface configured with the ability to load an exploit and schedule the activation of the exploit; - a database of verified exploits; - a primary verification module that receives exploits from the user interface and is connected to a database of verified exploits, wherein the primary verification module is configured to compare the received exploit with exploits from the database of verified exploits; - an additional verification unit for checking exploits other than the exploits contained in the database of verified exploits and configured to load approved exploits into the database of verified exploits; - a scheduler that includes a message broker and receives exploits and an exploit activation schedule from the primary verification module when the exploit matches at least one of the verified exploits from the database of verified exploits, and receives approved exploits and an exploit activation schedule from the additional verification unit; and - a scanning infrastructure that receives exploits from the scheduler in accordance with the loaded schedule and is configured with the ability to scan the computer system using the received exploit.

12. The system according to item 11, characterized in that the primary verification module is a static validator configured with the ability to: - counting the number of mismatched lines between the obtained exploit and each of the tested exploits; - selecting a verified exploit with the smallest number of mismatched strings; - sending the obtained exploit and data on the number of mismatched strings relative to the selected verified exploit for additional verification.

13. The system according to paragraph 11 or paragraph 12, characterized in that it additionally includes a database of authorized addresses, and the primary verification module is configured to compare the attacked addresses from the obtained exploit with the addresses contained in the database of authorized addresses.

14. The system according to paragraph 11, characterized in that the additional verification unit is designed with the ability to check the obtained exploit for at least the presence of: - commands for generating the attacked address; and / or - commands to obtain the attacked address from external sources; and / or - memory leaks; and / or - signs of maliciousness of the exploit.

15. The system of claim 11, wherein each exploit contains a marker that classifies the exploit as one of the following types: “port scanning,” “brute force,” “web fuzzing,” or “other,” and the resulting exploits are stored in the scheduler in accordance with the marker assigned to the exploit, and the scanning infrastructure includes a port scanning launch module, a protocol brute force module, a web fuzzing module, and an exploit launch module.

16. The system of claim 15, wherein the scheduler is configured to transmit exploits with a "port scan" marker to the port scan launch module in accordance with a schedule stored in the scheduler, wherein the port scan module includes a message broker and a plurality of network scanners and is configured to: - dividing the list of hosts to be scanned contained in the obtained exploit; - sending a separate request for each network and / or for each address to be scanned to the message broker; the message broker is configured with the ability to distribute scan requests between network scanners, and Network scanners are designed to scan hosts from a host list and send the scan results to a message broker.

17. The system according to paragraph 15, characterized in that the scheduler is configured with the ability to transmit exploits with the “brute force” marker to the protocol brute force module in accordance with a schedule stored in the scheduler, and the scheduler message broker is configured with the ability to generate and send scan requests containing an IP address, port, protocol, and a list of logins and passwords to the protocol brute force module, and the protocol brute force module is configured with the ability to: - implementation of brute force logins and passwords; - sending brute force results to the scheduler message broker.

18. The system according to item 15, characterized in that the scheduler is configured with the ability to transmit exploits with the "web fuzzing" marker to the web fuzzing module in accordance with a schedule stored in the scheduler, and the scheduler message broker is configured with the ability to generate and send scan requests containing the address of a web resource and a list of input data for fuzzing to the web fuzzing module, and the web fuzzing module is configured with the ability to: - performing fuzzing of the web resource located at the received address, using the received list of input data; - sending fuzzing results to the scheduler message broker.

19. The system according to item 15, characterized in that the scheduler is configured with the ability to transfer exploits with the “other” marker to the exploit launcher module in accordance with a schedule stored in the scheduler, wherein the exploit launcher module includes a plurality of container engines configured with the ability to: - listening to the scheduler message broker queue; - receiving exploits from the scheduler message broker; - launching the obtained exploit; - sending the results of running the exploit to the scheduler message broker.

20. The system according to item 11, characterized in that the scheduler is configured with the ability to check for updates in the task list at a certain frequency; updates in the task list are checked, and when a new task appears, the scheduler is configured with the ability to launch a new task in a coroutine and write the new task to the task dictionary, and if there are updates, the scheduler is configured with the ability stopping the old task and creating a new task.

Images