1
00:00:01,210 --> 00:00:06,710
Hello and welcome to my presentation with the title Hunting for Blue Mockingbird Coin Miners.

2
00:00:06,710 --> 00: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.

3
00:00:20,030 --> 00:00:26,390
But because we are in a recon village, this talk will not be about incident response only.

4
00:00:26,390 --> 00: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.

5
00:00:37,590 --> 00:00:43,670
As often happens, the attackers have deleted some of their tools after they used them.

6
00:00:43,670 --> 00: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.

7
00:00:51,850 --> 00: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.

8
00:00:59,830 --> 00: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.

9
00:01:14,810 --> 00:01:16,770
So, this is our agenda.

10
00:01:16,770 --> 00:01:18,930
And now, let me allow to introduce myself.

11
00:01:18,930 --> 00:01:19,970
Who am I?

12
00:01:20,150 --> 00: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.

13
00:01:30,570 --> 00: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.

14
00:01:39,670 --> 00:01:40,630
But now...

15
00:01:41,890 --> 00:01:42,230
Okay...

16
00:01:42,570 --> 00:01:45,170
We can ask one obvious question.

17
00:01:45,610 --> 00:01:50,130
Why a presentation about malware analysis, threat intelligence and OSing?

18
00:01:50,730 --> 00:01:56,590
There are a lot of automated solutions, such as antivirus scanners and sandboxes.

19
00:01:56,590 --> 00: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?

20
00:02:08,370 --> 00:02:12,090
Well, the answer is hidden in the previous sentence.

21
00:02:12,570 --> 00:02:16,170
They can identify the most of the common threats.

22
00:02:16,170 --> 00:02:19,090
And I would like to emphasize the word common.

23
00:02:19,690 --> 00: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.

24
00:02:33,530 --> 00:02:38,330
On the other hand, malware analysts can perform a brief analysis of those samples.

25
00:02:38,330 --> 00: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.

26
00:02:49,250 --> 00: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.

27
00:02:59,190 --> 00: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.

28
00:03:08,850 --> 00: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.

29
00:03:24,290 --> 00:03:32,310
And when we are talking about using threat intelligence fees and other data sources, we can search for many attributes.

30
00:03:32,950 --> 00:03:38,510
There are obvious ones like URLs, hashes, and so on.

31
00:03:38,510 --> 00:03:47,550
But in addition, very helpful can be searched by file name, regular expressions, and malware classifications, such as categories and tags.

32
00:03:47,550 --> 00: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.

33
00:03:59,710 --> 00:04:01,330
And where to search?

34
00:04:01,330 --> 00:04:07,990
Here is a list of couple of examples, which will be covered later during this talk.

35
00:04:07,990 --> 00:04:11,670
And also, some of these tools can be very handy for the analyst.

36
00:04:11,670 --> 00:04:15,310
But these slides will be shared with you, so let's move forward.

37
00:04:15,830 --> 00:04:22,650
And okay, now we are ready to start with advertised incident response and infection with coin miners.

38
00:04:23,990 --> 00:04:29,390
So, it began with a high load of some computers.

39
00:04:29,390 --> 00:04:34,990
One could say, nothing strange, maybe only updates were being applied.

40
00:04:34,990 --> 00:04:41,350
But when local IT guys verified these machines, they noticed something unusual.

41
00:04:41,350 --> 00:04:45,830
Abnormally high CPU and memory usage by SVC host process.

42
00:04:45,830 --> 00:04:52,910
Moreover, the SVC host process corresponded with the problem reports and solution control panel support service.

43
00:04:53,110 --> 00:04:57,190
This could be a more serious problem, indeed.

44
00:04:57,950 --> 00:05:01,710
Antivirus did not find anything.

45
00:05:01,710 --> 00:05:10,170
But after manual submission of DLLs, the antivirus company identified them as coin miner or crypto mining variant.

46
00:05:10,170 --> 00:05:13,630
So, that's how the incident response began.

