PENETRATION TESTING OF A NETWORKED SYSTEM

BACKGROUND

There is currently a proliferation of organizational networked systems. Every type of organization, be it a commercial company, a university, a bank, a government agency or a hospital, heavily relies on one or more networks interconnecting multiple computing nodes. Failures of the networked system of an organization or even of only a portion of it might cause a significant damage, up to completely shutting down all operations. Additionally, much of the data of the organization (and for some organizations even all data) exists somewhere on its networked system, including all confidential data comprising its “crown jewels” such as prices, details of customers, purchase orders, employees' salaries, technical formulas, etc. Loss of such data or leaks of such data to outside unauthorized entities might be disastrous for the organization.

Many organizational networks are connected to the Internet at least through one network node, and consequently they are subject to attacks by computer hackers or by hostile adversaries. Even an organizational network that is not connected to the Internet might be attacked by an employee of the organization. Quite often the newspapers are reporting incidents in which websites crashed, sensitive data was stolen or service to customers was denied, where the failures were the results of hostile penetration into an organization's networked system.

Thus, many organizations invest a lot of efforts and costs in preventive means designed to protect their networked systems against potential threats. There are many defensive products offered in the market claiming to provide protection against one or more known modes of attack, and many organizations arm themselves to the teeth with multiple products of this kind.

However, it is difficult to tell how effective such products really are in achieving their stated goals of blocking hostile attacks, and consequently most CISO's (Computer Information Security Officers) will admit (maybe only off the record), that they don't really know how well they can withstand an attack from a given adversary. The only way to really know how strong and secure a networked system is, is by trying to attack it as a real adversary would. This is known as penetration testing (pen testing, in short), and is a very common approach that is even required by regulation in some developed countries.

Penetration testing requires highly talented people to man the testing team. Those people should be familiar with each and every known security vulnerability and attacking method and should also have a very good familiarity with networking techniques and multiple operating systems implementations. Such people are hard to find and therefore many organizations give up establishing their own penetration testing teams and resort to hiring external expert consultants for carrying out that role (or completely give up penetration testing). But external consultants are expensive and therefore are typically called in only for brief periods separated by long time intervals in which no such testing is done. This makes the penetration testing ineffective as security vulnerabilities caused by new forms of attacks that appear almost daily are discovered only months after becoming serious threats to the organization.

Additionally, even rich organizations that can afford hiring talented experts for in-house penetration testing teams do not achieve good protection. Testing for security vulnerabilities of a large networked system containing many types of computers, operating systems, network routers and other devices is both a very complex and a very tedious process. The process is prone to human errors of missing testing for certain threats or misinterpreting the damages of certain attacks. Also, because a process of full testing of a large networked system against all threats is quite long, the organization might again end with a too long discovery period after a new threat appears.

Because of the above deficiencies automated penetration testing solutions were introduced in recent years by multiple vendors. These automated solutions reduce human involvement in the penetration testing process, or at least in some of its functions.

A penetration testing process involves at least the following main functions: (i) a reconnaissance function, (ii) an attack function, and (ii) a reporting function. The process may also include additional functions, for example a cleanup function that restores the tested networked system to its original state as it was before the test. In an automated penetration testing system, at least one of the above three functions is at least partially automated, and typically two or three of them are at least partially automated.

A reconnaissance function is the function within a penetration testing system that handles the collection of data about the tested networked system. The collected data may include internal data of networks nodes, data about network traffic within the tested networked system, business intelligence data of the organization owning the tested networked system, etc. The functionality of a prior art reconnaissance function can be implemented, for example, by software executing in a server that is not one of the network nodes of the tested networked system, where the server probes the tested networked system for the purpose of collecting data about it.

An attack function is the function within a penetration testing system that handles the determination of whether security vulnerabilities exist in the tested networked system based on data collected by the reconnaissance function. The functionality of a prior art attack function can be implemented, for example, by software executing in a server that is not one of the nodes of the tested networked system, where the server attempts to attack the tested networked system for the purpose of verifying that it can be compromised.

A reporting function is the function within a penetration testing system that handles the reporting of results of the penetration testing system. The functionality of a prior art reporting function may be implemented, for example, by software executing in the same server that executes the functionality of the attack function, where the server reports the findings of the attack function to an administrator or a CISO of the tested networked system.

FIG. 1A (PRIOR ART) is a block diagram of code modules of a typical penetration testing system. FIG. 1B (PRIOR ART) is a related flow-chart.

In FIG. 1A, code for the reconnaissance function, for the attack function, and for the reporting function are respectively labelled as 20, 30 and 40, and are each schematically illustrated as part of a penetration testing system code module (PTSCM) labelled as 10. The term ‘code’ is intended broadly and may include any combination of computer-executable code and computer-readable data which when read affects the output of execution of the code. The computer-executable code may be provided as any combination of human-readable code (e.g. in a scripting language such as Python), machine language code, assembler code and byte code, or in any form known in the art. Furthermore, the executable code may include any stored data (e.g. structured data) such as configuration files, XML files, and data residing in any type of database (e.g. a relational database, an object-database, etc.).

In one example and as shown in FIG. 1B, the reconnaissance function (performed in step S21 by execution of reconnaissance function code 20), the attack function (performed in step S31 by execution of attack function code 30) and the reporting function (performed in step S41 by execution of reporting function code 40) are executed in strictly sequential order so that first the reconnaissance function is performed by executing code 20 thereof, then the attack function is performed by executing code 30 thereof, and finally the reporting function is performed 40 by executing code thereof. However, the skilled artisan will appreciate that this order is just one example, and is not a requirement. For example, the attack and the reporting functions may be performed in parallel or in an interleaved way, with the reporting function reporting first results obtained by the attack function, while the attack function is working on additional results. Similarly, the reconnaissance and the attack functions may operate in parallel or in an interleaved way, with the attack function detecting a vulnerability based on first data collected by the reconnaissance function, while the reconnaissance function is working on collecting additional data.

FIG. 1A also illustrates code of an optional cleanup function which is labeled as 50. Also illustrated in FIG. 1B is step S51 of performing a cleanup function—e.g. by cleanup function code 50 of FIG. 1A.

“A campaign of penetration testing” is a specific run of a specific test of a specific networked system by the penetration testing system.

A penetration-testing-campaign module may comprise at least part of reconnaissance function code 20, attack function code 30 and optionally cleanup function code 50—for example, in combination with suitable hardware (e.g. one or more computing device 110 and one or more processor(s) 120 thereof) for executing the code.

FIG. 2 illustrates a prior art computing device 110 which may have any form-factor including but not limited to a laptop, a desktop, a mobile phone, a server, a tablet, or any other form factor. The computing device 110 in FIG. 2 includes (i) computer memory 160 which may store code 180; (ii) one or more processors 120 (e.g. central-processing-unit (CPU)) for executing code 180; (iii) a human-interface device 140 (e.g. mouse, keyboard, touchscreen, gesture-detecting apparatus including a camera, etc.) or an interface (e.g. USB interface) to receive input from a human-interface device; (iv) a display device 130 (e.g. computer screen) or an interface (e.g. HDMI interface, USB interface) for exporting video to a display device and (v) a network interface 150 (e.g. a network card, or a wireless modem).

Memory 160 may include any combination of volatile (e.g. RAM) and non-volatile (e.g. ROM, flash, disk-drive) memory.

Code 180 may include operating-system code—e.g. Windows®, Linux®, Android®, Mac-OS ®.

