How to use MITRE ATT&CK to detect attacks
There are countless techniques that can be used to attack a Windows system. The successful detection of attacks requires an understanding of the technique being used. But it also requires the system to be configured to log the relevant events in the first place. Then from all this data you need to pick out the events that were triggered by the respective technique.
MITRE ATT&CK Enterprise Matrix is a collection of tactics and techniques based on data taken from actual attacks. ATT&CK is publicly available and can be used free of charge. The April 2019 version of ATT&CK Enterprise Matrix includes 12 tactics and 244 techniques. For example, the credential access tactic involves techniques for gaining access to login credentials, including brute force, credential dumping and forced authentication. Each technique includes a description, a list of examples detailing how the technique is used along with possible countermeasures that are divided into categories of mitigation and detection.
The ATT&CK Enterprise Matrix is, among other things, a good foundation for identifying attacks. The recommended measures relate specifically to the technique in question. For example, in the case of Kerberoasting the recommended procedure is to monitor the Kerberos event log for Kerberos Service Ticket Operations on accounts that issue a large number of requests within the span of just a few minutes, particularly if the ticket request contains the encryption algorithm RC4 (type 0×17). The recommendations for dealing with the technique of credential dumping are more general. Recommendations include checking to make sure LSASS is started as a protected process and that attempts to access the LSASS process are monitored. The running of applications and scripts should be monitored for suspicious behavior as well. One of the best-known examples of credential dumping is the tool known as Mimikatz, which is not only used by security researchers but also by many groups who use it to launch real attacks. This is why we are currently configuring a test system that uses built-in Windows features to detect Mimikatz attacks.
The article covering Windows 10 client hardening already discussed several additional settings for the audit configuration. The latest version of the hardening checklist includes additional settings and has been updated for Windows 10 Build 1903. To detect when Mimikatz is being run requires some additional audit settings in Windows. These include some of the following settings which, incidentally, can also be used to detect other attack techniques:
The Windows client runs the LSASS process in protected mode, which can be verified by checking the system event log when starting the operating system. The event with the source Wininit and event ID 12 is: LSASS.exe was started as a protected process with level: 4. If Mimikatz now attempts to read the login credentials of users who are logged in, the operation will fail:
mimikatz # privilege::debug Privilege '20' OK mimikatz # sekurlsa::logonpasswords ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
Sysmon can be used to detect when Mimikatz starts, for example, by monitoring the Process Create event. If a modified version of Mimikatz is used and the name, description and other properties of the application have been concealed, this event is not necessarily reliable. When starting Mimikatz, the Sensitive Privilege Use task with event ID 4673 will also appear in the security event log as Failed. An attempt will be made to acquire SeTcbPrivilege privileges. If the process ID has the same ID as the Sysmon event, this is a red flag for suspicious activity.
In the next step, the Mimikatz driver is loaded to disable Protected Mode for the LSASS process in the system memory.
mimikatz # !+ [*] 'mimidrv' service not present [+] 'mimidrv' service successfully registered [+] 'mimidrv' service ACL to everyone [+] 'mimidrv' service started mimikatz # privilege::debug Privilege '20' OK mimikatz # !processprotect /remove /process:lsass.exe Process : lsass.exe PID 652 -> 00/00 [0-0-0]
This activity can be detected as event Driver Loaded in the Sysmon log. In addition, an entry for loading of the driver will also appear in the system event log with the Service Control Manager as the source and event ID 7045. The installation of a driver is also documented in the security event log and will have event ID 4697.
Once the LSASS process is no longer protected, the user’s login credentials can be read from the process memory.
mimikatz # sekurlsa::logonpasswords Authentication Id : 0 ; 2496472 (00000000:002617d8) Session : Interactive from 1 User Name : admin Domain : W10 Logon Server : W10 Logon Time : 31/02/2019 08:10:41 SID : S-1-5-21-2094461431-2471580941-81854671-1002 ...
Reading the login credentials generates the event An attempt was made to access an object with the category Kernel Object and event ID 4663 in the security event log. This means that an application has successfully accessed the LSASS process object.
Expanding the Sysmon configuration to include the following setting can make it easier to detect attacks on the LSASS process:
<!--SYSMON EVENT ID 10 : INTER-PROCESS ACCESS--> <!--DATA: UtcTime, SourceProcessGuid, SourceProcessId, SourceThreadId, SourceImage, TargetProcessGuid, TargetProcessId, TargetImage, GrantedAccess, CallTrace--> <ProcessAccess onmatch="include"> <TargetImage condition="contains">lsass.exe</TargetImage> </ProcessAccess>
Analyzing how Mimikatz is executed and applying these insights makes it possible to detect the attack. In the simplest scenario, you can monitor when mimikatz.exe is run and when the mimidrv.sys driver is loaded. By correlating the Process Create and Driver Loaded events as well as attempts to access the LSASS process, you can also detect a disguised version of Mimikatz or an application that uses similar mechanisms.
Detecting Mimikatz is only one first step towards being able to detect all of the attack techniques covered in the ATT&CK Enterprise Matrix. The documented techniques do, however, provide assistance and are therefore a good place to start building a detection framework. Another helpful tool is Andrea Fortuna’s collection of event log IDs. In addition, the mechanisms for detecting suspicious activities can usually be used for more than just a single technique, so you don’t have to set up a separate detection rule for each individual technique. It should also be noted that other attacks and activities that are beyond the scope of MITRE ATT&CK should be taken into account as well.
You can identify attacks on the client system by integrating an alarm into the central infrastructure or by using a central monitoring system to carry out the necessary analytics. In centralized analytics systems, you can also incorporate data from other systems to provide additional clues. The history from the previous few days should also be taken into account, because an attack can span several days or even weeks.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here