Hello and welcome to my presentation with the title
Hunting for Blue Mockingbird Coin Miners.
I am Vladislav Bačov and I would like to spend the next 20 or 25 minutes
with talking about incident response and investigation
of the recent incidents attributed to the relatively new trade actor
called Blue Mockingbird.
But because we are in a recon village,
this talk will not be about incident response only.
Instead, I would like to share with you
how our experiences have used reconnaissance
and open source intelligence approaches
to enrich our results from standard forensic and malware analysis.
As often happens, the attackers have deleted
some of their tools after they used them.
However, with our recon and OSing approach,
we were able to find them and reconstruct the original attack
performed by the attackers.
Moreover, we were able to track origin of the malware
and we got insight into the technical capabilities
of the Blue Mockingbird trade actor.
And finally, in some cases,
we could track the incomings of the cryptocurrency wallets
used by Blue Mockingbirds
and we can estimate profit of the attackers
and compare it with the damage they caused to their victims.
So, this is our agenda.
And now, let me allow to introduce myself.
Who am I?
I am Vladislav Bačov and I currently work
as a security senior consultant and malware analyst for Lifers,
a New York City-based incident response and digital forensic company.
In the past, I also worked for the government of one European country
as an analyst in CSIRT, Computer Security Incident Response Team Slovakia.
But now...
Okay...
We can ask one obvious question.
Why a presentation about malware analysis,
threat intelligence and OSing?
There are a lot of automated solutions,
such as antivirus scanners and sandboxes.
So, why do we need to bother with additional malware analysis
and enrichments with info from another public sources,
if those automated solutions can identify most of the common threats?
Well, the answer is hidden in the previous sentence.
They can identify the most of the common threats.
And I would like to emphasize the word common.
When you need to deal with advanced threat actors
or uncommon threats, such as rare or obfuscated malware samples,
they can stay undetected by many of antivirus scanners and sandboxes.
On the other hand, malware analysts can perform a brief analysis of those samples.
And moreover, if they enrich the better results with intelligence info,
they can quickly provide the rest of the team with accurate report.
And this report can include not only the purpose and capabilities of the malware,
but also origin of the samples or attributions to the threat actors.
It can also help to reveal yet undiscovered steps of attacker,
as well as it can recover yet missing pieces of malware puzzle used by attacker.
And last but not least, this brief analysis with intelligence data
can collect more indicator of compromise relevant for threat intelligence,
for threat hunting and monitoring team.
And when we are talking about using threat intelligence fees and other data sources,
we can search for many attributes.
There are obvious ones like URLs, hashes, and so on.
But in addition, very helpful can be searched by file name, regular expressions,
and malware classifications, such as categories and tags.
Also, search for strings embedded in the malware or search by import hashes
can discover more similar samples, which can be linked to the same attacks or to the same threat actors.
And where to search?
Here is a list of couple of examples, which will be covered later during this talk.
And also, some of these tools can be very handy for the analyst.
But these slides will be shared with you, so let's move forward.
And okay, now we are ready to start with advertised incident response and infection with coin miners.
So, it began with a high load of some computers.
One could say, nothing strange, maybe only updates were being applied.
But when local IT guys verified these machines, they noticed something unusual.
Abnormally high CPU and memory usage by SVC host process.
Moreover, the SVC host process corresponded with the problem reports and solution control panel support service.
This could be a more serious problem, indeed.
Antivirus did not find anything.
But after manual submission of DLLs, the antivirus company identified them as coin miner or crypto mining variant.
So, that's how the incident response began.
We verified the findings of our client and we started analyzing machine with the coin miner.
We followed the usual procedures and examined the provided evidence.
We also verified signatures of DLLs in Windows System 32 directory and we checked those files against the National Software Reference Library database.
As a result, we found a couple of malicious files.
For example, this unknown file where CPL support E-DLL, which tries to mimics the legitimate one file name without E suffix.
On the infected systems, there were a couple of DLLs marked as wannabe Windows System DLL files.
But their hashes and also their file names were not present in any databases of known software and also in clean Windows systems they were not found.
In addition, we saw that the extracted strings contained many occurrences of xamarin substrings, so we had to deal with infection of xamarin-based coin miner.
And there is another thing common for all of these xamarin-based coin miner DLLs.
They created a mutex called samplexn07 and this mutex ensures that only one instance of coin miner is running on each infected device.
I need to add that this mutex name can be used as an additional indicator of compromise and also it can be used for finding another related samples in public databases.
While the most detected fake DLLs had the same hash, there was only one with different hash.
It executed the command line with the command for creation of scheduled task called windows-problem-collections and as well as other persistence via services.
Thus, it was responsible for one part of persistent mechanism we already found.
But the question is, what else attacker deployed in the client network and how they got access to the network?
First steps of forensic analysis revealed the one batch file called x.bat and couple of suspicious tasks.
The batch file contained the PowerShell downloader, which downloads additional content from JavaScript resource on the local web server.
However, it was not JavaScript, but PowerShell, which created the scheduled task.
And these scheduled tasks used the file called scriptstamp.
In our case, it contains a backdoor, a Netcat backdoor.
And what about its origin?
The threat intelligence search based on file names and strings led us to the four years old scheduled task backdoor GitHub repository with Chinese comments in readme file.
Forensic analysis also revealed DLLs files dropped by IIS worker process.
The DLLs files were mixed mode assembly, so they contained both the managed and unmanaged code.
The .NET part of DLL contains only the empty class. Yes, it was really empty.
On the other hand, in the native code, this DLL main dispatcher spent a reverse shell connected to the attacker.
And as I mentioned, there were more similar DLL files.
However, these files differs only in two strings, which contained the original file name of DLL.
So nothing, no significant differences in the functionality of these files.
With the suspicion that this could be payload delivered after the exploitation of ASP.NET vulnerability because of IIS worker process,
we tried to find something more about it.
With the similarity in original build name, DLL names, it was easy to leverage the thread intelligence and found the particular vulnerability and the tool, which produces the same DLLs.
It turns out that these files had been part of remote code execution exploit for vulnerability in Telerik web user interface for ASP.NET.
This exploit can be found on GitHub, again.
And after review, it was clear that this tool was used for building the DLLs with the reverse shell we just discovered.
So we find the origin of this tool and also the initial letter of compromise.
Further investigation and hunting for other persistence methods revealed the WMI event subscriptions.
The attackers registered the event filter and consumer and also the filter to consumer binding.
And as a result, it executed the same command as we already saw in the DLL files.
Now, we thought that we were ready to start with remediation and removal the malicious artifacts from the network.
We developed a custom PowerShell script for detection of all malicious stuff we were aware, including the malicious files and also the persistent artifacts.
Then we deployed our scripts throughout EDR solution and there was a big surprise.
EDR fired alert that there were detected attempts to install persistence for malicious DLLs we already known.
So, we investigated those alerts and we found that those commands had been spawned by PowerShell process.
Actually, the PowerShell process associated with our removal script.
What? What the hell is this?
We were absolutely sure that our PowerShell script didn't do anything like this.
Its purpose was to remove malicious persistence, not to create new one.
Yet we tested our script in our lab and also our client tested the script in their environment and nothing similar was observed.
Hence, there was only one possible explanation of this.
The attacker established another persistence method we did not find yet.
Therefore, another investigation was needed.
After a while, we found that the malicious DLL is loaded into the PowerShell process shortly after it queried the registry for specific class ID.
And this class ID pointed to one of the malicious DLL files.
Okay, but now there is another question.
Why PowerShell was interested in this malicious class ID?
The answer was hidden in the environment variables.
Especially, there were two environment variables called core enable profiling and core profiler.
They caused that every managed process was connected to the profiler specified by given class ID.
So, the attacker misused the profiling of .NET applications.
Great. Another small victory for defenders. Yeah.
Now, before we continue, let's quickly summarize what we discovered until now.
We already saw thousands of malware samples from four families.
Coin miners, DLL installers for those coin miners, scheduled task backdoors, and reverse shells delivered after the exploitation.
Regarding persistence, we already discovered malicious services and scheduled tasks.
And later, we discovered and analyzed WMI event subscription and core profiler persistence.
At this point, we had a lot of samples and persistence.
But we were faced with the questions how the attacker installed all of these persistence artifacts,
and what they exactly did between the initial exploitation and installation of coin miners on thousands of computers.
Now, we really needed to enrich our results with external data from Threat Intelligence and OSINT.
We used a clever tool called Munin by Florian Erot.
All we needed to do was to create one file with hashes of malware samples and let Munin do its work.
We found several hashes in public repositories, but there were only one public submission of the DLL installer, without any trace detected.
When we did a context search instead of object search, we get another submission, as we can see in the picture.
The zip archive with potentially malicious files.
Now, let's look on the zipkernel file.
It contains several DLLs, batch files, and one MOF file, which stands for Managed Object Format.
We were familiar with some of them.
One DLL was coin miner and the second was installer we already analyzed.
The MOF file was interesting.
Now, you can see its content on the right.
It contained definitions of WMI event subscriptions used for persistence we found earlier.
So, we got it.
We found the WMI persistence.
Now, we are aware how it was created.
But what about the batch files?
They were new for us, but there was a strong assumption that they were also related to the same ethics.
When we examined the RNBAT file, we could say,
Eureka!
This batch file was an installation script for all stuff related to coin miners and persistence we already discovered.
Thus, this is another piece of puzzle we missed until now.
Second batch file, called sn.bat, was unpacker.
It also seemed that the coin miners malicious stuff originally came as a package called set.zip.
We also saw that this installation batch script was executed via a program called let.exe.
But what was the let.exe and what files did the set.zip contain?
We didn't find them yet.
So, let's continue.
We applied the same approach again and we tried to do a reconnaissance about let.exe and installation package.
In some cases, we were able to follow tracks of the let.exe execution in public sources.
It seemed that it was a kind of local privilege exploit.
Then, suddenly, we found the one submission of set.zip on hybrid analysis.
And this submission could be related to our investigation.
And yes, this file was exactly the one we were hunting for, the installation package.
And the program let.exe was included.
As it turned out that our hypothesis was correct.
The program let.exe was the juicy potato local privilege exploit with source codes available on GitHub.
Again. Again on GitHub.
There left only last sample.
We don't analyze it until now.
The nw.gold.dll from previous zip archive from any run.
It was mixed-mod.dll file.
Its name was composed from noun, timestamp, and architecture.
And the managed code contains only empty .NET class, while the native code contains a dropper of unpacker batch file we saw before.
But wait. Doesn't this nw.gold.dll file look familiar?
Of course. We already saw the mixed-mod.dll with empty C-sharp class.
It was reverse shell payload delivered by the Telerik WebUI exploitation.
So let's compare these two files side by side.
We can see that they contain a lot of similarity stuff.
And we could assume that this dll had been also created with build scripts from Telerik WebUI exploit.
But now, it was developed by TreadActor.
Okay. We found all missing pieces of puzzle.
We also collected all samples needed for attack reconstruction or simulation.
And in that moment, we went one step further.
We also collected the whole set of needed samples from public sources.
Therefore, we could demonstrate this attack using public sandboxes without revealing any sensitive info from the private samples shared by our client.
So, let's allow me to play a short video demonstration.
Okay. Thank you for watching the video.
And now, before we summarize our findings, let's proceed with the last part of this talk.
The attacker's profit.
We extracted crypto mining pool's parameters and configuration either from captured pickups or from memory dumps.
Then, we used these parameters for hunting for more and more samples and repeated this process again and again.
Finally, we collected several workers' IDs, but only two account IDs.
These account IDs were reused in several cases.
In the table, there are amounts of monero coin mines mined by attackers on various pools.
As a footnote, some workers were still active last week.
But back to the case.
In the cases we discovered, attackers have mined approximately 150 monero coins in total, which is now approximately 13,000 USD.
For comparison, average damages per day victim varies between $50,000 and $500,000.
And this includes only the direct costs, such as incident response and remediation process, investigation and reinstallation of their systems.
The indirect costs, such as reputation loss and disruption or damages due to downtime, aren't included in this estimation.
And last, but not least.
What do we discovered in our analysis and research?
First of all, thanks to online databases and feeds, we are able to find missing pieces and reconstruct the whole attack performed by this red actor.
In the meantime, this red actor got a name, Blue Mockingbird, given by Red Canary Company.
We observed that they were capable to adapt and customize various tools from GitHub and put all the data in their unpacker and installation scripts.
It is unusual to see so many persistence methods used in one attack.
This probably required research performed by Blue Mockingbird.
After that, they were able to earn thousands of dollars, but the victim damages are much greater than the attackers' profit.
So, that's all from my side. Here are provided some resources related to this talk.
And additionally, you can read something about my work or research on our company website or on my personal blog.
And you can find me also on Twitter.
So, thank you very much for attending this talk, and if you have any questions, please feel free to ask me.