Living the Sweet PowerShell #1
In 2018, I conducted an attack scenario in my laboratory environment based on some external sources and my own research. In the scenario, an attacker exploited the MS17-010 vulnerability to gain access to a compromised machine. Using the compromised user account with limited privileges the attacker established a PowerShell Empire connection and executed DCSYNC and golden ticket attacks to take control of the domain environment. Attacker used WMI for lateral movements, compromising other machines. Inspired by this scenario I wanted to start a series of articles to seek answers to questions about defensive measures against such attacks, developing SIEM rules, detection methods and how to intervene through SOAR (Cortex XSOAR) in future scenarios.
What is in the environment:
- Sysmon
- QRadar
- Configured PowerShell logs (Module Logging, etc.)
- Microsoft ATA
- Note: Due to using some screenshots from my previously prepared document, there may be variations in names and dates.
Attacker side:
Attacker using the MS17-010 vulnerability and takes control of Andre’s computer.
Defender side:
As defenders we need to disable PowerShell version 2.0. This version lacks sufficient logging capabilities making it highly attractive to threat actors. Microsoft has taken steps to enhance security in the latest versions of PowerShell. These improvements include advanced logging features logging of executed PowerShell commands, scripts, and their outputs. This provides crucial measures for the defense side and strengthens the overall security posture.
Is PowerShell version 2 active? Let’s check it:
I am running the following commands sequentially to disable version 2 of PowerShell.
Disable-WindowsOptionalFeature -Online -FeatureName "MicrosoftWindowsPowerShellV2Root"
Disable-WindowsOptionalFeature -Online -FeatureName "MicrosoftWindowsPowerShellV2"
Attacker side:
Let’s go back to Empire. To establish a connection from Empire we first need to set up a listener.
We can view our payload using the “launcher powershell” command in Empire.
Once we execute the launcher code in the shell obtained through MS17-010, we establish an Empire connection.
Defender side:
Until this point everything seems good. After obtaining the shell using MS17-010, when we execute the launcher code we establish an Empire connection. Now let’s see how we can detect it and what measures we can take. Depending on the security investments in your organization you can increase your detection chances separately through products like FireEye NX and SIEM.
(Don’t forget SSL visibility alongside FireEye NX☺️)
When reviewing logs in QRadar we can observe the obfuscate - deobfuscate state of the code that the attacker executed in base64 format due to PowerShell Module Logging being enabled.
As we continue inspecting the logs, the following sections within the payload will undoubtedly raise suspicion
value="/admin/get.php" ParameterBinding(Get-Random): name="InputObject"; value="/news.php" ParameterBinding(Get-Random): name="InputObject"; value="/login/process.php"
We can use the following regex pattern to detect the –enc command in the Empire launcher. By doing so we will not only identify Empire-related activity but also catch any instance of PowerShell using the encode command:
\-[Ee^]{1,2}[NnCcOoDdEeMmAa^]+ [A-Za-z0-9+/=]{5,}
On QRadar the following rule will serve our purpose effectively:
Sigma rule:
title: T1086-MITRE-PowerShell ENC Command Usage
id: -
description: PowerShell ENC Command Usage
references:
- https://unit42.paloaltonetworks.com/unit42-pulling-back-the-curtains-on-encodedcommand-powershell-attacks/
tags:
- attack.Execution
- attack.T1086
logsource:
product: windows
service: sysmon
date: 9/6/2020
author: Can Yoleri
detection:
selection:
EventID: 1
expression:
- '\-[Ee^]{1,2}[NnCcOoDdEeMmAa^]+ [A-Za-z0-9+/=]{5,}'
condition: selection
falsepositives:
— Legacy Apps.
level: High
We can create a rule on the SIEM to generate an alert if there is a connection to an IP address using PowerShell or CMD.
On QRadar, a rule like the following will serve our purpose effectively:
title: T1059/T1086 - MITRE - Connectivity Monitor for PowerShell / CMD
id: -
description: Connectivity Monitor for PowerShell / CMD
references:
-
tags:
- attack.Execution
- attack.T1059
- attack.T1086
logsource:
product: windows
service: sysmon
date: 9/6/2020
author: Can Yoleri
detection:
selection:
EventID: 3
Image:
— '*\powershell.exe'
— '*\cmd.exe'
expression: #dst_ip
- '\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.'
condition: selection
falsepositives:
— Legacy Apps.
level: High
Attacker side: Let’s continue:
Listing active connections:
First, I run Mimikatz to check if clear-text passwords are being stored. However, Mimikatz only provides hashes and does not show anything else
With the “creds” command we can view all the credential information we have obtained.
Defender side:
We ran Mimikatz, let’s see what logs we received.
As we mentioned the importance of having PowerShell logging enabled we can see that with PowerShell logging enabled we can easily view the output of commands and scripts executed on the system.
The output seen by the attacker:
QRADAR:
Certainly, if the computer has AV (Antivirus), EDR (Endpoint Detection and Response), and network security products installed and they are properly configured, they should be able to detect this activity and generate an alert.
To generate an alert in PowerShell logs if MD5/NTLM hash information is detected we can create a rule with the following regex pattern:
title: T1003-MITRE-NTLM Hash in PWSH Logs
id: -
description: NTLM Hash in PWSH Logs
references:
-
tags:
- attack.CredentialAccess
- attack.T1003
logsource:
product: windows
service: PowerShell
date: 10/6/2020
author: Can Yoleri
detection:
selection:
EventID: 4103
expression:
- '\b[0-9a-fA-F]{32}\b'
condition: selection
falsepositives:
— Legacy Apps.
level: High
While inspecting the logs we can observe instances where the source image is PowerShell, the target image is whoami and the Granted Access value is 0x1FFFFF.
This means that the PowerShell.exe with the value 0x1FFFFF may have executed the whoami.exe process, which is a part of Invoke-Mimikatz in Empire. However it is possible that this activity is legitimate. Nevertheless it is best to continue investigating to ensure security and verify the legitimacy of the activity.
The parent image is PowerShell and the image is whoami. It will match the encode rule we previously set up and it will generate an alert.
Mimikatz:
There is no simple way to address all possibilities or gather all events but I believe that beyond detecting tools like Mimikatz more rules and configurations are needed..
To prevent/detect credential dumping methods like this configurations such as Microsoft’s Credential Guard, LSA protection and technologies like AV and EDR are essential. Additionally, technologies that analyze traffic to analyze NTLM hashes, Mimikatz output, and transfers of password dumpers over SMB are also necessary.
Indeed, in addition to the mentioned security technologies we can also implement Group Policy hardening measures to mitigate the risks posed by Mimikatz.
Debug Privilege
To interact with the LSASS process, Mimikatz requires specific permissions.
Here I am granting the privilege to debug programs only to a specific group that needs it, adhering to the principle of least privilege.
When executed it will produce the following error:
WDigest
We navigate to the following path in the Registry and set the values of Negotiate and UseLogonCredential to 0. Although a privileged attacker can modify these values, we will monitor these values from SIEM. If the Registry value becomes 1 we will investigate the possibility of the attacker having changed it accordingly.
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Sigma:
title: T1003/T1112-MITRE-Registry Keys For Wdigest
id: -
description: Monitor for wdigest registry key
status: experimental
references:
-
tags:
- attack.CredentialDumping
- attack.T1003
- attack.DefenseEvasion
- attack.T1112
logsource:
product: windows
service: sysmon
date: 2020/06/1
author: Can Yoleri
detection:
selection:
ParentImage|contains:
- '\powershell.exe'
- '\cmd.exe'
Image:
— *\reg.exe
CommandLine|contains:
- '\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\'
- 'UseLogonCredential'
- 'Negotiate'
condition: 1 of them
falsepositives: — unknown
level: High
When the attacker runs the command they will receive the following error:
LSA Protection
This protection can be achieved by setting the “RunAsPPL” value to 1 in the Registry.
When executed:
Credential Caching
In case there is no access to the DC, we can check if there is any cached account information to authenticate the user. We can enter the cache value under the SECURITY registry key as follows:
HKEY_LOCAL_MACHINE\SECURITY\Cache
We can also set the value to 0 in the GPO settings to prevent caching.
When executed:
Indeed, we can continue to expand the preventive measures in various ways.
Attacker side:
As the attacker, we have successfully compromised the machine, executed Mimikatz but couldn’t find clear-text passwords. Now, let’s proceed with the scenario by identifying the IP address of the DC and continue our actions accordingly.
To identify the Domain Controller machine, I am using the
situational_awareness/network/powerview/get_domain_controller module
We see that the IP address of the domain controller is 10.10.10.128
Defender side:
We see the same output that the attacker saw in the PowerShell logs.
QRADAR:
As we continue to look at the logs we also notice the DNS Query logs. Encode PowerShell, Mimikatz, and now a DNS request to the DC..
Attacker side:
We will create a Golden Ticket by taking the hash of the KRBTGT account with DCSYNC.
What is DCSYNC?
DCSYNC is a function that can be used to simulate the replication process of an Active Directory domain controller (DC) from an attacker. It can be used to extract data from the DC, such as user passwords and other sensitive information.
To use DCSYNC, the attacker must have the appropriate permissions on a user account in the domain. These permissions can be domain administrator, enterprise administrator or a specific service account.
- Replicating Directory Changes
- Replicating Directory Changes All
- Replicating Directory Changes In Filtered Set
As an attacker, if I have access to such an authorized user I can use the DCSYNC feature of Mimikatz to impersonate myself as a Domain Controller and use the MS-DRSR protocol to request account password information from the targeted Domain Controller.
I am filling in the required fields on the module.
Defender side:
We can see that Microsoft ATA’s logs have generated an alarm for us. I had previously done this on another machine so it appears as 2 accounts.
Attacker side:
We can see the hash of the krbtgt user by looking at the creds command again.
Let’s learn SID information now.
Let’s create a Golden Ticket.
If we added 519 to the end of the SID information here, we would become Enterprise Admin in the root domain. But since we are not performing this scenario through the child domain, it will not make much difference.
Golden Ticket creation process was successful.
QRADAR:
Defender side:
Microsoft ATA is detecting Golden Ticket activity.
After creating Golden Ticket, we run the DCSYNC module again.
Defender side:
QRADAR:
Attacker side:
Let’s try the Invoke WMI lateral movement module now. When we type the listener and the name of the machine we want to connect to, it says Now active!
Defender side:
We can see that the Empire launcher is running by looking at the logs of the infected machine.
EventID:600
EventID:800 
I’m sure you can imagine what goes through my mind when I see this on top of so many encoded PowerShell logs 😱
I am running the get_loggedon module to see the users who are logged on to the machine.
When I look at the logs, I notice the Get-NetLoggedon part in the following log.
When I search for it on Google, I see that it is a function used in PowerView. Someone must have collected information here!
We can multiply scenarios, for example, we can change the ciphers when creating tickets so that ATA does not detect them, we can create silver tickets, we can bypass module logging. I am thinking of writing about these in the next articles. Developing the scenario is entirely up to our imagination.
References
https://devblogs.microsoft.com/powershell/windows-powershell-2-0-deprecation/
https://securityriskadvisors.com/blog/detecting-in-memory-mimikatz/