Computing device 110 may include a user-interface for receiving input from a user (e.g. manual input, visual input, audio input, or input in any other form) and for visually displaying output. The user-interface (e.g. graphical user interface (GUI)) of computing device 110 may thus include the combination of HID device 140 or an interface thereof (i.e. in communication with an external HID device 140), display device 130 or an interface thereof (i.e. in communication with an external display device), and user-interface (UI) code stored in memory 160 and executed by one or more processor(s) 120. The user-interface may include one or more GUI widgets such as labels, buttons (e.g. radio buttons or check boxes), sliders, spinners, icons, windows, panels, text boxes, and the like.

In one example, a penetration testing system is the combination of (i) code 10 (e.g. including reconnaissance function code 20, attack function code 30, reporting function code 40, and optionally cleaning function code 50); and (ii) one or more computing devices 110 which execute the code 10. For example, a first computing device may execute a first portion of code 10 and a second computing device (e.g. in networked communication with the first computing device) may execute a second portion of code 10.

FIGS. 3 and 4A-4D relate to a prior art example of penetration testing of a networked system. FIG. 3 shows a timeline—i.e. the penetration test begins at a time labelled as T_{Begin Pen-Test}. Subsequent points in time, during the penetration test, are labelled in FIG. 3 as T¹_{During Pen-Test}, T²_{During Pen-Test}and T³_{During Pen-Test}.

FIG. 4A shows an example networked system comprising a plurality of 24 network nodes labelled N101, N102 . . . N124. In the present document, a network node may be referred to simply as ‘node’—‘network node’ and ‘node’ are interchangeable.

Each network node may be a different computing device 110. Two network nodes are “immediate neighbors” of each other if and only if they have a direct communication link between them that does not pass through any other network node.

In the example of FIG. 4A, this is represented by an edge between the two nodes—thus, in this example nodes N108 and N112 are immediate neighbors while nodes N108 and N115 are not immediate neighbors.

Embodiments of the invention relate to penetration testing of networked systems, such as that illustrated in FIG. 4A.

During penetration testing, a node may become compromised. In the examples of FIGS. 4A-4D compromised nodes are indicated by an “X” in the circle—all other nodes have not yet been compromised.

The term “compromising a network node” is defined as: Successfully causing execution of an operation in the network node that is not allowed for the entity requesting the operation by the rules defined by an administrator of the network node, or successfully causing execution of code in a software module of the network node that was not predicted by the vendor of the software module. Examples for compromising a network node are reading a file without having read permission for it, modifying a file without having write permission for it, deleting a file without having delete permission for it, exporting a file out of the network node without having permission to do so, getting an access right higher than the one originally assigned without having permission to get it, getting a priority higher than the one originally assigned without having permission to get it, changing a configuration of a firewall network node such that it allows access to other network nodes that were previously hidden behind the firewall without having permission to do it, and causing execution of software code by utilizing a buffer overflow. As shown by the firewall example, the effects of compromising a certain network node are not necessarily limited to that certain network node. In addition, executing successful ARP spoofing, denial-of-service, man-in-the-middle or session-hijacking attacks against a network node are also considered compromising that network node, even if not satisfying any of the conditions listed above in this definition.

According to the example illustrated in FIGS. 4A-4D, initially, at time T_{Begin Pen-Test}, when the penetration test begins, none of the network-nodes have yet been compromised. Between time T_{Begin Pen-Test}and T¹_{During Pen-Test}, network node N122 is compromised—this is indicated in FIG. 4B by the “X.' Between time T¹_{During Pen-Test}and T²_{During Pen-Test}, network nodes N116 and N112 are compromised, as indicated by the X's in FIG. 4C. Between time T²_{During Pen-Test}and T³_{During Pen-Test}, network nodes N110 and N111 are compromised, as indicated by the X's in FIG. 4D.

In this particular example, it is assumed that it is easier for an attacker to compromise a node if one or more of its immediate neighbors has been compromised.

When a user desires to operate a prior art penetration testing system for running a test on a specific networked system, the penetration testing system must know what test it should execute. For example, the penetration testing system must know what is the type of attacker against whom the test is making its assessment (a state-sponsored actor, a cyber criminal etc.) and what are his capabilities. As another example, the penetration testing system must know what is the goal of the attacker according to which the attack will be judged as a success or a failure (copying a specific file and exporting it out of the tested networked system, encrypting a specific directory of a specific network node for ransom, etc.).

A specific run of a specific test of a specific networked system by a penetration testing system is called a “campaign” of that penetration testing system and entails performing at least the reconnaissance (step S21 of FIG. 1B), attack (step S31 of FIG. 1B) and reporting (step S41 of FIG. 1B) functions. A collection of values for all information items a penetration testing system must know before executing a campaign is called “specifications of the campaign” or “scenario”. For example, the type of the attacker and the goal of the attacker are specific information items of a campaign, and specific values for them are parts of the specifications of any campaign.

The results of the penetration testing campaign may be reported by performing the reporting function (step S41) of FIG. 1B.

All prior art penetration testing systems are not flexible in letting the user define the specifications of a campaign. Typically, those systems are delivered with a library of pre-defined campaign specifications from which the user should choose.

Some prior art penetration testing systems provide slightly better flexibility by allowing the user to select a scenario based on explicit selection of the type of the attacker. The user may be presented with a closed list of alternatives for the type of the attacker—a state-sponsored actor, a cyber criminal, an amateur hacker, etc., and he may choose one of those alternatives. Once the user picks one of the listed alternatives, the system selects a pre-defined scenario whose type of attacker is the same as the picked alternative. All other fields of the specifications of the campaign (goal of the attacker, capabilities of the attacker, etc.) are automatically decided either by the selected pre-defined scenario or by internal algorithms of the penetration testing system, with no explicit input from the user. The internal algorithms may depend on the user-selected type of attacker and/or on pre-defined information items of the selected pre-defined scenario, and/or on a random process. For example, the capabilities of the attacker may be automatically defined based on the type of the attacker, while the lateral movement strategy of the attacker may be picked at random from a pre-defined list of available strategies.

This rigid campaign definition is not satisfactory for many users, who would like to have greater control over the specifications of the campaigns they run for testing their networked systems. Such control will allow them to test specific combinations of features of scenarios, which might be impossible to test with prior art systems.

FIG. 32 illustrates one example of a networked system 200 that may be subjected to penetration testing. The networked system comprises a plurality of nodes—in the example of FIG. 32, 16 nodes are illustrated, each labeled by the letter “N” followed by an integer. Also illustrated in FIG. 32 are two external computing devices 254, 252 that reside outside the networked system 200. Computing device 254 resides ‘in the cloud’ relative to the networked system 200, while computing device 252 is in communication with the networked system 200 via a local-area network (LAN).

Both of nodes 254 and 252 are “networked system external”—i.e. outside of networked system 200. The term ‘networked system external’ is abbreviated as “NS-external”.

In the present document, a network node may be referred to simply as ‘node’—‘network node’ and ‘node’ are interchangeable. Each network node may be different a computing device 110 illustrated in FIG. 2.

A Discussion of Actual Attack vs. Simulated Attack

All prior art penetration testing systems can be characterized as doing either an “actual attack penetration testing” or as doing a “simulated penetration testing”.

