Introduction
The MITRE ATT&CK framework is a very popular concept in the security circle recently. Starting with this article, a new series (keng) will be started to record some learning notes of ATT&CK.
Before introducing the ATT&CK framework, as a security professional in the first party, please think about several questions:
1. How to answer your boss's soul-searching question:
How is our current security doing, what attacks can we prevent, and how big is the gap with the industry?
Why do we need to purchase these devices again this year when we just bought XX last year, why do we need to buy them again?
Why do we still have so many problems even though we have bought so many security devices?
2. If you want to build a SIEM or SOC system:
What data needs to be collected?
What rules have been made, what scenarios can be detected, and are these rule scenarios applicable to our environment?
How to verify the effectiveness of rule scenarios?
3. If you want to build your own threat intelligence
How to collect threat intelligence, what kind of content can be collected?
...
Someone might say, 'We have deployed host protection, WAF, next-generation firewalls, which can detect webshells, anti-reverse malware, analyze traffic to detect DNS tunnels, detect malicious domains, and fix all high-risk vulnerabilities, as well as no high-risk ports... etc., listing the functions and scenarios of existing security detection equipment.',
This raises a question, how can you ensure that the detection and protection scenarios you list cover all known attack methods? Etc., how many 'known' attack methods are there? If it is not comprehensive, how much is covered? Usually, experienced security professionals will directly tell you that the listed detection methods are the best practices derived from experience. (Of course, if you use the 'experience' reason to get next year's security budget from your boss, and if your boss can accept it, it's still pretty good)
Indeed, reliable security experience is very important, and these experiences can be used to formulate the best security construction plan based on the current situation of the organization. However, experience is very personal, and each security professional understands that their ultimate goal is to protect the information assets within the organization. But due to different security experience and understanding of security, different security practices will be produced, and different practices will also produce different security effects.
Is there a methodology that can effectively summarize the experience of all security professionals, forming a common security knowledge framework?
MITRE ATT&CK is a great tool that can solve the above 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 U.S. government. The CVE, CWE, CVSS, and other security standards and specifications that we are familiar with all come from this organization.
ATT&CK is a knowledge base of offensive tactics and techniques created and maintained by MITRE, full name Adversarial Tactics, Techniques, and Common Knowledge, abbreviated as ATT&CK. This knowledge base is community-driven and is a publicly available, globally accessible knowledge base.
ATT&CK is an elite knowledge base and model for network attack behavior, reflecting the attacker's attack lifecycle and the objectives of each attack stage, consisting of the following core components:
Tactics: Represent short-term tactical objectives in the attack process;
Techniques: Describe the means the adversary uses to achieve tactical objectives;
Sub-Techniques: Describe the technical means that the adversary uses to achieve tactical objectives at a lower level than technology;
Note: In ATT&CK, 'adversary' can also generally be understood as 'attacker', and this 'attacker' may not be the true attacker, but could also be the 'attacking side' in red-blue对抗 exercises; In this article, unless otherwise specified, the two have the same meaning.
ATT&CK has three core concepts, to put it in simpler terms is:
Attack perspective;
Based on observation;
An appropriate abstraction level can combine attack behavior and defense strategies;
1.1 Attack perspective
ATT&CK is different from other defense-oriented models (such as CVSS focused on vulnerability scoring, DREAD focused on risk calculation) in that ATT&CK uses the attacker's perspective to describe its terminology, model strategy, and technology. The detection and alerting from the defense perspective lack context, making it difficult to perform in-depth analysis, so using the attacker's perspective in ATT&CK is easier to understand the actions and potential countermeasures in the context than from a purely defensive perspective.
The shift in perspective changes the problem from 'what happens based on the list of available resources' to 'what may happen in the context of offense and defense', which provides a more accurate reference framework for how to evaluate the scope of defense.
The ATT&CK reference framework is unrelated to defensive tools or specific data collection methods, and defenders can understand the relationship between these actions and specific defense categories in the environment by following the motivations of individual attacker actions in the framework.
1.2 Based on observation
Most of the attack activities described by ATT&CK are derived from public events, most of which involve APT organizations, and these public events have become the foundation of the ATT&CK knowledge base. On this knowledge base, it is possible to more accurately describe 'in-the-wild' technologies or possible attack activities.
ATT&CK will also absorb technical findings from attack reports within the corporate internal network and technical findings from offensive and defensive exercises (such as technologies that can颠覆common defense).
ATT&CK is a model framework derived from real event observations, and it is the attack technology that an organization may encounter, so these technologies are not 'due to difficulty in use' or 'low usage rate' and are not visible theoretical technologies.
The main categories of ATT&CK observation sources are as follows:
Public messages
Community contributions
Unpublished incidents
In addition, the ATT&CK observation target is the attacker's attack methods, tools, and behavior patterns, also known as 'Tactics, Techniques, and Procedures (TTPs)', abbreviated as TTPs.
When mentioning TTPs, it is inevitable to mention the 'Pain Pyramid (Pyramid Of Pain)', which describes the failure indicators (IOCs) of the attack and defense process, with TTPs at the top of the Pain Pyramid, as shown in the following figure:
For the attacker, TTPs reflect the attacker's behavior, and the time and money cost required to adjust TTPs is 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, these IOCs are more difficult to identify and apply, as most security tools are not well-suited for exploiting them, which also means that the difficulty coefficient of collecting and applying TTPs to network defense is the highest.
For more detailed information about 'The Pyramid of Pain', please refer to this link:The Pyramid of Pain
The main target of ATT&CK observation is the TTPs of attackers, and the observed results are summarized and classified to form a knowledge base.
Simply put, ATT&CK is a knowledge base formed by observing and summarizing real and already occurred TTPs, which is not the result of academic theory, meaning that ATT&CK is very practical and implementable.
1.3 Abstract Level
The abstract level of 'Tactics (Tactics)' and 'Techniques (Techniques)' in ATT&CK is an important distinction between it and other security models.
General security models can be divided into three levels of abstraction: 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 libraries, malware libraries;
High-level abstract security models are very useful for understanding high-level processes and attack objectives, but these models cannot effectively convey the actions of attackers and the relationships between actions, nor can they describe the relationships between action sequences and defensive strategies in the environment (monitoring data sources, defense, configuration, etc.).
For low-level abstract models, such as exploit data, it describes specific instances of exploitable software (these instances are often used with code examples), but these instances do not well describe 'whether or can (should) be used' and the difficulty of using them. Similarly, malware databases also usually lack the context of 'how to use malware and who uses it', and they do not consider the situation of 'how to use legitimate software for malicious purposes'.
Therefore, in the actual environment, a need for an intermediate-level abstract model like ATT&CK is required to combine the different components of the high-level and low-level abstract models mentioned above.
The 'Tactics' and 'Techniques' in ATT&CK to some extent define the adversarial behaviors in the lifecycle, making them able to be effectively mapped to defense. The concepts of high-level abstract models such as 'Control', 'Execution', and 'Maintenance' are further refined in ATT&CK into more specific categories, and more specific behavioral actions are defined and classified within these categories.
For lower-level concepts such as exploit libraries and malware libraries, they are very useful toolkits, but due to their large number, it is difficult to interpret them in behavioral analysis, aside from regular vulnerability scanning, quick fixes, and IOCs usage. To fully understand their utility, it is necessary to understand the context in which they achieve their goals. The intermediate-level abstract model ATT&CK can associate low-level abstract information and event data such as vulnerability libraries (or malware libraries) to show who is doing what and the general usage of specific technologies.
Illustration of each abstract level:
In summary, the technical abstraction of ATT&CK has achieved the following two points:
Common classification of actions and objectives that both offensive and defensive sides can understand.
Appropriate classification levels link the opponent's actions with specific defensive methods.
1.4 Common Language
This is a personal supplement of mine. Although the official document does not single out this point, I believe that 'common language' is also one of the reasons why ATT&CK has become so popular, and it is also one of the most important values I believe in ATT&CK.
As mentioned earlier, ATT&CK is based on the perspective of attackers and observes and studies the behavior of attackers in the real world, and classifies and abstracts the observed results into specific tactics and techniques. In this process, all observed attack behaviors are processed in a standardized manner, forming a language and vocabulary for describing attack behaviors (TTPs).
Remember the personal experience of the security expert mentioned earlier? After classification and abstraction, the ATT&CK can incorporate the experience of most security experts. It is equivalent to the ATT&CK providing a set of standard language for describing offensive and defensive actions, and as long as this language is followed, the experience of security experts can be described. Once security experience can be described, it can effectively improve the efficiency and quality of industry communication.
Imagine, before the CVE (Common Vulnerabilities and Exposures, General Vulnerability Disclosure) was introduced, how did security professionals describe a vulnerability? Think about the following scenario:
Imagine, before the CVE (Common Vulnerabilities and Exposures, General Vulnerability Disclosure) was introduced, how did security professionals describe a vulnerability? Think about the following scenario:
Boss: Xiao Wang, have we fixed the Nginx vulnerability that appeared recently in our environment?
Brick King: Boss, which vulnerability are you talking about? Nginx has been exposed to a lot of vulnerabilities in the past few months, including one in version 13.02 and two in version 12.93.
Boss: That's it, it can affect SSL versions, and whatnot can steal keys;
Brick King: Is that one, Nginx affected...
Boss: No, it's that ...
Brick King: Oh, that's right, the official website has released a new version, which only says that XX vulnerabilities have been fixed, but I don't know if it includes this one, I need to verify it before going online...
Boss: ....
(The above scenario is purely absurd, please do not take it as a reference.)
Before the CVE vulnerability number was introduced, it was actually very difficult to describe a specific vulnerability of a program. Describing a vulnerability usually involves information such as vulnerability description, software version number, exploitation principle, and risk level. Different organizations or individuals may have different understandings of vulnerabilities, leading to different descriptions and making communication particularly difficult. However, once a CVE number is available, the complex vulnerability description is abstracted and refined into a single number, which can quickly locate the detailed information about the vulnerability, thereby greatly reducing communication costs.
Following the above example, if there is a CVE number, the above conversation can be simplified a lot:
Boss: Xiao Wang, have we fixed the CVE-2020-0000 vulnerability that just came out in our environment?
Oh, boss, the CVE-2020-0000 vulnerability is an Nginx privilege escalation vulnerability that affects 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 and CVE-2020-003 vulnerabilities. Our environment has been灰度上线,and it is expected that all can be fixed today.
Boss: Good, keep up with the follow-up in time.
It can be seen that with CVE numbers, the efficiency of vulnerability description can be greatly improved. Moreover, from the actual situation, CVE has already become an important de facto standard for vulnerability description, and the industry will use CVE to describe a vulnerability when describing it.
Similarly, ATT&CK is also a standardized description of 'attack behavior'. Various observed attack behaviors are classified into general descriptions, and even unique numbers are assigned to these classifications. In this way, it can be described as conveniently as CVE describes vulnerabilities.
For example, group (Groups) G0020 represents the APT organization 'Equation (方程式组织)', so that when communicating, using G0020 can make it very clear that what is being said is that 'the APT organization that once developed EternalBlue';
For example, the T1053.003 technique is under the tactical 'Execution' TA0002, indicating the crontab scheduled task under the Linux platform. When describing this technique, it is directly said that the specific technical concept T1053.003 replaces the vague concept of 'scheduled task'.
Let's think about it again, ifAn APT organization has used the crontab feature under the Linux platform to execute malicious code once.
It can be simply described as:
APT organization G0030 has achieved the tactical goal TA0002 by using the T1053.003 technique;
Just one simple sentence can clearly describe the attacker, attack behavior, and attack method, without ambiguity and easy to understand.
What is more important is that, through standardized descriptions of attack behaviors and the execution of automated detection, it is more convenient for the development of security tools and security strategies. Think about how many security tools are based on CVE, and it is not difficult to imagine how many security analysis tools will be developed based on ATT&CK in the future.
With the continuous popularity of ATTCK, ATT&CK will also become a factual standard about "attack behavior", and security professionals can describe the security status, protective capabilities, offensive and defensive exercises, security product capabilities, and coverage range of security products based on this standard. It can also describe the maturity of the entire organization's security operation system, defense gaps, current assessment, and other security capabilities.
2. Technical Domain of ATTCK
ATT&CK is composed of a series of technical domains. As of now, MITRE ATTCK has defined 3 technical domains, which are
Enterprise (Enterprise): Traditional enterprise network and cloud environment;
Mobile (Mobile): Mobile communication devices;
ICS: Industrial Control System, industrial control system
In each technical domain, ATT&CK defines multiple platforms (platforms), which may be an operating system or an application; "technology" and "sub-technology" can be applied to different platforms.
Technical Domain | Platform |
---|---|
Enterprise | Linux, macOS, Windows, AWS, Azure, GCP, SaaS, Office 365, Azure AD |
Mobile | Android, IOS |
Additionally, PRE-ATTCK is an extension of the ATT&CK technical domain, covering the collection of needs, reconnaissance, and weaponization before obtaining network access, and describes the countermeasures with behaviors independent of "technology". It models the behaviors of "attackers attempting to obtain organizational access permissions."
The first ATT&CK model was created in September 2013, primarily focusing on Windows enterprise environments. Through internal research and further development, it was publicly released in May 2015, covering 9 tactics and 96 techniques. Since then, ATT&CK has experienced significant growth based on the contributions of the cybersecurity community. MITRE has created several additional models based on ATT&CK, which were created using the method of creating the first ATT&CK. The initial ATT&CK was expanded to versions beyond Windows in 2017, including Mac and Linux, known as Enterprise ATT&CK. PRE-ATT&CK was released in 2017, focusing on the "left-side" attack behaviors of the kill-chain. The ATT&CK Mobile version was also released in 2017, focusing on behaviors in the mobile-specific domain. ATT&CK Cloud was released as part of Enterprise in 2019, describing the behavior environment and services for cloud. ATT&CK for ICS was released in 2020, containing the attack behaviors of industrial control systems.
PS: Unless otherwise specified, the ATT&CK model referred to in this article is Enterprise, and ATT&CK for ICS, PRE-ATTCK, and Mobile are not within the scope of this article.
3. ATT&CK Composition
3.1 ATT&CK Matrix
The foundation of ATT&CK is a set of "technologies" and "sub-technologies", which represent the actions that the opponent can perform to achieve the goal. These goals are represented by the "tactic" categories to which the "technologies" and "sub-technologies" belong.
"Tactic" refers to the objective of attack behavior, while "technology" refers to the techniques executed to achieve the goal, and "sub-technology" is a more specific technical explanation than "technology".
Currently, ATT&CK divides known attack behaviors into 12 tactics, 156 technologies, and 272 sub-technologies.
The relationship between "tactic", "technology", and "sub-technology" is visualized through the ATT&CK matrix.
3.2 Tactics
In addition, other
3.3 Techniques and Sub-Techniques
The 'technique' represents the 'way' an attacker achieves a 'tactical' objective by executing an action.
The 'technique' represents how an adversary achieves a 'tactical' objective by executing an action. For example, the adversary may dump credentials from the operating system to gain access to useful credentials on the network.
The 'technique' can also represent 'what' an adversary achieves by executing an action, which is the biggest difference between 'Discovery' tactics and other 'tactics' because these techniques can highlight the type of information the adversary obtains through specific actions.
There may be many methods or techniques to achieve a 'tactical' objective, so there are multiple 'techniques' in each 'tactic' category. Similarly, there may be multiple ways to execute a 'technique', so there may be multiple different 'sub-techniques' under a single 'technique'.
The 'sub-technique' further breaks down the behavior described by a technique into more specific descriptions about 'how to use the behavior to achieve the goal'. For example, for the 'OS Credential Dumping' technique, there are several more specific behaviors that can be described as 'sub-techniques', including 'accessing LSASS memory', 'Security Account Manager', or 'accessing "/etc/passwd" and "/etc/shadow"'.
"Technique" main field and description:
Field | Type | Description |
---|---|---|
Name (Name) | Field | The name of the technique (sub-technique) |
ID (ID) | Tag | The unique number of a technique (sub-technique) within the knowledge base. Format: (Technique) T####; (Sub-technique) T####.### |
Sub-Techniques | Field | The unique ID of a sub-technique that belongs to a specific technique. *Only applicable to techniques, not sub-techniques |
Tactic | Tag | Tactical objectives that (sub-)techniques can be used to achieve. (Sub-)Techniques can be used to execute one or more strategies. |
Description | Field | Information about (sub-)techniques, what they are, what they are usually used for, how the adversary uses them, and how their usage changes. This includes references to authoritative articles related to the technique, as well as references to its use in the wild. |
Platform | Tag | A system running internally with the adversary; it could be an operating system or an application (e.g., Microsoft Windows). (Sub-)Techniques can be applied to multiple platforms. |
Permissions Required | Tag | The minimum permissions required for an adversary to execute (sub-)techniques within the system, limited to privilege escalation. *Only needed in 'Privilege Escalation'. |
Effective Permissions | Tag | The level of privileges obtained by the adversary through the execution of (sub-)technology. Only applicable to (sub-)privilege escalation strategies. If valid permissions can be set during the execution of (sub-)technology, there can be multiple entries. *Only required in 'Privilege Escalation' |
Data Source | Tag | The information source collected by sensors or log systems, which can be used to collect information related to the actions, sequence of actions, or results of actions being executed by the adversary. The list of data sources can include different variants of operations performed on specific (sub-)technology. This attribute is limited to a predefined list to allow for 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 defense evasion (sub-)technology. *Only required in 'Evasion Defense' |
Version (Version) | Field | (Sub-)technology version, format: MAJOR.MINOR |
Impact Type | Tag | Indicates whether (sub-)technology can be used for integrity or availability attacks. Applies to affected (sub-)technology. |
Detection | Field | Contains advanced analysis processes, sensors, data, or detection strategies that can identify a (sub-)technology used by the adversary. This field describes methods for defense detection so that security detection personnel can take specific defensive methods or actions accordingly. There are many methods for detecting (sub-)technologies, but ATTCK and MITRE do not endorse specific supplier solutions, so detection recommendations are only for method or tool types and are unrelated to specific suppliers or tools. Moreover, even if (sub-)technologies are not always detectable, they should still be recorded. |
Mitigation Measures | Relationship/Field | Contains configurations, tools, or processes that can prevent the successful execution or the expected effect of (sub-)technology. This field describes how to apply specific mitigation measures to the details of (sub-)technology, so that security defense personnel can take specific mitigation strategies accordingly. Similarly, mitigation recommendations are still unrelated to specific suppliers, and not every (sub-)technology can be mitigated. |
3.3.1 Process (Procedures)
To complete a successful attack, simply having good 'tactics' and 'techniques' is not enough; the attacker needs to use a special action sequence called 'process' to execute every step of their attack cycle. In ATT&CK, 'process' refers to the specific implementation method used by the adversary for 'technology' or 'sub-technology'.
It is also important to note that the 'process' can span multiple 'technologies' and 'sub-technologies'. For example, the 'process' used by an attacker to 'dump credentials' includes PowerShell, Process Injection, and LSASS Memory, all of which are different behaviors, so the 'process' also includes how to use specific tools.
In ATT&CK, observed 'Processes' will be recorded in the 'Procedure Examples' section on the 'Techniques' and 'Sub-Techniques' pages.
3.3.2 Sub-Techniques
ATT&CK added sub-techniques in 2020, marking a major shift in the way behavior descriptions are made in the knowledge base. This change is due to the need to address some technical abstraction level issues that have emerged with the development of ATT&CK over the years. Some 'Techniques' are described very broadly, while others are very narrow (only describing very specific behaviors). This imbalance has made ATT&CK extremely bloated, not only making it difficult to visualize, but also making it difficult to understand the purpose behind some technologies.
Sub-techniques mainly improve the following points of ATT&CK:
Make the abstraction level of technologies similar throughout the knowledge base
Reduce the number of technologies to a manageable level
Provide a structure that allows easy addition of sub-techniques, which will reduce the need to change the technology over time
Some technologies may not be simple and can be implemented in various ways, which are the methods that need to be considered
Simplify the process of adding new technology (overlapping technology) domains to ATT&CK
Enable more detailed data sources and descriptions to allow behavior to be observed on specific platforms
There is no one-to-many relationship between 'Sub-Techniques' and 'Techniques'; each 'Sub-Techniques' will only have a relationship with one parent 'Techniques', which can avoid the entire model from becoming complex and difficult to maintain.
In some cases, 'Sub-Techniques' with multiple parent items may adopt 'Techniques' that span multiple 'Tactics'.
For example, the technology of scheduled tasks/jobs (Scheduled Task/Job) is included in both the 'Persistence' tactic and the 'Privilege Escalation' tactic, and only some of its 4 sub-technologies are applicable to 'Privilege Escalation'. In this case, 'Sub-Techniques' do not need to belong to all 'Tactics', even if the parent 'Techniques' of the 'Sub-Techniques' belong to the 'Tactics'. As long as the concept of 'Sub-Techniques' belongs to 'Techniques', it is not necessary to meet the 'Tactics' of each parent 'Techniques'.
This sentence is quite awkward, to put it simply, 'Sub-Techniques' are only related to their parent 'Techniques', and not related to the 'Tactics' of the 'Techniques' they belong to.
The "Sub-Techniques" attribute in ATT&CK is essentially the same as the "Techniques" attribute, but it will add a suffix after the parent "Techniques" to distinguish it.
3.4 Groups (Groups)
In the ATT&CK framework, "Groups" are used to track known attackers, and "Groups" are defined as named intrusion sets, threat groups, participant groups, or activities, which typically represent targeted, persistent threat activities. The ATT&CK framework primarily focuses on APT groups.
"Group" main fields and descriptions:
Field | Type | Description |
---|---|---|
Name (name) | Field | Name of the group |
ID | Tag | Unique number of the group in the knowledge base. Format: G#### |
Version (Version) | Field | Version of the group, format: MAJOR.MINOR |
Description | Field | Based on the description of the group in public threat reports, it may include activity time, suspicious details, targeted industries, and other notable events attributed to the group. |
(Sub-)Techniques / Sub-Techniques Used | Relationship/Field | List of (sub-)technologies used by the group, as well as the details of the process in which the group uses the technology (in the context of TTPs). |
3.5 Software (Software)
Attackers typically use different types of software during an intrusion. Software can represent an instance of a 'technology' or 'sub-technology', and it is necessary to classify it in the ATT&CK framework.
Software is divided into two main categories: tools and malware.
Tools: Refers to software that is commercial, open-source, self-developed, or publicly available, which can be used by defenders, penetration testers, red team members, or adversaries. This category includes both software that is typically not found on enterprise systems and software that is obtained as part of an existing operating system in the environment. Examples include PsExec, Metasploit, Mimikatz, and Windows utilities such as Net, netstat, Tasklist, etc.
Malware: refers to software, commercial, open source, or closed source, used for malicious purposes. For example: PlugX, CHOPSTICK, etc.
The category of software can be further subdivided, but the idea behind the current classification is to show how adversaries use tools and legitimate software to execute actions, just like they use traditional malware.
Main fields and descriptions of "Software":
Field | Type | Description |
---|---|---|
Name (Name) | Field | Software name |
ID (ID) | Tag | Unique identifier for the group in the knowledge base. Format: S#### |
Version (Version) | Field | Version of the software; format: MAJOR.MINOR |
Type (Type) | Tag | Type of software, "malware" or "tool" |
Platform | Tag | Platform used by the software, such as Windows |
Description | Field | Description of software based on technical references or public threat reports. It may contain technical details related to groups known to use the software or other related technologies. |
(Sub-)Techniques / Sub-Techniques Used | Relationship/Field | List of (sub-)technologies implemented or used by the software; |
3.6 Mitigations
Mitigations in ATT&CK are a security concept and technical category used to describe how to prevent a certain technique or sub-technique from being successfully executed;
As of March 2020, there are 41 mitigation measures in Enterprise ATT&CK, including mitigation measures such as application isolation and sandboxing, data backup, execution prevention, and network segmentation, etc. Mitigation measures are unrelated to supplier products and only describe the category or categories of technology, not specific solutions.
Main fields and descriptions of "Mitigation":
Field | Type | Description |
---|---|---|
Name (Name) | Field | Search for the name of the measure |
ID (ID) | Tag | Unique identifier for the group in the knowledge base. Format: M#### |
Description | Field | Description of the mitigation measure |
Version (Version) | Field | Version of the mitigation measure; format: MAJOR.MINOR |
(Sub-)Techniques Addressed by Mitigation | Relationship/Field | List of (sub-)technologies that this mitigation measure may involve. |
3.7 Relationships Between Different Components of ATT&CK
The above components do not exist independently; in ATT&CK, each component is associated with other components in some way.
The relationships between them can be shown by the following diagram:
For example, the APT28 organization uses Mimikatz to perform credential dumping on the Windows LSASS process memory, which can be represented by the following diagram
4. ATTCK Use Scenarios
As mentioned above, the most critical aspect of ATT&CK is still the use scenario. The main use scenarios of ATTCK include 4 scenarios, each of which has official best practice guidance and lists some tools that can be used in the scenarios.
Due to the limitations of length, this article only provides a basic description of the scenario, and in the following several articles, we will try to describe the usage methods of each scenario one by one.
The Cyber Analytics Repository (Cyber Analytics Repository, CAR) is an analytical knowledge base developed by MITER based on the MITER ATT&CK adversary model, which can serve as an organization's starting point for conducting behavioral detection and analysis using ATTCK.
ATT&CK can be used as a tool for building and testing behavioral analysis, for detecting hostile behavior in the environment, and identifying potential malicious activities in systems or networks.
Traditional detection usually uses intrusion characteristics (IOCs) or malicious activity signatures to detect. Behavioral detection and analysis is different from traditional feature detection, as it does not rely on prior knowledge (IOCs or signatures), and is also unrelated to the tools used by the adversary.
4.1 Behavioral Detection and Analysis
4.2 Threat Intelligence
Network threat intelligence covers the knowledge of threat actors (groups) that affect network security, including information about malware, tools, TTPs, espionage techniques, behavior, and other indicators related to threats.
ATT&CK understands attackers from the perspective of behavioral analysis, collects and forms documents, and these documents record tools that attackers may use.
Through these documents, analysts and defenders can better understand the common behaviors of various attackers and effectively map them to their own defense systems. In addition, the structured format of ATT&CK can classify behaviors outside of standards to enhance the value of threat reports.
4.3 Adversary Emulation and Red Team
'Adversary Emulation' and 'Red Team Attack' are both behaviors to verify defense capabilities, but they also have differences.
The 'Adversary Emulation' first assumes which attack organization is being simulated, and based on the threat intelligence information of that organization, simulates the behavior of the attack organization. By simulating the behavior of the attacker, the security process in a certain technical field is evaluated. 'Adversary Emulation' focuses on the organization's ability to verify and detect (or) mitigate the impact of adversary activities at all applicable points in its lifecycle.
ATT&CK can be used as a tool to create 'opponent simulation scenarios' to test and verify the defense against common techniques of opponents. Specific attacker details will be recorded in the structured document of ATT&CK, and defenders and risk hunters can use these documents to adjust and improve defense measures.
'Red Team attacks' refer to attack demonstrations conducted with a mindset of opposition without using known threat intelligence. The focus of the Red Team is to complete the final goal without being discovered, to demonstrate the impact of successful intrusion operations or tasks.
ATT&CK can be used as a tool to create 'Red Team plans' and organizational actions to avoid certain defense measures in the network.
In addition, ATT&CK can also be used as a roadmap for research to develop new attack methods or techniques that ordinary defense systems may not be able to detect.
4.4 Gap Analysis and Assessment
Gap analysis can help organizations determine which parts of the environment lack protection or visibility, and these gaps represent potential blind spots in defense or monitoring in the environment, allowing attackers to access their network without being discovered or effectively intercepted.
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 identifying the gaps, defense system construction investment plans can be arranged according to priority. Similarly, before purchasing security products, a common opponent attack model can also be compared to assess 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, which can continuously monitor threats in the network. Understanding the maturity of SOC is very important for determining 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 gap analysis assessment, SOC maturity assessment focuses on the SOC's ability to detect, understand, and respond to the constantly changing threats and processes in the network.
5. Postscript
Before completing this article, I read the official document of MITRE ATT&CK, 'MITRE ATT&CKÒ: Design and Philosophy', and it serves as the main reference source for this article. The article 'MITRE ATT&CK: Design and Philosophy' elaborates in detail on the design philosophy and concepts of ATTCK, which is a very detailed introductory tutorial for understanding the entire ATTCK system. Unfortunately, the entire text is in English, which is quite a hassle to read, so this article has made some translations and colloquial explanations based on this document to facilitate better reading and understanding.
接触ATT&CK也是一个偶然的机会,参加了今年4月份青藤云CEO张福举办的那个线上ATT&CK课程,受益匪浅。对于ATT&CK我也是一个新手,还有很多细节值得慢慢去研究学习。
ATT&CK官方资料丰富,社区活跃,基于ATT&CK的检测思路和工具也相当多,可以说是一个网络安全攻防的知识宝库。接下来一段时间,我将会按照官方文档教程逐一去实践这个框架,并整理成文,如果感兴趣的小伙伴可以关注本公众号。
PS:感谢青藤云CEO张福举办的那次线上交流会,并给我寄了一本ATTCK实践指南小册子,让我真正开始接触这个先进的概念,也期待青藤云能够对ATTCK做出更多研究,HIDS产品大卖!
参考:
《ATT&CK框架使用指南》 青藤云安全
《MITRE ATT&CK: 设计与哲学》©2020 The MITRE Corporation.
《TTPs & IOCs & 痛苦金字塔》 https://www.jianshu.com/p/b3654b179277Viola_Security
《战术、技术、程序》 https://azeria-labs.com/tactics-techniques-and-procedures-ttps/
Detailed explanation of house of emma exploitation techniques (analysis of 21 Huxiang Cup instances)
How many of the 7 attack techniques of hackers can you prevent?
2. Analyze the code, and you can find that the values of a, b, and c can be obtained
2.1. Obtain the password of the optical network terminal super administrator account (telecomadmin)

评论已关闭