WEBVTT 00:01.210 --> 00:06.710 Hello and welcome to my presentation with the title Hunting for Blue Mockingbird Coin Miners. 00:06.710 --> 00:19.250 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. 00:20.030 --> 00:26.390 But because we are in a recon village, this talk will not be about incident response only. 00:26.390 --> 00:37.570 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. 00:37.590 --> 00:43.670 As often happens, the attackers have deleted some of their tools after they used them. 00:43.670 --> 00:51.670 However, with our recon and OSing approach, we were able to find them and reconstruct the original attack performed by the attackers. 00:51.850 --> 00:59.690 Moreover, we were able to track origin of the malware and we got insight into the technical capabilities of the Blue Mockingbird trade actor. 00:59.830 --> 01:13.590 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. 01:14.810 --> 01:16.770 So, this is our agenda. 01:16.770 --> 01:18.930 And now, let me allow to introduce myself. 01:18.930 --> 01:19.970 Who am I? 01:20.150 --> 01:30.570 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. 01:30.570 --> 01:38.410 In the past, I also worked for the government of one European country as an analyst in CSIRT, Computer Security Incident Response Team Slovakia. 01:39.670 --> 01:40.630 But now... 01:41.890 --> 01:42.230 Okay... 01:42.570 --> 01:45.170 We can ask one obvious question. 01:45.610 --> 01:50.130 Why a presentation about malware analysis, threat intelligence and OSing? 01:50.730 --> 01:56.590 There are a lot of automated solutions, such as antivirus scanners and sandboxes. 01:56.590 --> 02:08.370 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? 02:08.370 --> 02:12.090 Well, the answer is hidden in the previous sentence. 02:12.570 --> 02:16.170 They can identify the most of the common threats. 02:16.170 --> 02:19.090 And I would like to emphasize the word common. 02:19.690 --> 02:33.530 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. 02:33.530 --> 02:38.330 On the other hand, malware analysts can perform a brief analysis of those samples. 02:38.330 --> 02:49.250 And moreover, if they enrich the better results with intelligence info, they can quickly provide the rest of the team with accurate report. 02:49.250 --> 02:58.540 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. 02:59.190 --> 03:08.480 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. 03:08.850 --> 03:22.170 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. 03:24.290 --> 03:32.310 And when we are talking about using threat intelligence fees and other data sources, we can search for many attributes. 03:32.950 --> 03:38.510 There are obvious ones like URLs, hashes, and so on. 03:38.510 --> 03:47.550 But in addition, very helpful can be searched by file name, regular expressions, and malware classifications, such as categories and tags. 03:47.550 --> 03:58.670 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. 03:59.710 --> 04:01.330 And where to search? 04:01.330 --> 04:07.990 Here is a list of couple of examples, which will be covered later during this talk. 04:07.990 --> 04:11.670 And also, some of these tools can be very handy for the analyst. 04:11.670 --> 04:15.310 But these slides will be shared with you, so let's move forward. 04:15.830 --> 04:22.650 And okay, now we are ready to start with advertised incident response and infection with coin miners. 04:23.990 --> 04:29.390 So, it began with a high load of some computers. 04:29.390 --> 04:34.990 One could say, nothing strange, maybe only updates were being applied. 04:34.990 --> 04:41.350 But when local IT guys verified these machines, they noticed something unusual. 04:41.350 --> 04:45.830 Abnormally high CPU and memory usage by SVC host process. 04:45.830 --> 04:52.910 Moreover, the SVC host process corresponded with the problem reports and solution control panel support service. 04:53.110 --> 04:57.190 This could be a more serious problem, indeed. 04:57.950 --> 05:01.710 Antivirus did not find anything. 05:01.710 --> 05:10.170 But after manual submission of DLLs, the antivirus company identified them as coin miner or crypto mining variant. 05:10.170 --> 05:13.630 So, that's how the incident response began. 05:14.730 --> 05:21.010 We verified the findings of our client and we started analyzing machine with the coin miner. 05:21.350 --> 05:26.410 We followed the usual procedures and examined the provided evidence. 05:26.410 --> 05:36.850 We also verified signatures of DLLs in Windows System 32 directory and we checked those files against the National Software Reference Library database. 05:36.850 --> 05:40.790 As a result, we found a couple of malicious files. 05:40.790 --> 05:53.290 For example, this unknown file where CPL support E-DLL, which tries to mimics the legitimate one file name without E suffix. 05:55.210 --> 06:02.510 On the infected systems, there were a couple of DLLs marked as wannabe Windows System DLL files. 06:02.510 --> 06:13.890 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. 06:13.890 --> 06:26.870 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. 06:27.970 --> 06:34.270 And there is another thing common for all of these xamarin-based coin miner DLLs. 06:34.270 --> 06:45.630 They created a mutex called samplexn07 and this mutex ensures that only one instance of coin miner is running on each infected device. 06:45.770 --> 06:58.150 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. 07:00.480 --> 07:06.740 While the most detected fake DLLs had the same hash, there was only one with different hash. 07:06.880 --> 07:19.810 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. 07:20.280 --> 07:26.020 Thus, it was responsible for one part of persistent mechanism we already found. 07:26.020 --> 07:32.980 But the question is, what else attacker deployed in the client network and how they got access to the network? 07:34.160 --> 07:42.780 First steps of forensic analysis revealed the one batch file called x.bat and couple of suspicious tasks. 07:43.400 --> 07:51.320 The batch file contained the PowerShell downloader, which downloads additional content from JavaScript resource on the local web server. 07:51.320 --> 07:57.580 However, it was not JavaScript, but PowerShell, which created the scheduled task. 07:57.920 --> 08:02.320 And these scheduled tasks used the file called scriptstamp. 08:02.320 --> 08:07.780 In our case, it contains a backdoor, a Netcat backdoor. 08:08.140 --> 08:10.740 And what about its origin? 08:10.740 --> 08:23.560 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. 08:26.540 --> 08:34.940 Forensic analysis also revealed DLLs files dropped by IIS worker process. 08:34.940 --> 08:42.020 The DLLs files were mixed mode assembly, so they contained both the managed and unmanaged code. 08:42.020 --> 08:46.860 The .NET part of DLL contains only the empty class. 08:46.860 --> 08:48.240 Yes, it was really empty. 08:48.240 --> 08:56.260 On the other hand, in the native code, this DLL main dispatcher spent a reverse shell connected to the attacker. 08:56.260 --> 09:00.640 And as I mentioned, there were more similar DLL files. 09:00.640 --> 09:08.980 However, these files differs only in two strings, which contained the original file name of DLL. 09:08.980 --> 09:15.980 So nothing, no significant differences in the functionality of these files. 09:16.360 --> 09:36.340 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. 09:37.260 --> 09:49.540 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. 09:50.200 --> 10:00.640 It turns out that these files had been part of remote code execution exploit for vulnerability in Telerik web user interface for ASP.NET. 10:00.940 --> 10:04.480 This exploit can be found on GitHub, again. 10:04.480 --> 10:16.760 And after review, it was clear that this tool was used for building the DLLs with the reverse shell we just discovered. 10:17.000 --> 10:24.020 So we find the origin of this tool and also the initial letter of compromise. 10:25.580 --> 10:32.660 Further investigation and hunting for other persistence methods revealed the WMI event subscriptions. 10:32.660 --> 10:39.660 The attackers registered the event filter and consumer and also the filter to consumer binding. 10:40.080 --> 10:46.400 And as a result, it executed the same command as we already saw in the DLL files. 10:46.700 --> 10:53.720 Now, we thought that we were ready to start with remediation and removal the malicious artifacts from the network. 10:53.720 --> 11:07.160 We developed a custom PowerShell script for detection of all malicious stuff we were aware, including the malicious files and also the persistent artifacts. 11:07.340 --> 11:14.200 Then we deployed our scripts throughout EDR solution and there was a big surprise. 11:14.200 --> 11:22.580 EDR fired alert that there were detected attempts to install persistence for malicious DLLs we already known. 11:22.580 --> 11:31.640 So, we investigated those alerts and we found that those commands had been spawned by PowerShell process. 11:32.180 --> 11:37.960 Actually, the PowerShell process associated with our removal script. 11:38.220 --> 11:39.120 What? 11:39.120 --> 11:41.180 What the hell is this? 11:41.180 --> 11:47.540 We were absolutely sure that our PowerShell script didn't do anything like this. 11:47.540 --> 11:51.900 Its purpose was to remove malicious persistence, not to create new one. 11:51.900 --> 12:01.560 Yet we tested our script in our lab and also our client tested the script in their environment and nothing similar was observed. 12:01.880 --> 12:05.210 Hence, there was only one possible explanation of this. 12:06.100 --> 12:10.700 The attacker established another persistence method we did not find yet. 12:10.700 --> 12:13.660 Therefore, another investigation was needed. 12:13.660 --> 12:23.660 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. 12:23.740 --> 12:27.740 And this class ID pointed to one of the malicious DLL files. 12:28.060 --> 12:30.980 Okay, but now there is another question. 12:30.980 --> 12:35.020 Why PowerShell was interested in this malicious class ID? 12:35.100 --> 12:37.880 The answer was hidden in the environment variables. 12:37.880 --> 12:44.940 Especially, there were two environment variables called core enable profiling and core profiler. 12:44.940 --> 12:52.340 They caused that every managed process was connected to the profiler specified by given class ID. 12:52.500 --> 12:56.180 So, the attacker misused the profiling of .NET applications. 12:56.820 --> 12:57.860 Great. 12:57.860 --> 12:59.840 Another small victory for defenders. 12:59.840 --> 13:00.720 Yeah. 13:01.180 --> 13:07.180 Now, before we continue, let's quickly summarize what we discovered until now. 13:07.180 --> 13:12.200 We already saw thousands of malware samples from four families. 13:12.240 --> 13:21.180 Coin miners, DLL installers for those coin miners, scheduled task backdoors, and reverse shells delivered after the exploitation. 13:21.360 --> 13:26.560 Regarding persistence, we already discovered malicious services and scheduled tasks. 13:26.700 --> 13:33.280 And later, we discovered and analyzed WMI event subscription and core profiler persistence. 13:34.100 --> 13:37.260 At this point, we had a lot of samples and persistence. 13:37.260 --> 13:51.100 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. 13:51.440 --> 13:59.120 Now, we really needed to enrich our results with external data from Threat Intelligence and OSINT. 13:59.120 --> 14:03.420 We used a clever tool called Munin by Florian Erot. 14:03.420 --> 14:12.760 All we needed to do was to create one file with hashes of malware samples and let Munin do its work. 14:13.040 --> 14:22.880 We found several hashes in public repositories, but there were only one public submission of the DLL installer, without any trace detected. 14:22.880 --> 14:31.220 When we did a context search instead of object search, we get another submission, as we can see in the picture. 14:31.440 --> 14:34.680 The zip archive with potentially malicious files. 14:36.900 --> 14:40.140 Now, let's look on the zipkernel file. 14:40.280 --> 14:47.700 It contains several DLLs, batch files, and one MOF file, which stands for Managed Object Format. 14:47.980 --> 14:50.620 We were familiar with some of them. 14:51.780 --> 14:56.880 One DLL was coin miner and the second was installer we already analyzed. 14:57.360 --> 14:59.860 The MOF file was interesting. 14:59.860 --> 15:02.980 Now, you can see its content on the right. 15:03.420 --> 15:10.820 It contained definitions of WMI event subscriptions used for persistence we found earlier. 15:10.820 --> 15:12.720 So, we got it. 15:12.720 --> 15:15.680 We found the WMI persistence. 15:15.680 --> 15:20.700 Now, we are aware how it was created. 15:22.060 --> 15:24.420 But what about the batch files? 15:24.420 --> 15:31.420 They were new for us, but there was a strong assumption that they were also related to the same ethics. 15:31.480 --> 15:36.900 When we examined the RNBAT file, we could say, Eureka! 15:36.900 --> 15:44.160 This batch file was an installation script for all stuff related to coin miners and persistence we already discovered. 15:44.160 --> 15:49.080 Thus, this is another piece of puzzle we missed until now. 15:49.520 --> 15:55.000 Second batch file, called sn.bat, was unpacker. 15:55.000 --> 16:02.040 It also seemed that the coin miners malicious stuff originally came as a package called set.zip. 16:02.320 --> 16:13.060 We also saw that this installation batch script was executed via a program called let.exe. 16:13.060 --> 16:20.040 But what was the let.exe and what files did the set.zip contain? 16:20.040 --> 16:22.040 We didn't find them yet. 16:22.040 --> 16:23.620 So, let's continue. 16:24.520 --> 16:32.400 We applied the same approach again and we tried to do a reconnaissance about let.exe and installation package. 16:32.400 --> 16:39.400 In some cases, we were able to follow tracks of the let.exe execution in public sources. 16:39.400 --> 16:42.460 It seemed that it was a kind of local privilege exploit. 16:42.460 --> 16:49.560 Then, suddenly, we found the one submission of set.zip on hybrid analysis. 16:49.720 --> 16:54.340 And this submission could be related to our investigation. 16:54.360 --> 17:00.620 And yes, this file was exactly the one we were hunting for, the installation package. 17:00.880 --> 17:04.040 And the program let.exe was included. 17:04.180 --> 17:09.140 As it turned out that our hypothesis was correct. 17:09.140 --> 17:18.100 The program let.exe was the juicy potato local privilege exploit with source codes available on GitHub. 17:18.100 --> 17:19.000 Again. 17:19.000 --> 17:20.600 Again on GitHub. 17:23.890 --> 17:27.370 There left only last sample. 17:27.890 --> 17:30.430 We don't analyze it until now. 17:30.430 --> 17:35.310 The nw.gold.dll from previous zip archive from any run. 17:35.690 --> 17:38.030 It was mixed-mod.dll file. 17:38.030 --> 17:42.130 Its name was composed from noun, timestamp, and architecture. 17:42.450 --> 17:51.670 And the managed code contains only empty .NET class, while the native code contains a dropper of unpacker batch file we saw before. 17:51.670 --> 17:52.930 But wait. 17:53.010 --> 17:57.470 Doesn't this nw.gold.dll file look familiar? 17:57.790 --> 17:59.210 Of course. 17:59.210 --> 18:03.410 We already saw the mixed-mod.dll with empty C-sharp class. 18:03.410 --> 18:09.970 It was reverse shell payload delivered by the Telerik WebUI exploitation. 18:10.250 --> 18:13.970 So let's compare these two files side by side. 18:15.090 --> 18:19.070 We can see that they contain a lot of similarity stuff. 18:19.070 --> 18:26.970 And we could assume that this dll had been also created with build scripts from Telerik WebUI exploit. 18:26.970 --> 18:30.750 But now, it was developed by TreadActor. 18:33.130 --> 18:34.570 Okay. 18:34.570 --> 18:37.330 We found all missing pieces of puzzle. 18:37.330 --> 18:42.770 We also collected all samples needed for attack reconstruction or simulation. 18:42.770 --> 18:46.250 And in that moment, we went one step further. 18:46.250 --> 18:53.370 We also collected the whole set of needed samples from public sources. 18:53.370 --> 19:04.650 Therefore, we could demonstrate this attack using public sandboxes without revealing any sensitive info from the private samples shared by our client. 19:05.030 --> 19:08.630 So, let's allow me to play a short video demonstration. 21:28.730 --> 21:29.690 Okay. 21:29.690 --> 21:31.290 Thank you for watching the video. 21:31.290 --> 21:36.310 And now, before we summarize our findings, let's proceed with the last part of this talk. 21:36.310 --> 21:37.850 The attacker's profit. 21:37.850 --> 21:46.010 We extracted crypto mining pool's parameters and configuration either from captured pickups or from memory dumps. 21:46.010 --> 21:52.630 Then, we used these parameters for hunting for more and more samples and repeated this process again and again. 21:52.630 --> 21:57.850 Finally, we collected several workers' IDs, but only two account IDs. 21:57.850 --> 22:01.710 These account IDs were reused in several cases. 22:01.710 --> 22:08.930 In the table, there are amounts of monero coin mines mined by attackers on various pools. 22:08.930 --> 22:13.250 As a footnote, some workers were still active last week. 22:13.650 --> 22:15.590 But back to the case. 22:15.850 --> 22:29.190 In the cases we discovered, attackers have mined approximately 150 monero coins in total, which is now approximately 13,000 USD. 22:29.190 --> 22:38.190 For comparison, average damages per day victim varies between $50,000 and $500,000. 22:38.190 --> 22:48.870 And this includes only the direct costs, such as incident response and remediation process, investigation and reinstallation of their systems. 22:48.870 --> 22:57.830 The indirect costs, such as reputation loss and disruption or damages due to downtime, aren't included in this estimation. 22:59.330 --> 23:01.590 And last, but not least. 23:01.590 --> 23:04.590 What do we discovered in our analysis and research? 23:04.590 --> 23:14.130 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. 23:14.310 --> 23:21.310 In the meantime, this red actor got a name, Blue Mockingbird, given by Red Canary Company. 23:21.310 --> 23:32.750 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. 23:32.930 --> 23:39.470 It is unusual to see so many persistence methods used in one attack. 23:39.610 --> 23:43.610 This probably required research performed by Blue Mockingbird. 23:43.610 --> 23:52.830 After that, they were able to earn thousands of dollars, but the victim damages are much greater than the attackers' profit. 23:53.570 --> 23:56.010 So, that's all from my side. 23:56.010 --> 23:59.330 Here are provided some resources related to this talk. 24:00.390 --> 24:07.510 And additionally, you can read something about my work or research on our company website or on my personal blog. 24:07.510 --> 24:10.110 And you can find me also on Twitter. 24:10.110 --> 24:16.030 So, thank you very much for attending this talk, and if you have any questions, please feel free to ask me.