[00:01.210 --> 00:04.050]  Hello and welcome to my presentation with the title
[00:04.050 --> 00:06.710]  Hunting for Blue Mockingbird Coin Miners.
[00:06.710 --> 00:10.230]  I am Vladislav Bačov and I would like to spend the next 20 or 25 minutes
[00:10.230 --> 00:13.090]  with talking about incident response and investigation
[00:13.090 --> 00:17.350]  of the recent incidents attributed to the relatively new trade actor
[00:17.350 --> 00:19.250]  called Blue Mockingbird.
[00:20.030 --> 00:23.070]  But because we are in a recon village,
[00:23.070 --> 00:26.390]  this talk will not be about incident response only.
[00:26.390 --> 00:28.670]  Instead, I would like to share with you
[00:28.670 --> 00:31.310]  how our experiences have used reconnaissance
[00:31.310 --> 00:33.290]  and open source intelligence approaches
[00:33.290 --> 00:37.570]  to enrich our results from standard forensic and malware analysis.
[00:37.590 --> 00:40.830]  As often happens, the attackers have deleted
[00:40.830 --> 00:43.670]  some of their tools after they used them.
[00:43.670 --> 00:47.050]  However, with our recon and OSing approach,
[00:47.050 --> 00:49.990]  we were able to find them and reconstruct the original attack
[00:49.990 --> 00:51.670]  performed by the attackers.
[00:51.850 --> 00:54.610]  Moreover, we were able to track origin of the malware
[00:54.610 --> 00:57.390]  and we got insight into the technical capabilities
[00:57.390 --> 00:59.690]  of the Blue Mockingbird trade actor.
[00:59.830 --> 01:01.770]  And finally, in some cases,
[01:01.770 --> 01:05.970]  we could track the incomings of the cryptocurrency wallets
[01:05.970 --> 01:07.270]  used by Blue Mockingbirds
[01:07.270 --> 01:09.750]  and we can estimate profit of the attackers
[01:09.750 --> 01:13.590]  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:22.350]  I am Vladislav Bačov and I currently work
[01:22.350 --> 01:25.910]  as a security senior consultant and malware analyst for Lifers,
[01:25.990 --> 01:30.570]  a New York City-based incident response and digital forensic company.
[01:30.570 --> 01:33.930]  In the past, I also worked for the government of one European country
[01:33.930 --> 01:38.410]  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:48.210]  Why a presentation about malware analysis,
[01:48.210 --> 01:50.130]  threat intelligence and OSing?
[01:50.730 --> 01:54.010]  There are a lot of automated solutions,
[01:54.010 --> 01:56.590]  such as antivirus scanners and sandboxes.
[01:56.590 --> 01:59.890]  So, why do we need to bother with additional malware analysis
[01:59.890 --> 02:04.090]  and enrichments with info from another public sources,
[02:04.090 --> 02:08.370]  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:21.890]  When you need to deal with advanced threat actors
[02:21.890 --> 02:27.310]  or uncommon threats, such as rare or obfuscated malware samples,
[02:27.310 --> 02:33.530]  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:43.290]  And moreover, if they enrich the better results with intelligence info,
[02:43.290 --> 02:49.250]  they can quickly provide the rest of the team with accurate report.
[02:49.250 --> 02:53.490]  And this report can include not only the purpose and capabilities of the malware,
[02:53.490 --> 02:58.540]  but also origin of the samples or attributions to the threat actors.
[02:59.190 --> 03:03.410]  It can also help to reveal yet undiscovered steps of attacker,
[03:03.410 --> 03:08.480]  as well as it can recover yet missing pieces of malware puzzle used by attacker.
[03:08.850 --> 03:13.030]  And last but not least, this brief analysis with intelligence data
[03:13.030 --> 03:19.370]  can collect more indicator of compromise relevant for threat intelligence,
[03:19.370 --> 03:22.170]  for threat hunting and monitoring team.
[03:24.290 --> 03:29.850]  And when we are talking about using threat intelligence fees and other data sources,
[03:29.850 --> 03:32.310]  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:43.450]  But in addition, very helpful can be searched by file name, regular expressions,
[03:43.450 --> 03:47.550]  and malware classifications, such as categories and tags.
[03:47.550 --> 03:51.730]  Also, search for strings embedded in the malware or search by import hashes
[03:51.730 --> 03:58.670]  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:48.240]  The .NET part of DLL contains only the empty class. 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:30.680]  With the suspicion that this could be payload delivered after the exploitation of ASP.NET vulnerability because of IIS worker process,
[09:30.680 --> 09:36.340]  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:41.180]  What? 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 --> 13:00.720]  Great. Another small victory for defenders. 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:43.220]  But we were faced with the questions how the attacker installed all of these persistence artifacts,
[13:43.220 --> 13:51.100]  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:35.700]  When we examined the RNBAT file, we could say,
[15:35.700 --> 15:36.900]  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:20.600]  Again. 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:57.470]  But wait. Doesn't this nw.gold.dll file look familiar?
[17:57.790 --> 18:03.410]  Of course. 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:37.330]  Okay. 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:31.290]  Okay. 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:59.330]  So, that's all from my side. 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.