Defending Against Credential Access Attacks: Harnessing the Power of MITRE D3FEND Decoy Objects

The Blue Report 2024

Get a comprehensive analysis of over 136 million cyber attacks and understand the state of threat exposure management.

DOWNLOAD

Obtaining credentials serves as a pivotal stage in adversaries' attack campaigns, granting them access to crucial resources and systems within the target environment. The acquired information becomes a potent tool, enabling lateral movement through networks, privilege escalation, and access to restricted data.

According to the insights from the Picus Red Report 2023, which offers a comprehensive analysis of the most prevalent MITRE ATT&CK tactics and techniques employed in 2022 and their utilization by threat actors, 'T1003 OS Credential Dumping' emerged as the second most prevalent ATT&CK technique. In a notable shift, 'T1003 OS Credential Dumping' moved from fifth place in the previous year's report to second place in the Red Report Top Ten for 2023. The observed increase in instances of credential dumping highlights the importance of implementing advanced and proactive defense mechanisms.

One such proactive defense mechanism is the strategic deployment of decoy objects. By creating deceptive elements within the network, organizations can divert and mislead attackers, creating an additional layer of defense against credential access attacks. These deceptive elements, strategically placed, not only act as a deterrent but also serve as early warning signals. Any interaction with these decoys triggers alerts, making it easier to detect adversaries within the network. In this blog, we delve into the MITRE D3FEND "Decoy Object" technique, exploring its implementation and how this strategic approach aids in the early detection of credential access attacks.

Enter MITRE D3FEND

The MITRE D3FEND matrix is a cybersecurity framework built on a knowledge graph researched and developed by MITRE. Its main goal is to outline effective defensive strategies against various threats and techniques used by adversaries at an operational level. In simple terms, D3FEND is designed to work hand in hand with ATT&CK, focusing on defense rather than offense. While ATT&CK primarily describes the offensive techniques of adversaries, D3FEND provides guidance to organizations on how to defend against the known attack techniques outlined in MITRE ATT&CK.

offensive-defensive-technique

Figure 1: Simplified Offensive and Defensive Technique Relationships [1]

Similar to the ATT&CK framework, The D3FEND knowledge graph user interface (Figure 2) presents defensive tactics and techniques in a tabular view that also incorporates hierarchy.

At the top of this hierarchy is a defensive tactic, which represents the most general organizing class in the D3FEND knowledge graph. A defensive tactic is a maneuver formulated in response to some adversary action. Examples of defensive tactics include Detect, Harden, Deceive, Evict, and Isolate.

At the next level, top-level techniques are distinguished as base techniques, serving as the foundation from which all other techniques are derived. More specific defensive techniques are then presented in the columns under the base techniques. For instance, the technique "Decoy File" is categorized under the base technique "Decoy Object."

D3FEND-knowledge-graph

Figure 2: D3FEND Knowledge Graph User Interface: Tactics and Techniques Overview [2]

For more detailed information about the MITRE D3FEND, you can check our blog post "What Is MITRE D3FEND Matrix?".

Deceive Tactic: A Closer Look

Deception means making someone believe something false is true. It's not a new idea—people have used it in wars for a very long time. In cybersecurity, it works in a similar way. Deception aims to trick attackers, leading them the wrong way and learning about their tools and tricks. It's like a clever game to actively defend our digital assets. And, of course, this approach is actively mentioned in different frameworks from MITRE, including the MITRE D3FEND matrix.

In the D3FEND matrix, there's a tactic called "Deceive" used to advertise, entice, and allow potential attackers access to an observed or controlled environment. There are two base techniques and nine techniques under this tactic.

deceive-tactic

Figure 3: "Deceive" Tactic Overview [3]

Each technique is explained in detail, including its definition, its operational mechanics, considerations for implementation, and relationships between digital artifacts and the technique. You can find this information on the related technique page. 

decoy-user-credential

Figure 4: "Decoy User Credential" Technique Overview [4]

Additionally, each related technique has associated ATT&CK techniques.

ATT&CK-techniques

Figure 5: Related ATT&CK techniques associated with the "Decoy User Credential" [5]

Use Cases of Deceive Tactic for Credential Access Attacks

Now, let's delve into the implementation of some of these techniques under the "Decoy Objects" base technique. We'll explore how to use them for detecting credential access attacks, presenting different use cases for added clarity.

Use Case 1: Detecting Access to Files Containing Unsecured Credentials

In this scenario, let's examine a specific procedure falling under the MITRE ATT&CK's "T1552.001: Credential in Files" sub-technique.

A common practice among administrators is utilizing Windows Deployment Services for creating and deploying Windows operating system images across various systems via the network, known as unattended installation. However, a significant security concern arises during unattended installations, as the local administrator password tends to be stored in multiple locations, either in plaintext or as Base64 encoded. These locations include:

  • C:\unattend.xml
  • C:\Windows\Panther\Unattend.xml
  • C:\Windows\Panther\Unattend\Unattend.xml
  • C:\Windows\system32\sysprep.inf
  • C:\Windows\system32\sysprep\sysprep.xml

