Managing Incidents
Understanding Threats and Incidents
Detailed incidents are generated by the Juniper ATP Appliance analysis and detection engines for related malware events.
For example, during an enterprise user’s web browsing session, a link from a compromised website might load an advertisement that redirects the user’s browser to an exploit site. From the exploit site, the browser might then download malicious mobile code to the user’s endpoint. The malicious code might be armored, designed to evade discovery while allowing the attacker to take control of the user’s device. This command and control (CnC) of the enterprise endpoint might download data theft software, or it may gain direct access to intellectual property and proprietary information or documents. The CnC code might involve obfuscated callbacks to the command and control server for data exfiltration, and the malware might then also compromise other assets in the enterprise network such as a share or dropbox where it will be inadvertently downloaded again by other corporate users.
All of the web-based malware events described above are detected by Juniper ATP Appliance as a combined incident. The results of Juniper ATP Appliance’s context-aware detonation engines are displayed on the Incidents page with sub-tab displays that contain malware results specific to Kill Chain progression and incident summaries.
The Incidents table is an important mechanism for filtering, sorting, and searching detection results for analysts and enterprise response teams.
The Incidents page is integrated with the Juniper ATP Appliance CM Dashboard. The Dashboard also displays incident detection results for all related malware events. Double-clicking a bubble in the Dashboard Threat View opens the Incident page in-focus for that host’s incident and related events.
Below the Incidents table, the left panel Details and Summary sections include sub-tabs for each Kill Chain result specific to the incident row selected in the table above. Sub-tabs include Exploits | Downloads | User Uploads | Infections | Execution | Data Theft.
Context-Aware Kill Chain Stage and Progression per Incident
Exploit |
XP |
Activity that could expose users to malicious objects. |
---|---|---|
Download |
DL |
Download of an object identified as malicious. |
User Upload |
UP |
A data upload performed at an endpoint. |
Execution |
EX |
Execution of malicious code on the enterprise endpoint [identified through Bit9/Carbon Black API integration] |
Infection |
IN |
Identified evidence of infection (CnC). |
Data Theft |
DT |
Analysis of data exfiltration from the endpoint. |
Threats and the Attack Life Cycle
The incidents detected by Juniper ATP Appliance reveal a variety of related events as they correlate to specific phases of the malware infection life cycle and Kill Chain. For example, when exploit content is delivered by a browser, the inspection and analysis components of the Juniper ATP Appliance Collectors and Cores perform indepth object analysis. Juniper ATP Appliance sends the full view of the web page and associated network objects, including the exploit, to the engines for dynamic behavioral analysis in virtualization, then emulation engines.
The consecutive virtualization and emulation environments are exploited as the malicious code executes, initiating a download of a “malware binary, another stage of the Kill Chain progression that Juniper ATP Appliance is actively tracking. When the malware binary is loaded into the Juniper ATP Appliance detonation engines, the binary instructs the system to transmit a network callback to the CnC center, for remote control by the attacker. Internal to the appliance, Juniper ATP Appliance captures and analyzes the network traffic generated by the malware and generates a dynamic network rule in order to identify this same callback traffic across the monitored, integrated network infrastructure. Juniper ATP Appliance’s mitigation rules block the callback traffic, capture and record all files created or modified during detonation, and generate an Incident representing all the events that took place in the virtualization and emulation engines, sending notification(s) to GSS and the administrator so that the infection detected by the Juniper ATP Appliance Cores can be remediated on the infected host in real time in the enterprise network. All of this data is represented in the Juniper ATP Appliance CM Incidents tables and sub-tabs.
Understanding Severity
Juniper ATP Appliance Threat Severity determinations are shown in the Incidents table as Risk levels. The colors do not relate to whether an infection is confirmed or not; they are based on the Threat Metric Risk Score.
Severity Risk Colors
Red-Max = Critical / Maximum risk events
Red-High = High risk events
Orange -Med = Medium risk events
Yellow -Low = low risk events
Green -Benign = clean events; benign (clean) events are displayed under the Show Benign option.
Severity Range
Severity is defined as a value (including decimals) between 0 and 1.
Severity Calculations |
||||
---|---|---|---|---|
Max |
High |
Med |
Low |
Benign |
1 |
0.75 |
0.5 |
0.25 |
0 |
To search for all clean/benign events, specify a minimum severity of 0 and maximum severity of 0.
Severity and the Kill Chain
Kill Chain |
Recommended Mitigation Action |
---|---|
EX, IN, DL+IN, DT |
Immediate response required;
|
DL |
Immediate response required
|
XP, UP |
Not an urgent action.
|
Severity and Risk Calculations
Risk calculation is context-specific and takes the following criteria into account:
The Relevance of the threat:
Asset Value of the enterprise network segment
Antivirus configuration of the endpoint
If you have configured which of your network segments are using which antivirus software (see Config Tab options), then, if the AV software for this endpoint can catch the malware download, then the risk calculation is lowered.
OS Match
If the operating system of the endpoint and the OS for which the malware was designed are a match, then risk calculation is higher. For example, OSX malware on a Windows machine (an OS Mismatch) represents a lower risk than Windows malware on a Windows machine.
Asset Value for the network segment or endpoint
The Juniper ATP Appliance system allows network segments to be configured with an asset value (Low, Medium, High, Critical) indicating the importance of this endpoint. This value is used in risk calculations.
Severity of the malware event
Malware severity
Different types of malware download are assigned different severities as part of risk calculation determinations.
When a malicious event is detected, the Juniper ATP Appliance detection and analysis engines determine severity as part of their Threat Metric determinations. As indicated, an infected host can undergo a combination of events— an initial infection, a secondary binary drop, as well as a callback—coupled with asset value assessments and chain heuristics— that together contribute to determining the severity of the attack.
All malware callback events are considered high severity events, which are displayed as "High" in the Central Manager Web UI. A callback event allows Juniper ATP Appliance to determine whether the endpoint has been infected. Binary downloads are assigned severity according to the threat category from the Core detonation and analysis engines; a callback could be Low, Medium, High or Critical.
Severity is closely linked to the infection life cycle and Juniper ATP Appliance provides unprecedented visibility into the details of every stage of the infection life cycle.
Interpreting Context-Aware Incident Details
The details provided on the Juniper ATP Appliance Incidents page include information about each malware attack and infection as well information that may be useful to analysts.
In the case of a Web Infection, an analyst would want to know how the source IP was initially infected.
From the Incident table, an analyst can determine that an infection came from a browser exploit attack or download, for example, and whether this event included another dropper binary. The particular malware family and any callbacks from the same malware family can also be determined. In every case, when a callback is matched to an actual Asset in the enterprise, the asset is determined to be compromised.
Analysts can drill down further to understand how the malware is working. Open the left panel sub-tabs on the Incidents page (Downloads and Infections) to review attack details.
Sometimes, a low severity, when combined with other threat-level events, it may be listed as a high severity incident.
In the case of a browser exploit, several events may appear to be malicious, but it might be difficult to tell. In order to know if an exploit is truly malicious, analysts can run the Juniper ATP Appliance Infection Verification Package (IVP) at the targeted endpoint, or configure Carbon Black integration, to verify infection.
From an analyst’s perspective, it is important to determine if an end asset was actually compromised. IVP helps determine if the incident is an attempted attack or a full exploit.
IVP also recognizes whether affected hosts downloaded multiple different binaries but a callback was generated on only one of them. It is sometimes possible that the other delivered binaries did not actually exploit an endpoint asset, but Juniper ATP Appliance reveals that there has been an exploit (EX) because of one callback from one host in the enterprise. In order to determine if this is truly an APT, an analyst must review the information provided about how the malware behaved and operated in the OS.
Juniper ATP Appliance allows analysts to see when an executable file was delivered; if it corrupted a root file system (a major red flag), then it may have ultimately loaded a DLL. The executable might register a new Windows service, which is another red flag. It is important to note that properly signed binaries are allowlisted, which is one way that legitimate installers are filtered out.
In some callback and DT instances, there may be a simple DNS match. But it is impossible to tell if an asset was compromised based only on the DNS. It is likely, but in order to confirm it, analysts must compare when the DNS record was first added to the database relative to when the asset first generated the DNS request.
Malware Download Naming Conventions
The general naming scheme for malware downloads is as follows:
Category[_Family].Suffix
“Category” would be malware of the type Adware, Suspicious, Trojan, Virus, Worm or Exploit.
The “Family” name applies to Trojan categorizations, and is obtained either from VirusTotal or the Juniper ATP Appliance Detection Engine’s behavioral classifier.
The “Suffix” meanings are:
.DC = Deep Cooker
.CY = Reputation engine + Static detection
.Rep = Reputation Engine Only (Reputation Engine detection)
.Static = (3rd party static detection scanner)
Uppercase names, such as TROJAN_NAME.DC indicates that there is a match on the VirusTotal database and chances are that this is a high confidence detection. For example: TROJAN_BROWSERFOX.DC.
A mixed-case naming means that other detection triggers were observed. There are 2 types of classifications: Category[_Family].Static and Category[_Family].DC
Category[_Family].Static is higher confidence because it is based on third party static detection.
The Category[_Family].DC format indicates that the detection occurred in the Detection Engine. If the Detection Engine was the only trigger, this may be a false positive, but it might also indicate a zero-day attack.