There are new articles available, click to refresh the page.
Before yesterdaySentinelLabs

Sanctions Be Damned | From Dridex to Macaw, The Evolution of Evil Corp

23 February 2022 at 17:46

By Antonio Pirozzi, Antonis Terefos and Idan Weizman

Executive Summary

  • Since OFAC sanctions in 2020, the global intelligence community has been split into different camps as to how Evil Corp is operating.
  • SentinelLabs assesses with high confidence that WastedLocker, Hades, Phoenix Locker, PayloadBIN belong to the same cluster. There are strong overlaps in terms of code similarities, packers, TTPs and configurations.
  • SentinelLabs assesses with high confidence that the Macaw ransomware variant is derived from the same codebase as Hades.
  • Our analysis indicates that Evil Corp became a customer of the CryptOne packer-as-a-service from March 2020. We created a static unpacker, de-CryptOne for CryptOne and identified different versions of this cryptor which have never previously been reported.

Read the Full Report


Evil Corp (EC) is an advanced cybercrime operations cluster originating from Russia that has been active since 2007. The UK National Crime Agency called it β€œthe world’s most harmful cyber crime group.” In December 2019, the U.S. Treasury Department’s Office of Foreign Assets Control (OFAC) issued a sanction against 17 individuals and seven entities related to EC cyber operations for causing financial losses of more than 100 million dollars with Dridex.

After the indictments, the global intelligence community was split into different camps as to how Evil Corp was operating. Some assessed that there was a voluntary transition of EC operations to another β€˜trusted’ partner while the core group remained the controller of operations. Some had theories that Evil Corp had stopped operating and that another advanced actor operated Hades, trying to mimic the same modus operandi as Evil Corp to mislead attribution. Others claimed possible attribution to the HAFNIUM activity cluster.

SentinelLabs has conducted an in-depth review and technical analysis of Evil Corp activity, malware and TTPs. Our full report has a number of important findings for the research community. We relied heavily on our analysis of a crypter tool dubbed β€œCryptOne”, which supports our wider clustering of Evil Corp activity. Our research also argues that the original operators continue to be active despite the sanctions, continuously changing their TTPs in order to stay under the radar.

In this post, we summarize some key observations from our technical analysis on the evolution of Evil Corp from Dridex through to Macaw Locker and, for the first time, publicly describe CryptOne and the role it plays in Evil Corp malware development. For the full technical analysis, comprehensive IOCs and YARA hunting rules, please see the full report.

Overview of Recent Evil Corp Activity

After the OFAC indictment, we witnessed a change in Evil Corp TTPs: from 2020, they started to frequently change their payload signatures, using different exploitation tools and methods of initial access. They switched from Dridex to the SocGholish framework to confuse attribution and distance themselves from both Dridex and Bitpaymer, which fell within the scope of the sanctions. During this period, they started relying more heavily on Cobalt Strike to gain an initial foothold and perform lateral movement, rather than PowerShell Empire.

In May 2020, a new ransomware variant appeared in the wild dubbed WastedLocker. WastedLocker (S0612) employed techniques to obfuscate its code and perform tasks similar to those already seen in BitPaymer and Dridex. Those similarities allowed the threat intelligence community to identify the connections between the malware families.

In December 2020, a new ransomware variant named Hades was first seen in the wild and publicly reported. Hades is a 64-bit compiled version of WastedLocker that displays important code and functionality overlaps. A few months later, in March 2021, a new variant Phoenix Locker appeared in the wild. Our analysis suggests this is a rebranded version of Hades with little to no changes. Later, a new variant named PayloadBIN appeared in the wild, a continuation from Phoenix Locker.

A Unique Cluster: BitPaymer, WastedLocker, Hades, Phoenix Locker, PayloadBIN

From our analysis, we discovered evidence of code overlaps, as well as shared configurations, packers and TTPs leading us to assess with high confidence that Bitpaymer, WastedLocker, Hades, PhoenixLocker and PayloadBIN share a common codebase. Our full report goes into the evidence in fine detail. The following section presents a brief summary.

From BitPaymer to WastedLocker

Previous research shows a sort of knowledge reuse between BitPaymer and WastedLocker. SentinelLabs analysis shows that Hades and WastedLocker share the same codebase.

