 Hello and welcome to my presentation with the title Hunting for Blue Mockingbird Coin Miners. I am Vajasal Baccio and I would like to spend the next 20 or 25 minutes talking about incident response and investigation of the recent incidents attributed to the relatively new thread after called Blue Mockingbird. But because we are in a recon village, this talk will not be about incident response Actually, instead, I would like to share with you our experiences, how we used reconnaissance and open-source intelligence approaches to enrich our results from standard forensic malware analysis. As often happens, the attackers have deleted some of their tools after they used them. However, with our recon and OSINT approach, we were able to find them and reconstruct the original attack performed by attackers. Moreover, we were able to track origin of the malware and we got inside into the technical capabilities of the Blue Mockingbird Stragator. And finally, in some cases, they could track the incoming of the cryptocurrency 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 Władysław Baciu and I currently work as a security senior consultant and malware analyst for lifers, New York City-based incident response and digital forensic company. In the past, I also worked for government of one European country as analyst in C-Cert, computer security incident response team for IKEA. But now, okay, we can ask one of you's question why presentation about malware analysis, threat intelligence and OSINT. There are a lot of automated solutions such as anti-virus 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, that's the reason 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 sophisticated malware samples they can stay undetected by many of anti-virus scanners and sandboxes. On the other hand, malware analyst can perform brief analysis of those samples and moreover, if they enrich the gathered 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 anti-squared steps of attacker as well as it can recover yet missing pieces of malware puzzle used by attacker. And last but not least, these brief analysis with intelligence data can collect more indicator of compromise really relevant for threat intelligence, for threat hunting and monitoring team. And when we are talking about using threat intelligences 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 we have 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 for that. 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 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 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 couple of malicious files. For example, this unknown file where CPL support E DLL which tried to mimics the legitimate one file name without E suffix. On the infected systems, there were couple of DLLs masked 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 eximeric substrings so we had to deal with infection of eximeric-based coin miner. And there is another thing common for all of these eximeric-based coin miner DLLs. They created a new text called sampleXN07 and this new text ensures that only one instance of coin miner is running on each infected device. I need to add that this modeXN 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. Two, it was responsible for one part of the persistence mechanism we already found. But the question is, what else attack had 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 screech temp. In our case, it contains a backdoor, a netcat backdoor. And what about its origin? The threat intelligence search based on filenames and strings led us to the four years old scheduled task backdoor given repository with Chinese commands in readme file. Forensic analysis also revealed DLLs files dropped by EIS worker process. The DLLs files were mixed-mod assembly so they contained both the managed and unmanaged code. The dotnet part of DLL contains only the empty class. Yes, it was really empty. On the other hand, in the native code, this DLL made dispatcher spend a reverse shell connected to the attacker. And as I mentioned, there were more similar DLL files. However, these files differ only in two strings which contained the original filename of DLL. So 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 the original DLL names, it was easy to leverage the thread intelligence and found the particular vulnerability and the tool which produced the same DLLs. It turns out that these files had been part of a remote code execution exploit for vulnerability in DLL user interface for ASP.net. This exploit can be found on GitHub again. And after a 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 persistent methods revealed the WMI event subscriptions. DataCares registered the event filter 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 custom PowerShell script for detection of all malicious stuff we were ever including the malicious files and also the persistent artifacts. Then we deployed our script 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 know. 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 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-enabled 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, schedule tasks backdoors and reverse shells delivered after the exploitation. Regarding peristals, we already discovered malicious services and scheduled tasks, and later we discovered and analyzed WMI event subscription and core-profiler peristals. At this point, we had a lot of samples and peristals, but we were faced with questions how the attacker installed all of these peristals 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 OSNT. We used a clever tool called Muinine by Florian Anod. All we needed to do was to create one file with hashes of malware samples and let Muinine to edit 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 zip camera 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 even 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 strong assumption that they were also related to the same ethics. When we examined the RNBAT file, it could say, Heureka! 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 Unpecker. It also seemed that the coin miner's malicious stuff originally came as package called set.zip. We also saw the installation batch script that this installation batch script was executed via program called let.exe. But what was the let.exe and what files did the set.zip contain? We didn't find it 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 calls available on GitHub. Again, again on GitHub. Then left only last sample. We don't analyze until now. The NW got DLL from previews zip archive from NIRAN. It was mixed-mode DLL file. Its name was composed from noun, timestamp and architecture. And the manage code contains only empty.net class, while the native code contains dropper of unpacker batch file we saw before. But wait, doesn't look this NW got DLL file familiar? Of course. We already saw the mixed-mode DLL with empty C sharp class. It was reverse shell payload delivered by the Telerik WI 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 WI exploit, but now it was developed by Reductor. We found all missing pieces of puzzle. We collected all samples needed for attack reconstruction or simulation. And in that moment, we also collected the whole set of needed samples from public sources. Therefore, we could demonstrate this attack using public sources in public sandboxes without revealing any sensitive info from the private samples shared by our client. Follow me to play a short video demonstration. Thank you for watching the video and now, before we summarize our findings, let's proceed with the last part of this talk. The attackers profit. We extracted crypto mining pools 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' but only two account IDs. These account IDs were already used in several cases. In the table, there are amounts of mineral coins mined by attackers on various pools. As a food note, some workers were still active last week. But back to the case, in the cases we discovered, attackers have mined approximately 150 mineral coins in total, which is now approximately $13,000. 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, was it what 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 Blue Mockingbird company. We observed that they were capable to adapt and customize various tools from GitHub and put all them together in their unpacker and installation scripts. It is unusual to see so many persistence methods used in one attacks. This probably required research performed by Blue Mockingbirds. After that, they were able to earn thousands of dollars, and the team damages are much greater than the attackers of it. So, that's all from my side. Here I have 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,