Hunting for self deleting malware
The Microsoft Malware Protection Center recently posted an interesting blog post about how they detected a software supply chain cyberattack. This was a nice example of using strong generic detections and combining a number of invariants across the kill chain to detect an attack for which no specific signature or IOCs existed.
The MMPC detection of a process attempting to perform a self-deletion action using cmd.exe caught my eye.
This is something we regularly see when investigating attacks. It also reminded me of a tweet posted a few weeks ago by one of my favorite Microsoft analysts, John Lambert. He suggested detecting ping and waitfor because malware uses them as synchronization crutches:
I logged into the Veramine portal in the context of a customer who has graciously given us permission to share redacted screenshots from the few hundred hosts they have connected. We start with a simple search that should match the MMPC sample behavior:
This search returned 91 matching processes:
Let's take a look at that first "ping 127.0.0.1 -n 3". Here is its process tree:
This looks like an uninstaller for a Windows and Office activation helper/crack. This might be worth investigating to determine whether this is unwanted software because this type of software also sometimes "bundles" other unwanted software such as SearchProtect and other browser hijack addins.
The next two search results also seem related to the same or a similar Key Management helper. This time the process was started by explorer.exe but the system32 CWD indicates it was less likely to be an interactive click by the user and more likely to be run automatically via some persistence mechanism:
The next few matches also seem to be related to an uninstall operations:
That particular uninstaller appears to have run the following set of commands:
- uninstall.bat >> C:/Users/..../AppData/Local/Nox/Log_script.txt
- ping -n 4 127.0.0.1
- tasklist | find /i "Nox_unload.exe"
- ping -n 2 127.0.0.1
- taskkill /im "Nox_unload.exe" /f
- ping -n 2 127.0.0.1
- taskkill /im "Nox_unload.exe" /f
- ping -n 2 127.0.0.1
- taskkill /im "Nox_unload.exe" /f
- ping -n 2 127.0.0.1
- taskkill /im "Nox_unload.exe" /f
- ping -n 2 127.0.0.1
- taskkill /im "Nox_unload.exe" /f
Unlikely to be malicious.
The command line of the next search result seems closer to the self-deleting behavior we set out to find:
Not sure what the OneKeyGhost product does but browsing to the product's homepage is blocked:
And several AV engines mark the exe as malicious, as can be seen in the Veramine binary details page and the VirusTotal webpage:
The OneKeyGhost.exe process makes a brief outbound network connection via the proxy but its hard to know for sure whether that network connection should change our suspicion level of the binary:
It may not actually be malicious or unwanted software but warrants further investigation. If it does end up being unwanted, the Veramine platform can block its execution across every host with a simple click on the "Actions" button in the binary details page.
Our goal is to build a general heuristic for potentially unwanted software and it doesn't feel like we have found it yet. I'd like to see more instances like OneKeyGhost and fewer instances of legitimate installers to sort through. To that end, we change our search query to better match the more interesting command line, minus a few legitimate android-sdk matches:
This search turned out to be a higher signal-to-noise than our original search. It matched 26 total processes and only eight distinct cmd.exe command lines. Here they were:
- C:\Windows\system32\cmd.exe /c attrib -r -s -h -a "C:\Windows\SetupRun.exe" & ping 127.0.0.1 -n 3 & del /a /f /q "C:\Windows\SetupRun.exe"
- "C:\Windows\System32\cmd.exe" /c ping -n 2 127.0.0.1 & del "Sysscan.exe"
- "C:\Windows\system32\cmd.exe" /c ping 127.0.0.1 -n 2 > nul & del "C:\Users....\AppData\Local\Temp\webfriend.exe" > nul
- C:\Windows\system32\cmd.exe /c attrib -r -s -h -a "C:\Windows\SetupRun.exe" & ping 127.0.0.1 -n 3 & del /a /f /q "C:\Windows\SetupRun.exe"
- C:\Windows\system32\cmd.exe /c ping 127.0.0.1 -n 2&del /f /q "C:\Users\asus\AppData\Local\Temp\filedisk.exe"
- "C:\Windows\System32\cmd.exe" /c ping -n 2 127.0.0.1 & del "csrss.exe"
- "C:\Windows\System32\cmd.exe" /c ping -n 2 127.0.0.1 & del "rsd.exe"
- cmd.exe /C ping 1.1.1.1 -n 1 -w 1500 > Nul & del "C:\Program Files\3uTools\Uninstall.exe" & ping 1.1.1.1 -n 1 -w 1500 > Nul & cd /d "C:\Users....\AppData\Local\Temp" & rmdir "C:\Program Files\3uTools" /q
#1 (SetupRun.exe) was an unsigned binary detected as malicious by 20 AV engines. A good start for this new search.
#2 (Sysscan.exe) was a very interesting case because it was loaded via drive redirection from the Terminal Services client:
A future version of the Veramine client will include the ability to scan files on SMB shares but for now we have limited visibility into this client. The Veramine sensor was unfortunately not installed on the particular host from which the RDP session originated but we do have a record of the user login via this machine's User Sessions tab, including the source IP and source hostname:
We can also get a clue about this process from the other processes launched by the same parent:
We don't know for sure which binary this is but VirusTotal does have a recently uploaded sysscan.exe with AV detections similar to other infections on this customer network. That file is https://www.virustotal.com/en/file/7e6a14ef9bdc19ae73cf4de4fec2d6dcd1035ccbcc393e2e4fdc6be7c848485f/analysis/ but it is hard to know for certain that this is the same file. Enough signs point to this process being suspicious that an IR should probably be initiated.
#3 (webfriend.exe) was an interesting search result not necessarily for itself which may or may not be malicious. However, the parent process binary (Total_System_Care_License_Key_Free_Download_2017.exe) is likely to be bad with 36 AV engines detecting it as malicious.
If we look at all the child processes of that malicious parent, we see that this process also launched a number of other suspicious-looking other child processes:
#4 (C:\Windows\SetupRun.exe) was also flagged by a number of AV engines as malicious. It was run a number of times on this network and also immediately deleted after being run:
This was also another malicious command line that also included attrib, in addition to ping and del. Perhaps the presence of attrib in the command line can increase the confidence of this heuristic.
#5 (filedisk.exe) We didn't find any record of a filedisk.exe ever having been run on the hosts where the Veramine sensor is installed so its hard to know for sure if this self delete was related to malicious activity. The process tree seems related to that suspicious OneKeyGhost we encountered ealier.
#6 (csrss.exe) and #7 (rsd.exe). We were initially disappointed to find that this csrss.exe involved in the self-delete was running from a tsclient network share because the current version of the Veramine sensor does not scan binaries launched from network shares. A future version of the Veramine sensor will do so. This process tree seemed suspicious due to the process using the same name (csrss.exe) as a known, trusted Microsoft process:
We thought the large number (1025728) passed in to the csrss.exe as a command line argument seemed distinctive enough that it might correlate to another related process where we could learn more about this csrss.exe. We did a quick search for other processes where that same number was passed in:
Bingo! On April 18, that suspicious csrss.exe was run from the \\tsclient share from which we don't have full visiblity. However, on May 9 a similar process tree showed up with a very similar command line.
This time the process binary was named rsd.exe but it sure looks similar and (most importantly, for this blog post) it was run from a user's desktop so the Veramine sensor uploaded a copy of it before it got deleted:
We cannot know for certain that csrss.exe and rsd.exe are the same binary but the same command line arguments do give us that suspicion. And VirusTotal tells us that this rsd.exe is flagged by 39 AV engines as malicious. It's also interesting to see the other child processes of this rsd.exe:
It appears to be using reg.exe to change RDP security settings to prevent anyone else from taking over this system. (Thanks to John Lambert for highlighting this pattern and several related post-exploitation steps.) And then it launches this binary we had not investigated before, 3925324.exe. This particular binary was seen for the first time today, the day we were performing this investigation. However, this same process binary was launched as three different processes, each having a different filename:
One of the other two instances of this same process binary, the one named 5633106.exe, was particularly interesting based on a child process it launched to allow RDP inbound on the client firewall:
We also saw that this particular parent rsd.exe also made an outbound network connection of udp/53 to the local domain controller, sending 35 bytes and receiving 80 bytes. It would be interesting to review the DNS logs from that server at that time to review which name this particular host might be attempting to resolve.
This "Hunting" exercise has given us enough confidence to build an algorithm that detects self-deleting binaries via command line matching. If you'd like to gain this type of visibility in your network, please reach out to us for a free trial of the Veramine platform. The sensor is a single Windows binary pre-configured with a unique customerguid so you can literally just run an exe on as many hosts as you'd like on your network and then log in to our cloud-based portal to perform this type of investigation right away. Or, if you'd prefer to self-host the Veramine server-side infrastructure, we would be happy to set up a test and evaluation instance in your data center - it only takes a few moments to get started if you can give us ssh access to a single linux server for setup. Please reach out for a trial or with any questions at [email protected].
Note: Thanks to Elia Florio and John Lambert from Microsoft for reviewing drafts of this post.