A prior art actual attack penetration testing system does its penetration testing by accessing and attempting to attack the tested networked system. Such a system actually accesses the tested networked system during the test and is not limiting itself to simulation. This includes (i) collecting data by the reconnaissance function about the tested networked system and its components by actively probing it. The probing is done by sending queries or other messages to one or more network nodes of the tested networked system, and then deducing information about the tested networked system from the received responses or from network traffic triggered by the queries or the messages. The reconnaissance function is fully implemented by software executing outside the tested networked system or by software executing in one or more network nodes of the tested networked system that analyze network traffic and network packets of the tested networked system, and (ii) verifying that the tested networked system can be compromised by actively attempting to compromise it and checking if it was indeed compromised. This implies that a side-effect of executing an actual attack penetration test might be actually compromising the tested networked system. Typically, prior art actual attack penetration testing systems include a function of cleanup and recovery at the end of the test, in which any compromising operation that was done during the test is undone.

A prior art simulated penetration testing system does its penetration testing by avoiding disturbance to the tested networked system and specifically by avoiding any risk of compromising it. This implies, among other things, that (i) no installation of software agents of any kind on network nodes of the tested networked system is allowed, and (ii) whenever there is a need to verify that the tested networked system can be compromised by an operation or a sequence of operations, the verification is done by simulating the results of that operation or sequence of operations or by otherwise evaluating them, without taking the risk of actually compromising the tested networked system. Some prior art simulated penetration testing systems implement the simulation by duplicating all or parts of the hardware of the tested networked system. Then when there is a need for verifying that an operation or a sequence of operations compromises the tested networked system, this is done by actually attacking the duplicated system without risking the tested system. While this implementation achieves the goal of avoiding the risk of not compromising the tested networked system, it is highly expensive and also difficult to accurately implement, and therefore rarely used.

While the prior art automated penetration testing systems provide great advantages over manual penetration testing systems, they still do not provide a fully satisfactory solution, as they suffer from some deficiencies, examples of which are explained below.

Prior art automated penetration testing systems face difficulties in their reconnaissance function's ability to collect internal data of network nodes. Internal data of a network node is data that is only directly accessible to code executing by a processor of that network node. This may include, for example, factual data about the network node such as the version of the firmware of a solid-state drive installed in that network node. Unless the internal node was already compromised by the penetration testing system, it might be difficult or even impossible for it to determine such internal fact. A human hostile attacker may gain knowledge of such fact by indirect means—for example if he had previously been an employee of the organization owning the tested networked system, or if he is an employee of the vendor supplying the organization with solid-state drives. Once the attacker possesses knowledge of the fact, he might use it to advantage for compromising the network node and consequently compromising the networked system. But a prior art penetration testing system that does not have access to that internal data of the network node might miss the detection of a security vulnerability related to a specific firmware version. This deficiency is mainly problematic for simulated penetration testing systems, but is also relevant to actual attack penetration testing systems, as even active probing by the penetration testing system may not be enough for obtaining internal data of a network node that was not yet compromised when the attempt to probe is performed from outside of the probed network node.

Another deficiency is relevant only to actual attack penetration testing systems that might actually compromise the tested networked system during the test. This characteristic of actual attack penetration testing systems is by itself a security vulnerability. As the testing process might compromise the networked system, there is a risk that the recovery function of the penetration testing system, that is supposed to undo the compromising and make the tested networked system safe again, might fail in fully doing that, and the tested networked system might be left with one or more compromised components without the CISO of the owning organization being aware of it. Additionally, even if the penetration testing system's recovery function is faultless, the testing still makes the tested networked system vulnerable and exposed to attacks during the test, before the recovery function is activated.

Another deficiency of an actual attack penetration testing system is that it cannot answer “what if” questions, as one cannot attack a configuration that does not exist in the real world. For example, a CISO of an organization may want to find out whether adding a new security tool will indeed improve his networked system's immunity to attacks. Or to find how much would the immunity degrade if he will remove an existing security tool that costs a lot of money in licensing fees. In both cases an actual attack penetration testing system cannot answer the question. Another example is determining the vulnerability of a networked system against a new type of attack whose existence is known, but its detailed implementation is not yet known. Again, an actual attack penetration testing system cannot make such determination.

Prior art automated penetration testing systems can successfully detect many types of vulnerabilities in the tested networked system. However, they have difficulty in detecting an important class of vulnerabilities, termed herein “opportunistic vulnerabilities”.

An “opportunistic vulnerability” is a security vulnerability that becomes available to attackers only after an occurrence of a specific event. In many cases, an opportunistic security vulnerability remains available to attackers only for a limited time interval, and once that time interval is over, the vulnerability is no longer available to them. However, in some cases an opportunistic vulnerability remains available to attackers with no time limit.

In some cases the availability of the vulnerability to the attackers is created by the occurrence of the event—for example when a transmission of a network message creates the weakness making an attack possible. In other cases, the availability of the vulnerability to attackers is not created by the occurrence of the event, but rather exists beforehand, and the occurrence of the event makes the existing vulnerability known to the attackers.

A specific event that triggers the availability of a specific opportunistic vulnerability is said to be an event “associated with” that specific opportunistic vulnerability, and the specific opportunistic vulnerability is said to be an opportunistic vulnerability “associated with” that specific event.

A specific event that triggers the availability of a specific opportunistic vulnerability may trigger that availability unconditionally. That is—the specific opportunistic vulnerability will become available to attackers following every occurrence of the specific event. However, it may also be the case that the specific event might sometimes trigger the specific opportunistic vulnerability and sometimes not trigger it, depending on some condition.

An event is said to be associated with an opportunistic vulnerability and an opportunistic vulnerability is said to be associated with an event if the event may trigger the opportunistic vulnerability, regardless if the triggering relation is conditional or unconditional. In the first case we say that the event is “unconditionally associated” with the opportunistic vulnerability, and in the second case we say that the event is “potentially associated” or “conditionally associated” with the opportunistic event. As a result of the above, detecting an event that is associated with an opportunistic vulnerability does not necessarily imply that the vulnerability will be available to the attacker in a future occurrence of the event. In order to conclude that the opportunistic vulnerability will indeed be available to the attacker for a future occurrence of the event, it must be determined that the condition enabling the triggering of the vulnerability by the event (if such exists) is satisfied.

A time interval during which a specific opportunistic vulnerability is available to attackers (if such limiting time interval exists for that specific opportunistic vulnerability) is said to be a time interval “associated with” that specific opportunistic vulnerability.

A time interval associated with an opportunistic vulnerability may be of a fixed length for all occurrences of the event associated with that opportunistic vulnerability, or it may have different length in different occurrences of the associated event and be terminated by the occurrence of another event that makes the use of the vulnerability to attackers no longer possible.

As one example of an opportunistic vulnerability, it might be the case that a bug in a storage driver causes a buffer overflow to occur in a certain network node whenever a USB storage device in inserted into a USB port of the network node, if the volume name of the storage device is longer than a certain length. Thus, the event of the insertion of the storage device having a volume name of a specific length may create an opportunity which attackers may exploit for compromising that network node, an opportunity that ceases to exist after any access to the inserted storage device.

Another example of an opportunistic vulnerability is when a transmission by a network node of a certain message type of a certain network protocol creates an opportunity for attackers to respond with a malicious reply message, which leads to compromising of the network node. In this example, the opportunity for the attacker is triggered by the event of transmission of the first message and is only available to the attacker until a true addressee of the first message responds to the message.

