In early April, we detected a significant increase in attacks that use banking Trojans of the QBot family (aka QakBot, QuackBot, and Pinkslipbot). The malware would be delivered through e-mail letters written in different languages — variations of them were coming in English, German, Italian, and French. The messages were based on real business letters the attackers had gotten access to, which afforded them the opportunity to join the correspondence thread with messages of their own. As a general rule, such letters would be urging the addressee — under a plausible pretext — to open an enclosed PDF file. As an example, they could be asking to provide all the documentation pertaining to the attached application or to calculate the contract value based on the attached cost estimate.

Example of a forwarded letter containing a malicious attachment

Such simulated business correspondence can obstruct spam tracking while increasing the probability of the victim falling for the trick. For authenticity, the attackers put the sender’s name from the previous letters in the ‘From’ field; however, the sender’s fraudulent e-mail address will be different from that of the real correspondent.

A short look at QBot

The banking Trojan QBot was detected for the first time in 2007. Since then, it has gone through multiple modifications and improvements to become one of the most actively spread malware in 2020. In 2021, we published a detailed QBot technical analysis. Currently the banker keeps getting new functions and module updates for increased effectiveness and profit.

QBot distribution methods have also evolved. Early on it was distributed through infected websites and pirated software. Now the banker is delivered to potential victims through malware already residing on their computers, social engineering, and spam mailings.

QBot infection chain

New QBot infection chain

The QBot malware delivery scheme begins with an e-mail letter with a PDF file in the attachment being sent. The document’s content imitates a Microsoft Office 365 or Microsoft Azure alert advising the user to click Open to view the attached files. If the user complies, an archive will be downloaded from a remote server (compromised site), protected with a password given in the original PDF file.

Examples of PDF attachments

In the downloaded archive there is a .wsf (Windows Script File) file containing an obfuscated script written in JScript.

Obfuscated JScript

After the WSF file is deobfuscated its true payload gets revealed: a PowerShell script encoded into a Base64 line.

Encoded PowerShell script

So, as soon as the user opens the WSF file from the archive, the PowerShell script will be discretely run on the computer and use wget to download a DLL file from a remote server. The library’s name is an automatically generated alphabetic sequence varying from one victim to another.

Decoded PowerShell script

The PowerShell script will try in succession to download the file from each one of the URLs listed in the code. To figure whether the download attempt was successful, the script will check the file size using the Get-Item command to get the information. If the file size is 100,000 bytes or more, the script will run the DLL with the help of rundll32. Otherwise, it will wait for four seconds before attempting to download the library using the next link down the list. The downloaded library is the Trojan known as QBot (detected as Trojan-Banker.Win32.Qbot.aiex).

Technical description of malicious DLL

We have analyzed the Qbot samples from the current e-mail campaign. The bot’s configuration block features company name “obama249” and time stamp “1680763529” (corresponding to April 6, 2023 6:45:29), as well as over a hundred IP addresses the bot will be using to connect to command servers. Most of these addresses belong to those users, whose infected systems provide an entry point into the chain which is used to redirect the botnet traffic to real command servers.

Qbot’s functionality hardly changed in the past couple of years. As before, the bot is capable of extracting passwords and cookies from browsers, stealing letters from your mailbox, intercepting traffic, and giving operators remote access to the infected system. Depending on the value of the victim, additional malware can be downloaded locally, such as CobaltStrike (to spread the infection through the corporate network) or various ransomware. Or else the victim’s computer can be turned into a proxy server to facilitate redirection of traffic, including spam traffic.

Statistics

We have analyzed the QBot attack statistics collected using Kaspersky Security Network (KSN). According to our data, the first letters with malicious PDF attachments began to arrive in the evening of April 4. The mass e-mail campaign began at 12:00 p.m. on the following day and continued until 9:00 p.m. During that time we detected an approximate total of 1,000 letters. The second upsurge began on April 6, again at noon, with over 1,500 letters dispatched to our customers this time. For the next few days new messages kept coming, and soon, on the evening of April 12 we discovered another upsurge with 2,000 more letters sent to our customers. After that cybercriminal activity went down, but users still receive fraudulent messages.

Geography of Qbot family attacks, April 1–11, 2023 (download)

In addition, we checked which countries were targeted by Qbot the most by relating the number of users attacked in a given country against the total number of users attacked worldwide. It turned out, the bank Trojan QBot was a more common issue for the residents of Germany (28.01%), Argentina (9.78%), and Italy (9.58%).

QBot is a well-known malware. Kaspersky solutions for consumers and for business use multi-layered approach, including Behavior Detection to detect and block this threat including the variant described in this article. All components of the attack are detected as HEUR:Trojan.PDF.QBot.gen, HEUR:Trojan.Script.Generic, Trojan-Banker.Win32.Qbot, and HEUR:Trojan-Dropper.Script.Qbot.gen, PDM:Trojan.Win32.Generic. Kaspersky solutions also detect and block most of the spam emails used in this attack.

