Campaign properties

This page provides some information about campaigns, including some definitions. An campaign is characterized by the following properties:

  • 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 adversary's lifecycle corresponding to the detected activities.

  • Duration — The time interval during which the activities associated to an campaign has been observed.

About attack stages

An adversary model describes the actions that an adversary may take to compromise and operate within an enterprise network. The VMware NSX Network Detection and Response 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 may be associated to a specific attack stage, providing an indication of the campaign progress along its lifecycle. (Activities encountered at different attack phases may not be associated to a specific attack stage.) Currently, the following attack stages are used:

Delivery

Delivery is the stage where attackers send the payload to the target. Common delivery mechanisms include remote exploits, spearphishing emails, drive-by-download webpages, and malicious USB or other removable drives.

Exploitation

Exploitation is the stage where the attackers payload is deployed in the target network. As a consequence, one or more devices in target network are compromised and under the attackers control.

Command and control

Command and Control is 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

Credential access is 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

Discovery is the stage where attackers attempt to find more information about the target environment. In particular, attackers often attempt to identify additional devices in the network, which they can use for their objectives.

Lateral movement

Lateral movement is the stage where attackers move across the target network by gaining access and control of remote systems.

Collection

Collection is the stage where attackers identify and gather information from a target network prior to exfiltration.

Exfiltration

Exfiltration is 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.

Note:

Correlation rules apply only to activities observed by an individual sensor or all the sensors of a sensor group. Activities observed by multiple sensors that are not part of a sensor group will not be grouped together into a campaign.

The following sections describe the correlation rules grouped by their general correlation strategy.

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 is useful, in particular, 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-download or malware distribution attack). As a consequence, these rules are restricted to threats of class command and control, drive-by, and malware distribution.

The rules in this group trigger in the following cases:

  • There are network signature events all where the threat class is command and control, affecting multiple hosts.

  • There are network signature events all where the threat class is malware distribution, affecting multiple hosts.

  • There are network signature events where the threat class is drive-by-download 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.

Malware download from mail

This rule identifies campaigns in which an internal host downloads a malicious file from a link contained in an email. When the rule triggers, it correlates the email message with related file download incidents. The rule triggers when:

  • An email with a link is received

  • At a later time, a host downloads a file from the exact same URL contained in the email, and the file is determined to be malicious

  • Any additional file download events from the same URL are also correlated into the resulting campaign

The correlation window is set to three days. Therefore, a file download event is considered to be relevant only if it occurs within three days of receiving an email with a matching URL. This limits the chance of correlating file downloads that are not actually caused by the email.

Note:

For the rule to trigger, the final download URL of the file must match exactly the URL contained in the email.

Confirmed drive-by-download

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

  • Drive-by-download 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-download followed by command and control activity: in this case, the correlation window is 4 hours, as the command and control channel may take some time to be set up.

Note:

These rules may create campaigns comprising only one host and one incident.

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 additional 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 is made 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). More information about the IoC generated from file analysis are available in the analyst API documentation.

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")

    • 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; or

    • The host generates traffic matching a network signature included in the network signature IoC for the file, and the traffic involves the same IP address or hostname observed during the file analysis (in case the signature IoC involves a host that is determined to be compromised rather than outright malicious, the path and port must match).

The correlation window in this case is set to four hours.

Note:

This rule may create campaigns comprising only one host and one incident.

Confirmed mail attachment execution

This rule identifies campaigns where a mail message containing a malicious attachment is received and the attachment is later successfully executed on a host. An attachment is considered to have successfully executed if, following the reception of the mail message, network traffic that matches network IoC for the attachment is detected (see description of network IoC generated during analysis for more information). This rule correlates an attachment with network behavior consistent with what would be expected from a host where the malicious attachment is opened, based on analysis of the attachment.

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: 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 VMware NSX Network Detection and Response detects a number of activities in a protected network that may be interesting to an analyst, but are probably not malicious. These detections generate INFO events, which can be viewed in the User Portal by setting an appropriate value of the "event outcome" filter.