47
00:05:14,730 --> 00:05:21,010
We verified the findings of our client and we started analyzing machine with the coin miner.

48
00:05:21,350 --> 00:05:26,410
We followed the usual procedures and examined the provided evidence.

49
00:05:26,410 --> 00: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.

50
00:05:36,850 --> 00:05:40,790
As a result, we found a couple of malicious files.

51
00:05:40,790 --> 00: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.

52
00:05:55,210 --> 00:06:02,510
On the infected systems, there were a couple of DLLs marked as wannabe Windows System DLL files.

53
00:06:02,510 --> 00: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.

54
00:06:13,890 --> 00: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.

55
00:06:27,970 --> 00:06:34,270
And there is another thing common for all of these xamarin-based coin miner DLLs.

56
00:06:34,270 --> 00: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.

57
00:06:45,770 --> 00: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.

58
00:07:00,480 --> 00:07:06,740
While the most detected fake DLLs had the same hash, there was only one with different hash.

59
00:07:06,880 --> 00: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.

60
00:07:20,280 --> 00:07:26,020
Thus, it was responsible for one part of persistent mechanism we already found.

61
00:07:26,020 --> 00:07:32,980
But the question is, what else attacker deployed in the client network and how they got access to the network?

62
00:07:34,160 --> 00:07:42,780
First steps of forensic analysis revealed the one batch file called x.bat and couple of suspicious tasks.

63
00:07:43,400 --> 00:07:51,320
The batch file contained the PowerShell downloader, which downloads additional content from JavaScript resource on the local web server.

64
00:07:51,320 --> 00:07:57,580
However, it was not JavaScript, but PowerShell, which created the scheduled task.

65
00:07:57,920 --> 00:08:02,320
And these scheduled tasks used the file called scriptstamp.

66
00:08:02,320 --> 00:08:07,780
In our case, it contains a backdoor, a Netcat backdoor.

67
00:08:08,140 --> 00:08:10,740
And what about its origin?

68
00:08:10,740 --> 00: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.

69
00:08:26,540 --> 00:08:34,940
Forensic analysis also revealed DLLs files dropped by IIS worker process.

70
00:08:34,940 --> 00:08:42,020
The DLLs files were mixed mode assembly, so they contained both the managed and unmanaged code.

71
00:08:42,020 --> 00:08:46,860
The .NET part of DLL contains only the empty class.

72
00:08:46,860 --> 00:08:48,240
Yes, it was really empty.

73
00:08:48,240 --> 00:08:56,260
On the other hand, in the native code, this DLL main dispatcher spent a reverse shell connected to the attacker.

74
00:08:56,260 --> 00:09:00,640
And as I mentioned, there were more similar DLL files.

75
00:09:00,640 --> 00:09:08,980
However, these files differs only in two strings, which contained the original file name of DLL.

76
00:09:08,980 --> 00:09:15,980
So nothing, no significant differences in the functionality of these files.

77
00:09:16,360 --> 00: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.

78
00:09:37,260 --> 00: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.

79
00:09:50,200 --> 00: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.

80
00:10:00,940 --> 00:10:04,480
This exploit can be found on GitHub, again.

81
00:10:04,480 --> 00: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.

82
00:10:17,000 --> 00:10:24,020
So we find the origin of this tool and also the initial letter of compromise.

83
00:10:25,580 --> 00:10:32,660
Further investigation and hunting for other persistence methods revealed the WMI event subscriptions.

84
00:10:32,660 --> 00:10:39,660
The attackers registered the event filter and consumer and also the filter to consumer binding.

85
00:10:40,080 --> 00:10:46,400
And as a result, it executed the same command as we already saw in the DLL files.

86
00:10:46,700 --> 00:10:53,720
Now, we thought that we were ready to start with remediation and removal the malicious artifacts from the network.

87
00:10:53,720 --> 00: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.

