Software that runs, automatically!
A lot of software on our machines (whether it be home desktops or enterprise servers) is designed to run automatically without manual triggers.
Great examples include:
- Vital system and user services like networking or time synchronisation during system boot-up.
- Anti-virus or other security solutions starting quickly after boot-up.
- Update checkers for critical software running every few hours.
Unfortunately, software that runs automatically makes malware salivate uncontrollably.
Malware often sets up automated executables that can re-trigger its malicious code in the hope of keeping itself alive and well on the system. Therefore, it is important to ensure systems do not have any suspicious automated scripts running that might be malicious (or otherwise unwanted).
Sysinternals Autoruns
On my Windows machine, I sometimes explore executables that are set to automatically run using Microsoft's Sysinternals Autoruns. Autoruns is a nifty tool that will show you all the registry entries, services, and tasks that are configured to trigger automatically.
During my inspection I managed to do some cleaning. I removed BaiduYunDetect from starting automatically. I use this app when I am downloading various files from the Baidu Cloud (often malware samples). Don't worry it hasn't mined any crypto on my system...yet. I disabled MicrosoftEdgeAutoLaunch since last time I used a Microsoft browser it was warning me about viewing websites over a secure connection. I also deleted some other entries that pointed to binaries that no longer existed due to uninstallations.
Autoruns makes it easy for you to spot potentially suspicious entries. If the binary being executed is not digitally signed by an authority that is trusted on your system, Autoruns highlights it with a red background (almost as if to shame it for merely existing).
However, it's important to note there is nothing suspicious about these two red entries. Ueli and Pushbullet are two well-known and trusted projects. They just likely haven't pursued digital verification by a trusted authority due to the associated costs. However, you can be almost certain that any malware that shows up here will not be digitally signed and verified.
QUEENCRACK?
All was going well, I was demolishing Autoruns entries like a system admin on their last day.
Until...I ran into QUEENCREEK.
Perhaps the biggest fear in this endeavour is finding an application that you do not recognise. You have to decide if it's malicious or not and how it got there. That is not always trivial. But hang on, this is a Verified digitally signed binary. I propose we distribute it far and wide and run it as Administrator on our main database host.
Not so fast!
Malware developers know that both humans and anti virus software inspect Autoruns entries. Therefore, they use various techniques to hide their intent. One of the most common techniques is to use a trusted application in the Autoruns entry that then triggers their malicious executable. In this case, we see an entry for Wscript.exe which is a legitimate binary by Microsoft that is used to execute other scripts (typically VBScript and Javascript). Therefore, it is no surprise to discover it is digitally signed and verified.
The entry is a Task Scheduler entry, so we can open it there to view its associated actions.
The plot thickens! We see this task is scheduled to trigger at logon, indefinitely.
The only action for the task is to use WScript to trigger task.vbs in batch mode with no logo (meaning no output is shown) :
"C:\WINDOWS\System32\Wscript.exe" //B //NoLogo "C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.vbs"In other words, task.vbs is silently triggered.
The observant amongst us will notice this seems to be located in a directory belonging to Intel (C:\Program Files\Intel). It is another common malware detection circumvention technique to store malicious binaries in trusted directories often belonging to trusted applications. This could work out well for the malware in the case that directory is excluded from real time scanning or security solutions think the malware belongs with its cohabitant binaries.
Next, we explore the contents of task.vbs:
Set objShell = CreateObject("WScript.Shell")
objShell.Run("C:\WINDOWS\System32\cmd.exe /c ""C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.bat"""), 0
Set objShell = Nothing Now this is what I would call a completely useless script. All this script does is invoke WScript again to invoke cmd and run a new file task.bat. This is another technique often used by malware in which it will pursue random or pointless execution (even if it's just sleeping or looping to burn CPU cycles) to try and throw off anti-virus software.
Alas, we move on to the infamous task.bat where surely the mystery is solved:
"C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.exe"Womp womp. This batch file does nothing but call a task.exe.
Finally, we arrive at the end of our little story.
We analyse our task.exe executable and notice that...it's digitally signed by Intel Corporation:
Intel, I knew it was them! Even when it was the malware developers, I knew it was them!
At this point, I do some research online to discover that this is not a malicious binary at all.
This binary is legitimate and part of the Intel PROSet/Wireless WiFi Software.
Take away
An Intel engineer must have read the project name as QUEENCRACK and confused their nightly black hat activities with their day job.
Using WScript in a Task Scheduler entry to invoke a VBS which invokes WScript to invoke cmd to invoke a Batch file which finally invokes an executable is madness. It mimics several techniques commonly used by actual malware. Furthermore, it opens the door for malware to "join the party" and replicate this exact setup but with a malicious payload. This ends up confusing end users and anti-virus engine heuristics. It's also not a surprise these files are scanned regularly on Virus Total (task.vbs, task.bat, task.exe).
