In the ongoing fight against cyber-threats, alert mapping is a useful tool for security analysts. It allows organisations to build an “alert library” via which they can better understand and contextualise threats going forward. As such, it’s fundamental to what we do here at SOC.OS. With the right approach, you can establish a rudimentary “how” and the all-important “why” of any cyber-attack.
How to map alerts with MITRE ATT&CK®
The MITRE ATT&CK framework is an industry standard knowledge base, providing a common language and real-world data with which to recognise and combat threats. Taking the above alert as an example, we’ll take you through the steps of manually mapping an event to the framework.
There are four key stages:
- Separate the alert into component parts
- Identify the connotations of component parts
- Use the components to build a colloquial understanding of the alert
- Match your colloquial understanding to the ATT&CK matrix
1. Separating the alert into component parts
An alert may contain information about what has triggered the alert, where on the network it was triggered, what system component it affects and what potentially malicious activity it references.
In this particular alert we can see that it was registered by “vBulletin”, on a “Routestring”, affects a “widgetConfig” and was an instance of “Remote.Code.Execution”.
2. Identifying the connotations of these component parts
VBulletin is a community forum software, that allows a community of customers or users to interact, solve queries and provide feedback.
A Routestring describes the connections between two hosts, so for example between the vBulletin forum and your organisation’s network, or those of your users.
A widget refers to a part of a Graphical User Interface (GUI) that allows the user to interact with an application or website and its operating system, prompting a user for input and/or providing information. Its configuration, or “Config” could refer to its initial settings or parameters.
Remote Code Execution is fairly self-explanatory: the adversary has gained access to a system and has deployed malicious code remotely.
3. Understanding the alert in plain language
From the individual components of this alert we can understand that:
- A public-facing software has been the site of an attack
- A stepped connection between this software and a network has been compromised
- A widget, or interactive feature’s settings have been altered. This widget could be prompting users to enter data, credentials, click a button or download a file
- The adversary has succeeded in accessing the application, installing malicious code, and running their own programming on an application
4. Mapping to the MITRE ATT&CK Framework
We can see that the breach occurred via vBulletin, or via an Exploit Public Facing Application (T1190) attack, an initial access technique.
Taking more context into account, this attack can be considered an Exploitation of Remote Services (T1210) attack, categorised as a lateral movement tactic. This type of attack “occurs when an adversary takes advantage of a programming error in a program, service, to execute adversary code.”
The need for automation
Hopefully this explanation of manual alert mapping has helped you to understand the alerts produced by your security tools in the context of the MITRE ATT&CK framework. What is clear, however, is how much of this is open to individual interpretation.
This is where automation can help. Building an alert database and using existing data to inform the categorising of alerts removes or at least reduces the capacity for human error. With automated mapping, your team is free to work on other tasks, and as the dataset grows it becomes more useful.