Many prior art penetration testing systems detect vulnerabilities by blindly attempting to compromise a network node without having certainty, in advance, whether the attempted vulnerability indeed compromises the attacked node. Clearly, vulnerabilities of the opportunistic type create a problem for such penetration testing systems. Since an event triggering the opportunistic vulnerability may occur at random, and the window of opportunity for attackers to exploit the opportunistic vulnerability may be limited, it is quite likely that an attempted “blind attack” by a penetration testing system will fail to detect the vulnerability. This is particularly true when the window of opportunity is short, as is the case in many real-life opportunistic vulnerabilities, including many of the examples provided herein. Thus, the prior art testing system would not detect that opportunistic vulnerability, while in reality the network node is subject to a threat of being compromised by a sophisticated attacker that knows how to time his attack to occur within the window of opportunity opened by the triggering event. Such an attacker might lay dormant while monitoring the network node for an occurrence of the triggering event, and upon detection of such an event, may exploit the newly created opportunistic vulnerability while the window of opportunity is still open.

Even penetration testing systems that use simulation instead of actual attacks face difficulties when trying to detect opportunistic vulnerabilities. In order to conclude that a given network node is prone to a given opportunistic vulnerability, it is necessary to determine that the event associated with the opportunistic vulnerability that triggers the vulnerability to occur may actually occur in the given network node. For example, if the triggering event of an opportunistic vulnerability is a transmission of a certain type of message of a certain network protocol out of the given network node, it might be the case that the given network node, even though theoretically prone to that vulnerability, in reality never uses the certain network protocol or never uses the certain type of message triggering the vulnerability. It may be possible to make an educated guess by the penetration testing system as to whether the triggering message is in actual use based on the applications installed in the network node and what versions they are, but this is quite difficult to do, and even under best case circumstances does not provide certainty.

The problems faced by prior art penetration testing systems when dealing with opportunistic vulnerabilities are even more severe when the event associated with the opportunistic vulnerability is a free event.

A “free event of a network node” is an event occurring in a network node of the networked system, which event is initiated in and by the node in which it occurs, and is not directly caused or triggered by an entity outside that node.

An occurrence of a free event in a network node may be triggered by:

