Hafnium, a state-sponsored APT group, is believed to have potentially compromised tens of thousands of organizations globally by leveraging multiple 0-day vulnerabilities (such as CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) affecting on-prem Microsoft Exchange servers.
If you are running an on-prem version of Microsoft Exchange, and specifically have OWA enabled, it is highly recommended to check your historical data (logs, network and endpoint) for any indicator of compromise.
In this post, we will look at some of different IOCs and queries that can be performed on NetWitness to help you start an investigation and potentially identify if your environment has been impacted by this attack.
These queries are initial queries, and further queries, filtering and investigations are needed to confirm a breach, such as filtering specifically on events related to your Exchange server's IP addresses, filtering out unsuccessful scanning activity (such as those returning specific HTTP error codes, empty payloads ….), or similar behaviors that might be known and legitimate in your specific environment.
The queries and details of the attack are based on the report published by Microsoft available at the following URL: https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
Pre-Query
Queries mentioned in this document depend on the type of data collected on NetWitness:
For all queries mentioned in this document, start by filtering events specifically targeting your Exchange Servers’ IP addresses.
NetWitness Network:
ip.dst = <exchange_ip> || alias.ip = <exchange_ip>
NetWitness Logs:
ip.dst = <exchange_ip> || device.ip = <exchange_ip>
NetWitness Endpoint:
ip.src=<exchange_ip> || ip.dst = <exchange_ip>
Authentication Bypass
The threat actor exploits the vulnerabilities to bypass authentication on Microsoft Exchange. This requires sending specially crafted HTTP POST requests, such as:
NetWitness Logs/Network Query:
action = 'post' && (directory = '/owa/auth/Current/themes/resources/' || (directory = '/ecp/' && filename = 'main.css','default.flt'))
One of the POST requests targets JavaScript file with a single character filename (“/ecp/<single character>.js”). This can be queried using RegEx, but it should be noted that such queries can be slower when executed on large sets of data and should be used with caution.
NetWitness Logs/Network RegEx Query:
action = 'post' && directory = '/ecp/' && filename regex '^.\.js'
The following are User-Agents have been observed initiating the HTTP POST requests:
NetWitness Logs/Network Query:
user.agent = 'DuckDuckBot/1.0;+(+http://duckduckgo.com/duckduckbot.html)','facebookexternalhit/1.1+(+http://www.facebook.com/externalhit_uatext.php)','Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)','Mozilla/5.0+(compatible;+Bingbot/2.0;++http://www.bing.com/bingbot.htm)','Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html','Mozilla/5.0+(compatible;+Konqueror/3.5;+Linux)+KHTML/3.5.5+(like+Gecko)+(Exabot-Thumbnails)','Mozilla/5.0+(compatible;+Yahoo!+Slurp;+http://help.yahoo.com/help/us/ysearch/slurp)','Mozilla/5.0+(compatible;+YandexBot/3.0;++http://yandex.com/bots)','Mozilla/5.0+(X11;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.103+Safari/537.36','ExchangeServicesClient/0.0.0.0','python-requests/2.19.1','python-requests/2.25.1'
The above queries can be combined to filter further any potential results.
Web Shells
Once the threat actor compromises the environment, they have been seen deploying Web Shells on the compromised server. In some cases, the web shell has been added to existing legitimate aspx files, and therefore it is recommended to check the date when those files were last modified to identify any potential anomaly or unexpected changes.
Some of the identified web shell filenames include:
NetWitness Logs/Network Query:
filename = 'web.aspx','help.aspx','document.aspx','errorEE.aspx','errorEEE.aspx','errorEW.aspx','errorFF.aspx','healthcheck.aspx','aspnet_www.aspx','aspnet_client.aspx','xx.aspx','shell.aspx','aspnet_iisstart.aspx','one.aspx','errorcheck.aspx','t.aspx','discover.aspx','aspnettest.aspx','error.aspx','shellex.aspx','supp0rt.aspx','HttpProxy.aspx'
One of the observed .aspx filenames is a sequence of 8 randomly generated characters. We can use regular expressions to identify filenames with exactly 8 characters. The analyst should manually identify which of the results look randomly generated as the query could typically return legitimate filenames that happen to be 8 character long.
As mentioned above, whenever using regular expressions on large sets of data, do expect slower query times and use with caution.
NetWitness Logs/Network RegEx Query:
filename regex '^[a-zA-Z0-9]{8}\.aspx'
Filtering Out Scanning Activity:
As this breach became public, increased scanning activity has been observed by multiple different threat actors scanning for already installed web shells, and it’s therefore possible to see traffic targeting a “blacklisted” filename that might not exist in your environment, which would create unnecessary noise. As these would typically return an HTTP client error status code, and to help filter out some of these unwanted unsuccessful scanning events, the above queries can be combined with the following one to only look at events that didn’t return an HTTP error code:
error !exists
More generally, it is possible to leverage NetWitness Endpoint to look at behaviors of the web service process (“w3wp.exe”) that could be suspicious. For example, the below behaviors are often associated with Web Shell activity.
NetWitness Endpoint Query:
boc = 'http daemon runs command prompt','http daemon runs powershell','http daemon runs reconnaissance tool' || analysis.file = 'http daemon writes executable'
Then, access to the web shells has been seen originating from specific user agents, such as:
NetWitness Logs/Network Query:
user.agent = 'antSword/v2.1','Googlebot/2.1+(+http://www.googlebot.com/bot.html)','Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html)'
Some of the IP addresses seen to have been used by the Threat Actor:
It should be noted that some of these IP addresses are linked to VPN services and to the Tor network, and therefore traffic from these IP addresses might not always be specifically linked to this attack campaign.
NetWitness Query:
ip.all = 103.77.192.219,104.140.114.110,104.250.191.110,108.61.246.56,149.28.14.163,157.230.221.198,167.99.168.251,185.250.151.72,192.81.208.169,203.160.69.66,211.56.98.146,5.254.43.18,80.92.205.81,165.232.154.116,182.18.152.105,89.34.111.11,86.105.18.116,5.2.69.14,91.192.103.43
Password Dumping
After exploiting the system, they have been seen using procdump to dump the LSASS process memory and compromise user credentials.
NetWitness Endpoint Query:
filename.all = 'procdump64.exe','procdump.exe' && param.all contains 'lsass.exe'
More generally, NetWitness Endpoint can detect password dumping activity using the following query:
attack.technique = 'credential dumping'
Data Exfiltration
The threat actor uses 7zip and WinRar to compress stolen data before exfiltrating it. They have been seen storing the file under the “C:\ProgramData\” folder.
NetWitness Endpoint Query:
filename.all = '7z.exe','rar.exe' && param.all contains 'programdata'
Reverse Shell
The threat actor has also used the Nishang PowerShell Framework to establish a reverse shell.
NetWitness Endpoint Query:
filename.all = 'powershell.exe','powershell_ise.exe' && param.all contains 'Net.Sockets.TCPClient'
Note that this query doesn’t specifically identify the use of Nishang but would filter on PowerShell events that should be investigated further.
Download of Tools from GitHub
The Attacker has also been seen downloading additional tools from GitHub, such as powercat, which is a PowerShell version of Netcat.
NetWitness Endpoint Query:
filename.all = 'powershell.exe','powershell_ise.exe','cmd.exe' && param.all contains 'powercat'
NetWitness Logs/Network query:
alias.host = 'raw.githubusercontent.com' && filename = 'powercat.ps1'
NetWitness would detect some of these behaviors out of the box without the need for these specific queries to be done manually. In those cases, the information would directly be available in the “ioc” (Indicator of Compromise) and “boc” (Behavior of Compromise) meta keys.
For more details on investigating additional techniques used by APT groups: https://community.rsa.com/t5/rsa-netwitness-platform-blog/profiling-attackers-series/ba-p/517665
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.