LinkedIn
Twitter
In our previous post, we introduced the alert graph and discussed its capabilities and the data that can be found on it. This time we are going to apply the alert graph to an investigation and broaden our investigation beyond a single alert to gain a wider view of the associated alerts and entities.
We will start with an alert relating to exfiltration from BigQuery. The alert has identified the user account 294955789211-compute@developer.gserviceaccount.com and IP address 104.198.226.161. We can also see that there are two impacted resources, the customers and keyscustomers tables, both within the claims dataset in BigQuery.
As we review the alert context sub-tab, we can view additional context regarding this alert. When we click on the customers table in the graph, we can see that there are additional alerts at the bottom of the view that are related to this resource within the past day. If we click the plus on the specific entity, we will see the entity’s associated alerts expand in the graph. I’ve already clicked the plus on this entity to expand the associated alerts, but you can see other entities have them as well.
Just a bit of warning, as we expand and pivot in the alert graph, I will be moving a few entities around to better arrange the information. If it looks like I am clicking on the same entity, it’s just that I slid that entity to a space where the additional alerts and associated entities were easier to visualize in the graph.
In our example, we can see that the alert SCC: BigQuery Exfiltration with DLP Context is associated with the same userid as our original alert and there is a new associated resource. Clicking on the alert itself will highlight the alert and its associated entities as well as add cards for the alert and entity. As we review our alert context, we can see that our impacted customers table appears to be exfiltrated to another BigQuery table called patients in the criticaldataset dataset. We can also see that this table appears to have sensitive data in it including social security numbers, credit card numbers, date of birth, and more.
If we turn our focus to the keyscustomers table resource, we can see that there is another alert also associated with this same user account. This time it looks like the contents of the keyscustomers table have been extracted to a storage bucket and the data in the table includes email addresses and encryption keys.
The common thread in all of these alerts appears to be the account 294955789211-compute@developer.gserviceaccount.com. If we click the plus on this user entity, we can see that there is an alert associated with it called SCC: Persistence Anomalous Grant with Context on Post-Grant API Actions. This alert is associated both with this account and the IP address we saw in our first alert, but it also adds two additional entities, an account and a resource. As we review the alert context, we can see that the anomalous account that was added is called analyticsworkload@production.iam.gserviceaccount.com and the resource that was created by the account is an instance with the name of workload-12345 in the us-central1-a zone. It appears that the role that was granted to the user was an editor role and it was used to create a compute instance.
What have we learned from our investigation? It would appear that the account 294955789211-compute@developer.gserviceaccount.com is being used to extract sensitive data from BigQuery and move it to tables and storage buckets. This same user is also creating additional workload instances, possibly with the keys that were extracted from the table. This illustrates how the alert graph can be used to view associated alerts and entities during an investigation. While we could adjust our time frame to broaden or narrow our investigation timeframe to determine if additional alerts are impacting these entities, we are going to stop here.
Before I wrap this up, I did want to include a “and one more thing…” to this blog.
While we have focused on alerts, did you know that the alert graph can also work on detections? When we talk about detections, we are talking about rules that are triggered but for whatever reason don’t have an alert associated with them. Perhaps the rule is only being tested and validated, it’s something that our threat hunters are using or events that the rule matches on are considered informational or contextual by the security team and don't warrant an alert being sent to their queue for triage.
These non-alerting detections can be made available in the graph by selecting graph options at the top of the graph view. If selected, when an entity is expanded, these detections will appear, but rather than a triangle with an exclamation point they will be indicated by a circle with an exclamation point. We can see that both in the card view on the left and in the graph.
Notice that the context from the rule carries over into the alert context sub-tab. In this example, we have Microsoft Entra ID events from Office 365 and Azure Active Directory. The Azure AD events are not alerting, yet we can use both in our investigation.
Chronicle SIEM users will find the alert graph in the Alerts & IOCs section of the UI when they select an alert. For users of the new integrated SecOps interface, the graph is found within each alert tab within a case.
I hope this mini-series has been helpful and encourages you to add outcome variables to your rules, so that you take advantage of all that the alert graph has to offer!