88
00:11:07,340 --> 00:11:14,200
Then we deployed our scripts throughout EDR solution and there was a big surprise.

89
00:11:14,200 --> 00:11:22,580
EDR fired alert that there were detected attempts to install persistence for malicious DLLs we already known.

90
00:11:22,580 --> 00:11:31,640
So, we investigated those alerts and we found that those commands had been spawned by PowerShell process.

91
00:11:32,180 --> 00:11:37,960
Actually, the PowerShell process associated with our removal script.

92
00:11:38,220 --> 00:11:39,120
What?

93
00:11:39,120 --> 00:11:41,180
What the hell is this?

94
00:11:41,180 --> 00:11:47,540
We were absolutely sure that our PowerShell script didn't do anything like this.

95
00:11:47,540 --> 00:11:51,900
Its purpose was to remove malicious persistence, not to create new one.

96
00:11:51,900 --> 00: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.

97
00:12:01,880 --> 00:12:05,210
Hence, there was only one possible explanation of this.

98
00:12:06,100 --> 00:12:10,700
The attacker established another persistence method we did not find yet.

99
00:12:10,700 --> 00:12:13,660
Therefore, another investigation was needed.

100
00:12:13,660 --> 00: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.

101
00:12:23,740 --> 00:12:27,740
And this class ID pointed to one of the malicious DLL files.

102
00:12:28,060 --> 00:12:30,980
Okay, but now there is another question.

103
00:12:30,980 --> 00:12:35,020
Why PowerShell was interested in this malicious class ID?

104
00:12:35,100 --> 00:12:37,880
The answer was hidden in the environment variables.

105
00:12:37,880 --> 00:12:44,940
Especially, there were two environment variables called core enable profiling and core profiler.

106
00:12:44,940 --> 00:12:52,340
They caused that every managed process was connected to the profiler specified by given class ID.

107
00:12:52,500 --> 00:12:56,180
So, the attacker misused the profiling of .NET applications.

108
00:12:56,820 --> 00:12:57,860
Great.

109
00:12:57,860 --> 00:12:59,840
Another small victory for defenders.

110
00:12:59,840 --> 00:13:00,720
Yeah.

111
00:13:01,180 --> 00:13:07,180
Now, before we continue, let's quickly summarize what we discovered until now.

112
00:13:07,180 --> 00:13:12,200
We already saw thousands of malware samples from four families.

113
00:13:12,240 --> 00:13:21,180
Coin miners, DLL installers for those coin miners, scheduled task backdoors, and reverse shells delivered after the exploitation.

114
00:13:21,360 --> 00:13:26,560
Regarding persistence, we already discovered malicious services and scheduled tasks.

115
00:13:26,700 --> 00:13:33,280
And later, we discovered and analyzed WMI event subscription and core profiler persistence.

116
00:13:34,100 --> 00:13:37,260
At this point, we had a lot of samples and persistence.

117
00:13:37,260 --> 00: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.

118
00:13:51,440 --> 00:13:59,120
Now, we really needed to enrich our results with external data from Threat Intelligence and OSINT.

119
00:13:59,120 --> 00:14:03,420
We used a clever tool called Munin by Florian Erot.

120
00:14:03,420 --> 00:14:12,760
All we needed to do was to create one file with hashes of malware samples and let Munin do its work.

121
00:14:13,040 --> 00: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.

122
00:14:22,880 --> 00:14:31,220
When we did a context search instead of object search, we get another submission, as we can see in the picture.

123
00:14:31,440 --> 00:14:34,680
The zip archive with potentially malicious files.

124
00:14:36,900 --> 00:14:40,140
Now, let's look on the zipkernel file.

125
00:14:40,280 --> 00:14:47,700
It contains several DLLs, batch files, and one MOF file, which stands for Managed Object Format.

126
00:14:47,980 --> 00:14:50,620
We were familiar with some of them.