<UserAccounts>
        <AdministratorPassword>
                <Value>password</Value>
                <Plaintext>true</Plaintext>
        </AdministratorPassword>
</UserAccounts>

Figure 6: An example of plaintext credentials within the unattend.xml file

When an attacker gains access to a system, one of their initial actions is typically to search the entire system to discover credentials for the local administrator account, including checking these aforementioned locations.

To identify these attackers, we can follow a deception-like approach. This involves creating a decoy file (utilizing the decoy file technique in the D3FEND matrix) containing fake credentials and deploying it to one of the aforementioned locations.

decoy-file-technique

Figure 7: Decoy File Technique Overview [6]

Let's begin by creating an unattend.xml decoy file. During creation, ensure that the decoy file closely resembles actual files to deceive attackers effectively.

Here's a glimpse of our decoy file. Take note that our fake user (superuser) and its corresponding credential (supersecretpassword) are included in this file for deceptive purposes.

<settings pass="oobeSystem">
         <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
                 <InputLocale>0409:00000409</InputLocale>
                 <SystemLocale>en-US</SystemLocale>
                 <UILanguage>en-US</UILanguage>
                 <UserLocale>en-US</UserLocale>
         </component>
         <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
                <UserAccounts>

                        <LocalAccounts>
                                <LocalAccount wcm:action="add">

                                        <Name>superuser</Name>

                                        <Group>Administrators</Group>

                                        <Password>
                                                <Value>supersecretpassword</Value>
                                                <Plaintext>true</Plaintext>
                                          </Password>

                                </LocalAccount>

                        </LocalAccounts>

                </UserAccounts>

                <AutoLogon>
                         <Username>superuser</Username>

                         <Enabled>true</Enabled>

                         <LogonCount>1</LogonCount>
                         <Password>

                                 <Value>supersecretpassword</Value>
                                 <Plaintext>true</Plaintext>
                         </Password>

                 </AutoLogon>

                 <OOBE>

                         <ProtectYourPC>3</ProtectYourPC>

                          <HideEULAPage>true</HideEULAPage>

                         <HideWirelessSetupInOOBE>1</HideWirelessSetupInOOBE>

                 </OOBE>

                 <FirstLogonCommands>

                         <SynchronousCommand wcm:action="add">

                         <Order>1</Order>

                         <CommandLine>reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v AutoLogonCount /t REG_DWORD /d 0 /f</CommandLine>

                         </SynchronousCommand>

                 </FirstLogonCommands>

         </component>

</settings>

Figure 8: A Section from the Decoy unattend.xml File

We deploy it to C:\Windows\Panther\Unattend.xml and set its "date modified" attribute to match the installation time of this host. This adjustment aims to enhance the decoy file's legitimacy, as Unattend.xml is typically unmodified after the system installation and configuration processes are completed.

PS C:\Windows\Panther> ls .\unattend.xml
Directory: C:\Windows\Panther


Mode                LastWriteTime                Length         Name
----                     -------------                  ------           ----
-a----                 12/14/2023 09:15 PM    14514           unattend.xml

PS C:\Windows\Panther> (Get-Item "C:\Windows\Panther\unattend.xml").CreationTime=("08 March 2021 15:23:00")
PS C:\Windows\Panther> (Get-Item "C:\Windows\Panther\unattend.xml").LastWriteTime=("08 March 2021 15:23:00")
PS C:\Windows\Panther> (Get-Item "C:\Windows\Panther\unattend.xml").LastAccessTime=("08 March 2021 15:23:00")

PS C:\Windows\Panther> ls .\unattend.xml
Directory: C:\Windows\Panther

 

Directory: C:\Windows\Panther


Mode                LastWriteTime                Length         Name
----                     -------------                  ------           ----
-a----                 3/8/2023 03:23 PM       14514           unattend.xml

Figure 9: Adjusting the Timestamps for the unattend.xml File

Then, we can monitor access to this file by enabling file system auditing and access logging specifically for the unattend.xml file. To achieve this, we configure a Security Auditing Control List (SACL).

Enabling file system auditing is accomplished with the following command:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

For access logging of the unattend.xml file, we execute the following PowerShell script:

# File for which auditing will be configured
$FileToAudit = "C:\Windows\Panther\Unattend.xml"
# Set properties for the new SACL
$AuditIdentity = "Everyone"
$AuditOnAction = "ReadData"
$AuditType = "Success"
$InheritanceFlags = "None"
$PropagationFlags = "None"
# Create a new audit rule
$NewAuditACE = New-Object System.Security.AccessControl.FileSystemAuditRule(
         $AuditIdentity,
         $AuditOnAction,
         $InheritanceFlags,
         $PropagationFlags,
         $AuditType
)
# Get the current ACL with auditing information
$Acl = Get-Acl $FileToAudit -Audit

# Add the new audit rule, preserving previously configured entries
$Acl.AddAuditRule($NewAuditACE)
# Set the modified ACL back to the file
Set-Acl -Path $FileToAudit -AclObject $Acl
Write-Host "Auditing configured successfully for $FileToAudit. ReadData access will be audited for Everyone."

Subsequently, we examine any generated 4663 events specifically related to this file.

