Campaign Properties

A campaign detected by the NSX Network Detection and Response application is characterized by multiple properties.

The following are the campaign properties and their definitions.

Property Name	Description
Name	A campaign ID that uniquely identifies the campaign.
Hosts	The hosts that are affected by the campaign.
Threat	The threats that have been detected for the campaign.
Attack Stages	The phases in the life cycle of the adversary corresponding to the detected activities. See About Attack Stages for details.
Duration	The time interval during which the activities associated with a campaign have been observed.

About Attack Stages

Attack stages are the phases in the life cycle of an adversary that corresponds to the activities detected by the NSX Network Detection and Response application.

An adversary model describes the actions that an adversary may take to compromise and operate within an enterprise network. The NSX Network Detection and Response application uses MITRE's Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK™) model to describe adversary behaviors. In this model, the techniques that an adversary could use are grouped into a number of tactic categories, which correspond to different stages in the attack lifecycle.

In the system, the activity associated with each detected event might be associated to a specific attack stage and might provide an indication of the campaign progress along its lifecycle. (Activities encountered at different attack phases might not be associated to a specific attack stage.) Currently, the following attack stages are used.

Attack Stage Name	Description
Delivery	The stage where attackers send the payload to the target. Common delivery mechanisms include remote exploits, drive-by-download webpages, and malicious USB or other removable drives.
Exploitation	The stage where the attacker's payload is deployed in the target network. Consequently, one or more devices in the target network are compromised and under the attacker's control.
Command and Control	The stage where attackers communicate with systems under their control within the target network, effectively obtaining "hands on the keyboard" remote access to these systems.
Credential Access	The stage where attackers gain access or control over system, domain, or service credentials used within the target environment. Typically, attackers attempt to obtain legitimate credentials from user and administrator accounts in order to impersonate them, or to create new accounts.
Discovery	The stage where attackers attempt to find more information about the target environment. Attackers often attempt to identify additional devices in the network, which they can use for their objectives.
Lateral Movement	The stage where attackers move across the target network by gaining access and control of remote systems.
Collection	The stage where attackers identify and gather information from a target network prior to exfiltration.
Exfiltration	The stage where attackers remove files and information from a target network.

About Correlation Rules

In general, incidents are grouped into a campaign when there is evidence that indicates that the corresponding malicious activities or attacks are related.

Since these correlation rules are running in the NSX Advanced Threat Prevention cloud service, they can be improved or extended independent of the NSX release cycles. Additionally, the list of correlation rules or the specific behavior of a rule can change over time.

The following are the currently supported correlation rules.

Anomaly Event

This rule correlates the detection events from the NSX Suspicious Traffic feature with higher-impact infection-type events. For example, an anomaly event from the NSX Suspicious Traffic feature coincides with a high-impact network event for the same hosts.

Exfiltration

This rule correlates exfiltration events that are preceded by infection-type events. For example, a command and control network event is followed by a network event that we know is exfiltrating data.

File Transfer (Hash-Based)

This rule correlates malicious file transfers. For example, if the same malicious file is downloaded to a number of hosts in the network, the rule will correlate all of these transfers into an intrusion. The similarity of malicious file transfers is determined based on the transferred file's SHA-1 hash.

File Transfer (Analysis Tag-based)

Vulnerability Scan

This rule correlates different types of network events that all potentially indicate a vulnerability scan. For example, multiple outbound infection-type or NTA events are observed from a single host towards one or multiple internal destination hosts.

Wave

This group of rules identifies attack "waves," in which the same attack (that is, incidents for the same threat) is observed on multiple hosts across the network within a certain time window.

This group of rules is useful to identify hosts in the network that have become part of the same command and control infrastructure or have been exposed to the same attack vector (for example, drive-by attack or malware distribution attack). As a result, these rules are restricted to threats of class command and control, drive-by, malware distribution, sinkhole, fake AV, and crypto mining.

The rules in this group trigger in the following cases.

There are network signature events where the threat class is command and control, affecting multiple hosts.
There are network signature events where the threat class is malware distribution, affecting multiple hosts.
There are network signature events where the threat class is drive-by and the entry (IP address or hostname) where the detections occurred are the same, affecting multiple hosts.
There are malicious reputation events for the same entry (IP address or hostname) and the threat class is command and control, affecting multiple hosts.
There are malicious reputation events for the same entry (IP address or hostname) and the threat class is malware distribution, affecting multiple hosts.

In this case, the correlation window is set to three days. Therefore, two incidents for the same threat affecting different hosts are considered related if they occur within this limited time range.