Qbot indicators of compromise

MD5

PDF files
253E43124F66F4FAF23F9671BBBA3D98
39FD8E69EB4CA6DA43B3BE015C2D8B7D

ZIP archives
299FC65A2EECF5B9EF06F167575CC9E2
A6120562EB673552A61F7EEB577C05F8

WSF files
1FBFE5C1CD26C536FC87C46B46DB754D
FD57B3C5D73A4ECD03DF67BA2E48F661

DLL
28C25753F1ECD5C47D316394C7FCEDE2

Malicious links

ZIP archive
cica.com[.]co/stai/stai.php
abhishekmeena[.]in/ducs/ducs.php

DLL
rosewoodlaminates[.]com/hea/yWY9SJ4VOH
agtendelperu[.]com/FPu0Fa/EpN5Xvh
capitalperurrhh[.]com/vQ1iQg/u6oL8xlJ
centerkick[.]com/IC5EQ8/2v6u6vKQwk8
chimpcity[.]com/h7e/p5FuepRZjx
graficalevi.com[.]br/0p6P/R94icuyQ
kmphi[.]com/FWovmB/8oZ0BOV5HqEX
propertynear.co[.]uk/QyYWyp/XRgRWEdFv
theshirtsummit[.]com/MwBGSm/lGP5mGh

On March 29, Crowdstrike published a report about a supply chain attack conducted via 3CXDesktopApp, a popular VoIP program. Since then, the security community has started analyzing the attack and sharing their findings. The following has been discovered so far:

• The infection is spread via 3CXDesktopApp MSI installers. An installer for macOS has also been trojanized.
• The malicious installation package contains an infected dll library that decrypts a shellcode from the d3dcompiler_47.dll library’s overlay and executes it.
• The decrypted payload extracts C2 server URLs from icons stored in a GitHub repository (the repository is removed).
• The payload connects to one of the C2 servers, downloads an infostealer and starts it.
• The infostealer collects system information and browser history, then sends it to the C2 server.

As we reviewed available reports on the 3CX attack, we began wondering if the compromise concluded with the infostealer or further implants followed. To answer that question, we decided to review the telemetry we had on the campaign. On one of the machines, we observed a DLL named guard64.dll, which was loaded into the infected 3CXDesktopApp.exe process. Interestingly enough, we opened an investigation into a case linked to that DLL on March 21, about a week before the supply chain attack was discovered. A DLL with that name was used in recent deployments of a backdoor that we dubbed “Gopuram” and had been tracking internally since 2020. Three years ago, we were investigating an infection of a cryptocurrency company located in Southeast Asia. During the investigation, we found that Gopuram coexisted on victim machines with AppleJeus, a backdoor attributed to the Korean-speaking threat actor Lazarus.

Over the years, we observed few victims compromised with Gopuram, but the number of infections began to increase in March 2023. As it turned out, the increase was directly related to the 3CX supply chain attack. We found out that the threat actor specifically targeted cryptocurrency companies, dropping the following files on infected machines:

• C:\Windows\system32\wlbsctrl.dll, a malicious library (MD5: 9f85a07d4b4abff82ca18d990f062a84);
• C:\Windows\System32\config\TxR\<machine hardware profile GUID>.TxR.0.regtrans-ms, an encrypted shellcode payload.

Once dropped, wlbsctrl.dll becomes loaded on every startup by the IKEEXT service via DLL hijacking. We further saw DLLs with the names ualapi.dll and ncobjapi.dll being sideloaded into spoolsv.exe and svchost.exe, respectively.

The wlbsctrl.dll library is responsible for decrypting and executing the shellcode stored in the C:\Windows\System32\config\TxR directory. The decryption is notably performed through the CryptUnprotectData API function that uses a different encryption key internally on every machine. This makes it difficult for researchers to decrypt the payload from the file without physical access to the victim machines.

Snippet of the loading function using CryptUnprotectData

The component loaded by the library is Gopuram’s main module. As mentioned above, its name in the export directory is guard64.dll. The job of the main module is to connect to a C2 server and request commands. The backdoor implements commands that allow the attackers to interact with the victim’s file system and create processes on the infected machine. Gopuram was additionally observed to launch in-memory modules. Just like the implants used in the 3CX campaign, Gopuram’s modules are DLL files that include an export function named DllGetClassObject. We have observed nine modules so far:

The discovery of the new Gopuram infections allowed us to attribute the 3CX campaign to the Lazarus threat actor with medium to high confidence. Our attribution is based on the following facts:

• While investigating an attack on a Southeast Asian cryptocurrency company in 2020, we found Gopuram coexisting on the same machine with the AppleJeus backdoor, which is attributed to Lazarus.

• The Gopuram backdoor has been observed in attacks on cryptocurrency companies, which is aligned with the interests of the Lazarus threat actor.