127
00:14:51,780 --> 00:14:56,880
One DLL was coin miner and the second was installer we already analyzed.

128
00:14:57,360 --> 00:14:59,860
The MOF file was interesting.

129
00:14:59,860 --> 00:15:02,980
Now, you can see its content on the right.

130
00:15:03,420 --> 00:15:10,820
It contained definitions of WMI event subscriptions used for persistence we found earlier.

131
00:15:10,820 --> 00:15:12,720
So, we got it.

132
00:15:12,720 --> 00:15:15,680
We found the WMI persistence.

133
00:15:15,680 --> 00:15:20,700
Now, we are aware how it was created.

134
00:15:22,060 --> 00:15:24,420
But what about the batch files?

135
00:15:24,420 --> 00:15:31,420
They were new for us, but there was a strong assumption that they were also related to the same ethics.

136
00:15:31,480 --> 00:15:36,900
When we examined the RNBAT file, we could say, Eureka!

137
00:15:36,900 --> 00:15:44,160
This batch file was an installation script for all stuff related to coin miners and persistence we already discovered.

138
00:15:44,160 --> 00:15:49,080
Thus, this is another piece of puzzle we missed until now.

139
00:15:49,520 --> 00:15:55,000
Second batch file, called sn.bat, was unpacker.

140
00:15:55,000 --> 00:16:02,040
It also seemed that the coin miners malicious stuff originally came as a package called set.zip.

141
00:16:02,320 --> 00:16:13,060
We also saw that this installation batch script was executed via a program called let.exe.

142
00:16:13,060 --> 00:16:20,040
But what was the let.exe and what files did the set.zip contain?

143
00:16:20,040 --> 00:16:22,040
We didn't find them yet.

144
00:16:22,040 --> 00:16:23,620
So, let's continue.

145
00:16:24,520 --> 00:16:32,400
We applied the same approach again and we tried to do a reconnaissance about let.exe and installation package.

146
00:16:32,400 --> 00:16:39,400
In some cases, we were able to follow tracks of the let.exe execution in public sources.

147
00:16:39,400 --> 00:16:42,460
It seemed that it was a kind of local privilege exploit.

148
00:16:42,460 --> 00:16:49,560
Then, suddenly, we found the one submission of set.zip on hybrid analysis.

149
00:16:49,720 --> 00:16:54,340
And this submission could be related to our investigation.

150
00:16:54,360 --> 00:17:00,620
And yes, this file was exactly the one we were hunting for, the installation package.

151
00:17:00,880 --> 00:17:04,040
And the program let.exe was included.

152
00:17:04,180 --> 00:17:09,140
As it turned out that our hypothesis was correct.

153
00:17:09,140 --> 00:17:18,100
The program let.exe was the juicy potato local privilege exploit with source codes available on GitHub.

154
00:17:18,100 --> 00:17:19,000
Again.

155
00:17:19,000 --> 00:17:20,600
Again on GitHub.

156
00:17:23,890 --> 00:17:27,370
There left only last sample.

157
00:17:27,890 --> 00:17:30,430
We don't analyze it until now.

158
00:17:30,430 --> 00:17:35,310
The nw.gold.dll from previous zip archive from any run.

159
00:17:35,690 --> 00:17:38,030
It was mixed-mod.dll file.

160
00:17:38,030 --> 00:17:42,130
Its name was composed from noun, timestamp, and architecture.

161
00:17:42,450 --> 00: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.

162
00:17:51,670 --> 00:17:52,930
But wait.

163
00:17:53,010 --> 00:17:57,470
Doesn't this nw.gold.dll file look familiar?

164
00:17:57,790 --> 00:17:59,210
Of course.

165
00:17:59,210 --> 00:18:03,410
We already saw the mixed-mod.dll with empty C-sharp class.

166
00:18:03,410 --> 00:18:09,970
It was reverse shell payload delivered by the Telerik WebUI exploitation.

167
00:18:10,250 --> 00:18:13,970
So let's compare these two files side by side.