Figure 10: An example of a 4663 ID Event Log

We can craft a Sigma rule to detect instances like the one described above:

title: Unattend.xml Files Enumeration for Unsecured Credentials
description: Detects attempts to find unsecured credentials in "unattend.xml" files, where credentials are commonly stored, within the Panther directory where installation logs are kept.
references:
  - https://attack.mitre.org/tactics/TA0006/
  - https://attack.mitre.org/techniques/T1552/
logsource:
    product: windows
    service: security
    definition1: 'Requirements: Group Policy : Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Object Access\Audit File System'
    definition2: 'You should enable System Access Control Lists (SACL) for related file.'
detection:
    selection:
        EventID: 4663
        ObjectName|endswith: '\unattend.xml'
        Accesses: 'ReadData (or ListDirectory)'
    condition: selection
falsepositives:
    - Unknown
level: high
tags:
    - attack.credential_access
    - attack.ta0006
    - attack.t1552

We can also identify attackers who accessed the aforementioned decoy files by checking the 4625 event, which includes information about the fake user.

Figure 11: An example of a 4625 ID Event Log

Use Case 2: Detecting Kerberoasting Activity

In this scenario, we are examining the MITRE ATT&CK's "T1558.003: Kerberoasting" sub-technique.  Kerberoasting is a post-exploitation attack technique that attempts to obtain a password hash of an Active Directory account that has a Service Principal Name ("SPN"). During this attack, a domain user with authentication accesses a Kerberos ticket for a specific SPN. The obtained Kerberos ticket is encrypted using the hash of the service account password linked to that SPN. (Service principal names (SPNs) are used to uniquely identify each instance of a Windows service). Subsequently, the attacker operates offline to crack the password hash, frequently employing brute force methods. For more detailed information about the Kerberoasting attack, please check our blog post "Kerberoasting Attack Explained - MITRE ATT&CK T1558.003".

We aim to identify Kerberoasting attacks by implementing a decoy user account. This strategy aligns with the Decoy Network Resource technique outlined in the D3FEND matrix.

Initially, we created a user account in the Active Directory. Subsequently, we set the adminCount attribute of this user to 1. We can assert that if a user's adminCount value is 1, this user has administrative privileges. As a result, our decoy account appears more attractive to potential attackers. 

decoy-account-properties

Figure 12: Decoy Account Properties

Decoy-account's-adminCount-attribute

Figure 13: Setting Decoy Account's adminCount Attribute

We need to add a Service Principal Name (SPN) to this account. This is what the attacker will encounter during an SPN discovery. Therefore, it is crucial to make it appear legitimate. Additionally, this SPN must be unique so that we can differentiate the Kerberos service ticket request for this SPN as invalid and, therefore, malicious.

Figure 14: Setting Decoy Account's Service Principal Name

To monitor if a Kerberos service ticket is requested for this decoy account, we need to enable the "Audit Kerberos Service Ticket Operations" policy on Domain Controllers. After enabling this policy, Kerberos service ticket requests can be tracked through 4679 events, which indicates that a Kerberos service ticket was requested.

Enabling Audit Kerberos Service Ticket Operations auditing is accomplished with the following command:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

After completing the setup of the decoy account and configuring the logs, we execute a Kerberoasting attack on one of the domain computers. We observe that the 4679 event is triggered, and our decoy account is visible in the service information section of the log. Additionally, we can obtain the IP address of the client machine that conducted the Kerberoasting attack. 

Figure 15: An example of a 4679 ID Event Log

It's possible to create detection rules using the 4679 event log, which includes the decoy account name in the service information section. Any Kerberos ticket request involving the decoy account should be considered malicious.

Conclusion

Credential attacks are one of the most prevalent tools in adversaries' tool sets, and organizations need proactive and adaptive defense strategies to protect themselves. With its emphasis on active defense and decoy objects, MITRE D3FEND offers a potent solution to stay one step ahead of adversaries. By strategically deploying decoy objects within the network, they not only act as a deterrent but also serve as early warning signals. Embracing the capabilities of MITRE D3FEND and positioning decoy objects as a cornerstone can significantly strengthen the defense against credential attacks.

References

[1] P. E. Kaloroumakis and M. J. Smith, "Toward a Knowledge Graph of Cybersecurity Countermeasures." [Online]. Available: https://d3fend.mitre.org/resources/D3FEND.pdf. [Accessed: Dec. 18, 2023]

[2] "MITRE D3FEND Knowledge Graph." Available: https://d3fend.mitre.org/. [Accessed: Dec. 18, 2023]

[3] "Deceive." Available: https://d3fend.mitre.org/tactic/d3f:Deceive/. [Accessed: Dec. 18, 2023]

[4] "Decoy User Credential." Available: https://d3fend.mitre.org/technique/d3f:DecoyUserCredential/. [Accessed: Dec. 18, 2023]

[5] "Decoy User Credential." Available: https://d3fend.mitre.org/technique/d3f:DecoyUserCredential/. [Accessed: Dec. 18, 2023]

[6] "Decoy File." Available: https://d3fend.mitre.org/technique/d3f:DecoyFile/. [Accessed: Dec. 18, 2023]