Note:

These rules can create campaigns comprising only of one host and one incident.

Confirmed Drive-by

This group of rules identifies campaigns where an internal host is exposed to a successful drive-by attack. A drive-by attack on a host is considered successful if it is followed by command and control, malware download, sinkhole, or fake AV activity. The rules in this group trigger in the following cases.

Drive-by closely followed by malware download activity: In this case, the correlation window is 10 minutes, as we expect the download to be immediately caused by a successful browser exploit.
Drive-by closely followed by fake AV activity: In this case, the correlation window is 10 minutes, as we expect the fake AV activity to immediately follow a drive-by exploit.
Drive-by followed by command and control activity: In this case, the correlation window is four hours, as the command and control channel might take some time to be set up.
Drive-by followed by sinkhole activity: In this case, the correlation window is four hours, as the activity towards a sinkholed malicious server over a command and control channel might take some time to be set up.

Note:

These rules can create campaigns comprising only of one host.

Confirmed File Download

This group of rules identifies campaigns where a malicious file is downloaded and successfully executed on a host. A downloaded file is considered to have successfully executed on a host if, shortly following the download, there are network events for activities that match the activity observed during the file analysis.

In particular, the file analysis can provide two more pieces of information to characterize the activity observed during the analysis.

Malware information: If the file behavior matches the behavior of a well-known threat, the malware name becomes available.
Network IoC information: If during the analysis the sample generates network traffic matching network signatures or threat intelligence, indicators for the traffic are made available. That is, information about malicious reputations and network signature matches are provided.

The rules in this group trigger in the following two cases, depending on the type of information derived from the file analysis.

Malware-based case
- A file is downloaded on a host.
- The file analysis attributes a specific threat to the file (for example, Emotet malware).
- At a later time, a network event for the same threat (that is, Emotet) is detected for the host that downloaded the file.
Network IoC-based case
- A file is downloaded on a host.
- The file analysis identifies network IoC for the file.
- At a later time, the host that downloaded the file attempts to contact an IP address or hostname included in the malicious reputation IoC extracted for the file and this traffic matches a network signature.

The NSX Network Detection and Response application sets the correlation window in this case to three days.

Note:

This rule can create campaigns comprising only of one host.

Lateral Movement

This group of rules identifies campaigns where attackers have established a "beachhead" in the network by compromising some hosts and then attempt to move laterally within the network to compromise additional hosts.

This group comprises two rules, each of which detects a separate step of the lateral movement campaign.

Outgoing lateral movement: This rule correlates outgoing lateral movement activity from a host in the home network and infections on that host that happened before the lateral movement detections (but within the correlation window).
Incoming lateral movement: This rule correlates incoming lateral movement activity towards a host in the configured home network and activity commonly observed after an initial compromise (Command&Control, probing and credential harvesting) that occurred on the same host after the lateral movement detections.

Notice that these rules will only trigger for hosts within the home network, that is the campaign is created only if both source and destination hosts of the lateral movement activities belong to the home network. If the home network is not configured, the system uses RFC1918 ranges by default.

INFO Events Promotion

The NSX Network Detection and Response application detects several activities in a protected network that might be interesting to an analyst, but are probably not malicious. These detections generate INFO events, which can be viewed by setting an appropriate value of the "event outcome" filter.

The NSX Network Detection and Response application does not consider INFO events for correlation purposes.

A challenge with these detections is that the same INFO event activity can be normal or highly suspicious, depending on the network in which the NSX Network Detection and Response application detected it. For example, the use of the remote desktop protocol (RDP) can be normal in an environment where this tool is used for legitimate administrative purposes, but can otherwise be a highly suspicious indication that an attacker might be attempting to remote-control a victim host.

Anomaly detection logic is able to determine when certain kinds of INFO detections are unusual for the monitored network and for the specific source hosts and destination hosts involved. When the system determines that an INFO detection is unusual, the event is promoted to "detection" mode and, as a consequence, is displayed among regular events. This scenario is relevant in the context of correlation rules for lateral movement, as the detection of lateral movement activity often result in the creation of INFO events.

Home Network

The home network configuration has the following effect on campaign correlation rules.

All campaign correlation rules ignore events that happened on hosts outside of the home network.
If no home network is configured, the system defaults to the RFC1918 ranges.

The home network is configured in Security > General Settings > Private IP Ranges.

Host Silencing

The host silencing configuration has the following effect on campaign correlation rules.

