Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


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.

Figure 1: Central Manager Incidents Tab - Max Severity RiskCentral Manager Incidents Tab - Max Severity Risk

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



Activity that could expose users to malicious objects.



Download of an object identified as malicious.

User Upload


A data upload performed at an endpoint.



Execution of malicious code on the enterprise endpoint [identified through Bit9/Carbon Black API integration]



Identified evidence of infection (CnC).

Data Theft


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











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


Immediate response required;

  • wipe infected endpoint hosts

  • block malware IP addresses (download server or CnC server)


Immediate response required

  • Deploy IVP or Bit9 integration (if configured) to confirm if the endpoint has executed the malware and is infected.


Not an urgent action.

  • Use IVP to confirm if machine is infected

Severity and Risk Calculations

Risk calculation is context-specific and takes the following criteria into account:

  1. The Relevance of the threat:

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

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

Navigating the Incidents Page

Review the entries in the Incidents table.

  • To drill down into more information about a particular incident, select a row in the table. The Details area below the Incidents table adjusts to display details for the selected row/incident.

  • Click the Upload File button on the upper right of the Incidents tab, and in the “Submit file for analysis” window that displays, select the file to upload for analysis and click the Submit file button. The Upload File feature calls the “file_submit” API and then, following analysis, displays the results returned from the API in a pop-up page in the Central Manager Web UI. The results are also displayed in the Incidents page table with the Kill Chain designation: DL (in this example) along with the incident sha1sum and filename.

  • Click the Mitigate Incident link to the right of the Details area to view mitigation options for the selected threat.

  • Click the “New” link in the Status column to change the status from a drop down menu, which allows administrators with access privileges to tag individual incidents as either:

    New | Acknowledged | In Progress | Complete

Setting Incident Status and Entering User Comments

All users who have access to incident details can mark an incident they’ve triaged or resolved so that other Juniper ATP Appliance users can monitor progress. There are four states available:

New | Acknowledged | In Progress | Complete

All users with access can also add Comments to incidents; when the Status link (for example, “New” in the screenshot below) is clicked on the Incidents page Status column, it opens a window in which the status can be updated and user comments and progress reports can be entered, as shown below:

The following table describes the columns and displays in the Incidents table.

Table 1: Main Incident Table Column Definitions




User-defined description of the resolution state of the Incident. Available options include: New | Acknowledged | In Progress | Complete. Click the Status descriptor per row to open the Status and User Commenting window for a given incident.


Threat Metric and Severity Rating


Name used to identify the detected download or infection.

Kill Chain

The Kill chain attack phase or progression determined by the detection engine:

XP (exploit) | DL (download) | UP (upload) | EX (execution) | IN (infection ) | DT (data theft)

Threat Source

The IP address or domain name of the malware source.

Threat Target

The IP address of the targeted host.

Target OS

The Operating system targeted by the malware.


Name of the Juniper ATP Appliance traffic inspection Collector that performed the initial object analysis and sent the malware object to the Core engines for behavioral analysis.

Date & Time

The timestamp for the malware download or infection as the current local time in the UTC standard format.


Click the up or down arrow in the column header to reorder the column contents.

Use the Details tables and sub-tab displays to review detailed information about any threat row selected from the Incidents table. The Details table is specific to the row selected in the Incidents table above, and it updates every time a new row is selected in the Incidents table.

Details Summary

The following table describes the categories in the Details Summary window.

Table 2: Details Summary window




The date and time of the detected threat.


Targeted host or device.


A summary description of the risk and threat name.


The severity rating.

Source IP

IP address or domain name of the malware source


Single or combined Kill Chain stages; example: DL+IN


Threat Metric context determination; example: OS Mismatch

Asset Value

User-defined network segment asset value.


Static analysis, behavioral analysis, reputation and network engines that were triggered by the events related to this incident.

Viewing Golden Image Results in Incidents Summary

A row in the Incidents tab Summary table displays Custom VM Image detection results for infection (IN) and exploit (XP) events as “Golden Image,” as shown below.

If three custom VM images have been configured, then three golden image results will show in the Summary.

Configure a custom VM golden image(s) specific to your enterprise OS environment(s) from the Config>Custom VM Image page of the Central Manager Web UI.


There are several circumstances in which the Golden Images results field on the Summary tab (outlined in the figure above) might be empty. For example, the malware may have been blocked by the AV (and hence would not undergone malware analysis in the detection engine) so no analysis results would be generated, or the malware was perhaps detected by the signature engine but not by the regular detection engine (and hence would not have been re-cooked by the golden image analysis engine).

Object Rescans History Timestamps on Incidents Page

Juniper ATP Appliance automatically rescans objects in order to ensure that the static and reputation detection results are up-to-date, and to protect against false positives and false negatives. In addition, when new machine learning models are available, any recaptured objects are analyzed to produce a new set of static, behavioral and reputation detection results


Juniper ATP Appliance sends an HTML email alert when correcting false negative events (when the appliance rescans and there is a detection). Alerts are not sent for false positive events.

The Juniper ATP Appliance Web Central Manager Incidents page displays the detection history of each scanned and analyzed object to show detection changes over time. The timestamps for each object rescan are shown in the History section of the Details area on the Incidents page; shown below.

In addition, this improved detection functionality includes alerts for each malware event detected during rescanning and re-analysis. An alert after rescanning may change a false positive result to a corrected benign event.

When an HTML email alert is generated following an object rescan event, the alert message states:

“Alert generated due to new analysis of sample” (this message differentiates a normal alert from a rescan alert):

Custom Time Range Filtering

Use the Custom Time Frame option to query for a slice of the detection database by time. The Custom Time Frame filter is available from the same pulldown menu from which to select filtering for the Last 24 hours, Last Week, and so on.

From the Incidents page, select Custom Time Frame from the dropdown menu shown in the following Web UI figure in order to display all incidents (including benign) for the time period you designate; you can then use the search to query a specific MD5 for example.


Benign objects are automatically cleared from the detection database after 30 days.

Several Use Cases for Custom Time Range filtering of the detection database:

  • To find an event that a Third Party detected but not displayed in the Benign listings.

    1. Select Custom Time Range

    2. Search by a text string found in the Incident columns.

  • To find all events seen from a particular Traffic Collector

    1. Select Custom Time Range

    2. Sort by Collector name or Search by text string found in Incident columns.

Malware Download Naming Conventions

The general naming scheme for malware downloads is as follows:

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