- i. A user of the node—for example by the user inserting a USB thumb drive or submitting a query to a web server.
- ii. An operating system of the node—for example, by the operating system sending a request message according to the ARP (Address Resolution Protocol) protocol in order to find out which MAC (Media Access Control) address (e.g. Ethernet address) corresponds to a given IP address.
  - According to the ARP protocol, a first network node that wants to communicate with a second node located on the same local network, but knows only the IP address of the second node and not its MAC address (i.e. the required translation of the second node's IP address to its MAC address is not found in the address matching cache of the first node), submits an ARP request message containing its own MAC and IP addresses and the known IP address of the second node. In response, the second node is expected, when identifying its IP address in the ARP request message, to send an ARP reply message containing its own MAC and IP addresses as well as the MAC and IP addresses of the first node that sent the ARP request. Upon identifying that the reply is addressed to it, the first node can extract from the reply the previously unknown MAC address of the second node, store it in its address matching cache for later use, and use the MAC address for communicating with the second node.
- iii. An application executing on the node—for example, a browser sending a message according to the WPAD (Web Proxy Auto-Discovery) protocol in order to find out a configuration file that determines a proxy server for a target URL.
  - According to the WPAD protocol, a network node that needs to determine the right proxy server for a target URL submits a WPAD message according to the DHCP (Dynamic Host Configuration Protocol) or the DNS (Domain Name System) protocols. The node expects to receive back an answer from a DHCP server or a DNS server containing a URL directing it to a configuration file, which in turn directs the node to the right proxy server for the target URL.

As elaborated herein below, all the above free event examples are associated with opportunistic vulnerabilities. In other words, each of the free events of the above examples may trigger a security vulnerability that creates an opportunity for a hostile attacker to compromise the network node, where the vulnerability becomes available to the attacker after the occurrence of the free event and because of it.

For example, when a user submits a query to a web server within the networked system that is already compromised by the attacker, the attacker can use the opportunity to compromise the node making the submission. The web server, which is under control of the attacker, may construct an answer page (for example an HTML page) that contains malicious code, that when rendered by the browser of the querying node compromises that node.

As another example, when an operating system of a first node transmits into the network an ARP request message asking for the MAC address of a second node having a given IP address, a third node, that is under the control of an attacker, might use the opportunity to perform “ARP spoofing”. This may be accomplished by the third node responding to the ARP request message before the true addressee of the message (the second node) does so. The false response provided by the third, compromised, node will be a formally-valid ARP reply message that includes a false MAC address belonging to the third node, or to another compromised node. As a result, the false MAC address will be used by the first node for communicating with what it believes to be the second node, while in reality the first node will be communicating with a compromised node which is controlled by the attacker. This might lead to a successful denial-of-service, man-in-the-middle, or session-hijacking attack, thus compromising the first node by the attacker.

As still another example, when a browser running on a first node transmits into the network a WPAD message asking to determine a proxy server for a target URL to which it wants access, a second node that is under the control of the attacker might use the opportunity and respond to the message, before any valid addressee of the message (which is a valid DHCP or DNS server) does so. This false response might include a false URL leading to a false configuration file that in turn determines a false proxy server that is under the control of the attacker. From now on, all communications the first node believes it is directing to the target URL are actually sent to the false proxy server, which is controlled by the attacker. As in the previous example, this might lead to compromising of the first node by the attacker.

As still another example, when a user inserts a USB thumb drive into a USB port of a first node, it may be determined that the currently inserted USB thumb drive is the same device that was previously detected being inserted into a USB port of a second network node (i.e. the same device serial number is detected in both cases) that is already compromised by an attacker. This finding implies that the user may be moving the USB thumb drive back and forth between the two nodes. The attacker may rely on this finding to compromise the first node, by making the second node download a malicious file onto the USB thumb drive the next time it is inserted into the second node, such that when the USB thumb drive will later be inserted into the first node, the first node will be compromised by the poisoned file.

In addition to the difficulties explained above for all opportunistic vulnerabilities, additional difficulties exist when a prior art penetration testing system has to detect an opportunistic vulnerability associated with a free event, because the triggering event is a free event. The additional difficulties arise from the fact that free events are asynchronous relative to the testing process, and cannot be generated or caused from outside of the targeted network node.

Additional difficulties are caused to prior art penetration testing systems when these have to detect an opportunistic vulnerability associated with an event that is an internal event of a network node. The additional difficulties arise from the fact that internal events are, by their nature, impossible to directly detect by software executing on a remote computing device that is separate from the targeted network node.

Thus, there is need in the art for an automatic penetration testing solution that efficiently and correctly handles opportunistic vulnerabilities, and especially opportunistic vulnerabilities that have free events associated with them.

Every penetration testing system operates by iteratively (physically or simulatively) compromising network nodes of the tested networked system. At any iteration during the testing process some of the network nodes of the tested networked system are considered to be already compromised by the potential attacker, and the penetration testing system is attempting to compromise an additional network node (not yet compromised) by utilizing the already-compromised network nodes that are operating under the control of the attacker's instructions. Once an additional network node is found to be compromisable, it is added to the group of already-compromised network nodes and a new iteration begins.

As a hypothetical example, there might be malicious code circulating in cyberspace and available to potential attackers known as the “Bad 7 Trojan”. This Bad 7 Trojan only compromises nodes running the Windows 7® Operating System under a specific set of circumstances, discussed below.

A penetration testing system has a frequent need to identify a vulnerability that would compromise a given network node. This identification is typically achieved by using a pre-compiled knowledge base about known vulnerabilities, that depends on characteristics of the given network node. In one example related to the Bad 7 Trojan, the penetration testing system may have in its knowledge base a rule saying that a network node running the Windows 7 Operating System might be compromised by sending it a specific network message through a specific Internet port.

However, knowing that a target network node might be compromised by a specific vulnerability is not the same as knowing for sure it would be compromised by that specific vulnerability under the current specific conditions in the target network node. For example, the target network node may have installed on it a patch provided by Microsoft for making the Windows 7 Operating System immune to that vulnerability—i.e. immune to the Bad 7 Trojan. Or the administrator of the target network node may have disabled the service that is typically using the specific Internet port (i.e. port number “XYZ”) used by the specific vulnerability (i.e used by the Bad 7 Trojan) and therefore the network node is currently not listening to that specific port and is thus currently not vulnerable to anything sent to it through that specific port. Additionally, even if a target network node would be compromised by the specific vulnerability under the current conditions if it receives a certain network message through the specific port (i.e. causing the node to execute the code of the Bad 7 Trojan), it might still be the case that a firewall that is protecting the target network node is blocking the damaging network message from reaching the specific port of the target network node, thus making it non-compromisable in practice.

Therefore, it is clear that without detailed knowledge about what is going on inside the target network node it is not always possible to know for sure whether a given potential vulnerability would compromise a given network node under current conditions. This is a major issue for penetration testing systems that need to know for sure that a given network node could be compromised before reporting a penetration success. As a result, when a penetration testing system determines that a given vulnerability might compromise a given network node, it has to find a way of validating that this is indeed so under current conditions.

The common approaches adopted by prior art penetration testing systems are:

a. Validating by actual attack—testing whether the given vulnerability succeeds in compromising the target network node by actually attempting to compromise the target network node using the vulnerability, and then finding out if the network node was indeed compromised.

b. Validating by simulation or by evaluation—testing whether the given vulnerability succeeds in compromising the target network node either by simulating the tested networked system and attempting to compromise it using the vulnerability in the simulation, or by evaluating the success/failure of applying the vulnerability by using pre-compiled knowledge about the vulnerability plus fresh data about current conditions in the target network node. In both cases the validation is done without actually attempting to compromise the tested networked system.

None of the above approaches provides a fully satisfactory solution to the validation problem. The actual attack method has the severe drawback of risking actually compromising the tested networked system. Even though penetration testing systems employing this method attempt to undo any compromising operations they performed during the test, it is difficult to guarantee that full recovery will always be achieved. The simulation/evaluation method has the drawback of sometimes lacking knowledge of data that is essential for reaching a correct result. If the condition for successful compromising depends on data that is internal to the target network node (for example the version of the firmware of a storage device internal to the node), then the method cannot reliably validate the success of the compromising by the vulnerability.

A possible remedy to the drawback of the simulation/evaluation method is to employ a reconnaissance client agent for collecting information about the target network node. A reconnaissance client agent is a software module that can be installed on a network node and can be executed by a processor of that network node for partially or fully implementing the reconnaissance function of a penetration test. The reconnaissance function is the function that is in charge of the collection of data useful for the penetration testing process, and this may include the collection of data that is internal to the network node in which the agent is installed.

As an example, US Application No. 2016/0044057 (hereinafter “057 application” or '057) to Chenette et al. discloses a penetration testing system that uses an agent software module installed in the target node (called “server” in '057), that is in charge of validation of vulnerabilities in that target node. When the penetration testing system of '057 needs to verify that a given vulnerability can compromise the target node under current conditions, an exploit payload is sent to the target node where the exploit contains code implementing the vulnerability. The agent installed on the target node receives the payload, but instead of attempting to execute the code (which would expose us to the danger of compromising the networked system by the testing process), it examines the code and determines whether the target node would have been compromised by executing it, taking into account the current state of the node and the defenses currently in place in it. As a client agent has access to internal data of the node in which it is installed, this solution solves the problem from which other evaluation-based penetration testing systems suffer, as explained above.

However, the solution of '057 suffers from other drawbacks. The client agent of '057 has to validate every type of vulnerability that is potentially applicable to the node on which it is installed. For each such vulnerability, it must implement logic for determining whether that vulnerability will succeed in compromising the node under current conditions. This logic is specific for each vulnerability and is not always simple and straight-forward. Therefore, when the number of potential vulnerabilities is high, as is usually the case, the complexity and code size of the client agent become high too. While penetration testing systems are complex systems, it is highly desirable that their complexity will reside in the central server from which the testing sessions are initiated and controlled, and will not be duplicated in code installed on each one of the many network nodes taking part in the test. Moreover, new vulnerabilities are discovered on almost a daily basis and require very frequent updates of the vulnerabilities validation logic of penetration testing systems. Having to frequently update the locally-installed agents in the many nodes of a tested networked system is a logistic nightmare and should better be avoided.

One additional drawback of the '057 method is that it relies on sending to the target node code or some other representation of the potential vulnerability. It is not always the case that a vulnerability is known to the penetration testing system with such detail. In many cases a newly-discovered vulnerability is known in general terms but not much detail is known about its implementation. In such case the agent-based '057 method cannot be used for validating success in compromising the target node by newly-discovered vulnerabilities.

There is thus a need for validating that a given vulnerability will indeed compromise a given node under current conditions, without suffering from the drawbacks described above.

In this disclosure, the phrase ‘active method of validation’ (or the equivalent ‘active method’) is used in connection with validation methods using actual attack. Similarly, the phrase ‘passive method of validation’ (or the equivalent ‘passive method’) is used in connection with validation methods using simulation or other type of evaluation.

U.S. Pat. No. 10,038,711 discloses penetration testing systems that employ reconnaissance agent penetration testing. Such penetration testing systems are characterized by using a reconnaissance agent software module installed on some network nodes of the tested networked system, where the instances of the reconnaissance agent take part in implementing the reconnaissance function. With regard to verifying that the tested networked system can be compromised by an operation or a sequence of operations, reconnaissance agent penetration testing systems may use either actual attack methods (active validation) or simulation/evaluation methods (passive validation).

This section is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the information anywhere in this background section (in particular, that U.S. Pat. No. 10,038,711) constitutes prior art against the present invention.

As explained above, every penetration testing system operates by iteratively compromising (physically or by simulation/evaluation) network nodes of the tested networked system. At any iteration during the testing process some of the nodes of the tested networked system are considered to be already compromised by the potential attacker, and the penetration testing system is attempting to compromise one or more additional network nodes (not yet compromised) by utilizing the already-compromised nodes that are operating under the control of the attacker's instructions. Once an additional network node is found to be compromisable, it is added to the group of already-compromised nodes and a new iteration begins.

Thus, a penetration testing system has a frequent need to identify a vulnerability that would compromise a given network node. This identification is typically achieved by using a pre-compiled knowledge base about known vulnerabilities, that depends on characteristics of the given network node. For example, the penetration testing system may have in its knowledge base a rule saying that a network node running the Windows 7 Operating System might be compromised by sending it a specific network message through a specific Internet port.

However, knowing that a node might be compromised is not the same as knowing for sure it would be compromised by the examined vulnerability under current conditions. For example, the target node may have installed on it a patch provided by Microsoft for making the Windows 7 Operating System immune to that vulnerability. Or the administrator of the target node may have disabled the service that is typically using the specific Internet port and therefore the node is currently not listening to that specific Internet port and is thus currently not vulnerable to anything sent to it through that specific Internet port.

Therefore, it is clear that without detailed knowledge about what is going on inside the target node it is not always possible to know for sure whether a given potential vulnerability would compromise a given network node under current conditions. This is a major issue for penetration testing systems, that need to know for sure that a given node could be compromised before reporting a penetration vulnerability. As a result, when a penetration testing system determines that a given vulnerability might compromise a given network node, it has to find a way of validating that this is indeed so under current conditions.

As explained above, the common solutions adopted by prior art penetration testing systems are:

a. Validating by actual attack—testing whether the given vulnerability succeeds in compromising the given node by actually attempting to compromise the node by exploiting the vulnerability, and then finding out if the attempt was successful and the node was indeed compromised.

b. Validating by simulation or by other evaluation—testing whether the given vulnerability succeeds in compromising the given node by either simulating the tested networked system and attempting to compromise it by exploiting the vulnerability in the simulation, or by evaluating the success/failure of exploiting the vulnerability by using pre-compiled knowledge about the vulnerability plus data about current conditions in the network node. In both cases the validation is done without actually attempting to compromise the tested networked system and thus without risking an actual compromising of the network node.

Each of the above approaches has its drawbacks. The actual attack method has the severe drawback of risking actually compromising the tested networked system. Even though penetration testing systems employing this method attempt to undo any compromising operations they performed during the test, it is difficult to guarantee that full recovery will always be achieved. The simulation/evaluation method has the drawback of sometimes lacking knowledge of data that is essential for reaching a correct result. If the condition for successful compromising depends on data that is internal to the target node (for example the version of the firmware of a storage device internal to the node), then the method cannot reliably validate the success of the compromising by the vulnerability unless special arrangements are done in order to obtain the required information during the execution of the penetration testing campaign.

Prior art penetration testing systems are quite rigid regarding the validation approach they employ—a given penetration testing system either employs validation by actual attack or validation by simulation/evaluation. This implies:

a. For a given penetration testing campaign, there is no way of employing validation by actual attack for some potential vulnerabilities and validation by simulation/evaluation for other potential vulnerabilities.

b. For a given scenario template, there is no way of employing validation by actual attack for execution of some campaigns that are based on the scenario template and employing validation by simulation/evaluation for execution of other campaigns that are also based on the scenario template.

c. For a given tested networked system, there is no way of employing validation by actual attack for execution of some penetration testing campaigns and employing validation by simulation/evaluation for execution of other penetration testing campaigns, even when different campaigns are based on different scenario templates.

But in many situations a user of a penetration testing system may want to have more flexibility. For example:

a. A user may want to execute a penetration testing campaign in which some potential vulnerabilities are validated by actual attack, while other potential vulnerabilities are validated by simulation or evaluation.

As an example, the user may prefer to use validation by actual attack for most vulnerabilities because it provides better reliability for the validation conclusions, but for some specific vulnerabilities would like to use validation by simulation/evaluation because the damage to the tested networked system in case an actual attack exploiting any of these specific vulnerabilities turns out to be successful (e.g. a shutdown of the network node) is unacceptable and therefore cannot be risked.

As another example, the user may prefer to use validation by simulation/evaluation for most vulnerabilities because it is important not to risk compromising the tested networked system, but for some specific vulnerabilities would like to use validation by actual attack because the importance of the resources put at risk by these specific vulnerabilities (e.g. password files) is so high that the most reliable validation conclusions are desired, even at the cost of risking the compromising of the tested networked system during the test (e.g. by exporting a password file to the penetration testing system, which may be under the control of the organization owning the tested networked system, and thus causing no real damage when being compromised during the penetration test).

b. A user may want to execute multiple penetration testing campaigns where all campaigns are based on the same scenario template, when some of the campaigns employ validation by actual attack, while other campaigns employ validation by simulation/evaluation.

As an example, the user may prefer to use validation by actual attack for most of the campaigns because this provides better reliability for the validation conclusions, but for some specific campaigns would like to use validation by simulation/evaluation because at the time of those specific runs a flawless operation of the tested networked system is critical and no risk of the system being compromised can be taken.

As another example, the user may prefer to use validation by simulation/evaluation for most of the campaigns because it is important not to risk compromising the tested networked system, but for some specific campaigns would like to use validation by actual attack because it is desired to get the most reliable validation conclusions once in a while, even at the cost of risking the compromising of the tested networked system.

c. A user may want to execute some penetration testing campaigns while employing validation by actual attack, and to execute some other penetration testing campaigns while employing validation by simulation/evaluation (where different campaigns are based on different scenario templates).

As an example, for some campaigns which are set with the goal of the attacker being exporting certain files out of the tested networked system, the user may accept the risk of compromising the networked system and wish to employ validation by actual attack, as the damage at risk is not critical (at least when the penetration testing system, which is the receiver of the exported files, is under control of the organization owning the tested networked system). For other campaigns which are set up with the goal of the attacker being damaging of certain files, the user may not agree to accept the risk and therefore wishes to employ validation by simulation/evaluation.

There is thus a need for providing users of penetration testing systems with greater flexibility in controlling the method of validation of potential vulnerabilities employed during the penetration testing process.

SUMMARY OF EMBODIMENTS

In some embodiments, the method is carried out so that before receiving the one or more manually-entered inputs that explicitly select the one or more capabilities of the attacker, the penetration testing system automatically computes and displays an explicit recommendation for selecting the one or more capabilities of the attacker.

In some embodiments, the received one or more manually-entered inputs comprises an explicit user approval of the explicit recommendation.

In some embodiments, further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the one or more capabilities of the attacker, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a value for a second information item of the penetration testing campaign, wherein the second information item is not a capability of the attacker.

In some embodiments, the executing of the penetration testing campaign is performed using both (i) the manually and explicitly selected value for the second information item, and (ii) the manually and explicitly selected one or more capabilities of the attacker.

In some embodiments, further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the one or more capabilities of the attacker, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a method of one of the manually and explicitly selected one or more capabilities of the attacker.

In some embodiments, the executing of the penetration testing campaign is performed using both (i) the manually and explicitly selected one or more capabilities of the attacker, and (ii) the manually and explicitly selected method.

A system for penetration testing of a networked system, the system comprising: a. an attacker-capability-selection user interface including one or more user interface components for manual and explicit selection of one or more capabilities of an attacker of a penetration testing campaign; b. a penetration-testing-campaign module programmed to perform the penetration testing campaign whose attacker has the one or more capabilities that are manually and explicitly selected via the attacker-capability-selection user interface; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the system further comprises a recommendation module configured to automatically compute an explicit recommendation for selecting the one or more capabilities of the attacker, wherein the attacker-capability-selection user interface displays the explicit recommendation.

In some embodiments, the system is configured so that the manual and explicit selection of the one or more capabilities of the attacker includes a manual and explicit approval of the explicit recommendation.

In some embodiments, the system further comprises a second user interface including one or more user interface components for manual and explicit selection of a value of a second information item of the penetration testing campaign, the second information item being other than a capability of the attacker, wherein the system is configured to receive the manual and explicit selection of the value of the second information item subsequent to the manual and explicit selection of the one or more capabilities.

In some embodiments, the penetration-testing-campaign module is configured, subsequent to the manual and explicit selection of both (i) the one or more capabilities of the attacker and (ii) the value of the second information item, to perform the penetration testing campaign using both (i) the manually and explicitly selected one or more capabilities of the attacker and (ii) the manually and explicitly selected value of the second information item.

In some embodiments, the system further comprises a second user interface including one or more user interface components for manual and explicit selection of a method of one capability of the manually and explicitly selected one or more capabilities of the attacker of the penetration testing campaign, wherein the system is configured to receive the manual and explicit selection of the method of the one capability subsequent to the manual and explicit selection of the one capability.

In some embodiments, the penetration-testing-campaign module is configured, subsequent to the manual and explicit selection of both (i) the one or more capabilities of the attacker and (ii) the method of the one capability, to perform the penetration testing campaign using both (ii) the manually and explicitly selected one or more capabilities of the attacker and (ii) the manually and explicitly selected method of the one capability.

In some embodiments, the method is carried out so that before receiving the one or more manually-entered inputs that explicitly select the one or more traits of the attacker, the penetration testing system automatically computes and displays an explicit recommendation for selecting the one or more traits of the attacker.

In some embodiments, the received one or more manually-entered inputs comprises an explicit user approval of the explicit recommendation.

In some embodiments, the method further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the one or more traits of the attacker, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a value for a second information item of the penetration testing campaign, wherein the second information item is not a trait of the attacker.

A system for penetration testing of a networked system, the system comprising: a. an attacker-trait-selection user interface including one or more user interface components for manual and explicit selection of one or more traits of an attacker of a penetration testing campaign; b. a penetration-testing-campaign module programmed to perform the penetration testing campaign whose attacker has the one or more traits that are manually and explicitly selected via the attacker-trait-selection user interface; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the system further comprises a recommendation module configured to automatically compute an explicit recommendation for selecting the one or more traits of the attacker, wherein the attacker-trait-selection user interface displays the explicit recommendation.

In some embodiments, the system is configured so that the manual and explicit selection of the one or more traits of the attacker includes a manual and explicit approval of the explicit recommendation.

In some embodiments, the system further comprises a second user interface including one or more user interface components for manual and explicit selection of a value of a second information item of the penetration testing campaign, the second information item being other than a trait of the attacker, wherein the system is configured to receive the manual and explicit selection of the value of the second information item subsequent to the manual and explicit selection of the one or more traits.

In some embodiments, the penetration-testing-campaign module is configured, subsequent to the manual and explicit selection of both (i) the one or more traits of the attacker and (ii) the value of the second information item, to perform the penetration testing campaign using both (i) the manually and explicitly selected one or more traits of the attacker and (ii) the manually and explicitly selected value of the second information item. A method of penetration testing of a networked system by a penetration testing system that is controlled by a user interface of a computing device so that a penetration testing campaign is executed according to a manual and explicit selecting of one or more network nodes of the networked system, the method comprising: receiving, by the penetration testing system and via the user interface of the computing device, one or more manually-entered inputs, the one or more manually-entered inputs explicitly selecting the one or more network nodes of the networked system, wherein at least one of the manually and explicitly selected nodes is other than the computing device; in accordance with the manual and explicit selecting of the network nodes, executing the penetration testing campaign by the penetration testing system so as to test the networked system, the penetration testing campaign being executed under the assumption that the manually and explicitly selected one or more network nodes of the networked system are already compromised at the time of beginning the penetration testing campaign; and reporting, by the penetration testing system, at least one security vulnerability determined to exist in the networked system by the executing of the penetration testing campaign, wherein the reporting comprises at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the method is carried out so that before receiving the one or more manually-entered inputs that explicitly select the one or more network nodes of the networked system, the penetration testing system automatically computes and displays an explicit recommendation for selecting the one or more network nodes that are already compromised at the time of beginning the penetration testing campaign.

In some embodiments, the received one or more manually-entered inputs comprises an explicit user approval of the explicit recommendation.

In some embodiments, the method further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the one or more network nodes of the networked system, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a value for a second information item of the penetration testing campaign, wherein the second information item is not a set of one or more network nodes that are assumed to be already compromised at the time of beginning the penetration testing campaign.

In some embodiments, the executing of the penetration testing campaign is performed using both (i) the manually and explicitly selected value for the second information item, and (ii) an assumption that the manually and explicitly selected one or more network nodes of the networked system are already compromised at the time of beginning the penetration testing campaign.

A system for penetration testing of a networked system, the system comprising: a. a network-nodes-selection user interface including one or more user interface components for manual and explicit selection of one or more network nodes, where the network-nodes-selection user interface resides in a computing device and at least one of the manually and explicitly selected one or more network nodes is other than the computing device; b. a penetration-testing-campaign module programmed to perform a penetration testing campaign under the assumption that the manually and explicitly selected one or more network nodes of the networked system are already compromised at the time of beginning the penetration testing campaign; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the system further comprises a recommendation module configured to automatically compute an explicit recommendation for selecting the one or more network nodes, wherein the network-nodes-selection user interface displays the explicit recommendation.

In some embodiments, the system is configured so that the manual and explicit selection of the one or more network nodes includes a manual and explicit approval of the explicit recommendation.

In some embodiments, the system further comprises a second user interface including one or more user interface components for manual and explicit selection of a value of a second information item of the penetration testing campaign, the second information item being other than one or more network nodes, wherein the system is configured to receive the manual and explicit selection of the value of the second information item subsequent to the manual and explicit selection of the one or more network nodes.

In some embodiments, the penetration-testing-campaign module is configured, subsequent to the manual and explicit selection of both (i) the one or more network nodes and (ii) the value of the second information item, to perform the penetration testing campaign using both (i) the manually and explicitly selected one or more network nodes and (ii) the manually and explicitly selected value of the second information item.

A method of penetration testing of a networked system by a penetration testing system that is controlled by a user interface of a computing device so that a penetration testing campaign is executed according to a manually and explicitly provided node-selection condition, the method comprising: receiving, by the penetration testing system and via the user interface of the computing device, one or more manually-entered inputs, the one or more manually-entered inputs explicitly selecting a Boolean node-selection condition, the manually and explicitly selected node-selection condition defining a proper subset of network nodes of the networked system such that any network node of the networked system is a member of the subset of network nodes if and only if it satisfies the condition; in accordance with the manual and explicit selecting of the node-selection condition, executing the penetration testing campaign by the penetration testing system so as to test the networked system, the penetration testing campaign being executed under the assumption that every node of the subset of network nodes is already compromised at the time of beginning the penetration testing campaign; and reporting, by the penetration testing system, at least one security vulnerability determined to exist in the networked system by the executing of the penetration testing campaign, wherein the reporting comprises at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the method is carried out so that before receiving the one or more manually-entered inputs that explicitly select the Boolean node-selection condition, the penetration testing system automatically computes and displays an explicit recommendation for selecting the Boolean node-selection condition.

In some embodiments, the received one or more manually-entered inputs for selecting the Boolean node-selection condition comprise an explicit user approval of the explicit recommendation.

In some embodiments, the method further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the Boolean node-selection condition, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a value for a second information item of the penetration testing campaign, wherein the second information item is not a node-selection condition defining a subset of network nodes that are assumed to be already compromised at the time of beginning the penetration testing campaign.

In some embodiments, the executing of the penetration testing campaign is performed using both (i) the manually and explicitly selected value for the second information item, and (ii) an assumption that every node of the subset of network nodes is already compromised at the time of beginning the penetration testing campaign.

A system for penetration testing of a networked system, the system comprising: a. a node-selection-condition user interface including one or more user interface components for manually and explicitly selecting a Boolean node-selection condition defining a proper subset of network nodes of the networked system such that any network node of the networked system is a member of the subset of network nodes if and only if it satisfies the condition; b. a penetration-testing-campaign module programmed to perform a penetration testing campaign under the assumption that every network node of the subset of network nodes is already compromised at the time of beginning the penetration testing campaign; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the system further comprises a recommendation module configured to automatically compute an explicit recommendation for selecting the Boolean node-selection condition, wherein the node-selection-condition user interface displays the explicit recommendation.

In some embodiments, the system is configured so that the manual and explicit selection of the Boolean node-selection condition includes a manual and explicit approval of the explicit recommendation.

In some embodiments, the system further comprises a second user interface including one or more user interface components for manual and explicit selection of a value of a second information item of the penetration testing campaign, the second information item being other than a Boolean node-selection condition, wherein the system is configured to receive the manual and explicit selection of the value of the second information item subsequent to the manual and explicit selection of the Boolean node-selection condition.

In some embodiments, the penetration-testing-campaign module is configured, subsequent to the manual and explicit selection of both (i) the Boolean node-selection condition and (ii) the value of the second information item, to perform the penetration testing campaign using both (i) the manually and explicitly selected Boolean node-selection condition and (ii) the manually and explicitly selected value of the second information item.

A method of penetration testing of a networked system by a penetration testing system that is controlled by a user interface of a computing device so that a penetration testing campaign is executed according to an automatic selecting of one or more network nodes of the networked system, the method comprising: determining, by the penetration testing system, at least one of (i) a type of an attacker of the penetration testing campaign, and (ii) whether one or more network nodes of the networked system satisfy a pre-defined Boolean condition; based on a result of the determining, automatically selecting, by the penetration testing system, the one or more network nodes of the networked system, wherein at least one of the automatically selected network nodes is other than the computing device; in accordance with the automatically selecting of the network nodes, executing the penetration testing campaign by the penetration testing system so as to test the networked system, the penetration testing campaign being executed under the assumption that the automatically selected one or more network nodes of the networked system are already compromised at the time of beginning the penetration testing campaign; and reporting, by the penetration testing system, at least one security vulnerability determined to exist in the networked system by the executing of the penetration testing campaign, wherein the reporting comprises at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the determining comprises determining the type of the attacker of the penetration testing campaign.

In some embodiments, the determining of the type of the attacker comprises automatically determining the type of the attacker by the penetration testing system.

In some embodiments, the determining of the type of the attacker comprises receiving, via the user interface of the computing device, one or more manually-entered inputs that explicitly select the type of the attacker.

In some embodiments, the determining comprises automatically determining whether the one or more network nodes of the networked system satisfy the pre-defined Boolean condition.

In some embodiments, the pre-defined Boolean condition is satisfied for a given network node if and only if the given network node has a direct connection to a computing device that is outside the networked system.

In some embodiments, the pre-defined Boolean condition is satisfied for a given network node if and only if the given network node has an operating system that is a member of a pre-defined set of operating systems.

In some embodiments, the pre-defined Boolean condition is satisfied for a given network node if and only if the given network node has a cellular communication channel.

A system for penetration testing of a networked system that is controlled by a user interface of a computing device, the system comprising: a. a node-selection module configured to: determine at least one of (i) a type of an attacker of a penetration testing campaign, and (ii) whether one or more network nodes of the networked system satisfy a pre-defined Boolean condition; and based on a result of the determining, automatically select one or more network nodes of the networked system, wherein at least one of the automatically selected network nodes is other than the computing device; b. a penetration-testing-campaign module programmed to perform the penetration testing campaign under the assumption that the automatically selected one or more network nodes of the networked system are already compromised at the time of beginning the penetration testing campaign; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the node-selection module is configured to determine the type of the attacker of the penetration testing campaign.

In some embodiments, the node-selection module is configured to automatically determine the type of the attacker of the penetration testing campaign.

In some embodiments, the node-selection module is configured to determine the type of the attacker by receiving, via the user interface of the computing device, one or more manually-entered inputs that explicitly select the type of the attacker.

In some embodiments, the node-selection module is configured to automatically determine whether the one or more network nodes of the networked system satisfy the pre-defined Boolean condition.

In some embodiments, the pre-defined Boolean condition is satisfied for a given network node if and only if the given network node has a cellular communication channel.

A method of penetration testing of a networked system by a penetration testing system that is controlled by a user interface of a computing device so that a penetration testing campaign is executed according to one or more manually and explicitly-selected goals of an attacker of the penetration testing campaign, the method comprising: receiving, by the penetration testing system and via the user interface of the computing device, one or more manually-entered inputs, the one or more manually-entered inputs explicitly selecting one or more goals of the attacker of the penetration testing campaign, wherein at least one goal of the one or more goals satisfies at least one condition selected from the group consisting of: i. the at least one goal is a resource-specific goal; ii. the at least one goal is a file-specific goal; iii. the at least one goal is a node-count-maximizing goal; iv. the at least one goal is a file-count-maximizing goal; v. the at least one goal is an encryption-related goal; vi. the at least one goal is a file-exporting goal; vii. the at least one goal is a file-size-related goal; viii. the at least one goal is a file-type-related goal; ix. the at least one goal is a file-damage-related goal; and x. the at least one goal is a node-condition-based goal; executing the penetration testing campaign, by the penetration testing system and according to the manually and explicitly-provided selection of the one or more goals of the attacker, so as to test the networked system; and reporting, by the penetration testing system, at least one security vulnerability determined to exist in the networked system by the executing of the penetration testing campaign, wherein the reporting comprises at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability. In some embodiments, the at least one goal is a resource-specific goal.

In some embodiments, the at least one goal is a file-specific goal.

In some embodiments, the at least one goal is a node-count-maximizing goal.

In some embodiments, the at least one goal is a file-count-maximizing goal.

In some embodiments, the at least one goal is an encryption-related goal.

In some embodiments, the at least one goal is a file-exporting goal.

In some embodiments, the at least one goal is a file-size-related goal.

In some embodiments, the at least one goal is a file-type-related goal.

In some embodiments, the at least one goal is a file-damage-related goal.

In some embodiments, the at least one goal is a node-condition-based goal.

In some embodiments, the method is carried out so that before receiving the one or more manually-entered inputs that explicitly select the one or more goals of the attacker, the penetration testing system automatically computes and displays an explicit recommendation for selecting the one or more goals of the attacker.

In some embodiments, the received one or more manually-entered inputs comprises an explicit user approval of the explicit recommendation.

In some embodiments, the method further comprising: subsequent to the receiving by the penetration testing system of the one or more manually-entered inputs that explicitly select the one or more goals of the attacker, receiving, by the penetration testing system and via the user interface of the computing device, one or more additional manually-entered inputs, the one or more additional manually-entered inputs explicitly selecting a value for a second information item of the campaign of the penetration testing system, wherein the second information item is not a goal of the attacker.

A system for penetration testing of a networked system, the system comprising: a. a goals-selection user interface including one or more user interface components for manual and explicit selection of one or more goals of an attacker of a penetration testing campaign, wherein at least one goal of the one or more goals satisfies at least one condition selected from the group consisting of: i. the at least one goal is a resource-specific goal; ii.

the at least one goal is a file-specific goal; iii. the at least one goal is a node-count-maximizing goal; iv. the at least one goal is a file-count-maximizing goal; v. the at least one goal is an encryption-related goal; vi. the at least one goal is a file-exporting goal; vii. the at least one goal is a file-size-related goal; viii. the at least one goal is a file-type-related goal; ix. the at least one goal is a file-damage-related goal; and x. the at least one goal is a node-condition-based goal; b. a penetration-testing-campaign module programmed to perform the penetration testing campaign whose attacker has the one or more goals that are manually and explicitly selected via the goals-selection user interface; and c. a reporting module for reporting at least one security vulnerability determined to exist in the networked system according to results of the penetration testing campaign that is performed by the penetration-testing-campaign module, wherein the reporting module is configured to report the at least one security vulnerability by performing at least one of (i) causing a display device to display a report describing the at least one security vulnerability, and (ii) electronically transmitting a report describing the at least one security vulnerability.

In some embodiments, the at least one goal is a resource-specific goal.