• While looking for additional implants that used the same loader shellcode as the 3CX implants, we discovered a sample on a multiscanner service (MD5: 933508a9832da1150fcfdbc1ca9bc84c) loading a payload that uses the wirexpro[.]com C2 server. The same server is listed as an IoC for an AppleJeus campaign by Malwarebytes.

  

  First bytes of the loader shellcode used in 3CX and AppleJeus

  Note, though, that the shellcode is based on open-source code that has been used by other threat actors, for example, SilentBreak. Still, the use of that shellcode along with the 0xF558F4DA constant (which is the ROR13 hash for the string DllGetClassObject) is a more unique pattern.

• While investigating a malicious MSI file (MD5: ec3f99dd7d9dbce8d704d407b086e84f) that has been uploaded to a multiscanner service, we observed the following two events:

  • The dll library dropped from the MSI was observed to launch an in-memory payload that contacts the oilycargo[.]com domain. This domain name has previously been attributed to Lazarus by multiple researchers.

  • In our telemetry, we observed AvBugReport.exe, the executable hosting dll, to contain Gopuram’s main module payload, guard64.dll.

These four facts allow us to conclude that Lazarus is likely the threat actor deploying the Gopuram backdoor.

As for the victims in our telemetry, installations of the infected 3CX software are located all over the world, with the highest infection figures observed in Brazil, Germany, Italy and France.

As the Gopuram backdoor has been deployed to less than ten infected machines, it indicates that attackers used Gopuram with surgical precision. We additionally observed that the attackers have a specific interest in cryptocurrency companies.

As it turns out, the infostealer is not the only malicious payload deployed during the 3CX supply chain attack. The threat actor behind Gopuram additionally infects target machines with the full-fledged modular Gopuram backdoor. We believe that Gopuram is the main implant and the final payload in the attack chain. Our investigation of the 3CX campaign is still far from complete. We will continue analyzing the deployed implants to find out more details about the toolset used in the supply chain attack.

Gopuram indicators of compromise

MD5 hashes
9f85a07d4b4abff82ca18d990f062a84
96d3bbf4d2cf6bc452b53c67b3f2516a

File paths
C:\Windows\System32\config\TxR\<machine hardware profile GUID>.TxR.0.regtrans-ms
C:\Windows\system32\catroot2\edb.chk.log

More indicators of compromise and YARA rules for detecting Gopuram components are available for TIP subscribers. Contact intelreports@kaspersky.com for more details.

Summary

At the end of September, GTSC reported an attack on critical infrastructure that took place in August. During the investigation, experts found that two 0-day vulnerabilities in Microsoft Exchange Server were used in the attack. The first one, later identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability that allows an authenticated attacker to remotely trigger the next vulnerability – CVE-2022-41082. The second vulnerability, in turn, allows remote code execution (RCE) when MS Exchange PowerShell is accessible to the attacker. As noted in the GTSC report, both vulnerabilities were exploited together in the wild to create a backdoor on a vulnerable server, and perform lateral movement.

After CVE-2022-41040 and CVE-2022-41082 were revealed, Microsoft provided mitigation guidance followed by a few updates. According to the company, the vulnerabilities affect MS Exchange Server 2013, MS Exchange Server 2016 and MS Exchange Server 2019.

On October 11, 2022, Microsoft released patches to cover these vulnerabilities as part of its Patch Tuesday update. After that, on November 17, a security researcher published the first working PoC. It was a Python script that accepts the following parameters: user, password, mail address and command line to be executed on the victim’s host.

The cybersecurity community dubbed the pair of vulnerabilities ProxyNotShell. The name refers to a recent ProxyShell attack chain containing similar vulnerabilities in Exchange Servers that were disclosed in 2021. ProxyShell is a set of three vulnerabilities: CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207. Attackers used them to create web shells and execute arbitrary code on vulnerable Microsoft Exchange Servers.

ProxyNotShell exploitation details