Among other similarities, detailed in the full report, we observe that the RSA functions – responsible for asymmetrically encrypting the keys which were used in the AES phase to encrypt files – are identical in both ransomware variants, hinting that the same utility library was used.

From WastedLocker to Hades

Previous research assessed the main similarities and differences between the two ransomware families. SentinelLabs analysis shows that Hades and WestedLocker share the same codebase.

Again we see the same RSA functions in both families. Both also implement file and directory enumeration logic identically. Comparing the logic and the Control Flow Graph of both routines, we conclude that both ransomware use the same code for file and directory enumeration. We also found similarities between the functions responsible for drive enumeration.

From Hades to Phoenix Locker

In the samples we analyzed, we discovered that Phoenix Locker was a reused and newly-packed Hades payload. Hades and Phoenix samples were compiled at the same time. We confirmed that they reused a β€˜clean’ Hades version each time, statically introducing junk code with the help of a script in order to alter the signature. The compiler and linker versions are also the same. This technique of payload reuse was also seen in BitPaymer in order to make the ransomware polymorphic and more evasive.

From Phoenix Locker to PayloadBIN

We observed that the majority of PayloadBIN functions overlap with PhoenixLocker. File enumerating functions are practically identical.

We conducted further similarity analysis by analyzing the TTPs of the different variants. We did this by extracting the main command lines from all the ransomwares and comparing them. We distinguished two distinct clusters.

From Hades onwards, we found a unique self-delete implementation including the waitfor command.

cmd /c waitfor /t 10 pause /d y & attrib -h "C:\Users\Admin\AppData\Roaming\CenterLibrary\Tip" & del "C:\Users\Admin\AppData\Roaming\CenterLibrary\Tip" & rd "C:\Users\Admin\AppData\Roaming\CenterLibrary\"

This command is not present in WastedLocker, where the choice command is used instead:

cmd /c choice /t 10 /d y & attrib -h "C:\Users\Admin\AppData\Roaming\Wmi" & del "C:\Users\Admin\AppData\Roaming\Wmi"

Whilst syntax difference may seem like a significant difference, these two implementations are very similar: the logic is the same, only the signature changes.

All ransomwares have the same implementation of Shadows copy deletion:

C:\Windows\system32\vssadmin.exe Delete Shadows /All /Quiet

The evidence of this code reuse supports the assessment that it is almost certain these ransomware families are related to the same β€˜factory’.

Analysis of the Cypherpunk Variant

A new, possibly experimental, variant dubbed β€œCypherpunk” – first reported in June 2021- was analyzed and linked to the same lineage.

C:\Users\Lucas\Documents\OneNote Notebooks\Personal\General.one.cypherpunk
C:\Users\Lucas\Documents\OneNote Notebooks\Personal\CONTACT-TO-DECRYPT.txt
C:\Users\Lucas\Desktop\th (2).jpg.cypherpunk

Code similarity analysis shows that the Cypherpunk version (SHA1 e8d485259e64fd375e03844c03775eda40862e1c) is the same as the previous PayloadBIN variant. It was compiled on 2021-04-01 17:15:24, 20 days after the PayLoadBIN sample. It is possible that this is another attempt at rebranding. Although this variant was reported, it was improperly flagged as Hades.

SentinelLabs assesses this new finding is likely an indication that Evil Corp is still working on updating their tradecraft in order to change their signature and stay under the radar.

Evil Corp Pivots to Macaw Locker Ransomware

In October 2021, a new ransomware variant named β€˜Macaw Locker’ appeared in the wild, in an attack that began on October 10th against Olympus. A few days later Sinclair Broadcast Group was also attacked, causing widespread disruption. Some researchers claimed a possible connection with WastedLocker, but to date no further details have emerged.

Macaw ransom note

The ransomware presents anti-analysis features like API hashing and indirect API calls with the intention of evading analysis. One aspect that immediately sets Macaw apart is that it requires a custom token, provided from the command line, which appears to be specific to each victim; without it, the ransomware won’t execute.

macaw_sample.exe -k 

The use of a custom token is also seen in Egregor and BlackCat ransomware families, and is a technique used to aid anti-analysis (T1497.002).

Another new addition to Macaw is a special function that acquires the imports for APIs at runtime, instead of when the executable is started via the PE import section. Below, we can see the function that is used before each API call to get its address prior to the call itself.

Macaw function to dynamically fetch addresses

The function gets a 32-bit value that uniquely represents the required API and searches for it through a data structure created beforehand. The data structure can be described as an array with small binary search trees in each of its entries.

We assessed the similarity of two core functions between Hades and Macaw. In both strains, the implementation is the same. The only minor differences are from the imports fetched at runtime.

CryptOne: One Packer To Rule Them All

CryptOne (also known as HellowinPacker) was a special packer used by Evil Corp up until mid-2021.

CryptOne appears to have first been noticed in 2015. Early versions were used by an assortment of different malware families such as NetWalker, Gozi, Dridex, Hancitor and Zloader. In 2019, Bromium analyzed and reported it as in use by Emotet. In June 2020, NCC Group reported that CryptOne was used to pack WastedLocker. In 2021, researchers observed CryptOne being advertised as a Packer-as-a-Service on various crime-oriented forums.

CryptOne has the following characteristics and features:

  • Sandbox evasion with getInputState() or GetKeyState() API;
  • Anti-emulation with UCOMIEnumConnections and the IActiveScriptParseProcedure32 interface;
  • Code-flow obfuscation;

We created a static unpacker, de-CryptOne, which unpacks both x86 and x64 samples. It outputs two files:

  1. the shellcode responsible for unpacking
  2. the unpacked sample.

We collected CryptOne packed samples, and with the use of the above tool, unpacked and categorized them at scale.

Unpacking CryptOne

CryptOne unpacking method consists of two stages:

  1. Decrypts and executes embedded shellcode.
  2. Shellcode decrypts and executes embedded executables.

CryptOne gets chunks of the encrypted data, which are separated by junk.

CryptOne junk data

Example Memory Dump:

  • 0x5EE00, Encrypted size
  • 0x4011CA, Address of encrypted data
  • 0x4D/”M”, Junk data
  • 0x14, Junk size
  • 0x7A, Chunk Size

After removal of the junk data, the decryption starts with a simple XOR-Key which increases by 0x4 in each round. The initial XOR-Key is 0xA113.

CryptOne XOR Key

Once the shellcode is decrypted, we can partially observe the string β€œThis program cannot be run in DOS mode” where this data contains an executable which requires a second decryption.

CryptOne partially decrypted shellcode

Similar to previous decryption, this time the shellcode decrypts the embedded binary.

Fastcall Shellcode XOR

The shellcode allocates and copies the encrypted executable and starts the decryption loop; once it finishes, it jumps to the EntryPoint and executes the unpacked sample.

CryptOne executing the unpacked sample

At this stage we can observe strings related to the unpacked sample.

CryptOne embedded strings after unpacking

A Unique Factory

Hunting for CryptOne led us to identify different implementations of the stub, some of which have never been reported previously. Each version is identified by a certain signature, listed below:

  • 111111111\\{aa5b6a80-b834-11d0-932f-00a0c90dcaa9}
  • 1nterfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • 444erfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • 555erfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • 5nterfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • 987erfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • Interfac4\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • InterfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • aaaerfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • interfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}
  • rrrerfacE\\{b196b287-bab4-101a-b69c-00aa00341d07}

The first part of the string is composed of a custom string (111111111, 1nterfacE, 444erfacE,…) which is replaced at runtime by the β€˜interface’ keyword, creating the following registry key:


The registry keys are related to the UCOMIEnumConnections and IActiveScriptParseProcedure32 interfaces respectively.

Once executed, the cryptor checks for the presence of those keys before loading the next stage payload. If it does not find the keys, then the malware goes into an endless loop without doing anything as an anti-emulation technique. This works because some emulators do not implement the full Windows registry.

In reviewing two different versions of CryptOne:


we noticed that in order to update the signature, the actor needs to re-compile the cryptor as the cryptor implementation changes.

CryptOne Timeline

Our analysis shows that it is likely Evil Corp started being a customer of the CryptOne service from March 2020. From March to May 2020 we found WastedLocker, gozi_rm3 (version:3.00 build:854) and Dridex (10121) samples were all packed and compiled in the same timeframe using the same CryptOne stub signature(InterfacE).

For a limited period of time between May 2020 and August 2020, we observed different versions of CryptOne overlaps.

CryptOne overlaps between May 2020 and August 2020

It seems that from a specific point in time, around September 2020, Hades, PhoenixLocker and PayloadBIN started adopting a specific CryptOne stub identified by the signature:


From December 2020, the CryptOne version β€˜111111111’ appeared in the wild without any overlap.


Clustering Evil Corp activity is demonstrably difficult considering that the group has changed TTPs several times in order to bypass sanctions and stay under the radar. This is in addition to the overall trend of actors receding back into secrecy. In this research, we connect the dots in the Evil Corp ecosystem, cluster Evil Corp malware, document the group’s activities and provide insight into their TTPs.

SentinelLabs assesses with high confidence that WastedLocker, Hades, PhoenixLocker, Macaw Locker and PayloadBIN belong to the same cluster. Our assessment is based on code similarity and reuse, timeline consistency and nearly identical TTPs across the ransomware families indicating there is a consistent modus operandi for the cluster. In addition, we assess that there is a likely evolutionary link between WastedLocker and BitPaymer, and suggest that it can be attributed to the same Evil Corp activity cluster.

We fully expect that Evil Corp will continue to evolve and target organizations. In addition, we assess it is likely they will also continue to advance their tradecraft, finding new methods of evading detection and misleading attribution. SentinelLabs will continue tracking this activity cluster to provide insight into its evolution.

In-depth technical analysis, Indicators of Compromise and further technical references are available in the full report.

Read the Full Report

Hide and Seek | New Zloader Infection Chain Comes With Improved Stealth and Evasion Mechanisms

13 September 2021 at 16:33

By Antonio Pirozzi and Antonio Cocomazzi

Executive Summary

  • New ZLoader campaign has a stealthier distribution mechanism which deploys a signed dropper with lower rates of detection.
  • The campaign primarily targets users of Australian and German banking institutions.
  • The new infection chain implements a stager which disables all Windows Defender modules.
  • The threat actor uses a backdoored version of the Windows utility wextract.exe to embed the ZLoader payload and lower the chance of detection.
  • SentinelLabs identified the entire infrastructure of the β€˜Tim’ botnet, composed of more than 350 recently-registered C2 domains.

Read the Full Report


ZLoader (also known as Terdot) was first discovered in 2016 and is a fork of the infamous Zeus banking trojan. It is still under active development. A multitude of different versions have appeared since December 2019, with an average frequency of 1-2 new versions released each week.

ZLoader is a typical banking trojan which implements web injection to steal cookies, passwords and any sensitive information. It attacks users of financial institutions all over the world and has also been used to deliver ransomware families like Egregor and Ryuk. It also provides backdoor capabilities and acts as a generic loader to deliver other forms of malware. Newer versions implement a VNC module which permits users to open a hidden channel that gives the operators remote access to victim systems. ZLoader relies primarily on dynamic data exchange (DDE) and macro obfuscation to deliver the final payload through crafted documents.

A recent evolution of the infection chain included the dynamic creation of agents, which download the payload from a remote server. The new infection chain observed by SentinelLabs demonstrates a higher level of stealth by disabling Windows Defender and relying on living-off-the-land binaries and scripts (LOLBAS) in order to evade detection. During our investigation, we were also able to map all the new ZLoader C2 infrastructure related to the β€˜Tim’ botnet and identify the scope of the campaign and its objectives, which primarily involved stealing bank credentials from customers of European banks.

Overview of the ZLoader infection chain

Technical Analysis

The malware is downloaded from a Google advertisement published through Google Adwords. In this campaign, the attackers use an indirect way to compromise victims instead of using the classic approach of compromising the victims directly, such as by phishing.

We observed the following pattern of activity that leads to infection:

  • The user performs a search on www.google.com to find a website to download the required software from; in our case, we observed a search for β€œteam viewer download”.
  • The user clicks on an advertisement shown by Google and is redirected to the fake TeamViewer site under the attacker’s control.
  • The user is tricked into downloading the fake software in a signed MSI format.

Once the user clicks on the advertisement, it will redirect through the aclk page. This redirect demonstrates the attackers usage of Google Adwords to gain traffic:


After further navigation (and redirects), the malicious Team-Viewer.msi is downloaded from the final URL hxxps://team-viewer.site/download/Team-Viewer.msi.

The downloaded file is a fake TeamViewer installer signed on 2021-08-23 10:07:00. It appears that the cybercriminals managed to obtain a valid certificate issued by Flyintellect Inc, a Software company in Brampton, Canada. The company was registered on 29th June 2021, suggesting that the threat actor possibly registered the company for the purpose of obtaining those certificates.

Pivoting from this certificate, we were able to spot other samples signed with the same certificate. These other samples suggest that the attackers had multiple campaigns ongoing beyond TeamViewer and which included fakes such as JavaPlug-in.mis, Zoom.mis, and discord.msi.

At the time of writing, these four samples have no detections on VirusTotal (a complete list of IoCs can be found in the full report).

New Zloader Infection Chain Bypass Defences

The .msi file is the first stage dropper which runs an installation wizard. It creates random legitimate files in the directory C:\Program Files (x86)\Sun Technology Network\Oracle Java SE. Once the folder has been created, it will drop the setup.bat file, triggering the initial infection chain by executing cmd.exe /c setup.bat.

This initiates the second stage of the infection chain, downloading the dropper updatescript.bat through the PowerShell cmdlet Invoke-WebRequest, from hxxps://websekir.com/g00glbat/index/processingSetRequestBat/?servername=msi. The dropper then executes the third stage with the command cmd /c updatescript.bat.

The third stage dropper contains most of the logic to impair the defenses of the machine. It also drops the fourth stage using a stealthy execution technique. At first, it disables all the Windows Defender modules through the PowerShell cmdlet Set-MpPreference. It then adds exclusions, such as regsvr32, *.exe, *.dll, with the cmdlet Add-MpPreference to hide all the components of the malware from Windows Defender.

At this point the fourth stage dropper is downloaded from the URL hxxps://pornofilmspremium.com/tim.EXE and saved as tim.exe. The execution of tim.exe is done through the LOLBAS command explorer.exe tim.exe. This allows the attacker to break the parent/child correlation often used by EDRs for detection.

The first part of the attack chain

The tim.exe binary is a backdoored version of the Windows utility wextract.exe. This backdoored version contains extra embedded resources with names like β€œRUNPROGRAM”, β€œREBOOT”, and β€œPOSTRUNPROGRAM”, among others.

Resources embedded in the tim.exe binary (left) and legit wextract.exe(right)

This backdoored version contains additional code for creating a new malicious batch file with the name tim.bat. It is placed in a temporary directory retrieved with the Win32 function GetTempPath(). It retrieves the content of the resource β€œRUNPROGRAM” (containing the string value cmd /c tim.bat) and uses it as the command line parameter for the CreateProcess() Win32 function.

The tim.bat file is a very short script that downloads the final ZLoader DLL payload with the name tim.dll from the URL hxxps://pornofilmspremium.com/tim.dll and executes it through the LOLBAS command regsvr32 tim.dll. This allows the attackers to proxy the execution of the DLL through a signed binary by Microsoft.

This dropper downloads the script nsudo.bat from hxxps://pornofilmspremium.com/nsudo.bat and runs asynchronously in parallel with the execution of tim.dll. The script aims to further impair defenses of the machine.

Privilege Escalation and Defense Evasion

The nsudo.bat script performs multiple operations with the goal of elevating privileges on the system and impairing defenses.

At first, it checks if the current context of execution is privileged by verifying the access to the SYSTEM hive. This is done through %SYSTEMROOT%\system32\cacls.exeΒ  %SYSTEMROOT%\system32\config\system. If the process in which it runs has no access on that hive it will jump to the label :UACPrompt.

This part of the script implements an auto elevation VBScript that aims to run an elevated process in order to make system changes. The snippet of the script in charge of the UACPrompt feature is as follows:

      echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
      set params = %*:"="
      echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%\getadmin.vbs"
      del "%temp%\getadmin.vbs"
      exit /B

This snippet creates the VBScript getadmin.vbs, runs it and deletes it. Using a VBScript eases the interaction with COM objects. In this case, it instantiates a Shell.Application object and calls the function ShellExecute() to trigger the UAC elevation and the interaction with the AppInfo service.

Once the elevation occurs the script is run with elevated privileges. At this point, the script performs the steps to disable Windows Defender. It does this through a software utility called NSudo renamed as javase.exe, which is downloaded from the URL hxxps://pornofilmspremium.com/javase.exe. The attacker leverages this utility in order to spawn a process with β€œTrustedInstaller” privileges. This can be abused by the attacker to disable the Windows Defender service even if it runs as a Protected Process Light.

The script downloads the file autorun100.bat from and places it in the startup folder %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. This script ensures that the WinDefend service is deleted at the next boot through the utility NSudo.

The nsudo.bat script also completely disables UAC by setting the following registry key to 0:


In order to have these changes take effect, the computer is forced to restart. The nsudo.bat script does this with shutdown.exe /r /f /t 00. At this point, the attack chain of the script nsudo.bat is complete.

ZLoader Payload Execution Chain

The tim.dll is the main ZLoader payload that encapsulates the unpacking logic and adds persistence. It is executed through the system signed binary regsvr32.exe.

It first creates a directory with a random name inside %APPDATA% and then creates a copy of itself in the newly created directory. It then adds a new registry key in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. The registry key value contains the command line of the malicious process to spawn on user logon. This ensures that the attacker’s implant survives machine reboots. The DLL execution also relies on the regsvr32 binary. This is an example of the registry key created on a single run of the sample:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\Iwalcacvalue: regsvr32.exe /s C:\Users\[REDACTED]\AppData\Roaming\Kyubt\otcyovw.dll

Then it starts the unpacking by leveraging a process injection technique known as Thread Hijacking. It contains a small variation but essentially uses the same pattern of Win32 API calls used for Thread Hijacking:

VirtualAllocEx() -> WriteProcessMemory() -> GetThreadContext() -> SetThreadContext() -> ResumeThread()

It first creates a new process as a host for the unpacked DLL, and for this sample it uses a new instance of msiexec.exe. Then it allocates and writes 2 RWX memory regions inside the target process. One contains the unpacked version of the DLL XOR’ed with a key; the second, contains some shellcode to decrypt the DLL and jump to the entry point.

The unpacking routine

Once the memory is written in the remote process it sets the new thread context EIP to point to the unpacking routine shellcode and resumes the main thread of msiexec. This is how the hijacking of the main thread occurs. The unpacked DLL is extracted from the memory of msiexec.exe process by dumping the memory address used in the first WriteProcessMemory() call.

We have compared the unpacked DLL with the recent ZLoader payloads and found a similarity score of 92.62%.

Final part of the attack chain

Analyzing The New Zloader C2 Infrastructure

The analyzed sample belongs to the β€˜Tim’ Botnet as defined in the malware configuration. Some of the embedded C2s (the full list can be found in the IoC section of the full report) are also shared by the googleaktualizacija ZLoader botnet.

One of the C2s dumped from the infected machine, mjwougyhwlgewbajxbnn[.]com, used to resolve to 194.58.108[.]89 until the 25th of August 2021. As of the 26th of August, however, it points to 195.24.66[.]70.

The IP 194.58.108[.]89 belongs to ASN 48287 – RU-CENTER and seems to deploy many different domains – 350 at the time of writing – forming the new ZLoader infrastructure. Some domains implement the gate.php component, which is a fingerprint of the ZLoader botnet. We noticed during our investigation that all the domains were registered from April to Aug 2021, and they switched to the new IP (195.24.66[.]70) on the 26th of August.

A Targeted Campaign: AU And DE Financial Institutions

The new ZLoader campaign is targeted. The final payload has a list of embedded AU and DE domains, and contains some strings with wildcards used by the malware to intercept specific users’ web requests to bank portals.


From our analysis of the communication patterns related to mjwougyhwlgewbajxbn[.]com, we were able to map most of the source traffic used by the operators of the botnet.

The pornofilmspremium[.]com domain delivers the tim.exe component. The domain was registered on 2021-07-19 (Location RU, ASN: REG RU 197695) and is associated by the community with ZLoader [1, 2]. The email address [email protected][.]com was used to register this domain and a number of others, as detailed in the full report.


The attack chain analyzed in this research shows how the complexity of the attack has grown in order to reach a higher level of stealthiness. The first stage dropper has been changed from the classic malicious document to a stealthy, signed MSI payload. It uses backdoored binaries and a series of LOLBAS to impair defenses and proxy the execution of their payloads.

This is the first time we have observed this attack chain in a ZLoader campaign. At the time of writing, we have no evidence that the delivery chain has been implemented by a specific affiliate or if it was provided by the main operator. SentinelLabs continues to monitor this threat in order to track further activity.

Indicators of Compromise

For a full list of IoCS see the full report.

Read the Full Report

Read the Full Report

We thank Awais Munir for his assistance in the technical analysis of the Zloader campaign.

  • There are no more articles