168
00:18:15,090 --> 00:18:19,070
We can see that they contain a lot of similarity stuff.

169
00:18:19,070 --> 00:18:26,970
And we could assume that this dll had been also created with build scripts from Telerik WebUI exploit.

170
00:18:26,970 --> 00:18:30,750
But now, it was developed by TreadActor.

171
00:18:33,130 --> 00:18:34,570
Okay.

172
00:18:34,570 --> 00:18:37,330
We found all missing pieces of puzzle.

173
00:18:37,330 --> 00:18:42,770
We also collected all samples needed for attack reconstruction or simulation.

174
00:18:42,770 --> 00:18:46,250
And in that moment, we went one step further.

175
00:18:46,250 --> 00:18:53,370
We also collected the whole set of needed samples from public sources.

176
00:18:53,370 --> 00: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.

177
00:19:05,030 --> 00:19:08,630
So, let's allow me to play a short video demonstration.

178
00:21:28,730 --> 00:21:29,690
Okay.

179
00:21:29,690 --> 00:21:31,290
Thank you for watching the video.

180
00:21:31,290 --> 00:21:36,310
And now, before we summarize our findings, let's proceed with the last part of this talk.

181
00:21:36,310 --> 00:21:37,850
The attacker's profit.

182
00:21:37,850 --> 00:21:46,010
We extracted crypto mining pool's parameters and configuration either from captured pickups or from memory dumps.

183
00:21:46,010 --> 00:21:52,630
Then, we used these parameters for hunting for more and more samples and repeated this process again and again.

184
00:21:52,630 --> 00:21:57,850
Finally, we collected several workers' IDs, but only two account IDs.

185
00:21:57,850 --> 00:22:01,710
These account IDs were reused in several cases.

186
00:22:01,710 --> 00:22:08,930
In the table, there are amounts of monero coin mines mined by attackers on various pools.

187
00:22:08,930 --> 00:22:13,250
As a footnote, some workers were still active last week.

188
00:22:13,650 --> 00:22:15,590
But back to the case.

189
00:22:15,850 --> 00:22:29,190
In the cases we discovered, attackers have mined approximately 150 monero coins in total, which is now approximately 13,000 USD.

190
00:22:29,190 --> 00:22:38,190
For comparison, average damages per day victim varies between $50,000 and $500,000.

191
00:22:38,190 --> 00:22:48,870
And this includes only the direct costs, such as incident response and remediation process, investigation and reinstallation of their systems.

192
00:22:48,870 --> 00:22:57,830
The indirect costs, such as reputation loss and disruption or damages due to downtime, aren't included in this estimation.

193
00:22:59,330 --> 00:23:01,590
And last, but not least.

194
00:23:01,590 --> 00:23:04,590
What do we discovered in our analysis and research?

195
00:23:04,590 --> 00: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.

196
00:23:14,310 --> 00:23:21,310
In the meantime, this red actor got a name, Blue Mockingbird, given by Red Canary Company.

197
00:23:21,310 --> 00: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.

198
00:23:32,930 --> 00:23:39,470
It is unusual to see so many persistence methods used in one attack.

199
00:23:39,610 --> 00:23:43,610
This probably required research performed by Blue Mockingbird.

200
00:23:43,610 --> 00:23:52,830
After that, they were able to earn thousands of dollars, but the victim damages are much greater than the attackers' profit.

201
00:23:53,570 --> 00:23:56,010
So, that's all from my side.

202
00:23:56,010 --> 00:23:59,330
Here are provided some resources related to this talk.

203
00:24:00,390 --> 00:24:07,510
And additionally, you can read something about my work or research on our company website or on my personal blog.

204
00:24:07,510 --> 00:24:10,110
And you can find me also on Twitter.

205
00:24:10,110 --> 00:24:16,030
So, thank you very much for attending this talk, and if you have any questions, please feel free to ask me.