The first step in this attack is exploiting CVE-2022-41040 to get access to the PowerShell API endpoint. Using an insufficient filtering of input data in the Exchange Autodiscover mechanism, an attacker with a known login and password combination for a registered account, can gain access to the privileged endpoint of the Exchange Server API (https://%exchange server domain%/powershell). This access allows the attacker to execute PowerShell commands in Exchange’s environment on the server machine, passing them in the payload via the XML SOAP protocol.

At the next step, the attacker must get access to Web-Based Enterprise Management (WBEM) via the WSMAN Protocol. The attacker initiates the shell on the vulnerable system for further PowerShell script execution via Windows Remote Management (PsRemoting).

HTTP POST request with XML SOAP to initiate PsRemoting

After initiation of the shell, the attacker should immediately extend its lifetime; otherwise, the shell will be closed as its expiration time is too short by default. This is necessary for further command execution on Exchange Server. To do that the attacker immediately sends a special request via WSMAN that enables the keep alive option.

HTTP POST request with XML SOAP to extend the shell’s lifetime

After that, the attacker exploits a second vulnerability – CVE-2022-41082. By using PowerShell Remoting the attacker sends a request to create an address book, passing encoded and serialized data with a special payload as a parameter. In a published PoC, this encoded data contains a gadget called System.UnitySerializationHolder that spawns an object of the System.Windows.Markup.XamlReader class. This class processes XAML data from a payload, which creates a new object of the System.Diagnostics class and contains a method call to open a new process on the target system. In the published PoC, this process is calc.exe.

HTTP POST request with XML SOAP to start new process

Main payload portion that executes the calc.exe process

ProxyNotShell post exploitation

A few weeks later after the vulnerability was disclosed, Kaspersky detected a successful exploitation of ProxyNotShell in the wild. The actor performed the following actions:

• Reconnaissance (users, groups, domains)
• Various hijack attempts (even dropping vulnerable binaries)
• Remote process injection
• Persistence
• Reverse shell

In this case, the attacker had the credentials to perform such an intrusion. They exploited the company’s Exchange Server and as a result were able to create any process they wanted on the Exchange machine, passing commands as a payload.

On the server side all processes that are started via exploitation have a main parent process with certain parameters: w3wp.exe -ap “msexchangepowershellapppool”.

These post-exploitation steps of the attack are very similar to the steps in the attack reported by TrendMicro, with the only difference being the vulnerabilities that are exploited.

Our products protect against all of these post exploitation steps as well as other attacks leveraging the CVE-2022-41040 and CVE-2022-41082 vulnerabilities. The detection name for ProxyNotShell is PDM:Exploit.Win32.Generic.

Our recommendations

A few words of advice to those worried about possible exploitation of ProxyNotShell or other 0-day vulnerabilities:

• Focus your defense strategy on detecting lateral movement and data exfiltration to the internet. Pay special attention to outgoing traffic to detect cybercriminal connections.
• Use the latest Threat Intelligence data to stay aware of actual TTPs used by threat actors.
• Use a security solution with exploit prevention, vulnerability and patch management components, such as Kaspersky Endpoint Security for Business. Our Exploit Prevention component monitors suspicious actions by applications and blocks the execution of malicious files.
• Use solutions like Kaspersky Endpoint Detection and Response and Kaspersky Managed Detection and Response that identify and stop attacks in the early stages.

Indicators of compromise

Overview

On September 10, 2022, a user reported on Zimbra’s official forums that their team detected a security incident originating from a fully patched instance of Zimbra. The details they provided allowed Zimbra to confirm that an unknown vulnerability allowed attackers to upload arbitrary files to up-to-date servers. At the moment, Zimbra has released a patch and shared its installation steps. In addition, manual mitigation steps can be undertaken by system administrators to prevent successful exploitation (see below).

Kaspersky investigated the threat and was able to confirm that unknown APT groups have actively been exploiting this vulnerability in the wild, one of which is systematically infecting all vulnerable servers in Central Asia.

On October 7, 2022, a proof of concept for this vulnerability was added to the Metasploit framework, laying the groundwork for massive and global exploitation from even low-sophistication attackers.

Vulnerability details

The vulnerability affects a component of the Zimbra suite called Amavis, and more specifically the cpio utility it uses to extract archives. The underlying cause is another vulnerability (CVE-2015-1197) in cpio, for which a fix is available. Inexplicably, distribution maintainers appear to have reverted the patch and use a vulnerable version instead. This creates a large attack surface where any software relying on cpio might in theory be leveraged to take over the system. CVE-2015-1197 is a directory traversal vulnerability: extracting specially crafted archives containing symbolic links can cause files to be placed at an arbitrary location in the file system.

In the context of CVE-2022-41352, the exploitation scenario unfolds as follows:

1. An attacker sends an e-mail with a malicious Tar archive attached.
2. On receiving the e-mail, Zimbra submits it to Amavis for spam and malware inspection.
3. Amavis analyzes the e-mail attachments and inspects the contents of the attached archive. It invokes cpio and CVE-2015-1197 is triggered.
4. During the extraction, a JSP webshell is deployed on one of the public directories used by the webmail component. The attacker can browse to the webshell to start executing arbitrary commands on the victim machine.

Mitigation

Since Zimbra released a patch for this vulnerability, the best course of action is to update your devices immediately. If this for some reason is not possible, installing pax on the machine hosting the Zimbra installation will prevent the vulnerability from being exploitable. pax is available from package managers (such as apt and yum) of all major Linux distributions. Among all Linux variants officially supported by Zimbra, only Ubuntu installs pax by default and is therefore not affected by CVE-2022-41352:

Please note that installing pax doesn’t address the root issue with any distribution, where other program paths both within and outside of Zimbra could still cause cpio to process untrusted data.

Detection

The vulnerability covered in this post was exploited during two successive attack waves. The first, taking place in early September, appears to have been relatively targeted and affected government targets in Asia. The second, which started on September 30, was much more massive in scope and went after all vulnerable servers located in specific Central Asian countries. Now that a proof of concept has been added to Metasploit, we expect a third wave to begin imminently, likely with ransomware as an end-goal this time.

After taking the aforementioned mitigation steps, owners of Zimbra servers are encouraged to check for traces of compromise. The following paths are known locations for webshells deployed by malicious actors currently leveraging CVE-2022-41352:

/opt/zimbra/jetty/webapps/zimbra/public/.error.jsp
/opt/zimbra/jetty/webapps/zimbra/public/ResourcesVerificaton.jsp
/opt/zimbra/jetty/webapps/zimbra/public/ResourceVerificaton.jsp
/opt/zimbra/jetty/webapps/zimbra/public/ZimletCore.jsp
/opt/zimbra/jetty/webapps/zimbra/public/searchx.jsp
/opt/zimbra/jetty/webapps/zimbra/public/seachx.jsp

In addition, it is worth noting that the Metasploit exploit drops its webshell in the following location:

/opt/zimbra/jetty_base/webapps/zimbra/[4-10 random characters].jsp

Remediation

If you discover one of these files on your Zimbra installation, please contact an incident response specialist as soon as possible. Removing the file is not enough. Performing disinfection on Zimbra is extremely difficult, as the attacker will have had access to configuration files containing passwords used by various service accounts. These credentials can be used to regain access to the server if the administrative panel is accessible from the internet. In addition, considering the rudimentary nature of all webshells we have discovered so far, it is almost certain that attackers will deploy more robust and sophisticated backdoors as soon as they get the chance.

Kaspersky products offer full coverage against this threat and block any attempt at exploiting CVE-2022-41352. We detect exploits using the vulnerability as HEUR:Exploit.Multi.CVE-2022-41352.gen. More information about the two attack waves is available via our Threat Intelligence reporting service, please contact intelreports@kaspersky.com for details.

On August 8, CheckPoint published a report on ten malicious Python packages in the Python Package Index (PyPI), the most popular Python repository among software developers. The malicious packages were intended to steal developers’ personal data and credentials.

Following this research, we used our internal automated system for monitoring open-source repositories and discovered two other malicious Python packages in the PyPI. They were masquerading as one of the most popular open-source packages named “requests“.

Timeline of uploaded packages:

The attacker used a description of the legitimate “requests” package in order to trick victims into installing a malicious one. The description contains faked statistics, as if the package was installed 230 million times in a month and has more than 48000 “stars” on GitHub. The project description also references the web pages of the original “requests” package, as well as the author’s email. All mentions of the legitimate package’s name have been replaced with the name of the malicious one.

After downloading the malicious packages, it becomes clear that the source code is nearly identical to the code of the legitimate “requests” package, except for one file: exception.py. In the malicious package, this script was last modified on July 30, exactly on the date of publication of the malicious package.

The malicious payload is a Base64-encoded Python script hidden in the “HTTPError” class. The script writes another Python one-liner script into a temporary file and then runs that file via the system.start() function. Then that one-liner script downloads the next-stage script from https://zerotwo-best-waifu[.]online/778112985743251/wap/enner/injector and executes it.

Downloader

The next stage is a downloader obfuscated with a publicly available tool named Hyperion. Obfuscation is done using multiple techniques, such as renaming variables and library functions, adding mixed boolean-arithmetic expressions and junk code, and compressing the code chunks with the zlib library.

The downloader terminates if the OS name is not “nt” (Windows). It randomly selects one of the directories under C:\Users\<username>\AppData\Roaming or C:\Users\<username>\AppData\Local, generates a random eight-characters string consisting of the “bcdefghijklmnopqrstuvwxyz” characters and randomly picks one of extensions from the following list:

['.dll', '.png', '.jpg', '.gay', '.ink', '.url', '.jar', '.tmp', '.db', '.cfg']

Then the malware downloads the final stage payload from https://zerotwo-best-waifu[.]online/778112985743251/wap/shatlegay/stealer123365, saves it to the previously generated location and executes it.

In order to achieve persistence on the infected machine, the malware creates a registry value with name “Realtek HD Audio Universal Service” in the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Windows system registry branch.

The script searches for an existing executable in the %system32% directory, named SecurityHealthSystray.exe or the SystemSettingsAdminFlows.exe, adds a “&” character (to ensure sequential execution in a command-line string), and then adds the location of the Python interpreter with the location of the malicious script. It is worth noting that this method does not work properly, as the system starts only the first executable, and the persistence is not actually achieved.

C:\Windows\System32\<SecurityHealthSystray.exe | SystemSettingsAdminFlows.exe> & <Python interpreter path> <generated path for dropped final payload>

Final payload: W4SP Stealer

The final payload is a Trojan written in Python and obfuscated with the same obfuscator as the downloader. The malware is dubbed “W4SP Stealer” by its author in the code.

Upon launching, the stealer identifies the external IP address of the victim’s machine by making a GET request to https://api.ipify.org and installs two legitimate PyPI packages – “requests” and “pycryptodome” in order to send exfiltrated data to the operator and work with cryptography for decrypting cookies and passwords from browsers. Then the malware starts collecting Discord tokens, saved cookies and passwords from browsers in separate threads.

Collected passwords and cookies are stored in the files %TEMP%\wppassw.txt and %TEMP%\wpcook.txt in the following format:

UR1: <URL> | U53RN4M3: <USERNAME> | P455W0RD: <DECRYPTED_PASSWORD>

H057 K3Y: <HOST_KEY> | N4M3: <NAME>| V41U3: <DECRYPTED_COOKIE>

All files created by the stealer on the victim’s machine start with the line: “<–W4SP STEALER ON TOP–>”.  All collected data is sent to the operator via a Discord webhook (https://discord[.]com/api/webhooks/1001296979948740648/4wqCErLU3BVeKWnxDA70Gns5vcfxh5OCb3YDIFZaFujqfSRIwHH4YIu3aLOVWjCDeO1H) and rendered in a prettified format:

The stealer also creates and sends a list of saved browser credentials for the URLs containing keywords “mail”, “card”, “bank”, “buy”, “sell”, etc. (see Appendix for a full list). Apart from that, it gathers data from the MetaMask, Atomic and Exodus wallets, as well as Steam and Minecraft credentials.

Having collected credentials, the stealer starts traversing the victim’s directories named Downloads, Documents and Desktop, looking for filenames containing the following words:

'passw', 'mdp', 'motdepasse', 'mot de passe', 'login', 'paypal', 
'banque', 'account', 'metamask', 'wallet', 'crypto', 'exodus', 
'discord', '2fa', 'code', 'memo', 'compte', 'token'

Interestingly, this list contains multiple French words: “mot de passe” (password), “mdp” (abbreviation for “mot de passe”), “banque” (bank), “compte” (account). The matching files are then uploaded to the same Discord channel.

The stealer also downloads a JavaScript payload from zerotwo-best-waifu[.]online/778112985743251/wap/dsc_injection, writing it into Discord’s index.js file. Then it kills the running discord.exe process, so that the user has to restart Discord, thus activating the payload.

subprocess.Popen('taskkill /im discord.exe /t /f',shell=true)

The injected script monitors the victim’s actions such, as changing their email address, password or billing information. The updated information is also sent to the Discord channel.

We have already reported these two packages to the PyPI security team and Snyk Vulnerability Database.

Kaspersky solutions detect the threat with the following verdicts:

• Trojan.Python.Inject.d
• Trojan.Python.Agent.gj

IOCs

Samples

URLs

https://zerotwo-best-waifu[.]online/778112985743251/wap/enner/injector
https://zerotwo-best-waifu[.]online/778112985743251/wap/shatlegay/stealer123365
https://zerotwo-best-waifu[.]online/778112985743251/wap/dsc_injection

Appendix

On July 26, using the internal automated system for monitoring open-source repositories, we identified four suspicious packages in the Node Package Manager (npm) repository. All these packages contained highly obfuscated malicious Python and JavaScript code. We dubbed this malicious campaign “LofyLife”.

Description of the proc-title package (Translation: This package correctly capitalizes your titles as per the Chicago manual of style)

The Python malware is a modified version of an open-source token logger called Volt Stealer. It is intended to steal Discord tokens from infected machines, along with the victim’s IP address, and upload them via HTTP. The JavaScript malware we dubbed “Lofy Stealer” was created to infect Discord client files in order to monitor the victim’s actions. It detects when a user logs in, changes email or password, enables/disables multi-factor authentication (MFA) and adds new payment methods, including complete bank card details. Collected information is also uploaded to the remote endpoint whose address is hard-coded.

Data is exfiltrated to Replit-hosted instances:

• life.polarlabs.repl[.]co
• Sock.polarlabs.repl[.]co
• idk.polarlabs.repl[.]co

Kaspersky solutions detect the threat with the following verdicts:

• HEUR:Trojan.Script.Lofy.gen
• Trojan.Python.Lofy.a

We are constantly monitoring the updates to repositories to ensure that all new malicious packages are detected.

Timeline of uploaded packages

We covered the incident in more detail in a private report delivered to customers of our Threat Intelligence Portal.

At the end of May, researchers from the nao_sec team reported a new zero-day vulnerability in Microsoft Support Diagnostic Tool (MSDT) that can be exploited using Microsoft Office documents. It allowed attackers to remotely execute code on Windows systems, while the victim could not even open the document containing the exploit, or open it in Protected Mode. The vulnerability, which the researchers dubbed Follina, later received the identifier CVE-2022-30190.

CVE-2022-30190 technical details

Briefly, the exploitation of the CVE-2022-30190 vulnerability can be described as follows. The attacker creates an MS Office document with a link to an external malicious OLE object (word/_rels/document.xml.rels), such as an HTML file located on a remote server. The data used to describe the link is placed in the tag with attributes Type=”http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject”, Target=”http_malicious_link!”. The link in the Target attribute points to the above-mentioned HTML file, inside which a malicious script is written using a special URI scheme.
When opened, the attacker-created document runs MSDT. The attacker can then pass, through a set of parameters, any command to this tool for execution on the victim’s system with the privileges of the user who opened the document. What is more, the command can be passed even if the document is opened in Protected Mode and macros are disabled.
At the time of posting, two document formats were known to allow CVE-2022-30190 exploitation: Microsoft Word (.docx) and Rich Text Format (.rtf). The latter is more dangerous for the potential victim because it allows execution of a malicious command even without opening the document — just previewing it in Windows Explorer is enough.

Protecting against Follina

Kaspersky is aware of attempts to exploit the CVE-2022-30190 vulnerability through Microsoft Office documents. Our solutions protect against this using the Behavior Detection and Exploit Prevention tools.
The following verdict names are possible:

• PDM:Exploit.Win32.Generic
• HEUR:Exploit.MSOffice.Agent.n
• HEUR:Exploit.MSOffice.Agent.gen
• HEUR:Exploit.MSOffice.CVE-2017-0199.a
• HEUR:Exploit.MSOffice.CVE-2021-40444.a
• HEUR:Exploit.MSOffice.Generic

Geography of Follina exploitation attempts with Exploit.MSOffice.CVE-2021-40444.a verdict, May 1 – June 3, 2022 (download)

We expect to see more Follina exploitation attempts to gain access to corporate resources, including for ransomware attacks and data breaches. Therefore, we continue to closely monitor the situation and improve overall vulnerability detection. In addition, as part of the Managed Detection and Response service, our SOC experts can detect vulnerability exploitation, investigate attacks and provide clients with all necessary threat-related information.
To protect against Follina exploitation, we strongly advise that you follow Microsoft’s own guidelines: Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability. In particular, to prevent exploitation of this vulnerability, you can disable support for the MSDT URL protocol by taking these steps:

1. Run Command Prompt as Administrator.
2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename”
3. Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

Last week researchers found the critical vulnerability CVE-2022-22965 in Spring – the open source Java framework. Using the vulnerability, an attacker can execute arbitrary code on a remote web server, which makes CVE-2022-22965 a critical threat, given the Spring framework’s popularity. By analogy with the infamous Log4Shell threat, the vulnerability was named Spring4Shell.

CVE-2022-22965 and CVE-2022-22963: technical details

CVE-2022-22965 (Spring4Shell, SpringShell) is a vulnerability in the Spring Framework that uses data binding functionality to bind data stored within an HTTP request to certain objects used by an application. The bug exists in the getCachedIntrospectionResults method, which can be used to gain unauthorized access to such objects by passing their class names via an HTTP request. It creates the risks of data leakage and remote code execution when special object classes are used. This vulnerability is similar to the long-closed CVE-2010-1622, where class name checks were added as a fix so that the name did not match classLoader or protectionDomain. However, in a newer version of JDK an alternative method exists for such exploitation, for example, through Java 9 Platform Module System functionality.
So an attacker can overwrite the Tomcat logging configuration and then upload a JSP web shell to execute arbitrary commands on a server running a vulnerable version of the framework.

A vulnerable configuration consists of:

• JDK version 9+
• Apache Tomcat for serving the application
• Spring Framework versions 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19 and below
• application built as a WAR file

CVE-2022-22963 is a vulnerability in the routing functionality of Spring Cloud Function that allows code injection through Spring Expression Language (SpEL) by adding a special spring.cloud.function.routing-expression header to an HTTP request. SpEL is a special expression language created for Spring Framework that supports queries and object graph management at runtime. This vulnerability can also be used for remote code execution.

A vulnerable configuration consists of:

• Spring Cloud Function 3.1.6, 3.2.2 and older versions

Mitigations for Spring vulnerabilities exploitation

CVE-2022-22965 is fixed in 2.6.6; see the Spring blog for details.

To fix CVE-2022-22963, you also need to install the new Spring Cloud Function versions; see the VMware website for details.

To detect exploitation attempts, ensure that Advanced Exploit Prevention and Network Attack Blocker features are enabled. Some techniques used during exploitation can be seen in other exploits that we detect, which is why the verdict names can differ.

Indicators of Compromise

Verdicts
PDM:Exploit.Win32.Generic
UMIDS:Intrusion.Generic.Agent.gen
Intrusion.Generic.CVE-*.*

MD5 hashes of the exploits
7e46801dd171bb5bf1771df1239d760c – shell.jsp (CVE-2022-22965)
3de4e174c2c8612aebb3adef10027679 – exploit.py (CVE-2022-22965)

Detection of the exploitation process with Kaspersky EDR Expert

Last week, security researcher Max Kellermann discovered a high severity vulnerability in the Linux kernel, which was assigned the designation CVE-2022-0847. It affects the Linux kernels from 5.8 through any version before 5.16.11, 5.15.25 and 5.10.102, and can be used for local privilege escalation. The vulnerability resides in the pipe tool, which is used for unidirectional communication between processes, so the researcher called it “Dirty Pipe”. Although the flaw is fixed in the latest Linux kernel versions, and, according to our data, there is no mass exploitation of this vulnerability at the moment, a detailed description and a working POC are available online, which increases the risk of this vulnerability being exploited by attackers.

Kaspersky products protect against attacks leveraging the Dirty Pipe vulnerability. The detection verdicts are:

• HEUR:Exploit.Linux.CVE-2022-0847.a
• HEUR:Exploit.Linux.CVE-2022-0847.b
• HEUR:Exploit.Linux.CVE-2022-0847.с
• HEUR:Exploit.Linux.CVE-2022-0847.gen

Dirty Pipe technical details

An unprivileged local user could use the Dirty Pipe flaw to write to pages in the page cache backed by read-only files and as such, escalate their privileges on the system. This vulnerability happens due to usage of partially uninitialized memory of the pipe buffer structure during its construction. A lack of zero initialization of the new structure’s member results in a stale value of flags, which can be abused by an attacker to gain write access to pages in the cache even if they originally were marked with a read-only attribute.

There are plenty of ways for attackers to gain the root privileges using this vulnerability, such as unauthorized creation of new cron jobs, SUID binary hijacking, /etc/passwd modification, and so on.

A working version of the Dirty Pipe exploit is already available on various security-related sites and repositories, so it can be used by attackers ITW.

Dirty Pipe mitigations

To ensure that your corporate infrastructure is protected against this and similar threats:

• Apply all relevant security updates once they are available. To patch CVE-2022-0847, update your Linux systems to versions 5.16.11, 5.15.25 and 5.10.102 or newer.
• Use a security solution that provides patch management and endpoint protection, such as Kaspersky Endpoint Security for Linux.
• Use the latest Threat Intelligence information to stay aware of actual TTPs used by threat actors.

IOCs (MD5 hashes of CVE-2022-0847 exploits)

ebc8f0556e031a0b1180cfdfe6bf6e03
c3662a101db6bd9edec35767c7b85741

Executive summary

On February 24, 2022, Avast Threat Research published a tweet announcing the discovery of new Golang ransomware, which they called HermeticRansom. This malware was found around the same time the HermeticWiper was found, and based on publicly available information from security community it was used in recent cyberattacks in Ukraine. The new ransomware was likely used as a smokescreen for the HermeticWiper attack due to its non-sophisticated style and poor implementation.

In this report, we present our analysis of HermeticRansom, which we also call Elections GoRansom.

Our findings in a nutshell:

• Elections GoRansom (aka HermeticRansom) was used to target assets on the same day as HermeticWiper;
• The developers used a sarcastic function-naming scheme related to US presidential elections;
• The malware does not use any kind of obfuscation and has pretty straightforward functionality, suggesting it was created in a short amount of time.

HermeticRansom’ technical analysis

The malware is created in Golang and uses no anti-analysis components as string encryption, function names stripping, etc. After execution, it creates an ID which is later used as the key from the array of Latin alphabet characters and numbers using a standard Golang rand function:

ID key generation routine

Then the malware identifies hard drives present on the infected system and collects a list of directories and files, excluding the Windows and Program Files folders.

Folder profiling

After that, the ransomware note is created as a “read_me .html” file and dropped to the user’s Desktop folder. The note contains the victim ID and the actor’s contact emails on the ProtonMail domain; emails are hard-coded as seen below:

Ransomware note in HTML format

The malware utilizes a strange ineffective encryption workflow – it creates a copies of the initial sample and runs them as separate processes for each file encrypted; copy names are generated using Golang GUID library functions.

Self-copies made by HermeticRansom

To encrypt victims’ data, HermeticRansom relies on a list of hard-coded files types, as follows:

List of hardcoded file extensions to encrypt

Files are encrypted using the AES algorithm with the generated key. Then the AES key is encrypted with RSA-OAEP. OAEP is parameterized with a hash function that is used as a random oracle. The hashing function is SHA-256. The RSA public key is hard-coded as a base64 blob. After decoding the key in JSON format, it is converted to a byte array:

Hardcoded encryption public key

Once files are encrypted, HermeticRansom appends a “.encryptedJB” extension to each. Also the ProtonMail email address is appended to the filename:

Encrypted files with the new extension

The malware structures and methods are named in a sarcastic manner related to US presidential elections.

Unstripped function names

HermeticRansom’ attribution

Given the circumstances under which HermeticRansom appeared, including the date, time and victims’ geo-locations, we have moderate confidence it is connected with HermeticWiper’s general objectives – destroying or otherwise making Windows systems unusable due to data loss.

Conclusions

HermeticRansom is an excellent example of a targeted attack preventing victims from using their data while also potentially acting as a smokescreen for further attacks. The simplicity of the code, along with the grammar and spelling errors left in the ransom note, probably indicate that it was a last-minute operation, potentially deployed to boost the effectiveness of other cyber-attacks on Ukraine.

Indicators of compromise

HermeticRansom MD5
d5d2c4ac6c724cd63b69ca054713e278