INFO events are not considered for correlation purposes.

A challenge with these detections is that the same INFO event activity may be completely normal or highly suspicious, depending on the network in which it is detected. For example, the use of the remote desktop protocol (RDP) may be normal in an environment where this is used for legitimate administrative purposes, but can otherwise be a highly suspicious indication that an attacker may 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 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 is a particularly 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 for a sensor group. Correlation rules ignore any home network settings on an individual sensor once that sensor is added to the sensor group.

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 silenc is configured, all source hosts detected in an event are considered valid for correlation.

You must check your host silencing configuration to ensure it doesn’t mistakenly include hosts whose activity should be included in campaigns.

Correlation rules consider the host silencing configuration of each individual sensor separately, even if a sensor belongs to a sensor group.

Sensor groups

Correlation rules apply only to activities observed by the same sensor group (or individual sensor). Activities observed by different sensors that are not part of a specific sensor group will not be grouped together into a campaign. Therefore, if you have multiple sensors, you should group all the sensors whose activity should be correlated into one sensor group.

For example, in an installation with the following configuration:

  • A sensor group is containing sensor01 and sensor02

  • sensor01 has configured home network for range 192.168.1.0/24

  • sensor02 has silenced host 192.168.1.50

In this configuration:

  • An event detected by sensor02 on host 192.168.0.192 is still considered by the correlation rules (although it is outside sensor01 home network).

  • An event detected by sensor01 on host 192.168.1.50 is still considered by the correlation rules (although it is silenced by sensor02).

About evidence

The VMware NSX Network Detection and Response 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 local reputation

Similar to reputation with the difference that "reputation" evidence is generated for IP addresses and domains that are in a VMware NSX Network Detection and Response block list. "Local reputation" evidence is generated for IP addresses and domains that were determined to be bad specifically in the context of your network, based on what is observed when detonating your threat samples. This happens when:

  1. A bad file is detected in your network and detonated in the system sandbox.

  2. In the sandbox, the file contacts domain maybeevil.com.

  3. the system automatically blocks maybeevil.com locally for your network.

  4. Traffic is detected to maybeevil.com on your network.

The "local reputation" evidence is generated in 4 of this process.

A subject field and an IP address or domain are displayed.

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 (reference event) or Detector: llrules:1490720342088 (reference event).

Click the Intelligence pages icon icon to view the signature in Intelligence.

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 (reference event).

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 (link to report) (reference event) and an analysis summary such as https://user.lastline.com/portal#/analyst/task/6a19af333d8f0010126d568c4bfd73ba/overview.

Additional optional information from the reference event:

  • The URL the file was downloaded from

  • The file type (typically executable)

  • The filename

Evidence type url

A malicious URL was detected on the network (a user's browser visited a bad URL).

A task_uuid, the identifier of an analysis (detonation in sandbox, although in this case the sandbox is visiting a URL, rather than executing a file) and the severity, the score of that analysis, is displayed.

URL detection is similar to file download.

Additional optional information from the reference event:

  • The URL itself

Additional evidence can provide confirmation of the threat, such as:

  • The use of a specific port number

  • The use of a specific URL path

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.

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

Basic detection evidence: mail

Evidence type mail_attachment

A malicious or suspicious file was attached to an email.

A task_uuid, the identifier of an analysis (detonation in sandbox), and the severity, the score of that analysis, is displayed.

Information displayed is similar to file download, with the difference that a link to a mail event is provided.

Additional evidence can provide confirmation of the threat, such as:

  • The attachment filename

  • The attachment file type

  • Mail information, such as sender, recipient, subject

Evidence type mail_url

A malicious URL was detected in an email. This URL was somewhere in the body of the message where a user might click on it.

A task_uuid, the identifier of an analysis (detonation in sandbox), and the severity, the score of that analysis, is displayed.

Information displayed is similar to url, with the difference that the URL was found in an email instead of being visited by someone using a browser.

Additional evidence can provide confirmation of the threat, such as:

  • The URL

  • Mail information, such as sender, recipient, subject

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:

  • 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 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.