The MITRE ATT&CK framework is a very popular concept in the security circle recently. I will start to record the ATT&CK learning from this article.
Before introducing ATTCK, please think about a few questions:
1). How to answer your boss’s question:
How is our security doing now, what attacks can we prevent, and what is the gap with others?
Why do you need to purchase these equipment in this year’s budget? Didn’t you just buy XX last year? How can you buy it again?
Why do I have such problems after buying so many safety equipment?
2. If you want to build a SIEM or SOC system:
What data need to be collected?
What rules have been made, what scenarios can be detected, and can these rules and scenarios be applicable in our environment?
How to verify that the rule scenario is valid?
3. If you want to build your own threat intelligence
How to collect threat intelligence and what can be collected?
So many questions, in the final analysis, are how to evaluate the current security situation in the organization and how to gradually promote the construction of security defense.
Someone might say that we have deployed host protection, WAF, and next-generation firewalls, which can detect webshells, Trojan horses, traffic analysis to detect DNS tunnels, malicious domain names, and repair all high-risk vulnerabilities and no high-risk ports. .. and so on. These enumerate the functions and scenarios of existing safety inspection equipment.
There is a problem. How do you ensure that the detection and protection scenarios you listed cover all known attack methods? How many known “attack techniques” are there? If it is not full coverage, how much is coverage? Usually experienced security practitioners will tell you directly that the detection method scenarios listed are best practices derived from experience.
This is indeed the case. Reliable safety experience is very important. These experiences can work out the best safety construction plan based on the current situation of the organization. But experience is a very personal thing. Every security officer understands that his ultimate goal is to protect the information assets in the organization. However, due to different security experiences and different understandings of security, different security practices will be produced. Practice will also produce different safety effects.
Is it possible that there is a way to summarize the experience of all security practitioners and form a common security knowledge framework?
MITRE ATT&CK is a good tool that can solve the above-mentioned problems.
1. What is MITRE ATT&CK
MITRE is a non-profit organization that provides systems engineering, research and development and information technology support to the US government. The well-known security standards and specifications such as CVE, CWE, and CVSS are all from the organization.
ATT&CK is a knowledge base of confrontation tactics and technology created and maintained by MITRE. Its full name is Adversarial Tactics, Techniques, and Common Knowledge, or ATT&CK for short. This knowledge base is community-driven, and is an open, free, and globally accessible knowledge base.
ATT&CK is a selected knowledge base and model for cyber attack behavior, reflecting the attacker’s attack life cycle and the goals of each attack stage, and consists of the following core components:
Tactics: Indicates short-term tactical goals during the attack;
Techniques: describe the opponent’s means to achieve tactical goals;
Sub-Techniques: describe the opponent’s technical means to achieve tactical goals at a lower level than technology;
Note: In ATT&CK, “adversary” can also be generally understood as “attacker”. This “attacker” may not be the real attacker, or it may be the “attacker” in the red-blue confrontation exercise; in this article, if none Special note, there is no difference in the meaning of these two words.
ATT&CK has three core concepts, generally speaking:
Based on observation
Appropriate abstraction level can combine attack behavior and defense strategy;
1.1 Attack perspective
ATT&CK is different from other defensive models (for example, CVSS, which focuses on vulnerability scores, and DREAD, which focuses on risk calculation). ATT&CK uses the attacker’s perspective in terms of its terminology, model strategies, and technologies. The detection alarms from the defense perspective lack the context of the alarms, making these alarms difficult to be analyzed in depth. Therefore, ATT&CK uses the attack perspective to understand the actions and potential countermeasures in the context more easily than from a pure defense perspective.
The change of perspective changes the problem from “what happens based on the list of available resources” to “what may happen in the framework of the combination of offense and defense”, and to some extent provides a more accurate frame of reference for how to evaluate the scope of defense.
The ATT&CK reference frame has nothing to do with defense tools or specific data collection methods. Defenders can understand the relationship between these actions and specific defense categories in the environment as long as they follow the motivation of the attacker’s individual actions in the framework.
1.2 Based on observation
Most of the attacks described by ATT&CK are based on public events, most of which involve APT organizations, and these public events have become the basis of ATT&CK’s knowledge base. On this knowledge base, it is possible to more accurately describe “in the wild” technology or possible attacks.
ATT&CK will also absorb attack reports from the company’s intranet and technologies discovered in offensive and defensive exercises (for example, technologies that can subvert common defenses).
ATT&CK is a model framework based on observations of real events. It is an attack technique for real threats that organizations may encounter. Therefore, these techniques are not “difficult to use” or “usage rate is too low” to be less visible theory. technology.
ATTCK observation sources mainly include the following categories:
In addition, ATT&CK observes the target is the attacker’s attack methods, tools and behavior patterns, also called “tactics, techniques, and procedures (Tactics, Techniques, and Procedures, TTPs)”, referred to as TTPs.
When it comes to TTPs, you must not get around “Pyramid Of Pain.” The Pyramid of Pain describes the IOCs of the offensive and defensive process. TTPs are at the apex of the Pyramid of Pain, as shown below:
The Pyramid of Pain
For the attacker, TTPs reflect the behavior of the attacker, and the time and money costs required to adjust TTPs are also the most expensive. For the defender, detection and response based on TTPs may cause more pain to the opponent.
Therefore, TTPs are also the most valuable type of IOCs in the pain pyramid for defense. On the other hand, such IOCs are more difficult to identify and apply. Since most security tools are not suitable for using them, it also means that the difficulty of collecting and applying TTPs to network defense is the highest.
For a more detailed introduction to “Pyramid of Pain”, you can check this link: The Pyramid of Pain.
The main objective of ATT&CK’s observation is the attacker’s TTPs, and records of observation results are summarized and classified to form a knowledge base.
To put it simply, ATT&CK is a knowledge base based on observations and summaries of actual TTPs that have occurred. This is not the result of academic theories, which means that ATT&CK has strong practicality and landability.
1.3 Level of abstraction
The abstraction level of “Tactics” and “Techniques” in ATT&CK is an important difference between it and other security models.
The general security model can be divided into three abstract levels: high, medium and low:
High-level abstraction: For example: Lockheed Martin Cyber KillChain®, Microsoft STRIDE
Intermediate abstraction: For example: MITRE ATT&CK
Low-level abstraction: for example: exploit library, malware library;
High-level abstract security models are useful for understanding high-level processes and attack targets, but these models cannot effectively convey the actions of the attacker and the relationship between the actions, nor can they describe the action sequence and the defense strategy in the environment (monitored Data source, defense, configuration, etc.).
For low-level abstract models, such as exploit data, it describes specific instances of exploitable software (these instances are usually used together with code examples), but these instances cannot well describe whether or not they can (should) be used and used How difficult are they”. Similarly, malware databases often lack the context of “how to use malware and by whom”, and they also fail to consider “how to use legitimate software for malicious purposes”.
Therefore, in the actual environment, an intermediate abstract model like ATT&CK is needed to combine the different components of the above-mentioned high-level abstract model and low-level abstract model.
The “tactics” and “techniques” in ATT&CK define confrontational behaviors in the life cycle to a certain extent, enabling them to be effectively mapped to defenses. The concepts of high-level abstract models such as “control”, “execution” and “maintenance” are further subdivided into more specific categories in ATT&CK, and then more specific actions are defined and classified in these categories.
They are very useful toolkits for lower-level concepts such as exploit libraries and malware libraries. However, due to their large number, it is difficult to behave in addition to regular vulnerability scanning, quick fixes, and IOCs. It is explained in the analysis. To fully understand their utility, one must understand the context in which they achieve their goals. The intermediate abstract model ATT&CK can associate low-level abstract information such as vulnerability libraries (or malware libraries) with event data to show who is doing what and the general usage of specific technologies.
Schematic diagram of each abstraction level:
In general, the technical abstraction of ATT&CK realizes the following two points:
A common classification of actions and goals that both offense and defense can understand.
The appropriate level of classification links the opponent’s actions with specific methods of defending it.
1.4 Universal language
I added this point. The official document does not mention this point separately, but I think “universal language” is also the reason why ATT&CK is so popular, and it is also one of the most important values of ATT&CK.
As mentioned earlier, ATT&CK observes and studies the behavior of attackers based on the real world from the perspective of attack, and classifies and abstracts the observed results into specific tactics and techniques. In this process, all observed attack behaviors are invisibly standardized and processed to form a language and vocabulary for describing attack behaviors (TTPs).
Remember the personal experience of security experts mentioned earlier? After classification and abstraction, ATT&CK can incorporate most of the experience of security experts. It is equivalent to that ATT&CK provides a standard language for describing offense and defense. As long as this language is followed, the experience of security experts can be described. When the safety experience can be described, the efficiency and quality of communication can be effectively improved.
Imagine how security practitioners describe a vulnerability before there was no CVE (Common Vulnerabilities and Exposures). Imagine the following scenario:
Boss: Linda, have we fixed the Nginx vulnerability that just appeared?
linda: Boss, which loophole are you talking about? In recent months, Nginx has many vulnerabilities, one in version 13.02 and two in version 12.93.
Boss: That’s the one that can affect the ssl version and can steal the key;
linda: Is it that, Nginx affected…
Boss: No, it’s that…
linda: Oh, ah, the official website has released a new version, just saying that XX vulnerabilities have been fixed, but I don’t know if this is included. It needs to be verified online..
Before there is a CVE vulnerability number, it is actually difficult to describe a specific vulnerability of a program. Describing a vulnerability is usually described by using information such as vulnerability description, software version number, utilization principle, and risk level. Different organizations or individuals have different understandings of the vulnerability. , It will describe different things, and it will be particularly difficult to communicate. But when the CVE number appears, the complex vulnerability description is abstracted and refined into a number, and the vulnerability details can be quickly located based on this number, which greatly saves communication costs.
Following the above example, if you have the CVE number, the above dialogue can be simplified a lot:
Boss: Linda, have we fixed the CVE-2020-0000 vulnerability that was released recently?
linda: Oh, boss, the CVE-2020-0000 vulnerability is an Nginx privilege escalation vulnerability that affects the XXX version. The official website released a new version this morning that can fix this vulnerability, and the new version also fixes CVE-2020-002 , CVE-2020-003 vulnerability. Our environment is already on the line, and it is expected to be fully restored today.
Boss: Okay, follow up in time.
It can be seen that with the CVE number, the efficiency of vulnerability description can be greatly improved. And from the actual situation, CVE has also become a very important de facto standard for vulnerability description. When describing a vulnerability, everyone will use CVE to describe it.
Similarly, ATT&CK is also a standardized description of “aggressive behavior”. Various types of observed attacks are classified into general descriptions, and even these categories are assigned unique numbers. In this way, the attacks can be described as easily as CVE descriptions of vulnerabilities.
For example, Groups G0020 represents the APT organization “Equation (Equation Organization)”, so when using G0020 in communication, you can directly understand that it is the “APT organization that once developed the Eternal Blue”;
For another example, the T1053.003 technology is under the tactical “Excution” TA0002, which represents the crontab timing task under the Linux platform. When describing this technology, I will directly mention the specific technical concept of T1053.003 instead of the ambiguous “timing” Task” concept.
Imagine again, if an APT organization uses crontab to implement a malicious code execution under the Linux platform, it can be simply described as:
G0030, the APT organization, used T1053.003 technology to achieve the TA0002 tactical goal;
In this way, a simple sentence can describe the attacker, attack behavior, and attack technique clearly, without ambiguity and easy to understand.
More importantly, after a standardized description of attack behavior, the implementation of automated detection is more convenient for the development of security tools and security strategies. Thinking about how many security tools are based on CVE, it is not difficult to imagine how many security analysis tools will be developed based on ATT&CK in the future.
As ATTCK continues to be known, ATT&CK will also become a de facto standard for “attack behavior”. Based on this standard, security practitioners can describe the organization’s security status, protection capabilities, offensive and defensive exercises, security product capabilities, and security products. Coverage can also describe the security capabilities of the entire organization, such as the maturity of the security operation system, defense gaps, and current status assessment.
2. ATTCK technical field
ATT&CK consists of a series of technical fields. Up to now, MITRE ATTCK has defined 3 technical fields, namely
Enterprise: traditional enterprise network and cloud environment;
Mobile: mobile communication equipment;
ICS: Idustrial Control System Industrial Control System
In each technical field, ATT&CK defines multiple platforms (platforms), a platform may be an operating system or an application; “technology” and “sub-technology” can be applied on different platforms.
|Enterprise||Linux, macOS, Windows, AWS, Azure, GCP, SaaS, Office 365, Azure AD|
In addition, PRE-ATTCK is an extension of the ATT&CK technical field, which covers the description of the demand collection, investigation, and weaponization of confrontation before gaining network access. It is independent of “technology” and through the “attackers attempt to gain access to organizations Behavior” for behavior modeling.
The first ATT&CK model was created in September 2013, mainly focusing on the Windows enterprise environment. Through internal research and further improvement and development and then publicly released in May 2015, it covers 9 tactics and 96 technologies. Since then, ATT&CK has experienced tremendous growth based on the contributions of the cybersecurity community. MITRE created several additional ATT&CK-based models based on the method of creating the first ATT&CK. The original ATT&CK was expanded to versions other than Windows in 2017, including Mac and Linux, and was called Enterprise ATT&CK. PRE-ATT&CK was released in 2017, focusing on kill-chain’s “left-side attack” behavior. The mobile version of ATT&CK was also released in 2017, focusing on behaviors in mobile-specific areas. ATT&CK Cloud was released as part of Enterprise in 2019, describing the behavioral environment and services for the cloud. ATT&CK for ICS was released in 2020 and included attacks on industrial control systems.
PS: Unless otherwise specified, the ATT&CK model mentioned in this article refers to Enterprise, and ATT&CK for ICS, PRE-ATTCK and Mobile are temporarily out of the scope of this article;
3. ATT&CK composition
3.1 ATT&CK matrix
The foundation of ATT&CK is a set of “techniques” and “sub-techniques”. These “technologies” and “sub-technologies” represent actions that the opponent can perform to achieve goals. These goals are represented by the “tactical” category to which “technical” and “sub-technique” belong.
“Tactic” refers to the target of the attack, while “technique” refers to the technology executed to achieve the goal, and “sub-technology” is a more specific technical description than “technology”.
At this stage, ATT&CK divides known attacks into 12 tactics, 156 technologies and 272 sub-technologies;
The relationship between “tactic”, “technology” and “sub-technology” is visualized through the ATT&CK matrix.
Tactical and (sub)technical matrix
“Tactics” is the “objective”. In a sense, “tactics” is the meaning of “technical” execution and the reason why the opponent performs specific attack techniques; “tactics” is the context category of individual “techniques”, covering the opponent The standard notation of what is done in the course of action, such as Persistence, Discovery, Lateral Movement, Execution, Exfiltration, etc. “Tactics” is also regarded as a label in ATT&CK. If different “technologies” or “sub-technologies” achieve the same purpose, they will be labeled with the same “tactical” label;
Each “tactical” has a definition that describes the category and serves as the basis for classification of “technical”. For example: “Execution” is defined as a “tactic” that means “(sub)technique” that “results in the execution of hostile control code on a local or remote system”. This “tactic” is usually used together with “initial access”. As a means to execute code once access is gained, and to move laterally to expand access to remote systems on the network.
In addition, other “tactical” categories can also be defined as needed to more accurately describe the opponent’s goals. The application of ATT&CK modeling methods in other fields may also require new or different categories to associate technologies, although there may be some overlap with the strategy definitions in existing models.
Example: Execution Tactics
3.3 Technology and Sub-Techniques
“Technology” represents the “method” by which attackers perform actions to achieve “tactical” goals.
“Technology” represents how an opponent performs an action to achieve a “tactical” goal. For example, an adversary may dump credentials from the operating system to gain access to useful credentials in the network.
“Technology” can also represent the “what” an opponent obtains by performing an action. For “Discovery” tactics, this is the biggest difference from other “tactics” because these technologies can highlight the opponent’s specific actions. The type of information obtained.
There may be many methods or techniques to achieve “tactical” goals, so there are multiple “technologies” in each “tactical” category. Similarly, there may be multiple ways to implement a “technology”, so there may be multiple different “sub-technology” under a “technology”.
“Sub-technology” further decomposes the behavior described by the technology into more specific descriptions of “how to use behavior to achieve goals”. For example, for the “OS Credential Dumping” technology, there are several more specific behaviors under this technology that can be described as “sub-technology”, including “access to LSASS memory”, “security account manager” or “access”/etc/passwd” And “/etc/shadow”.
For example: Command and Scripting Interpreter technology
“Technology” main fields and description:
|Name||Field||The name of the technology (sub-technology)|
|ID||Tag||The unique number of the technology (sub-technology) in the knowledge base. Format: (Technology) T####; (Sub-Technology) T####.###|
|Sub-Techniques||Field||Sub-technology id belonging to a certain technology. *Only applicable to technology, not applicable to sub-technology|
|Tactic||Tag||(Sub) Tactical goals that technology can be used to accomplish. The (sub)technology can be used to execute one or more strategies.|
|Description||Field||Information about the (sub)technology, what it is, what it is usually used for, how the opponent uses it, and how it changes. Includes references to authoritative articles on technical information related to the technology, as well as references used in the field.|
|Platform||Tag||A system in which an opponent runs; it may be an operating system or an application (such as Microsoft Windows). The (sub)technology can be applied to multiple platforms.|
|Permissions Required||Tag||The minimum authority required by the adversary to perform (sub)techniques in the system is limited to elevated authority. *Only required in “Elevation of Privilege”|
|Effective Permissions||Tag||The level of authority that the adversary will obtain by performing (sub)techniques. Only applicable to the technology under the (sub)privilege escalation strategy. If effective permissions can be set when performing (sub)technology, there can be multiple entries. *Only required in “Privilege Escalation”|
|Data Source||Tag||The sources of information collected by sensors or log systems can be used to collect information related to identifying the actions being performed by the opponent, the sequence of actions, or the results of these actions. The data source list can contain different variants for performing operations on a specific (sub)technology. This attribute is restricted to a defined list to allow technical coverage analysis based on unique data sources. (For example, “If I have process monitoring, what technologies can I detect?”)|
|Defense Bypassed||Tag||Used to bypass or evade a specific defense tool, method or process. Only applicable to defensive evasion (sub) technology. *Required only in the sub “Evasion of Defense”|
|Version||Field||(Sub)Technical version, format: MAJOR.MINOR|
|Impact Type||Tag||Indicates whether the (sub)technology can be used for integrity or availability attacks. Applies to impact (sub)technology.|
|Detection||Field||Contains advanced analysis processes, sensors, data or detection strategies that can identify a (sub)technology that has been used by an adversary. This field describes the method used for defensive detection, so that security inspectors can take specific defensive methods or actions based on this. There are many detection (sub)technical methods, but ATTCK and MITRE do not recognize specific supplier solutions, so the detection recommendations are only methods or tool types, and have nothing to do with specific suppliers or tools. In addition, even if the (sub)technology is not always possible to be detected, it should be documented.|
|Mitigation||Relationship/Field||Contains configurations, tools, or processes that can prevent (sub)technical execution from being successful or achieve expected results. This field describes how to apply specific mitigation measures to the (sub)technical details, so that security personnel can adopt specific mitigation strategies accordingly. Similarly, mitigation recommendations are still not related to specific vendors, and not every (sub)technology can be mitigated.|
To complete a successful attack, good “tactics” and “techniques” are not enough. The attacker needs to use a special sequence of actions called “procedures” to execute every step of his attack cycle. In ATT&CK, “process” is the specific implementation method used by the adversary for “technology” or “sub-technology”.
It should also be noted that the “process” can span multiple “technologies” and “sub-technologies”. For example, the “process” used by the attacker to “dump credentials” includes PowerShell, Process Injection, and LSASS Memory. They are all different behaviors, so the “process” also includes how to use a specific tool.
In ATT&CK, the observed “process” will be recorded in the “Procedure Examples” section of the “Technology” and “Sub-technology” pages.
For example: Procedure corresponding to Command and Scripting Interpreter technology, the first column is the name of the APT organization, and the second column is the process by which the APT organization implements the technology.
ATT&CK added sub-technology in 2020, which marked a major change in the way of describing behavior in the knowledge base. This change is due to the need to solve some technical abstraction level issues that have emerged with the development of ATT&CK over the years. Some “technical” descriptions are very broad, some are very narrow (only very specific behaviors are described). This imbalance causes ATT&CK to become extremely bloated, which not only makes ATT&CK difficult to visualize, but also makes it difficult to understand the purpose behind certain technologies.
The sub-technology mainly improves the following points of ATT&CK:
Make the level of abstraction of the technology similar throughout the knowledge base
Reduce the number of technologies to a manageable level
Provide a structure that allows easy addition of sub-technologies, which will reduce the need to make changes to the technology over time
Some technologies may not be simple and can be implemented in a variety of ways, and these methods need to be considered
Simplify the process of adding new technology (overlapping technology) domains to ATT&CK
Enable more detailed data sources and descriptions so that behavior can be observed on a specific platform
There is no one-to-many relationship between “sub-technology” and “technology”. Each “sub-technology” will only have a relationship with one parent “technology”, which can prevent the entire model from becoming complicated and difficult to maintain.
In some cases, “child technologies” with multiple parents may use “technologies” that span multiple “tactics.”
For example, the scheduled task/job (Scheduled Task/Job) technology is included in both the “Persistence” tactics and the “Privilege Escalation” tactics. Only one of its four sub-techniques These sub-techniques are suitable for “Privilege Escalation”. In this case, “Sub-Techniques” does not need to belong to all “Tactics”, even if the parent “Techniques” of the “Sub-Techniques” belongs to this ” Tactics”. As long as “Sub-Techniques” conceptually belongs to “Techniques”, there is no need to satisfy the “tactics” of each parent “technology”.
The meaning of the above passage is that “Sub-Techniques” is only related to its parent “Techniques”, and has nothing to do with the “Tactics” to which “Techniques” belongs.
The attributes of “sub-technology” in ATT&CK are basically the same as “technology”, but the ID will be suffixed after the parent “technology” to show the difference.
For example: PowerShell, a sub-technology of Command and Scripting Interpreter
In ATT&CK, “Groups” are objects used to track known attackers. “Groups” are defined as named intrusion sets, threat groups, participant groups, or activities. They usually represent targeted and continuous Threat activity. ATT&CK mainly focuses on APT groups.
For example: APT32
“Group” main fields and descriptions:
|ID||Tag||The unique number of the group in the knowledge base. Format: G####|
|Version||Field||The version of the group, format: MAJOR.MINOR|
|Description||Field||Based on the description of the group in the public threat report, it may contain activity time, suspicious details, target industries, and other notable events attributed to the group.|
|Techniques / Sub- Techniques Used||Relationship/Field||A list of (sub)techniques used by the group, and details describing how the group uses the technology (in the context of TTPs).|
Attackers usually use different types of software during the invasion. Software can represent an instance of “technology” or “sub-technology”, so classification in ATT&CK is also necessary.
Software is divided into two categories: tools and malware.
Tools: Refers to commercial, open source, self-developed or publicly available software that can be used by defenders, penetration testers, red team members, or adversaries. This category includes software that is not normally found on enterprise systems, as well as software that is usually obtained as part of an operating system that already exists in the environment. Such as PsExec, Metasploit, Mimikatz, and Windows utilities such as Net, netstat, Tasklist, etc.
Malicious software: Refers to commercial, open source or closed source software used for malicious purposes. For example: PlugX, CHOPSTICK, etc.
Software categories can be further subdivided, but the idea behind the current classification is to show how adversaries use tools and legitimate software to perform actions, just as they use traditional malware.
|Name||Field||name of software|
|ID||Tag||The unique number of the group in the knowledge base. Format: S####|
|Version||Field||Software version; format: MAJOR.MINOR|
|Type||Tag||Software type, “malware” or “tool”|
|Platform||Tag||The platform used by the software, such as Windows|
|Description||Field||Software description based on technical references or public threat reports. It may contain technical details related to groups known to use the software or other related to it.|
|Techniques / Sub- Techniques Used||Relationship/Field||List of (sub)technologies implemented or used by the software;|
Mitigations in ATT&CK are a security concept and technology category used to describe “how to prevent a certain technology or sub-technology from successfully executing”;
As of March 2020, there are 41 mitigation measures in Enterprise ATT&CK, which include application isolation and sandboxing, data backup, execution prevention, and network segmentation. The mitigation measures have nothing to do with the supplier’s products, and only describe the category or category of the technology, not a specific solution.
for example：Disable or Remove Feature or Program
The main fields and descriptions of “Mitigation Measures”:
|Name||Field||Search measure name|
|ID||Tag||The unique number of the group in the knowledge base. Format: M####|
|Description||Field||Description of mitigation measures|
|Version||Field||Version of mitigation measures; format: MAJOR.MINOR|
|Techniques Addressed by Mitigation||Relationship/Field||A list of (sub)technologies that this mitigation measure may involve.|
3.7 The relationship between ATT&CK components
The above-mentioned components do not exist alone. In ATT&CK, each component is related to other components in some way.
The relationship between them can be shown in the following diagram:
ATT&CK Model Relationships
For example, the APT28 organization uses Mimikatz to dump the credentials of the Windows LSASS process memory, which can be represented by the following figure
ATT&CK Model Relationships Example
4. ATTCK usage scenarios
There are so many ATT&CKs mentioned above, but the most important thing is the usage scenario. There are mainly 4 scenarios in ATTCK usage scenarios, each of which is officially guided by best practices, and some tools that can be used in the scenario are listed.
This article only provides a basic description of the scenes, and I will write a few more articles to try to describe the usage of each scene one by one.
Cyber Analytics Repository (CAR) is an analysis knowledge base developed by MITER based on the MITER ATT&CK opponent model, which can be used as a starting point for organizations to conduct behavior detection and analysis on ATTCK.
ATT&CK can be used as a tool for constructing and testing behavior analysis to detect hostile behavior in the environment and identify potential malicious activities in the system or network.
Traditional detection usually uses intrusion signatures (IOCs) or malicious activity signatures to detect. Behavior detection analysis is different from traditional feature detection. Behavior detection analysis does not rely on prior knowledge (IOCs or signatures), and has nothing to do with the tools used by the opponent.
4.1 Behavior detection analysis
4.2 Threat Intelligence
Cyber threat intelligence covers the network and the knowledge of threat actors (groups) that affect network security. It includes information about malware, tools, TTPs, espionage technology, behavior, and other threat-related indicators.
ATT&CK understands the attacker from the perspective of behavior analysis, and includes documents that have nothing to do with the tools that the attacker may use.
Through these documents, analysts and defenders can better understand the general behavior of each attacker, and effectively map it to their own defense system. In addition, ATT&CK’s structured format can classify behaviors outside the standard to increase the value of threat reports.
4.3 Opponent simulation and red team
Both “adversary simulation” and “red team attack” are behaviors that verify defense capabilities, but they are different.
“Adversary simulation” first assumes which attacking organization it is simulating, and simulates the behavior of the attacking organization based on the threat intelligence information of the organization. By simulating the behavior of the attacker, the whole process of security in a certain technical field is evaluated. “Adversary simulation” focuses on the organization’s ability to detect and/or mitigate the effects of adversary activities at all applicable points in its life cycle.
ATT&CK is a tool that can be used to create “adversary simulation scenarios” to test and verify the defense of adversaries’ common technologies. Specific attacker details will be recorded in the ATT&CK structured documents in the form of documents, and defenders and risk hunters can use these documents to adjust and modify defense measures.
“Red team attack” refers to attack demonstrations with a confrontational attitude without using known threat intelligence. The focus of the red team is to complete the ultimate goal of the operation without being detected, to show the impact of the successful intrusion mission or operation.
ATT&CK can be used as a tool to create “red team plans” and organize actions to avoid certain defensive measures in the network.
In addition, ATT&CK can also be used as a research roadmap to develop new attack methods or methods that may not be detected by ordinary defense systems.
4.4 Gap analysis and assessment
Gap analysis allows organizations to determine which parts of the environment lack protection or lack visibility. These gaps represent potential defense or monitoring blind spots in the environment, allowing attackers to access them without being detected or effectively intercepted. The internet.
ATT&CK can be used as an attack model centered on common behaviors to evaluate whether the tools, monitoring and interception in defense measures are effective. After the gap is identified, the investment plan for defense system construction can be arranged according to priority. Similarly, before buying a security product, you can also compare it with a common adversary attack model to evaluate the coverage in ATT&CK.
In addition, the organization’s security operations center (SOC) is an important part of many large and medium-sized enterprise networks and can continuously monitor threats in the network. Understanding the maturity of SOC is very important to determine the effectiveness of SOC. ATT&CK can be used as a measurement method to determine the effectiveness of SOC in detecting, analyzing and responding to intrusions. Similar to the gap analysis assessment, the SOC maturity assessment focuses on the SOC used to detect, understand, and respond to changing threats and processes in the network.
Before finishing this article, I read the official document “MITRE ATT&CKÒ: Design and Philosophy” of MITRE ATT&CK, and used it as the main reference source for this article. The article “MITRE ATT&CK: Design and Philosophy” elaborated on the design philosophy and philosophy of ATTCK. It is used as a very detailed introductory tutorial to understand the entire system of ATT&CK. Unfortunately, the full text is in English, which seems quite laborious, so this article is Based on this document, some translations and colloquial explanations have been made for better reading and understanding.
I am also a novice to ATT&CK, and there are many details worth studying slowly.
ATT&CK has abundant official information and active community. There are also many detection ideas and tools based on ATT&CK, which can be said to be a treasure house of network security knowledge.