If host silencing is configured, all campaign correlation rules ignore events that happened on silenced hosts.
If no host silencing is configured, all source hosts detected in an event are considered valid for correlation.

To ensure that host silencing does not mistakenly include hosts whose activity should be included in campaigns, you must verify your host silencing configuration.

About Evidence

The NSX Network Detection and Response application reports on the actions observed while analyzing an event, incident, or campaign.

The evidence contains the following information.

Basic Detection Evidence: Network

Evidence type REPUTATION

Indicates that network traffic was detected to an IP or domain that is associated with a known threat.

A SUBJECT field and an IP address or domain are displayed. For example: reputation: evil.com (reference event), 6.6.6.6 (reference event), or bad.org (reference event).

These bad domains and IP addresses are typically blocked. Additional reputation information is displayed if available.

IP addresses may be annotated with a location (country flag).

Evidence type SIGNATURE

Indicates that network traffic was detected that matches a network signature for a known threat.

A Detector field that is the name/unique identifier of the signature that matched is displayed. For example, Detector: et:2014612 or Detector: llrules:1490720342088.

Evidence type ANOMALY

Similar to SIGNATURE with the difference that detection is based on a heuristic that detected something anomalous. For example, Anomaly: anomaly:download_smb.

Evidence type FILE DOWNLOAD

A malicious or suspicious file was downloaded.

A task_uuid, the identifier of an analysis (detonation in sandbox), and the severity, the score of that analysis, is displayed. For example, File download: a7ed621.

The following lists additional optional information from the reference event.

The URL the file was downloaded from
The file type (typically executable)
The filename

Evidence type UNUSUAL_PORT

Indicates that a TCP or UDP port is being used that is an uncommon one and corresponds to what is expected of this specific threat.

The IP address or domain involved in the traffic that used the unusual port is displayed in the SUBJECT field.

Evidence type URL_PATH_MATCH

Similar to unusual port, with the difference that detection is based on a URL path. For example, http://evil.com/evil/path?evil=threat, the detection is triggered by the /evil/path portion of the URL.

Evidence type DGA

DGA stands for "Domain Generation Algorithm", an approach used by some malware, where instead of using a small number of domains for Command and Control, the malware includes an algorithm that generates thousands of new random-looking domains each day. It then tries to contact each of them. To control their malware, the hacker just registers one or a few of these domains. The use of DGA is very visible on the network due to resolution attempts of many such domains.

The DGA evidence is currently used in addition to regular reputation evidence, when multiple bad domains from a DGA algorithm being resolved is detected.

Evidence from Correlation of Multiple Events

Evidence from correlation of multiple events

The following evidence types are created in cases when the combination of multiple network events on a host increases confidence that a threat has been correctly detected. The evidence types may be, for example, the same malicious reputation entry being contacted or the same network signature being triggered.

For each of these cases, the threat may be tagged as follows.

Repeated: The specific threat was seen three or more times.
Periodic: The specific threat was also seen occurring at regular intervals.

A label is shown on the corresponding reputation/signature evidence.

In the example of REPUTATION evidence, if repeated and periodic evidence for bad.org are detected, a REPEATED or PERIODIC tag is displayed.

Evidence type CONFIRMED_EXECUTION

This is associated with threats, such as MALICIOUS FILE DOWNLOAD. It means that network behavior is detected from the host that downloaded the file that confirms that the downloaded file was actually executed.

That is:

A malicious file was downloaded to host 1.2.3.4.
When executed in a sandbox, this file contacted evil host evil.com.
Shortly afterwards, command and control traffic from host 1.2.3.4 to evil.com is observed, confirming that the malicious file was executed.

The linked reference event is to where file was downloaded.

Additional evidence can provide confirmation of the threat, such as the following information about the file.

Task UUID
Score
Filename
URL it was downloaded from

Evidence type CONFIRMED_C&C

Similar to CONFIRMED_EXECUTION, this evidence is added to the command&control detection for the specified threat because the host previously downloaded a file for that threat.

Evidence type CONFIRMED_DRIVE_BY

This is added in situations a drive-by attack was detected followed by some indication that attack was successful. For example:

Host 1.2.3.4 seems to be the victim of a drive-by attack.
Shortly afterwards, host 1.2.3.4 either:
- Downloaded a malicious file
- Performed command&control traffic

This evidence is added to reference event of the initial drive-by event.

Evidence type DRIVEBY_CONFIRMATION

Similar to CONFIRMED_DRIVEBY evidence, this evidence is added as a reference event to the malicious file download or command&control detections that happened shortly after a drive-by attack.