FortiCNAPP Intrusion Graph – Visualizing the Propagation of Threat Activity
Intruder Movement
Cyber intruders gain access to cloud environments in a variety of ways, ranging from the exploitation of vulnerable software to the use of leaked or harvested access keys. In many cases, these intruders do not stay put; they move through the environment to expand their opportunities for exploitation and persistence. Evidence of this movement is essential for differentiating benign versus malicious behavior and for successfully remediating genuine intrusions.
Composite Alerts
FortiCNAPP presents suspected intrusions in the form of Composite Alerts. The aim with Composite Alerts is to assemble a complete narrative of suspicious activity, so that it may be triaged without your security team having to look elsewhere for more context. We have designed Composite Alerts to track within a single alert all entities and activity that may be associated with one another. Examples of what we look for include entities associated by suspected lateral movement, privilege escalation, and access via the same anomalous source. We also correlate entities exhibiting similar rare behaviors. Composite Alerts evolve over time as new evidence of suspicious activity is detected.
Because a Composite Alert can span multiple hosts, containers, and identities, it can be challenging to quickly understand the relationships between the key cloud entities involved. To address this issue, we have added a new feature to Composite Alerts called the Intrusion Graph.
A screenshot of the Intrusion Graph in the FortiCNAPP UI. The Intrusion Graph is rendered in the Observations Tab of Composite Alerts.
The Intrusion Graph
The Intrusion Graph is designed to provide a compact visual summary of the most important relationships within a Composite Alert. To ensure these graphs remain easily readable even for alerts that include numerous entities and threat signals, we will group entities and the relationships together. Fine-grained investigation is enabled by clicking on the nodes and edges in the graph to reveal all the specific interactions.
Node Click: Lists Individual Entities:
Clicking a node will show the list of individual entities represented by the node. In this case the machine node represents two separate hosts.
Edge Click: Lists Individual Relationships:
Clicking an edge will show the list of individual relationships represented by the edge. In this case the ran anomalous process edge represents four specific relationships between one host and four processes.
The Intrusion Graph summarizes a wide variety of suspicious activity in a compact visual form. As such, the best way to describe the benefits of this feature is by way of example.
Examples
Example 1: Suspicious Access and Action

We have found that when suspicious actions performed by a host or identity co-occur with suspicious access of that host or identity, the likelihood of an intrusion increases substantially. That is why the Intrusion Graph is designed to ensure that these distinct kinds of signals are clearly presented as separate stages of the suspected intrusion.
In this case, a host has been accessed by two separate suspicious IP addresses, and then that same host has gone on to launch nearly a hundred suspicious processes. After seeing this succinct summary of the signals presented in the alert, the customer would be able to drill into the details about these signals either by clicking on the edges and nodes in the graph or by consulting the Observation Timeline.
Example 2: High Confidence Evidence

In cases where certain observations provide strong evidence of a penetration test or compromise, we augment the Intrusion Graph with those artifacts to more clearly justify the alert. In the case above, evidence of the use of the secret-scanning tool Trufflehog was identified in a user agent string. Because that signal is such clear evidence that an intrusion is underway, it is explicitly included in the Intrusion Graph.
Example 3: Aggregation Based on Similar Behavior

When multiple machines or identities exhibit similar suspicious behavior around the same time, the Intrusion Graph will aggregate those entities together into a single alert based on that shared behavior. In those cases, the shared behaviors are themselves represented as one node in the graph. The collection of machines exhibiting those behaviors are presented as one or more other nodes linked with the “shared behavior” relationship. Notably: while the Intrusion Graph often aggregates entities of the same type, it may hold out individual entities when their relationships are uniquely significant. In the example above, all four machines in the Intrusion Graph exhibit similar suspicious behaviors, but only the jump host was contacted directly by suspicious remote hosts, so it is presented separately.
Example 4: Intruder Movement – IAMUser Assumes Role

In another example, multiple machines or identities are included in an alert because one entity acted upon another, potentially constituting lateral movement or privilege escalation. In the example above, the IAMUser, after being accessed from multiple distant geolocations in a short period of time, assumed multiple roles. For that reason, the activity of those roles is also considered relevant to the alert, and thus the roles are presented in the Intrusion Graph.
Example 5: Intruder Movement – Use of Instance Roles

One of the most important features of Composite Alerts is their ability to automatically correlate signals across different data sources. In the graph shown above, the Composite Alert has correlated signals generated from agent telemetry with those collected from the AWS audit logs. In this scenario, an EC2 instance was compromised via a suspicious remote host. The intruder then leveraged the Assumed Role Identity of the EC2 instance to create a new IAMUser, establishing a persistent backdoor into the environment. Taken separately: connecting to new hosts, calling sensitive APIs and the creation of new users are not remarkable. Taken together, however, these signals paint a picture of a potential intrusion in progress that demands further investigation. The Intrusion Graph presents the evidence collected in the Composite Alert succinctly. The graph allows the responder to quickly understand the scope of the alert and explains why signals from both host machines and AWS identities are included in the Observation Timeline.
Example 6: Intruder Movement – Hard-Coded Keys

There are multiple ways for intruders to escalate their access from a compromised host to the cloud control plane. Beyond hijacking the Role of an EC2 Instance, hard-coded keys on a host also provide a potential mechanism for an attacker to gain access to AWS Identities. In the case above, AWS keys were detected on a machine that was accessed from suspicious IP addresses. When users that can be accessed by those keys then begin exhibiting suspicious behavior, the Composite Alert combines those signals into one narrative. This automatic correlation significantly lessens the burden of investigation for our users both directly and in collaboration with the FortiCNAPP AI Assistant.
Conclusion
Detecting intrusions is difficult because the individual steps of an attack are often indistinguishable from normal background activity. An actor’s intent may only become clear when multiple pieces of observations are assembled into a coherent picture of an intrusion in progress. FortiCNAPP Composite Alerts builds that picture automatically. Now, with the addition of the Intrusion Graph, that evidence is presented clearly and succinctly in a visual form. By showing the propagation of suspected threats this way, we make it even easier for our customers to identify and fully contain intrusions early, before attackers can cause significant harm.
