Introducing Blue Mockingbird

Blue Mockingbird is the name we’ve given to a cluster of similar activity we’ve observed involving Monero cryptocurrency-mining payloads in dynamic-link library (DLL) form on Windows systems. They achieve initial access by exploiting public-facing web applications, specifically those that use Telerik UI for ASP.NET, followed by execution and persistence using multiple techniques (check out my colleague Jesse Brown’s new blog for details on Blue Mockingbird’s COR_PROFILER persistence mechanism). During at least one incident, the adversary used proxying software and experimented with different kinds of reverse shell payloads to connect to external systems. The earliest Blue Mockingbird tools we’ve observed were created in December 2019.

Gaining entry

In at least two incident response (IR) engagements, Blue Mockingbird has exploited public-facing web applications (T1190: Exploit Public-Facing Application) that implemented Telerik UI for ASP.NET AJAX. This suite of user interface components accelerates the web development process, but some versions are susceptible to a deserialization vulnerability, CVE-2019-18935. The exploitation of this CVE is not unique to Blue Mockingbird, but it has been a common point of entry.

In exploiting this vulnerability, two DLLs are uploaded to a web application running on a Windows IIS web server. In telemetry, investigators will notice w3wp.exe writing the DLLs to disk and then immediately loading them into memory afterward. In some cases, this will cause w3wp.exe to temporarily freeze and fail to successfully serve HTTP responses.

For a diagnostic to determine whether you are potentially affected by the Telerik CVE, you can search the IIS access logs for the string POST Telerik.Web.UI.WebResource.axd. In victim environments, our IR partners found entries similar to these:

In the entries, the string 200 refers to HTTP response code 200 where the POST request was successful, and the string 500 refers to HTTP code 500 where the POST request was not processed successfully by the web server. These code 500 entries happened when the w3wp.exe process loaded the uploaded DLLs into memory and temporarily froze.

Searching the IIS access logs for entries like these is a good idea even if you don’t explicitly know whether you use Telerik UI, as some web applications require the suite as a dependency behind the scenes.

If you have endpoint detection and response (EDR) or similar tools, you’ll notice cmd.exe or other suspicious processes spawning from w3wp.exe.

Execution and evasion

The primary payload distributed by Blue Mockingbird is a version of XMRIG packaged as a DLL. XMRIG is a popular, open-source Monero-mining tool that adversaries can easily compile into custom tooling. During the incidents, we noted three distinct uses.

The first use was execution with rundll32.exe explicitly calling the DLL export fackaaxv (T1218.011: Rundll32). This export seems unique to this actor’s payloads and doesn’t seem to happen other places in the wild:

rundll32.exe dialogex.dll,fackaaxv

The next use was execution using regsvr32.exe using the /s command-line option (T1218.010: Regsvr32). Supplying the /s switch executes the DllRegisterServer export exposed by the DLL payload. This export ultimately passed control of execution into the function that fackaax exported:

regsvr32.exe /s dialogex.dll

The final execution path was with the payload configured as a Windows Service DLL (T1569.002: Service Execution). Once configured, execution of the service invoked the export ServiceMain, which again passed control to fackaaxv.

Come for the exploit, stay for the mining

Blue Mockingbird leveraged multiple techniques for persistence during incidents. The most novel technique was the use of a COR_PROFILER COM hijack to execute a malicious DLL and restore items removed by defenders (T1559.001: Component Object Model). To use COR_PROFILER, they used wmic.exe and Windows Registry modifications to set environment variables and specify a DLL payload.

The payload DLL specified as a COR_PROFILER was simple and gathered few antivirus detections. It executed the following command:

Since COR_PROFILER was configured, every process that loaded the Microsoft .NET Common Language Runtime would execute the command above, re-establishing persistence. The command configured the Windows Problem Reports and Solutions Control Panel Support service to execute automatically at boot (T1543.003: Windows Service). In a separate command, the actor modified the existing wercplsupport service to use the miner DLL instead of the legitimate one:

Note that the actor used the DLL name wercplsupporte.dll as an attempt to masquerade as the legitimate DLL name, which is wercplsupport.dll (T1036.005: Match Legitimate Name or Location). In addition, more masquerading was used to make malicious Scheduled Tasks blend in with legitimate ones (T1053.005: Scheduled Task).

In some cases, the actor even created a new service to perform the same actions as the COR_PROFILER payload: