The percentage of ICS computers on which malicious objects were blocked continued to decrease, reaching 19.6% in Q1 2026. This is the lowest value in three years, and it is 1.4 times lower than in Q2 2023.
Percentage of ICS computers on which malicious objects were blocked, Q2 2023–Q1 2026
Regionally, the percentages ranged from 9.1% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of attacked ICS computers
The percentage of ICS computers on which malicious objects were blocked increased in five regions over the quarter, most notably in Southern Europe, Northern Europe, and Russia.
In Q1 2026, Southern Europe led the way in growth for internet and email threats. The region also saw the fastest growth in spyware, as well as malicious scripts and phishing pages.
In Russia, the percentage of ICS computers on which malicious objects were blocked exceeded the figures for the previous two quarters. Russia saw an increase in the percentage for threats from the internet, and a slight increase in the figure for threats from email clients (Russia is one of three regions where this figure did not decrease).
Among the threat categories, the greatest increases were observed in the percentages for denylisted internet resources, as well as spyware (distributed in the region via the internet and email clients).
Biometric systems (26.4%) traditionally rank top among the industries and OT infrastructure types covered in this report in terms of the percentage of ICS computers on which malicious objects were blocked. These systems are characterized by internet access, extensive email use for data exchange and approvals (such as access granting), and, in many cases, minimal cybersecurity controls within the organizations that use these systems.
Industries ranked by the percentage of ICS computers on which malicious objects were blocked
Biometric systems rank first among industries in terms of email threats. At the same time, unlike other industries, the percentage for email threats in biometric systems exceeds that for internet threats.
In all selected industries, the global average follows a downward trend. In Q1 2026, the percentage of ICS computers on which malicious objects were blocked increased only in the manufacturing sector — by 1.0 pp. The percentages for this industry increased across 10 regions, with the most notable increases in Western Europe, Northern Europe, and Russia.
In Q1 2026, Kaspersky security solutions blocked malware from 10,052 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which denylisted internet resources were blocked increased (after decreasing over the previous two quarters), and there was a slight increase in the percentage for AutoCAD malware.
Percentage of ICS computers on which the activity of malicious objects from various categories was prevented
Malicious scripts and phishing pages retained their to spot among threat categories by the percentage of ICS computers on which these threats were blocked. The global average in Q1 2026 was 6.56%.
Over the quarter, the percentages increased in four regions. The most significant change was observed in Southern Europe (9.85%, +0.94 pp). The figures for malicious scripts in the region increased over three consecutive quarters.
Among the selected industries, across all regions, the highest percentages for the malicious scripts and phishing pages category were recorded for biometric systems (19.59%) and building automation (15.43%) in Southern Europe. These same industries lead in similar rankings for malicious documents and spyware.
The percentage of ICS computers on which spyware was blocked decreased over two consecutive quarters, dropping to 3.73%. Despite the decline, spyware has ranked second among threat categories by the percentage of attacked computers for three consecutive quarters.
The percentages increased in five regions over the quarter, most notably in Southern Europe (5.46%, +0.35 pp) and Russia (2.84%, +0.24 pp).
In Southern Europe, the percentage of ICS computers on which spyware was blocked increased in all the selected industries except manufacturing. The greatest increase was observed in biometric systems.
Among the selected industries, the highest percentage of spyware in Russia was recorded in biometric systems. That said, the percentage of ICS computers on which spyware was blocked increased in all industries in the region except construction. The percentage figure has been increasing for two consecutive quarters in the oil and gas industry (by a factor of 1.63 over six months), and for three consecutive quarters in engineering and ICS integration, as well as electric power. In the remaining sectors, the values have been fluctuating.
Percentage of ICS computers on which spyware was blocked in various industries in Russia, Q3 2025–Q1 2026
The percentage of ICS computers on which denylisted internet resources were blocked increased to 3.54%.
The most notable increase over the quarter occurred in Southeast Asia (4.58%, +0.65 pp). Among the industries in the region, the highest percentage figures for this threat category were recorded in electric power and construction. Over the quarter, the largest increases in percentages figures were observed in the electric power and manufacturing industries.
In North America (Canada), denylisted internet resources (2.14%) showed the greatest increase among all categories — by a factor of 1.22.
Among the selected industries across all regions, the highest percentage figures for the denylisted internet resources category were in the electric power (7.11%) and construction (6.25%) industries in Southeast Asia.
The percentage figure for this category decreased over two consecutive quarters, reaching its lowest value (1.56%) for the entire period of observations in Q1 2026. It increased just in two regions: Australia and New Zealand (1.12%, +0.04 pp), and Russia (0.62%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for malicious documents were recorded for biometric systems (9.02%) and building automation (6.97%) in Southern Europe. These same industries also lead in similar rankings for malicious scripts and spyware.
The percentage of ICS computers on which ransomware was blocked has decreased for two consecutive quarters, dropping to 0.14%. This is the lowest value among all categories.
The percentage increased in two regions: North America (Canada) (0.11%, +0.04 pp) and slightly in Northern Europe (0.06%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for ransomware were recorded in the oil and gas and manufacturing industries (0.92% and 0.65%, respectively) in Central Asia and the South Caucasus, and in biometric systems (0.89%) in Russia.
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased to 0.59%.
The percentage increased in seven regions. The largest increase was observed in Africa (0.63%, +0.16 pp). Among the selected industries, the largest increases in the region were in the manufacturing and oil and gas industries.
Among the selected industries across all regions, the highest percentages for miners in the form of executable files were recorded in construction (1.99%), biometric systems (1.98%), and the oil and gas industry (1.97%) in Central Asia and the South Caucasus.
The percentage of ICS computers on which web miners were blocked has been declining for a year, and in Q1 2026, it reached the lowest value for the entire period under review (0.22%).
At the same time, the percentage increased in seven regions. The largest increases were observed in South Asia (0.28%, +0.11 pp), the Middle East (0.31%, +0.09 pp), and Africa (0.34%, +0.08 pp). Despite the increases, the percentages in these regions for Q1 2026 did not exceed those observed in 2023–2024 and in Q1 2025.
Among the selected industries across all regions, the highest percentages for web miners were recorded for biometric systems (0.97%) in Russia. Biometric systems in South Asia (0.79%) ranked second, and the electric power sector in Southeast Asia (0.76%) ranked third.
The percentage of ICS computers on which worms were blocked decreased to 1.33%.
The percentage decreased across all regions following an increase in the previous quarter (due to a wave of phishing attacks that distributed the Backdoor.MSIL.XWorm backdoor worm across all regions of the world).
Among the selected industries across all regions, the highest percentage figure for worms was recorded for biometric systems (4.80%) in Central Asia and the South Caucasus. Two industries in Africa – biometric systems (4.04%) and electric power (3.53%) – took the second and third spots, respectively.
The percentage of ICS computers on which viruses were blocked decreased to 1.31%.
The top 3 regions by this figure remained the same: Southeast Asia (6.11%, first by a wide margin), Africa (4.15%), and East Asia (2.97%). These same regions are also among the leaders by the percentage of systems affected by AutoCAD malware. The largest increase in this figure was observed in Africa (+0.41 pp).
Among the selected industries across all regions, the highest percentages for viruses were recorded in the construction industry (6.35%) and building automation (5.50%) in Southeast Asia.
The percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.30%.
The most notable increase over the quarter was observed in Africa, with the region’s percentage figure rising by 0.47 pp, a very significant increase for this category, and almost doubling (to 0.91%).
Among the selected industries across all regions, the highest percentages for AutoCAD malware were recorded in the construction industry in East Asia (5.58%) and Southeast Asia (3.87%).
In Q1 2026, the average percentages across all threat sources, except threats from the internet, decreased globally.
Percentage of ICS computers on which malicious objects from various sources were blocked
The percentage of ICS computers on which threats from the internet were blocked increased to 7.88%. However, over the past three years, the percentage figure for internet threats has followed a downward trend.
The largest increases in the percentages were recorded in Southern Europe (8.59%, +0.59 pp), Southeast Asia (10.16%, +0.55 pp), and Northern Europe (4.47%, +0.51 pp).
Among the selected industries across all regions, the highest percentages for threats from the internet were recorded in electric power (13.16%) and construction (12.55%) in Southeast Asia, and in the engineering and ICS integration sector (12.33%) in South Asia.
The percentage of ICS computers on which threats delivered via email clients were blocked decreased to 2.59%. This is a three-year low.
The percentage of this threat source increased in three regions: Southern Europe (6.54%, +0.2 pp), East Asia (1.5%, +0.09 pp), and slightly in Russia (0.7%, +0.04 pp).
Among the selected industries across all regions, the highest percentages for email threats were recorded for biometric systems (19.78%) and building automation (12.34%) in Southern Europe. In these two industries, the percentage of ICS computers on which email threats are blocked is higher than the percentage for threats from the internet. A similar situation was observed in two other instances, both in biometric systems (in South America and Southeast Asia).
The percentage of ICS computers on which threats were detected when connecting removable media continued to decrease, reaching its lowest value for the period under review (0.26%).
Among the selected industries across all regions, the highest percentages for removable media threats blocked on ICS computers were observed in the electric power sector in Central Asia and the South Caucasus (1.45%), East Asia (1.34%), and Africa (1.16%).
The percentage of ICS computers on which threats are blocked in network folders is steadily decreasing. In Q1 2026, it was the lowest for the period under review (0.029%).
East Asia has traditionally led by a wide margin. The percentage for East Asia (0.135%) is 27 times higher than the lowest regional value (recorded in Northern Europe).
The largest increases in the percentages for threats from network folders were observed in Africa (0.037%, +0.006 pp) and South America (0.013%, +0.006 pp).
Among the selected industries across all regions, the construction industry in East Asia, at 0.36%, holds the top positions in the ranking by the percentage of ICS computers on which threats are blocked in network folders.
For more information on industrial threats see the full version of the report.
The percentage of ICS computers on which malicious objects were blocked continued to decrease, reaching 19.6% in Q1 2026. This is the lowest value in three years, and it is 1.4 times lower than in Q2 2023.
Percentage of ICS computers on which malicious objects were blocked, Q2 2023–Q1 2026
Regionally, the percentages ranged from 9.1% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of attacked ICS computers
The percentage of ICS computers on which malicious objects were blocked increased in five regions over the quarter, most notably in Southern Europe, Northern Europe, and Russia.
In Q1 2026, Southern Europe led the way in growth for internet and email threats. The region also saw the fastest growth in spyware, as well as malicious scripts and phishing pages.
In Russia, the percentage of ICS computers on which malicious objects were blocked exceeded the figures for the previous two quarters. Russia saw an increase in the percentage for threats from the internet, and a slight increase in the figure for threats from email clients (Russia is one of three regions where this figure did not decrease).
Among the threat categories, the greatest increases were observed in the percentages for denylisted internet resources, as well as spyware (distributed in the region via the internet and email clients).
Biometric systems (26.4%) traditionally rank top among the industries and OT infrastructure types covered in this report in terms of the percentage of ICS computers on which malicious objects were blocked. These systems are characterized by internet access, extensive email use for data exchange and approvals (such as access granting), and, in many cases, minimal cybersecurity controls within the organizations that use these systems.
Industries ranked by the percentage of ICS computers on which malicious objects were blocked
Biometric systems rank first among industries in terms of email threats. At the same time, unlike other industries, the percentage for email threats in biometric systems exceeds that for internet threats.
In all selected industries, the global average follows a downward trend. In Q1 2026, the percentage of ICS computers on which malicious objects were blocked increased only in the manufacturing sector — by 1.0 pp. The percentages for this industry increased across 10 regions, with the most notable increases in Western Europe, Northern Europe, and Russia.
In Q1 2026, Kaspersky security solutions blocked malware from 10,052 different malware families of various categories on industrial automation systems.
Over the quarter, the percentage of ICS computers on which denylisted internet resources were blocked increased (after decreasing over the previous two quarters), and there was a slight increase in the percentage for AutoCAD malware.
Percentage of ICS computers on which the activity of malicious objects from various categories was prevented
Malicious scripts and phishing pages retained their to spot among threat categories by the percentage of ICS computers on which these threats were blocked. The global average in Q1 2026 was 6.56%.
Over the quarter, the percentages increased in four regions. The most significant change was observed in Southern Europe (9.85%, +0.94 pp). The figures for malicious scripts in the region increased over three consecutive quarters.
Among the selected industries, across all regions, the highest percentages for the malicious scripts and phishing pages category were recorded for biometric systems (19.59%) and building automation (15.43%) in Southern Europe. These same industries lead in similar rankings for malicious documents and spyware.
The percentage of ICS computers on which spyware was blocked decreased over two consecutive quarters, dropping to 3.73%. Despite the decline, spyware has ranked second among threat categories by the percentage of attacked computers for three consecutive quarters.
The percentages increased in five regions over the quarter, most notably in Southern Europe (5.46%, +0.35 pp) and Russia (2.84%, +0.24 pp).
In Southern Europe, the percentage of ICS computers on which spyware was blocked increased in all the selected industries except manufacturing. The greatest increase was observed in biometric systems.
Among the selected industries, the highest percentage of spyware in Russia was recorded in biometric systems. That said, the percentage of ICS computers on which spyware was blocked increased in all industries in the region except construction. The percentage figure has been increasing for two consecutive quarters in the oil and gas industry (by a factor of 1.63 over six months), and for three consecutive quarters in engineering and ICS integration, as well as electric power. In the remaining sectors, the values have been fluctuating.
Percentage of ICS computers on which spyware was blocked in various industries in Russia, Q3 2025–Q1 2026
The percentage of ICS computers on which denylisted internet resources were blocked increased to 3.54%.
The most notable increase over the quarter occurred in Southeast Asia (4.58%, +0.65 pp). Among the industries in the region, the highest percentage figures for this threat category were recorded in electric power and construction. Over the quarter, the largest increases in percentages figures were observed in the electric power and manufacturing industries.
In North America (Canada), denylisted internet resources (2.14%) showed the greatest increase among all categories — by a factor of 1.22.
Among the selected industries across all regions, the highest percentage figures for the denylisted internet resources category were in the electric power (7.11%) and construction (6.25%) industries in Southeast Asia.
The percentage figure for this category decreased over two consecutive quarters, reaching its lowest value (1.56%) for the entire period of observations in Q1 2026. It increased just in two regions: Australia and New Zealand (1.12%, +0.04 pp), and Russia (0.62%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for malicious documents were recorded for biometric systems (9.02%) and building automation (6.97%) in Southern Europe. These same industries also lead in similar rankings for malicious scripts and spyware.
The percentage of ICS computers on which ransomware was blocked has decreased for two consecutive quarters, dropping to 0.14%. This is the lowest value among all categories.
The percentage increased in two regions: North America (Canada) (0.11%, +0.04 pp) and slightly in Northern Europe (0.06%, +0.01 pp).
Among the selected industries across all regions, the highest percentages for ransomware were recorded in the oil and gas and manufacturing industries (0.92% and 0.65%, respectively) in Central Asia and the South Caucasus, and in biometric systems (0.89%) in Russia.
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked decreased to 0.59%.
The percentage increased in seven regions. The largest increase was observed in Africa (0.63%, +0.16 pp). Among the selected industries, the largest increases in the region were in the manufacturing and oil and gas industries.
Among the selected industries across all regions, the highest percentages for miners in the form of executable files were recorded in construction (1.99%), biometric systems (1.98%), and the oil and gas industry (1.97%) in Central Asia and the South Caucasus.
The percentage of ICS computers on which web miners were blocked has been declining for a year, and in Q1 2026, it reached the lowest value for the entire period under review (0.22%).
At the same time, the percentage increased in seven regions. The largest increases were observed in South Asia (0.28%, +0.11 pp), the Middle East (0.31%, +0.09 pp), and Africa (0.34%, +0.08 pp). Despite the increases, the percentages in these regions for Q1 2026 did not exceed those observed in 2023–2024 and in Q1 2025.
Among the selected industries across all regions, the highest percentages for web miners were recorded for biometric systems (0.97%) in Russia. Biometric systems in South Asia (0.79%) ranked second, and the electric power sector in Southeast Asia (0.76%) ranked third.
The percentage of ICS computers on which worms were blocked decreased to 1.33%.
The percentage decreased across all regions following an increase in the previous quarter (due to a wave of phishing attacks that distributed the Backdoor.MSIL.XWorm backdoor worm across all regions of the world).
Among the selected industries across all regions, the highest percentage figure for worms was recorded for biometric systems (4.80%) in Central Asia and the South Caucasus. Two industries in Africa – biometric systems (4.04%) and electric power (3.53%) – took the second and third spots, respectively.
The percentage of ICS computers on which viruses were blocked decreased to 1.31%.
The top 3 regions by this figure remained the same: Southeast Asia (6.11%, first by a wide margin), Africa (4.15%), and East Asia (2.97%). These same regions are also among the leaders by the percentage of systems affected by AutoCAD malware. The largest increase in this figure was observed in Africa (+0.41 pp).
Among the selected industries across all regions, the highest percentages for viruses were recorded in the construction industry (6.35%) and building automation (5.50%) in Southeast Asia.
The percentage of ICS computers on which malware for AutoCAD was blocked increased to 0.30%.
The most notable increase over the quarter was observed in Africa, with the region’s percentage figure rising by 0.47 pp, a very significant increase for this category, and almost doubling (to 0.91%).
Among the selected industries across all regions, the highest percentages for AutoCAD malware were recorded in the construction industry in East Asia (5.58%) and Southeast Asia (3.87%).
In Q1 2026, the average percentages across all threat sources, except threats from the internet, decreased globally.
Percentage of ICS computers on which malicious objects from various sources were blocked
The percentage of ICS computers on which threats from the internet were blocked increased to 7.88%. However, over the past three years, the percentage figure for internet threats has followed a downward trend.
The largest increases in the percentages were recorded in Southern Europe (8.59%, +0.59 pp), Southeast Asia (10.16%, +0.55 pp), and Northern Europe (4.47%, +0.51 pp).
Among the selected industries across all regions, the highest percentages for threats from the internet were recorded in electric power (13.16%) and construction (12.55%) in Southeast Asia, and in the engineering and ICS integration sector (12.33%) in South Asia.
The percentage of ICS computers on which threats delivered via email clients were blocked decreased to 2.59%. This is a three-year low.
The percentage of this threat source increased in three regions: Southern Europe (6.54%, +0.2 pp), East Asia (1.5%, +0.09 pp), and slightly in Russia (0.7%, +0.04 pp).
Among the selected industries across all regions, the highest percentages for email threats were recorded for biometric systems (19.78%) and building automation (12.34%) in Southern Europe. In these two industries, the percentage of ICS computers on which email threats are blocked is higher than the percentage for threats from the internet. A similar situation was observed in two other instances, both in biometric systems (in South America and Southeast Asia).
The percentage of ICS computers on which threats were detected when connecting removable media continued to decrease, reaching its lowest value for the period under review (0.26%).
Among the selected industries across all regions, the highest percentages for removable media threats blocked on ICS computers were observed in the electric power sector in Central Asia and the South Caucasus (1.45%), East Asia (1.34%), and Africa (1.16%).
The percentage of ICS computers on which threats are blocked in network folders is steadily decreasing. In Q1 2026, it was the lowest for the period under review (0.029%).
East Asia has traditionally led by a wide margin. The percentage for East Asia (0.135%) is 27 times higher than the lowest regional value (recorded in Northern Europe).
The largest increases in the percentages for threats from network folders were observed in Africa (0.037%, +0.006 pp) and South America (0.013%, +0.006 pp).
Among the selected industries across all regions, the construction industry in East Asia, at 0.36%, holds the top positions in the ranking by the percentage of ICS computers on which threats are blocked in network folders.
For more information on industrial threats see the full version of the report.
Unit 42 explores The Gentlemen ransomware operations, revealing the affiliate model driving its rapid growth. Learn more here.
The post No Manners Here: The Ruthless Rise of The Gentlemen Ransomware appeared first on Unit 42.
In this post, we explore the emergence of Remus Stealer, analyzing its structural and behavioral similarities to the infamous Lumma malware.
Table Of Contents
The underground marketplace rarely stays quiet for long. A new information-stealing malware dubbed Remus Stealer has surfaced in the cybercrime underground, exhibiting significant similarities to the notorious Lumma malware family across its administration panel, stolen log files, and core code structure.
Despite parallels in its code and functionality, threat actors are eagerly buying into the platform. In addition to its familiar features, it provides attackers with a distinct, modern command and control (C2) and networking infrastructure designed to slip past current security perimeters.
Flashpoint first observed Remus appearing for sale within illicit communities in March 2026. The malware listing offers similar functionality to other popular Malware-as-a-Service (MaaS) offerings, including Google OAuth cookie restoration and Telegram channel integration for logs.
Much like the Lumma malware family, the Remus subscription service operates on a three-tiered access model:
At this time, Remus has no additional channels or automated bots associated with its sale or distribution. Despite undeniable similarities to Lumma, its developer claims to not be a rebrand of the Lumma project.
Since March 2026, Remus has continued its operations mostly unhindered by negative associations associated with Lumma—particularly the doxxing of its panel in August 2025.
Similarities can be observed in the Remus and Lumma panels in both aesthetics and functionality. Both panels use similar assets for tab icons and have embedded advertisements for other illicit services such as packers and log clouds. Harvested logs also share extremely similar directory structures in log files, including unique identifiers.
Remus is a 64-bit compiled binary, and Lumma was a 32-bit binary. However, major similarities between the code bases of both malware can be observed.
Upon execution of an unpacked sample, both Remus and Lumma will send warning messages to the user that the build is unpacked. This was a unique phenomenon first established by Lumma several years ago. In both Remus and Lumma samples, the pack check and window message are performed before the main functionality of the malware.
In both Remus and Lumma, a function is used first to check if the sample is packed, and a second function is used to send the window error message.
Remus uses similar string obfuscation methods to Lumma, in which each string has been uniquely encoded and then decoded during runtime. Deobfuscation occurs by looping byte by byte through encoded blobs. Each encoded string is obfuscated by a unique pattern. This can be seen in the code samples below:
Of note, both samples have at least one NOP instruction between the encoded blob being moved onto the stack and the deobfuscation loop.
Another unique feature of Lumma is the presence of a plaintext identifier string used to link customers to specific build generations. In Lumma, this string was referred to as the LID (Lumma ID), and this ID method appears in Remus as well as a “tag.”
Like the Lumma LID string, the Remus tag could be leveraged to attribute variant builds and campaigns to single threat actors or groups.
Additionally, both Remus and Lumma exhibit similar control flow obfuscation by replacing direct jumps with indirect jumps read from offsets that have been moved onto the stack, jumps computed from a jump table, and jumps resolved by a pointer.
Although Remus bears remarkable similarities to Lumma, its main differences lie in its C2 beaconing.
Before performing main stealer functionality, Remus will beacon out to its C2 infrastructure. It will attempt to resolve several domain:port combinations via POST requests, and attempt a final connection to find the C2 server using EtherHiding. If it is unable to connect, the malware will terminate.
After a connection is established, the stealer sends a POST request to the C2 in order to receive an access token. Once received and decoded, this access token is used to receive encrypted config data used by Remus to target assets on the victim system. Data collected for logs is then exfiltrated as encrypted POST data.
Remus stealer represents a sophisticated continuation of the MaaS infostealer model left behind by Lumma’s collapse. While the developer asserts independence, the overwhelming code overlaps, matching obfuscation techniques, and administrative panels indicate that Remus is either heavily inspired by, or derived from the Lumma codebase. These traits have allowed it to thrive, providing threat actors with a familiar, robust alternative that sidesteps the reputational baggage and law enforcement scrutiny of its predecessors.
Flashpoint continuously tracks the latest developments in illicit communities, hard-to-reach adversary spaces, and malware repositories to identify emerging threats. Request a demo to learn how Flashpoint’s primary source collections and analyst insights empowers your security teams.
The post Remus Stealer: A New, Not-So-New Infostealer appeared first on Flashpoint.
The 2026 World Cup presents major cyber risks from ransomware groups, state-aligned actors, and other groups targeting critical infrastructure. Learn more here.
The post 2026 World Cup: Discussing The World’s Biggest Game’s Attack Surface appeared first on Unit 42.
Unit 42 explores trends in data theft and extortion, outlining key strategies for organizations as frontier AI models advance.
The post Out of the Crypt: The Evolving Cyber Extortion Economy appeared first on Unit 42.
Authors: Yun Zheng Hu and Mick Koomen
Last year, we published research1 about a North Korean Lazarus subgroup targeting financial and cryptocurrency organizations, encountered during multiple incident response engagements. This Lazarus subgroup overlaps with activity linked to AppleJeus2, Citrine Sleet3, UNC47364, and Gleaming Pisces5. In one investigation, we observed that the actor had replaced ThemeForestRAT and PondRAT with a more sophisticated memory-only toolset. This follow-up post covers all three malware families from that toolset: DPAPILoader, RemotePELoader and RemotePE.
The three form a chain. DPAPILoader decrypts and loads RemotePELoader from disk using the Windows Data Protection API (DPAPI). RemotePELoader beacons to a C2 server and waits until it receives the next stage: RemotePE, a RAT executed entirely in memory and never written to disk, leaving no filesystem artifacts. At the time of writing, we have not found samples of RemotePELoader or RemotePE on VirusTotal.
The toolset’s environmental keying, memory-only execution, EDR evasion, and low forensic footprint suggest it is purpose-built for long-term observation campaigns. This allows the actor to quietly maintain access over an extended period before moving to a high-impact final objective such as data theft or a large-scale financial heist, consistent with this actor’s known history.
We are sharing samples with detection rules and indicators of compromise (IOCs) to help defenders identify and respond to this toolset in their environments.
DPAPILoader is implemented as a DLL whose purpose is to decrypt and load an encrypted payload from disk using DPAPI. In the incident response case, it was found as C:\Windows\System32\Iassvc.dll, installed under the service name “Internet Authentication Service.” This service runs Iassvc.dll automatically on system startup, providing persistence for the toolset. The filename and service name are chosen to mimic the legitimate Windows Server Internet Authentication Service (IAS) and its accompanying DLL C:\Windows\System32\iassvcs.dll (note the extra ‘s’ in the filename).
In Listing 1, we list a Windows service record, extracted from the forensic image using Dissect6, that shows the masquerading in detail.
Login
name (string) = Ias
displayname (string) = Internet Authentication Service
description (string) = Internet Authentication Service (IAS) is a component of Windows Server operating systems that provides centralized user authentication, authorization and accounting.
servicedll (path) = %SystemRoot%\system32\Iassvc.dll
imagepath (path) = %systemroot%\system32\svchost.exe
imagepath_args (string) = -k netsvcs -p
objectname (string) = LocalSystem
start (string) = Auto Start (2)
type (string) = Service - Own Process (0x10)
errorcontrol (string) = Normal (1)
Listing 1: Service record from Dissect showing Windows service that runs DPAPILoader
The sample from our investigation first checks whether it is running under C:\Windows\System32\Svchost.exe. It then loops over all files matching the wildcard path C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US*.*. This directory normally contains Microsoft Cabinet files used for device metadata packages. DPAPILoader skips any file beginning with the Cabinet magic bytes (MSCF / 4D 53 43 46), filtering out legitimate metadata packages. Any file that passes this check and is larger than 51200 bytes (50 KiB) is decrypted using DPAPI and loaded into memory using libpeconv7 , an open-source reflective PE loading library.
Across the DPAPILoader samples we observed, the loading mechanism and host process differ, as documented in the Observed Samples section, but the core behaviour is consistent.
DPAPILoader uses the Windows Data Protection API (DPAPI) to decrypt its payload. DPAPI ties cryptographic keys to a specific user account, with key management handled entirely by the OS. The caller only invokes encrypt and decrypt functions.
This offers the actor two advantages. First, the encrypted payload on disk is never in plaintext: if a sample is uploaded to VirusTotal, it is useless without the victim’s DPAPI keys. Static analysis is effectively impossible without them. Second, each deployment produces a unique encrypted blob, meaning the payload hash differs across victims and evades hash-based detection. The only prerequisite is prior access to the target machine to encrypt and drop the payload, something the actor has at this stage of the intrusion.
After DPAPI decryption, the payload is additionally XORed with 0x8D before loading. This is consistent across all observed DPAPILoader samples. This approach is an instance of environmental keying8, where malware is bound to a specific victim environment and cannot be analysed or executed elsewhere.
We identified three DPAPILoader samples spanning roughly nine months, with differences in loading mechanism, host process, and payload storage.
The first sample (Iassvc.dll) is loaded as a Windows service via Svchost.exe, the second (sspicli.dll) is sideloaded by ESET’s edp.exe, and the third (wmiclnt.dll) uses the WmiOpenBlock export with no identified host process.
| PE timestamp | DLL name | Export | String obfuscation |
|---|---|---|---|
| 2023-11-14 | Iassvc.dll | ServiceMain | XOR 0x8D |
| 2024-02-21 | sspicli.dll | InitSecurityInterfaceW | XOR 0x8D |
| 2024-08-21 | wmiclnt.dll | WmiOpenBlock | DPAPI + XOR 0x8D |
The first two samples load the DPAPI-encrypted payload from the DeviceMetadataStore path. The third embeds the encrypted payload directly in the DLL, removing the dependency on a separate file on disk.
The second and third samples were found on VirusTotal. Without the victims’ DPAPI keys, we are unable to decrypt them. Both are a practical demonstration of the environmental keying discussed earlier.
The first sample comes from our incident response case, where a full forensic image of the compromised machine gave us access to the victim’s DPAPI keys, allowing us to trivially decrypt the payload using a Dissect9 shell:
It turns out the decrypted payload is another loader, which we named RemotePELoader.
RemotePELoader is decrypted from the DPAPI payload on disk and is responsible for retrieving the core module from a C2 server and loading it into memory. Both the loader and the core module share a configuration file stored on disk, and are designed to work as a pair, deployed together as part of the same installation. Upon execution, RemotePELoader spawns a thread that first applies evasion techniques, reads the configuration, and then enters a C2 polling loop. It has no RAT functionality of its own; its sole purpose is to load the next stage.
RemotePELoader applies two evasion techniques before performing any further actions. The first is HellsGate10 (specifically the TartarusGate11 variant), a technique that dynamically resolves Windows syscall numbers at runtime. It scans the loaded ntdll.dll for syscall stubs to obtain the numbers for NtOpenSection, NtMapViewOfSection, NtUnmapViewOfSection, NtProtectVirtualMemory, and NtClose. Using these direct syscalls, RemotePELoader iterates the Process Environment Block’s module list and remaps each DLL from its \KnownDlls section object, a kernel-maintained mapping of trusted system DLLs, replacing any hooked in-memory copies with clean ones and effectively unhooking all userland security product hooks.
The second is patching Event Tracing for Windows (ETW), a Windows mechanism used by security products to monitor process behaviour at runtime. RemotePELoader patches function EtwEventWrite() in the current process using a well-known technique, overwriting it with the following bytes.
48 33 c0 ; XOR RAX, RAX c3 ; RET
Listing 2: Bytes written to EtwEventWrite to disable ETW event generation
This causes EtwEventWrite to immediately return 0, suppressing all ETW event generation and preventing security tooling that relies on ETW telemetry from receiving events.
Together, these two techniques hinder detection by endpoint security products that rely on userland API hooking or ETW telemetry.
After applying evasion techniques, RemotePELoader reads a configuration file using the same wildcard search as DPAPILoader:\??\C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US*.*
The configuration file is smaller than the encrypted RemotePELoader payload, so it identifies it by looking for a file that does not begin with Cabinet magic bytes and is smaller than 20480 bytes (20 KiB). When found, it decrypts the contents using DPAPI and XORs all bytes with 0x8D.
The configuration file structure is depicted in Listing 3.
struct RemotePEC2Config // sizeof=0xb38
{
int dwReconnectMinutes; // minutes to wait after C2 session ends
int dwSleepUntilEpoch; // UNIX epoch wake-up timestamp
int dwSleepMin; // minimum sleep time between C2 polls
int dwSleepMax; // maximum sleep time between C2 polls
wchar_t wsC2Url_1[260]; // C2 URL (up to three)
wchar_t wsC2Url_2[260];
wchar_t wsC2Url_3[260];
wchar_t wsProxy[260]; // optional proxy address
char sProxyUserName[128]; // optional proxy username
char sProxyPassword[128]; // optional proxy password
wchar_t wsUserAgent[260]; // configurable HTTP user-agent string
};
Listing 3: RemotePE C2 configuration structure on disk
Since both RemotePELoader and the configuration file reside in the same directory, a size check is used to distinguish between them, without it, the configuration file could be mistakenly loaded as a PE, or the PE read as a configuration file. This shared logic, combined with the identical cryptographic scheme, further ties the two loaders together as a coordinated toolset.
After reading the configuration, RemotePELoader enters a loop until it receives a PE payload from the server. On the first run it sleeps until the configured wake-up timestamp and on subsequent iterations it sleeps for a random interval within the configured bounds. It then finds an active C2 server via a check-in request and keeps polling for a PE payload. If no payload is returned, it restarts the loop. Once a payload is received, it sends a confirmation request to the active C2, loads the retrieved PE payload using libpeconv, and exits the thread.
RemotePELoader communicates with the C2 server over HTTP, using POST requests. Host information is passed via the HTTP Cookie header, with a check-in request identified by the presence of at_check=true. The server responds with a JSON object where the odata.metadata key contains the C2 session ID. Once a session ID is obtained, subsequent requests replace the at_check cookie with ai_session, set to the session ID received from the server. The table below documents each cookie field used in the check-in request.
| Cookie name | Cookie value description |
|---|---|
| MSCC | Random buffer with regex [0-9a-z]{24} prepended to the string “-c1=2-c2=2-c3=2” |
| MicrosoftApplicationsTelemetryDeviceId | Bot ID |
| MSFPC | Random numbers with format string “%08lx%08lx%08lx%08lx” |
| HASH | Random number with format string “%04x” |
| LV | Current year and month in YYYYMM format |
| V | Constant number |
| LU | Epoch of current time |
| MS0 | Random numbers with format string “%08lx%08lx%08lx%08lx”, likely to indicate RemotePELoader request |
| at_check | Indicates a check-in request (no session yet) |
| ai_session | Session ID from C2 after initial check-in |
Once a C2 session is established, RemotePELoader polls the server at random intervals between the configured minimum and maximum sleep times. In our tests, the server did not immediately return a payload, suggesting an actor-in-the-loop model where the operator manually decides when to deliver it. When the operator delivers the payload, the server returns a JSON object where the odata.metadata key contains the PE payload, AES-GCM encrypted and Base64-encoded.
All messages exchanged with the C2 server are AES-encrypted, except for the initial check-in response containing the session ID. The AES key and nonce for each message are derived using SplitMix64, seeded with a random value generated by a Mersenne Twister PRNG. Each message is structured as follows, with the seed prepended to the AES-GCM tag and ciphertext:
struct C2Message {
uint64_t aes_seed; // SplitMix64 seed for AES key and nonce
unsigned char aes_tag[16]; // AES authentication tag
unsigned char ciphertext[]; // AES-GCM encrypted data
};
Listing 4: C2 message structure used by RemotePELoader and RemotePE
The decrypted payload is RemotePE, a fully-fledged RAT that runs entirely in memory, covered in the next section.
RemotePE is a fully-fledged RAT that we retrieved directly from a RemotePELoader C2 server by emulating its C2 protocol.
Written in C++ using object-oriented programming, RemotePE is a multithreaded program that appears to share a codebase with RemotePELoader. Both components share the same on-disk configuration file, this is by design: if an operator updates the configuration and the host reboots, both components need to read the same updated values to maintain access. Furthermore, C2 logic, including session handling, AES-GCM encryption, and the C2Message structure are equal. Also, in the samples from our investigation, RemotePELoader and RemotePE each verify they were loaded by the previous stage by checking that lpReserved == 0x1000 in DllMain, enforcing the integrity of the chain.
RemotePE starts two threads at startup. The first, IChannelController, handles C2 communication. The second, IMiddleController, processes commands received from the C2 server. When the C2 server ends the current session, both threads stop and RemotePE either exits or sleeps until the configured wake-up time.
The IChannelController thread first locates an active C2 server and then polls it for commands. Between each polling iteration, the thread sleeps for a configured random interval, or wakes immediately if command output is available. In that case, the output is sent back to the C2 server without waiting for the next polling interval, allowing the operator to issue the next command promptly. Received commands are pushed to a queue consumed by IMiddleController.
The IMiddleController thread processes commands from the queue and pushes output back to a queue read by IChannelController. Each C2 message from the server consists of a list of entries delimited by $, where each entry is a bundle of commands (see the C2 Protocol section). Commands can optionally be executed in a separate thread, and all output is merged into a single reply sent back to the server.
While sleeping, RemotePE also checks for the existence of a Windows event named 554D5C1F-AABE-49E4-AB57-994D22ECED28. If present, it wakes immediately and restarts both controller threads. Neither RemotePE nor the loaders create this event, implying it is created externally as an out-of-band mechanism to wake RemotePE on demand.
RemotePE supports six categories of commands, identified by their C++ runtime type information (RTTI) class names. The table below lists each class along with the functionality it exposes. An operator invokes a function by specifying its class ID and function ID, along with any required parameters.
| Internal class name | Class ID | Function ID | Description |
|---|---|---|---|
IConfigProfile |
0 | 0 | Get the current C2 configuration |
| 1 | Set the C2 configuration | ||
IConsole |
1 | 0 | Get the current working directory |
| 1 | Change the current working directory | ||
| 2 | Execute a command and return its output | ||
| 3 | Get loaded modules (DLLs) | ||
| 4 | Register a new module (DLL) | ||
| 5 | Invoke a registered module’s function pointer with arguments | ||
| 6 | Unload a module (DLL) | ||
IFileExplorer |
2 | 0 | Get information on the drives of the system |
| 1 | List the files in a directory | ||
| 2 | Delete a file | ||
| 3 | Rename a file | ||
| 4 | Read from a file | ||
| 5 | Write to a file | ||
| 6 | ZIP a file or directory and return it as data | ||
IProcess |
3 | 0 | Get process listing |
| 1 | Kill process by ID | ||
| 2 | Search for a file in the directories of a given environment variable | ||
| 3 | Create a process | ||
| 4 | Create a process as a user | ||
ITimer |
4 | 0 | Sleep for X minutes, non-persistent |
| 1 | Sleep for X minutes, and persist this also in the C2 configuration on disk | ||
| 2 | Exit RemotePE | ||
IPing |
5 | N/a | A no-op command |
Most commands provide standard RAT functionality. One notable exception is the file deletion command, which overwrites each file with constant bytes seven times before renaming and deleting it, a secure deletion pattern consistent with PondRAT and POOLRAT, two malware families previously associated with this actor. Unlike some implementations that overwrite with random bytes, RemotePE uses constant bytes, though the multi-pass overwrite and rename pattern is shared.
RemotePE also implements a plugin system that allows the operator to dynamically register DLL payloads at runtime. These payloads must be valid both as a Windows DLL and as reflective shellcode, with the DLL entry point re-executed to unload them: a dual-format requirement and unload behaviour that matches pe_to_shellcode12 , which refers to such payloads as “shellcodified DLLs”. RemotePE can hold multiple plugins simultaneously, which the operator can invoke via the IConsole commands described above.
Similar to RemotePELoader, the IChannelController thread begins by locating an active C2 server via a check-in request, then polls it in a loop. The request format is largely identical to that of RemotePELoader, with one exception: RemotePE uses the MUID cookie instead of MS0, which the C2 server likely uses to differentiate between the two families. Session handling is identical to RemotePELoader. For a full description of cookie fields, see the RemotePELoader C2 Communication section.
Though RemotePE communicates with the same C2 server as RemotePELoader, the protocol diverges after the initial check-in. The outer message structure is identical to RemotePELoader’s C2Message (seed, AES-GCM tag, and ciphertext). The decrypted ciphertext, however, contains a RemotePE-specific structure, see Listing 5.
struct C2Command {
uint32_t payload_size;
uint16_t class_id; // class ID from the commands table
uint16_t function_id; // function ID from the commands table
uint32_t request_id; // used to match responses
unsigned char payload[]; // variable length, payload_size bytes
};
struct C2CommandBatch {
uint16_t command_count;
C2Command commands[]; // variable length, command_count entries
};
Listing 5: RemotePE C2 command structures
Command responses sent back to the server use the structures defined in Listing 6.
struct C2CommandResponse {
uint32_t response_size;
uint32_t error; // error code, if any
uint32_t request_id; // used to respond to a C2Command request
unsigned char payload[]; // variable length, compressed, response_size bytes
};
struct C2CommandResponseBatch {
uint16_t command_count;
C2CommandResponse commands[]; // variable length, command_count entries
};
Listing 6: RemotePE command output structures
When IChannelController receives a C2CommandBatch, it decrypts it and pushes the commands to the queue consumed by IMiddleController, as described in the Control Flow section. Command output is compressed using MSZIP via the Windows Cabinet compression API (cabinet.dll).
Figure 5 shows the C2 server command parsing of the IMiddleController thread. At first, command batches can be delimited by the “$”, where each command of a batch is traversed. After running the commands, all command outputs that were not run as a separate thread are merged into a C2 reply that is sent back to the server.
Command output is compressed, and the whole C2CommandResponseBatch structure is AES-GCM encrypted and Base64-encoded, before being sent back to the C2 server in the armAuthorization JSON key. An example of this is shown in Figure 6. The JSON keys and HTTP cookie names used within the C2 protocol, e.g., armAuthorization, odata.metadata, and MSFPC are also used within the Microsoft ecosystem.
armAuthorization JSON keyA example Python script to decrypt C2 command responses can be found here:
We obtained four RemotePE samples: three retrieved from active C2 servers and one recovered through forensic analysis. The C2 servers were identified during the incident response engagement or through fingerprinting. Ordering the samples by PE compile timestamp reveals incremental changes across versions, primarily in the config loading mechanism and bot identification method, suggesting active development between mid-2023 and mid-2024.
| PE timestamp | Config loading | Bot ID |
|---|---|---|
| 2023-07-04 | Find DPAPI encrypted config on disk | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2023-10-17 | C2 URLs passed via lpThreadParameter, fixed User-Agent | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2024-04-18 | Find DPAPI encrypted config on disk | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2024-05-11 | DPAPI config path passed via lpThreadParameter | Software\Microsoft\Cryptography\MachineGuid |
The 2023-10-17 sample does not use DPAPI and instead receives its C2 urls directly via lpThreadParameter, parsed using CommandLineToArgvW. Unlike the other samples, it also performs HellsGate syscall resolution and ETW patching itself, rather than relying on RemotePELoader to do so. This suggests that early versions of RemotePE were more standalone and not exclusively tied to the DPAPILoader/RemotePELoader chain, capable of being deployed by any loader passing the configuration as a thread parameter.
The table below shows the time between our initial check-in and RemotePE payload delivery across six successful retrieval sessions, along with the payload delivery time converted to Korea Standard Time (KST, UTC+9).
| C2 session started (UTC) | Payload returned (UTC) | Delta | Payload returned (KST,UTC+9) |
|---|---|---|---|
| 2024-02-07 00:21 | 2024-02-07 01:09 | 48 min | 2024-02-07 10:09 |
| 2024-12-09 08:48 | 2024-12-09 09:08 | 20 min | 2024-12-09 18:08 |
| 2024-12-10 23:57 | 2024-12-11 00:46 | 49 min | 2024-12-11 09:46 |
| 2025-01-10 08:21 | 2025-01-10 08:21 | 0 min | 2025-01-10 17:21 |
| 2025-02-10 21:56 | 2025-02-10 23:03 | 67 min | 2025-02-11 08:03 |
| 2025-07-09 11:57 | 2025-07-10 07:50 | 20 hrs | 2025-07-10 16:50 |
Many other sessions yielded no payload. All six successful payload deliveries fall within daytime hours in the UTC+9 timezone (08:00–19:00 KST), as shown in Table 5.
The RemotePE C2 infrastructure is hosted on Namecheap shared hosting, consistent with what we observed in earlier campaigns involving ThemeForestRAT and PondRAT. As with those campaigns, the use of shared hosting makes IP-based blocking ineffective, since the same server hosts legitimate domains.
Through fingerprinting of C2 server characteristics, we identified additional domains and servers beyond those found during the incident response engagement. These are listed in the IOCs section.
At the time of writing, several C2 servers we identified never returned a payload during our emulated sessions, though some remain live. Others that had previously delivered RemotePE appear to no longer do so. Whether this reflects the infrastructure going dormant, being abandoned, a change in C2 protocol, or the actor detecting unexpected connections is unclear.
The DPAPILoader, RemotePELoader, and RemotePE toolset represents a deliberate effort to minimise forensic footprint. A RemotePELoader sample from disk uploaded to VirusTotal is useless without the victim’s DPAPI keys. Furthermore, by combining environmental keying via DPAPI with fully in-memory execution of the final payload, the actor ensures that forensic imaging of the disk will not yield recoverable artifacts of RemotePE.
The actor-in-the-loop delivery model and the toolset’s low detection rate (neither RemotePELoader nor RemotePE appeared on VirusTotal prior to this publication) suggest this toolset may be reserved for high-value targets where long-term, stealthy access is the objective, consistent with this Lazarus subgroup’s known focus on financial and cryptocurrency organisations.
Defenders should focus on host-based detection. The most reliable indicators are DPAPI-encrypted blobs in unexpected directories, in our case this was the DeviceMetadataStore directory, though this can vary. Another indicator is to look for suspicious DLLs masquerading as legitimate Windows services or sideloaded DLLs.
For network-based detection, SNI fields and DNS queries for known C2 domains are the most actionable opportunities. Pivoting on Namecheap shared hosting infrastructure also proved effective in identifying additional malicious C2 servers during our investigation. Organisations with TLS inspection can detect the characteristic cookie fields and JSON keys, though care should be taken to avoid false positives given the traffic’s close resemblance to legitimate Microsoft traffic.
We are sharing the samples, including decrypted versions that would otherwise remain inaccessible due to environmental keying, both for preservation and to help defenders detect and respond to this toolset. YARA rules and IOCs are provided below.
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
| Domain | First seen | Last seen |
|---|---|---|
| livedrivefiles[.].com | 2023-07-17 | 2025-07-27 |
| aes-secure[.]net | 2023-09-18 | * |
| azureglobalaccelerator[.]com | 2023-09-18 | * |
| msdeliverycontent[.]com | 2024-02-19 | 2026-05-09 |
| akamaicloud[.]com | 2024-02-19 | 2025-02-14 |
| intelcloudinsights[.]com | 2024-04-13 | 2026-04-23 |
| devicelinkintel[.]com | 2024-08-16 | * |
| Type | Indicator | Comment |
|---|---|---|
| file.name | Iassvc.dll | Filename used for DPAPILoader |
| event.name | 554D5C1F-AABE-49E4-AB57-994D22ECED28 | RemotePE specific event name |
| digest.sha256 | Comment |
|---|---|
| 4f6ae0110cf652264293df571d66955f7109e3424a070423b5e50edc3eb43874 | DPAPILoader (Iassvc.dll) |
| aa4a2d1215f864481994234f13ab485b95150161b4566c180419d93dda7ac039 | DPAPILoader (wmiclnt.dll) |
| 159471e1abc9adf6733af9d24781fbf27a776b81d182901c2e04e28f3fe2e6f3 | DPAPILoader (sspicli.dll) |
| 7a05188ab0129b0b4f38e2e7599c5c52149ce0131140db33feb251d926428d68 | RemotePELoader (decrypted from disk) |
| 37f5afb9ed3761e73feb95daceb7a1fdbb13c8b5fc1a2ba22e0ef7994c7920ef | RemotePE (2023-07-04) |
| 6b33d20196267b0d64bca815ca863558d26b17cee77caf62a6cce8eae555ac8d | RemotePE (2023-10-17) |
| 62e040a32aac2d2faa8d2bffa2cf7ab662228cebf9bb78eaa0a633c0b729d119 | RemotePE (2024-04-18) |
| 710f15302859c7af1c1e25219d704841b3fdbc48f16a5a574d5ab6cf4f4842e8 | RemotePE (2024-05-11) |
rule Lazarus_DPAPILoader_Hunting {
meta:
description = "Hunting rule to detect DPAPILoader, a loader used to load RemotePE."
author = "Fox-IT / NCC Group"
strings:
$msg_1 = "[!] Could not allocate memory at the desired base!\n"
$msg_2 = "[!] Virtual section size is out ouf bounds: "
$msg_3 = "[!] Invalid relocDir pointer\n"
$msg_4 = "[-] Not supported relocations format at %d: %d\n"
$msg_5 = "[!] Cannot fill imports into 32 bit PE via 64 bit loader!\n"
condition:
any of them and pe.imports("Crypt32.dll", "CryptUnprotectData")
}
rule Lazarus_RemotePE_C2_strings {
meta:
description = "RemotePE strings used for C2."
author = "Fox-IT / NCC Group"
strings:
$a = "MicrosoftApplicationsTelemetryDeviceId" wide ascii xor
$b = "armAuthorization" wide ascii xor
$c = "ai_session" wide ascii xor
condition:
uint16(0) == 0x5A4D and all of them
}
rule Lazarus_RemotePE_class_strings {
meta:
description = "RemotePE class strings."
author = "Fox-IT / NCC Group"
strings:
$a = "IMiddleController" ascii wide xor
$b = "IChannelController" ascii wide xor
$c = "IConfigProfile" ascii wide xor
$d = "IKernelModule" ascii wide xor
condition:
all of them
}
rule Lazarus_RemotePE_DPAPI_Encrypted_config {
meta:
description = "Detects RemotePE DPAPI-encrypted config on disk"
author = "Fox-IT Security Research Team"
condition:
filesize == 3094
and uint32(0) == 0x00000001 // DPAPI blob version = 1
and uint32(0x8E) == 0x00000B40 // dwDataLen = 0xB40 (padded config)
}
Listing 7: YARA rules for DPAPILoader, RemotePELoader and RemotePE
︎︎︎︎︎︎︎︎︎︎︎︎
