Our first story of 2026 revealed how a destructive new botnet called Kimwolf has infected more than two million devices by mass-compromising a vast number of unofficial Android TV streaming boxes. Today, we’ll dig through digital clues left behind by the hackers, network operators and services that appear to have benefitted from Kimwolf’s spread.
On Dec. 17, 2025, the Chinese security firm XLab published a deep dive on Kimwolf, which forces infected devices to participate in distributed denial-of-service (DDoS) attacks and to relay abusive and malicious Internet traffic for so-called “residential proxy” services.
The software that turns one’s device into a residential proxy is often quietly bundled with mobile apps and games. Kimwolf specifically targeted residential proxy software that is factory installed on more than a thousand different models of unsanctioned Android TV streaming devices. Very quickly, the residential proxy’s Internet address starts funneling traffic that is linked to ad fraud, account takeover attempts and mass content scraping.
The XLab report explained its researchers found “definitive evidence” that the same cybercriminal actors and infrastructure were used to deploy both Kimwolf and the Aisuru botnet — an earlier version of Kimwolf that also enslaved devices for use in DDoS attacks and proxy services.
XLab said it suspected since October that Kimwolf and Aisuru had the same author(s) and operators, based in part on shared code changes over time. But it said those suspicions were confirmed on December 8 when it witnessed both botnet strains being distributed by the same Internet address at 93.95.112[.]59.
Image: XLab.
Public records show the Internet address range flagged by XLab is assigned to Lehi, Utah-based Resi Rack LLC. Resi Rack’s website bills the company as a “Premium Game Server Hosting Provider.” Meanwhile, Resi Rack’s ads on the Internet moneymaking forum BlackHatWorld refer to it as a “Premium Residential Proxy Hosting and Proxy Software Solutions Company.”
Resi Rack co-founder Cassidy Hales told KrebsOnSecurity his company received a notification on December 10 about Kimwolf using their network “that detailed what was being done by one of our customers leasing our servers.”
“When we received this email we took care of this issue immediately,” Hales wrote in response to an email requesting comment. “This is something we are very disappointed is now associated with our name and this was not the intention of our company whatsoever.”
The Resi Rack Internet address cited by XLab on December 8 came onto KrebsOnSecurity’s radar more than two weeks before that. Benjamin Brundage is founder of Synthient, a startup that tracks proxy services. In late October 2025, Brundage shared that the people selling various proxy services which benefitted from the Aisuru and Kimwolf botnets were doing so at a new Discord server called resi[.]to.
On November 24, 2025, a member of the resi-dot-to Discord channel shares an IP address responsible for proxying traffic over Android TV streaming boxes infected by the Kimwolf botnet.
When KrebsOnSecurity joined the resi[.]to Discord channel in late October as a silent lurker, the server had fewer than 150 members, including “Shox” — the nickname used by Resi Rack’s co-founder Mr. Hales — and his business partner “Linus,” who did not respond to requests for comment.
Other members of the resi[.]to Discord channel would periodically post new IP addresses that were responsible for proxying traffic over the Kimwolf botnet. As the screenshot from resi[.]to above shows, that Resi Rack Internet address flagged by XLab was used by Kimwolf to direct proxy traffic as far back as November 24, if not earlier. All told, Synthient said it tracked at least seven static Resi Rack IP addresses connected to Kimwolf proxy infrastructure between October and December 2025.
Neither of Resi Rack’s co-owners responded to follow-up questions. Both have been active in selling proxy services via Discord for nearly two years. According to a review of Discord messages indexed by the cyber intelligence firm Flashpoint, Shox and Linus spent much of 2024 selling static “ISP proxies” by routing various Internet address blocks at major U.S. Internet service providers.
In February 2025, AT&T announced that effective July 31, 2025, it would no longer originate routes for network blocks that are not owned and managed by AT&T (other major ISPs have since made similar moves). Less than a month later, Shox and Linus told customers they would soon cease offering static ISP proxies as a result of these policy changes.
Shox and Linux, talking about their decision to stop selling ISP proxies.
The stated owner of the resi[.]to Discord server went by the abbreviated username “D.” That initial appears to be short for the hacker handle “Dort,” a name that was invoked frequently throughout these Discord chats.
Dort’s profile on resi dot to.
This “Dort” nickname came up in KrebsOnSecurity’s recent conversations with “Forky,” a Brazilian man who acknowledged being involved in the marketing of the Aisuru botnet at its inception in late 2024. But Forky vehemently denied having anything to do with a series of massive and record-smashing DDoS attacks in the latter half of 2025 that were blamed on Aisuru, saying the botnet by that point had been taken over by rivals.
Forky asserts that Dort is a resident of Canada and one of at least two individuals currently in control of the Aisuru/Kimwolf botnet. The other individual Forky named as an Aisuru/Kimwolf botmaster goes by the nickname “Snow.”
On January 2 — just hours after our story on Kimwolf was published — the historical chat records on resi[.]to were erased without warning and replaced by a profanity-laced message for Synthient’s founder. Minutes after that, the entire server disappeared.
Later that same day, several of the more active members of the now-defunct resi[.]to Discord server moved to a Telegram channel where they posted Brundage’s personal information, and generally complained about being unable to find reliable “bulletproof” hosting for their botnet.
Hilariously, a user by the name “Richard Remington” briefly appeared in the group’s Telegram server to post a crude “Happy New Year” sketch that claims Dort and Snow are now in control of 3.5 million devices infected by Aisuru and/or Kimwolf. Richard Remington’s Telegram account has since been deleted, but it previously stated its owner operates a website that caters to DDoS-for-hire or “stresser” services seeking to test their firepower.
Reports from both Synthient and XLab found that Kimwolf was used to deploy programs that turned infected systems into Internet traffic relays for multiple residential proxy services. Among those was a component that installed a software development kit (SDK) called ByteConnect, which is distributed by a provider known as Plainproxies.
ByteConnect says it specializes in “monetizing apps ethically and free,” while Plainproxies advertises the ability to provide content scraping companies with “unlimited” proxy pools. However, Synthient said that upon connecting to ByteConnect’s SDK they instead observed a mass influx of credential-stuffing attacks targeting email servers and popular online websites.
A search on LinkedIn finds the CEO of Plainproxies is Friedrich Kraft, whose resume says he is co-founder of ByteConnect Ltd. Public Internet routing records show Mr. Kraft also operates a hosting firm in Germany called 3XK Tech GmbH. Mr. Kraft did not respond to repeated requests for an interview.
In July 2025, Cloudflare reported that 3XK Tech (a.k.a. Drei-K-Tech) had become the Internet’s largest source of application-layer DDoS attacks. In November 2025, the security firm GreyNoise Intelligence found that Internet addresses on 3XK Tech were responsible for roughly three-quarters of the Internet scanning being done at the time for a newly discovered and critical vulnerability in security products made by Palo Alto Networks.
Source: Cloudflare’s Q2 2025 DDoS threat report.
LinkedIn has a profile for another Plainproxies employee, Julia Levi, who is listed as co-founder of ByteConnect. Ms. Levi did not respond to requests for comment. Her resume says she previously worked for two major proxy providers: Netnut Proxy Network, and Bright Data.
Synthient likewise said Plainproxies ignored their outreach, noting that the Byteconnect SDK continues to remain active on devices compromised by Kimwolf.
A post from the LinkedIn page of Plainproxies Chief Revenue Officer Julia Levi, explaining how the residential proxy business works.
Synthient’s January 2 report said another proxy provider heavily involved in the sale of Kimwolf proxies was Maskify, which currently advertises on multiple cybercrime forums that it has more than six million residential Internet addresses for rent.
Maskify prices its service at a rate of 30 cents per gigabyte of data relayed through their proxies. According to Synthient, that price range is insanely low and is far cheaper than any other proxy provider in business today.
“Synthient’s Research Team received screenshots from other proxy providers showing key Kimwolf actors attempting to offload proxy bandwidth in exchange for upfront cash,” the Synthient report noted. “This approach likely helped fuel early development, with associated members spending earnings on infrastructure and outsourced development tasks. Please note that resellers know precisely what they are selling; proxies at these prices are not ethically sourced.”
Maskify did not respond to requests for comment.
The Maskify website. Image: Synthient.
Hours after our first Kimwolf story was published last week, the resi[.]to Discord server vanished, Synthient’s website was hit with a DDoS attack, and the Kimwolf botmasters took to doxing Brundage via their botnet.
The harassing messages appeared as text records uploaded to the Ethereum Name Service (ENS), a distributed system for supporting smart contracts deployed on the Ethereum blockchain. As documented by XLab, in mid-December the Kimwolf operators upgraded their infrastructure and began using ENS to better withstand the near-constant takedown efforts targeting the botnet’s control servers.
An ENS record used by the Kimwolf operators taunts security firms trying to take down the botnet’s control servers. Image: XLab.
By telling infected systems to seek out the Kimwolf control servers via ENS, even if the servers that the botmasters use to control the botnet are taken down the attacker only needs to update the ENS text record to reflect the new Internet address of the control server, and the infected devices will immediately know where to look for further instructions.
“This channel itself relies on the decentralized nature of blockchain, unregulated by Ethereum or other blockchain operators, and cannot be blocked,” XLab wrote.
The text records included in Kimwolf’s ENS instructions can also feature short messages, such as those that carried Brundage’s personal information. Other ENS text records associated with Kimwolf offered some sage advice: “If flagged, we encourage the TV box to be destroyed.”
An ENS record tied to the Kimwolf botnet advises, “If flagged, we encourage the TV box to be destroyed.”
Both Synthient and XLabs say Kimwolf targets a vast number of Android TV streaming box models, all of which have zero security protections, and many of which ship with proxy malware built in. Generally speaking, if you can send a data packet to one of these devices you can also seize administrative control over it.
If you own a TV box that matches one of these model names and/or numbers, please just rip it out of your network. If you encounter one of these devices on the network of a family member or friend, send them a link to this story (or to our January 2 story on Kimwolf) and explain that it’s not worth the potential hassle and harm created by keeping them plugged in.
KrebsOnSecurity.com celebrates its 16th anniversary today! A huge “thank you” to all of our readers — newcomers, long-timers and drive-by critics alike. Your engagement this past year here has been tremendous and truly a salve on a handful of dark days. Happily, comeuppance was a strong theme running through our coverage in 2025, with a primary focus on entities that enabled complex and globally-dispersed cybercrime services.
Image: Shutterstock, Younes Stiller Kraske.
In May 2024, we scrutinized the history and ownership of Stark Industries Solutions Ltd., a “bulletproof hosting” provider that came online just two weeks before Russia invaded Ukraine and served as a primary staging ground for repeated Kremlin cyberattacks and disinformation efforts. A year later, Stark and its two co-owners were sanctioned by the European Union, but our analysis showed those penalties have done little to stop the Stark proprietors from rebranding and transferring considerable network assets to other entities they control.
In December 2024, KrebsOnSecurity profiled Cryptomus, a financial firm registered in Canada that emerged as the payment processor of choice for dozens of Russian cryptocurrency exchanges and websites hawking cybercrime services aimed at Russian-speaking customers. In October 2025, Canadian financial regulators ruled that Cryptomus had grossly violated its anti-money laundering laws, and levied a record $176 million fine against the platform.
In September 2023, KrebsOnSecurity published findings from researchers who concluded that a series of six-figure cyberheists across dozens of victims resulted from thieves cracking master passwords stolen from the password manager service LastPass in 2022. In a court filing in March 2025, U.S. federal agents investigating a spectacular $150 million cryptocurrency heist said they had reached the same conclusion.
Phishing was a major theme of this year’s coverage, which peered inside the day-to-day operations of several voice phishing gangs that routinely carried out elaborate, convincing, and financially devastating cryptocurrency thefts. A Day in the Life of a Prolific Voice Phishing Crew examined how one cybercrime gang abused legitimate services at Apple and Google to force a variety of outbound communications to their users, including emails, automated phone calls and system-level messages sent to all signed-in devices.
Nearly a half-dozen stories in 2025 dissected the incessant SMS phishing or “smishing” coming from China-based phishing kit vendors, who make it easy for customers to convert phished payment card data into mobile wallets from Apple and Google. In an effort to wrest control over this phishing syndicate’s online resources, Google has since filed at least two John Doe lawsuits targeting these groups and dozens of unnamed defendants.
In January, we highlighted research into a dodgy and sprawling content delivery network called Funnull that specialized in helping China-based gambling and money laundering websites distribute their operations across multiple U.S.-based cloud providers. Five months later, the U.S. government sanctioned Funnull, identifying it as a top source of investment/romance scams known as “pig butchering.”
Image: Shutterstock, ArtHead.
In May, Pakistan arrested 21 people alleged to be working for Heartsender, a phishing and malware dissemination service that KrebsOnSecurity first profiled back in 2015. The arrests came shortly after the FBI and the Dutch police seized dozens of servers and domains for the group. Many of those arrested were first publicly identified in a 2021 story here about how they’d inadvertently infected their computers with malware that gave away their real-life identities.
In April, the U.S. Department of Justice indicted the proprietors of a Pakistan-based e-commerce company for conspiring to distribute synthetic opioids in the United States. The following month, KrebsOnSecurity detailed how the proprietors of the sanctioned entity are perhaps better known for operating an elaborate and lengthy scheme to scam westerners seeking help with trademarks, book writing, mobile app development and logo designs.
Earlier this month, we examined an academic cheating empire turbocharged by Google Ads that earned tens of millions of dollars in revenue and has curious ties to a Kremlin-connected oligarch whose Russian university builds drones for Russia’s war against Ukraine.
An attack drone advertised on a website hosted in the same network as Russia’s largest private education company — Synergy University.
As ever, KrebsOnSecurity endeavored to keep close tabs on the world’s biggest and most disruptive botnets, which pummeled the Internet this year with distributed denial-of-service (DDoS) assaults that were two to three times the size and impact of previous record DDoS attacks.
In June, KrebsOnSecurity.com was hit by the largest DDoS attack that Google had ever mitigated at the time (we are a grateful guest of Google’s excellent Project Shield offering). Experts blamed that attack on an Internet-of-Things botnet called Aisuru that had rapidly grown in size and firepower since its debut in late 2024. Another Aisuru attack on Cloudflare just days later practically doubled the size of the June attack against this website. Not long after that, Aisuru was blamed for a DDoS that again doubled the previous record.
In October, it appeared the cybercriminals in control of Aisuru had shifted the botnet’s focus from DDoS to a more sustainable and profitable use: Renting hundreds of thousands of infected Internet of Things (IoT) devices to proxy services that help cybercriminals anonymize their traffic.
However, it has recently become clear that at least some of the disruptive botnet and residential proxy activity attributed to Aisuru last year likely was the work of people responsible for building and testing a powerful botnet known as Kimwolf. Chinese security firm XLab, which was the first to chronicle Aisuru’s rise in 2024, recently profiled Kimwolf as easily the world’s biggest and most dangerous collection of compromised machines — with approximately 1.83 million devices under its thumb as of December 17.
XLab noted that the Kimwolf author “shows an almost ‘obsessive’ fixation on the well-known cybersecurity investigative journalist Brian Krebs, leaving easter eggs related to him in multiple places.”
Image: XLab, Kimwolf Botnet Exposed: The Massive Android Botnet with 1.8 million infected devices.
I am happy to report that the first KrebsOnSecurity stories of 2026 will go deep into the origins of Kimwolf, and examine the botnet’s unique and highly invasive means of spreading digital disease far and wide. The first in that series will include a somewhat sobering and global security notification concerning the devices and residential proxy services that are inadvertently helping to power Kimwolf’s rapid growth.
Thank you once again for your continued readership, encouragement and support. If you like the content we publish at KrebsOnSecurity.com, please consider making an exception for our domain in your ad blocker. The ads we run are limited to a handful of static images that are all served in-house and vetted by me (there is no third-party content on this site, period). Doing so would help further support the work you see here almost every week.
And if you haven’t done so yet, sign up for our email newsletter! (62,000 other subscribers can’t be wrong, right?). The newsletter is just a plain text email that goes out the moment a new story is published. We send between one and two emails a week, we never share our email list, and we don’t run surveys or promotions.
Thanks again, and Happy New Year everyone! Be safe out there.
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked decreased from the previous quarter by 0.4 pp to 20.1%. This is the lowest level for the observed period.
Percentage of ICS computers on which malicious objects were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 9.2% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage increased in five regions. The most notable increase occurred in East Asia, triggered by the local spread of malicious scripts in the OT infrastructure of engineering organizations and ICS integrators.
Changes in the percentage of ICS computers on which malicious objects were blocked, Q3 2025
The biometrics sector traditionally led the rankings of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.
Rankings of industries and OT infrastructures by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked increased in four of the seven surveyed industries. The most notable increases were in engineering and ICS integrators, and manufacturing.
Percentage of ICS computers on which malicious objects were blocked in selected industries
In Q3 2025, Kaspersky protection solutions blocked malware from 11,356 different malware families of various categories on industrial automation systems.
Percentage of ICS computers on which the activity of malicious objects of various categories was blocked
In Q3 2025, there was a decrease in the percentage of ICS computers on which denylisted internet resources and miners of both categories were blocked. These were the only categories that exhibited a decrease.
Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).
The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.
In Q3 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased.
Percentage of ICS computers on which malicious objects from various sources were blocked
The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of threats from the source itself.
Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including technological infrastructures.
In Q3 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 4.01%. This is the lowest quarterly figure since the beginning of 2022.
Percentage of ICS computers on which denylisted internet resources were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 2.35% in Australia and New Zealand to 4.96% in Africa. Southeast Asia and South Asia were also among the top three regions for this indicator.
The percentage of ICS computers on which malicious documents were blocked has grown for three consecutive quarters, following a decline at the end of 2024. In Q3 2025, it reached 1,98%.
Percentage of ICS computers on which malicious documents were blocked, Q3 2022–Q3 2025
The indicator increased in four regions: South America, East Asia, Southeast Asia, and Australia and New Zealand. South America saw the largest increase as a result of a large-scale phishing campaign in which attackers used new exploits for an old vulnerability (CVE-2017-11882) in Microsoft Office Equation Editor to deliver various spyware to victims’ computers. It is noteworthy that the attackers in this phishing campaign used localized Spanish-language emails disguised as business correspondence.
In Q3 2025, the percentage of ICS computers on which malicious scripts and phishing pages were blocked increased to 6.79%. This category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.
Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious scripts and phishing pages were blocked ranged from 2.57% in Northern Europe to 9.41% in Africa. The top three regions for this indicator were Africa, East Asia, and South America. The indicator increased the most in East Asia (by a dramatic 5.23 pp) as a result of the local spread of malicious spyware scripts loaded into the memory of popular torrent clients including MediaGet.
Malicious objects used to initially infect computers deliver next-stage malware — spyware, ransomware, and miners — to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.
In Q3 2025, the percentage of ICS computers on which spyware and ransomware were blocked increased. The rates were:
The percentage of ICS computers on which miners of both categories were blocked decreased. The rates were:
Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.
To spread across ICS networks, viruses and worms rely on removable media and network folders in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.
In Q3 2025, the percentage of ICS computers on which worms and viruses were blocked increased to 1.26% (by 0.04 pp) and 1.40% (by 0.11 pp), respectively.
This category of malware can spread in a variety of ways, so it does not belong to a specific group.
In Q3 2025, the percentage of ICS computers on which AutoCAD malware was blocked slightly increased to 0.30% (by 0.01 pp).
For more information on industrial threats see the full version of the report.
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked decreased from the previous quarter by 0.4 pp to 20.1%. This is the lowest level for the observed period.
Percentage of ICS computers on which malicious objects were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 9.2% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage increased in five regions. The most notable increase occurred in East Asia, triggered by the local spread of malicious scripts in the OT infrastructure of engineering organizations and ICS integrators.
Changes in the percentage of ICS computers on which malicious objects were blocked, Q3 2025
The biometrics sector traditionally led the rankings of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.
Rankings of industries and OT infrastructures by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked increased in four of the seven surveyed industries. The most notable increases were in engineering and ICS integrators, and manufacturing.
Percentage of ICS computers on which malicious objects were blocked in selected industries
In Q3 2025, Kaspersky protection solutions blocked malware from 11,356 different malware families of various categories on industrial automation systems.
Percentage of ICS computers on which the activity of malicious objects of various categories was blocked
In Q3 2025, there was a decrease in the percentage of ICS computers on which denylisted internet resources and miners of both categories were blocked. These were the only categories that exhibited a decrease.
Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).
The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.
In Q3 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased.
Percentage of ICS computers on which malicious objects from various sources were blocked
The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of threats from the source itself.
Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including technological infrastructures.
In Q3 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 4.01%. This is the lowest quarterly figure since the beginning of 2022.
Percentage of ICS computers on which denylisted internet resources were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 2.35% in Australia and New Zealand to 4.96% in Africa. Southeast Asia and South Asia were also among the top three regions for this indicator.
The percentage of ICS computers on which malicious documents were blocked has grown for three consecutive quarters, following a decline at the end of 2024. In Q3 2025, it reached 1,98%.
Percentage of ICS computers on which malicious documents were blocked, Q3 2022–Q3 2025
The indicator increased in four regions: South America, East Asia, Southeast Asia, and Australia and New Zealand. South America saw the largest increase as a result of a large-scale phishing campaign in which attackers used new exploits for an old vulnerability (CVE-2017-11882) in Microsoft Office Equation Editor to deliver various spyware to victims’ computers. It is noteworthy that the attackers in this phishing campaign used localized Spanish-language emails disguised as business correspondence.
In Q3 2025, the percentage of ICS computers on which malicious scripts and phishing pages were blocked increased to 6.79%. This category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.
Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious scripts and phishing pages were blocked ranged from 2.57% in Northern Europe to 9.41% in Africa. The top three regions for this indicator were Africa, East Asia, and South America. The indicator increased the most in East Asia (by a dramatic 5.23 pp) as a result of the local spread of malicious spyware scripts loaded into the memory of popular torrent clients including MediaGet.
Malicious objects used to initially infect computers deliver next-stage malware — spyware, ransomware, and miners — to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.
In Q3 2025, the percentage of ICS computers on which spyware and ransomware were blocked increased. The rates were:
The percentage of ICS computers on which miners of both categories were blocked decreased. The rates were:
Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.
To spread across ICS networks, viruses and worms rely on removable media and network folders in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.
In Q3 2025, the percentage of ICS computers on which worms and viruses were blocked increased to 1.26% (by 0.04 pp) and 1.40% (by 0.11 pp), respectively.
This category of malware can spread in a variety of ways, so it does not belong to a specific group.
In Q3 2025, the percentage of ICS computers on which AutoCAD malware was blocked slightly increased to 0.30% (by 0.01 pp).
For more information on industrial threats see the full version of the report.
Recently, the Cybersecurity and Infrastructure Security Agency (CISA) added (along with two others) a vulnerability in ASUS Live Update to its catalog of Known Exploited Vulnerabilities (KEV).
The KEV catalog lists vulnerabilities that are known to be exploited in the wild and sets patch deadlines for Federal Civilian Executive Branch (FCEB) agencies. When CISA adds an issue to this list, it’s a strong signal that exploitation is real, ongoing, and urgent.
The ASUS Live Update Embedded Malicious Code vulnerability, tracked as CVE-2025-59374 (with a CVSS score of 9.3), affects Live Update, a utility commonly used to deliver firmware and software updates to ASUS devices.
This isn’t the first time ASUS Live Update has been linked to serious security incidents. In 2019, ASUS responded to media reports about attacks on the Live Update tool by advanced persistent threat (APT) groups, stating that:
“A small number of devices have been implanted with malicious code through a sophisticated attack on our Live Update servers in an attempt to target a very small and specific user group.”
Later investigations revealed that a sophisticated supply chain attack mounted in 2018, attributed to Chinese state-sponsored attackers, had inserted a backdoor into ASUS Live Update. The attack was particularly effective because that utility came preinstalled on most ASUS devices and was used to the automatically update BIOS, UEFI, drivers, and other components.
CISA now notes that the affected devices could be abused to perform unintended actions if certain conditions are met. Originally, the attackers reportedly targeted only around 600 specific devices, based on hashed MAC addresses hardcoded in various versions of the tool. This was despite the fact that millions of users may have downloaded the backdoored utility.
Support for the ASUS Live Update application has since been discontinued. The final intended version of ASUS Live Update was 3.6.15, but it will continue to provide software updates. This is likely why a CVE was assigned and why the vulnerability was added to the KEV catalog. There was no official “why now” statement from ASUS, MITRE, or CISA, but the timing aligns with a legacy, end-of-support product being reclassified as a vulnerability with confirmed active exploitation.
First of all, make sure you’re running a clean version of the utility. ASUS urges users to update to version 3.6.8 or later to address known security issues.
Alternatively, you can download and install the latest version manually. ASUS’ own support article describes the only official way to get the current Live Update package:
This is as close as we could get you to a “direct” official download. The URL is different for every model and ASUS does not provide a central Live Update installer directory. While this makes it harder than it maybe should be, we do recommend using this official download. Given the history of supply chain abuse involving this tool, downloading it from third-party sources is a risk not worth taking.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Recently, the Cybersecurity and Infrastructure Security Agency (CISA) added (along with two others) a vulnerability in ASUS Live Update to its catalog of Known Exploited Vulnerabilities (KEV).
The KEV catalog lists vulnerabilities that are known to be exploited in the wild and sets patch deadlines for Federal Civilian Executive Branch (FCEB) agencies. When CISA adds an issue to this list, it’s a strong signal that exploitation is real, ongoing, and urgent.
The ASUS Live Update Embedded Malicious Code vulnerability, tracked as CVE-2025-59374 (with a CVSS score of 9.3), affects Live Update, a utility commonly used to deliver firmware and software updates to ASUS devices.
This isn’t the first time ASUS Live Update has been linked to serious security incidents. In 2019, ASUS responded to media reports about attacks on the Live Update tool by advanced persistent threat (APT) groups, stating that:
“A small number of devices have been implanted with malicious code through a sophisticated attack on our Live Update servers in an attempt to target a very small and specific user group.”
Later investigations revealed that a sophisticated supply chain attack mounted in 2018, attributed to Chinese state-sponsored attackers, had inserted a backdoor into ASUS Live Update. The attack was particularly effective because that utility came preinstalled on most ASUS devices and was used to the automatically update BIOS, UEFI, drivers, and other components.
CISA now notes that the affected devices could be abused to perform unintended actions if certain conditions are met. Originally, the attackers reportedly targeted only around 600 specific devices, based on hashed MAC addresses hardcoded in various versions of the tool. This was despite the fact that millions of users may have downloaded the backdoored utility.
Support for the ASUS Live Update application has since been discontinued. The final intended version of ASUS Live Update was 3.6.15, but it will continue to provide software updates. This is likely why a CVE was assigned and why the vulnerability was added to the KEV catalog. There was no official “why now” statement from ASUS, MITRE, or CISA, but the timing aligns with a legacy, end-of-support product being reclassified as a vulnerability with confirmed active exploitation.
First of all, make sure you’re running a clean version of the utility. ASUS urges users to update to version 3.6.8 or later to address known security issues.
Alternatively, you can download and install the latest version manually. ASUS’ own support article describes the only official way to get the current Live Update package:
This is as close as we could get you to a “direct” official download. The URL is different for every model and ASUS does not provide a central Live Update installer directory. While this makes it harder than it maybe should be, we do recommend using this official download. Given the history of supply chain abuse involving this tool, downloading it from third-party sources is a risk not worth taking.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Operators behind RansomHouse, a ransomware-as-a-service (RaaS) group, have upgraded their encryption methods from single-phase to complex and layered.
The post From Linear to Complex: An Upgrade in RansomHouse Encryption appeared first on Unit 42.
Hamas-affiliated threat actor Ashen Lepus (aka WIRTE) is conducting espionage with its new AshTag malware suite against Middle Eastern government entities.
The post Hamas-Affiliated Ashen Lepus Targets Middle Eastern Diplomatic Entities With New AshTag Malware Suite appeared first on Unit 42.
Unit 42 outlines a Howling Scorpius attack delivering Akira ransomware that originated from a fake CAPTCHA and led to a 42-day compromise.
The post Anatomy of an Akira Ransomware Attack: When a Fake CAPTCHA Led to 42 Days of Compromise appeared first on Unit 42.
Authors: Yun Zheng Hu and Mick Koomen
In the past few years, Fox-IT and NCC Group have conducted multiple incident response cases involving a Lazarus subgroup that specifically targets organizations in the financial and cryptocurrency sector. This Lazarus subgroup overlaps with activity linked to AppleJeus1, Citrine Sleet2, UNC47363, and Gleaming Pisces4. This actor uses different remote access trojans (RATs) in their operations, known as PondRAT5, ThemeForestRAT and RemotePE. In this article, we analyse and discuss these three.
First, we describe an incident response case from 2024, where we observed the three RATs. This gives insights into the tactics, techniques, and procedures (TTPs) of this actor. Then, we discuss PondRAT, ThemeForestRAT and RemotePE, respectively.
PondRAT received quite some attention last year, we give a brief overview of the malware and document other similarities between PondRAT and POOLRAT (also known as SimpleTea) that have not yet been publicly documented. Secondly, we discuss ThemeForestRAT, a RAT that has been in use for at least six years now, but has not yet been discussed publicly. These two malware families were used in conjunction, where PondRAT was on disk and ThemeForestRAT seemed to only run in memory.
Lastly, we briefly describe RemotePE, a more advanced RAT of this group. We found evidence that the actor cleaned up PondRAT and ThemeForestRAT artifacts and subsequently installed RemotePE, potentially signifying a next stage in the attack. We cannot directly link RemotePE to any public malware family at the time of this writing.
In all cases, the actor used social engineering as an initial access vector. In one case, we suspect a zero-day might have been used to achieve code execution on one of the victim’s machines. We think this highlights their advanced capabilities, and with their history of activity, also shows their determination.
In 2024, Fox-IT investigated an incident at an organisation in decentralized finance (DeFi). There, an employee’s machine was compromised through social engineering. From there, the actor performed discovery from inside the network using different RATs in combination with other tools, for example, to harvest credentials or proxy connections. Afterwards, the actor moved to a stealthier RAT, likely signifying a next stage in the attack.
In Figure 1, we provide an overview of the attack chain, where we highlight four phases of the attack:
We found traces matching a social engineering technique previously described by SlowMist6. This social engineering campaign targets employees of companies active in the cryptocurrency sector by posing as employees of investment institutions on Telegram.
This Lazarus subgroup uses fake Calendly and Picktime websites, including fake websites of the organisations they impersonate. We found traces of two impersonated employees of two different companies. We did not observe any domains linked to the “Access Restricted” trick as described by SlowMist. In Figure 2, you can see a Telegram message from the actor, impersonating an existing employee of a trading company. Looking up the impersonated person, showed that the person indeed worked at the trading company.
From the forensic data, we could not establish a clear initial access vector. We suspect a Chrome zero-day exploit was used. Although, we have no actual forensic data to back up this claim, we did notice changes in endpoint logging behaviour. Around the time of compromise, we noted a sudden decrease in the logging of the endpoint detection agent that was running on the machine. Later, Microsoft published a blogpost7, describing Citrine Sleet using a zero-day Chrome exploit to launch an evasive rootkit called FudModule8, which could explain this behaviour.
The actor leveraged the SessionEnv service for persistence. This existing Windows service is vulnerable to phantom DLL loading9. A custom TSVIPSrv.dll can be placed inside the %SystemRoot%\System32\ directory, which SessionEnv will load upon startup. The actor placed its own loader in this directory, which we refer to as PerfhLoader. Persistence was ensured by making the service start automatically at reboot using the following command:
sc config sessionenv start=auto
The actor also modified the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SessionEnv\RequiredPrivileges registry key by adding SeDebugPrivilege and SeLoadDriverPrivilege privileges. These elevated privileges enable loading kernel drivers, which can bypass or disable Endpoint Detection and Response (EDR) tools on the compromised system.
In a case from 202010, this actor used the IKEEXT service for phantom DLL loading, writing PerfhLoader to the path %SystemRoot%\System32\wlbsctrl.dll. The vulnerable VIAGLT64.SYS kernel driver (CVE-2017-16237) was also used to gain SYSTEM privileges.
PerfhLoader is a simple loader that reads a file with a hardcoded filename (perfh011.dat) from its current directory, decrypts its contents, loads it into memory and executes it. In all observed cases, both PerfhLoader and the encrypted DLL were in the %SystemRoot%\System32\ folder. Normally, perfhXXX.dat files located in this folder contain Windows Performance Monitor data, which makes it blend in with normal Windows file names.
The cipher used to encrypt and decrypt the payload uses a rolling XOR key, we denote the implementation in Python code in Listing 1.
Login
def crypt_buf(data: bytes) -> bytes:
xor_key = bytearray(range(0x10))
buf = bytearray(data)
for idx in range(len(buf)):
a = xor_key[(idx + 5) & 0xF]
b = xor_key[(idx - 3) & 0xF]
c = xor_key[(idx - 7) & 0xF]
xor_byte = a ^ b ^ c
buf[idx] ^= xor_byte
xor_key[idx & 0xF] = xor_byte
return bytes(buf)
Listing 1: Python implementation of the XOR cipher used by PerfhLoader
The decrypted content contains a DLL that PerfhLoader loads into memory using the Manual-DLL-Loader project11. Interestingly, PondRAT uses this same project for DLL loading.
After establishing a foothold, the actor deployed various tools in combination with the RATs described earlier. These included both custom tooling and publicly available tools. Table 1 lists some of the tools we recovered that the actor used.
| Tool | Tool Origin | Description |
|---|---|---|
| Screenshotter | Actor | A tool that takes periodic screenshots and stores them locally |
| Keylogger | Actor | A Windows keylogger that writes user keystrokes to a file |
| Chromium browser dumper | Actor | A browser dump tool that dumps Chromium-based browser cookies and credentials |
| MidProxy | Actor | Proxy tool |
| Mimikatz12 | Public | Windows secrets dumper |
| Proxy Mini13 | Public | Proxy tool |
| frpc14 | Public | Fast reverse proxy client |
Interestingly, the Fast Reverse Proxy client we found was the same client found in the 3CX compromise by Mandiant15. This client is version 0.32.116 and is from 2020, which is remarkable. We also found traces of a Themida-packed version of Quasar17, a malware family we did not see this Lazarus subgroup use before.
The actor used PondRAT in combination with ThemeForestRAT for roughly three months, to afterwards clean up and install the more sophisticated RAT called RemotePE. We will now discuss these three RATs.
PondRAT is a simple RAT, which its authors seem to refer to as “firstloader”, based on the compilation metadata string objc_firstloader that is present in the macOS samples.
In our case, PondRAT was the initial access payload used to deploy other types of malware, including ThemeForestRAT. Judging from network data, apart from ThemeForestRAT activity, we observed significant activity to the PondRAT C2 server, indicating it was not just used for its loader functionality. In the incident response case from 2020 we encountered POOLRAT in combination with ThemeForestRAT. This could indicate that PondRAT is a successor of POOLRAT.
PondRAT is a straightforward RAT that allows an operator to read and write files, start processes and run shellcode. It has already been described by some vendors. As far as we know, the earliest sample is from 2021, referenced in a CISA article18. Based on PondRAT’s user-agent, we also noticed that PondRAT was used in an AppleJeus campaign Volexity wrote about19 (MSI file with hash 435c7b4fd5e1eaafcb5826a7e7c16a83). 360 Threat Intelligence Center wrote about PondRAT as well20, linking it to Lazarus and later writing about it being distributed through Python Package Index (PyPI) packages21. Vipyr Security wrote22 about malware that was dropped through malicious Python packages distributed through PyPI, which turned out to be PondRAT. Unit42 published an analysis23 of the RAT, referring to it as PondRAT and showing similarities between PondRAT and another RAT used by Lazarus: POOLRAT.
As described by Unit42, there are similarities between POOLRAT and PondRAT. There is overlap in function and class naming and both families check for successful responses in a similar way.
POOLRAT has more functionality than PondRAT. For example, POOLRAT has a configuration file for C2 servers, can timestomp24 files, can move files around, functionalities that PondRAT lacks. We think this is because there is no need for more functionality if its main function is to load other malware, allowing for a smaller code base and less maintenance.
PondRAT communicates over HTTP(S) with a hardcoded C2 server. Messages sent between the malware and the server are XOR-ed first and then Base64-encoded. For XORing it uses the hex-encoded key 774C71664D5D25775478607E74555462773E525E18237947355228337F433A3B.
Figure 4 contains an example check-in request to the C2 server. The tuid parameter contains the bot ID, control indicates the request type, and the payload parameter contains the encrypted check-in information. In this case, control is set to fconn, indicating it is a bot check-in, matching with the corresponding function name FConnectProxy(). When receiving a server reply starting with OK, PondRAT fetches a command from the server. For at least one Linux and macOS variant, the parameter names and string values consisted of scrambled letters, e.g. lkjyhnmiop instead of tuid and odlsjdfhw instead of fconn.
PondRAT has basic commands, such as reading and writing files and executing programs. Table 2 lists all commands and their names from the symbol data. When a bot command is executed, the response includes both the original command ID and a status code indicating either success (0x89A) or failure (0x89B).
| Command ID / Status code | Symbol name | Description |
|---|---|---|
| 0x892 | csleep | Sleep |
| 0x893 | MsgDown | Read file |
| 0x894 | MsgUp | Write file |
| 0x895 | Ping | |
| 0x896 | Load PE from C2 in memory | |
| 0x897 | MsgRun | Launch process |
| 0x898 | MsgCmd | Execute command through the shell |
| 0x899 | Exit | |
| 0x89a | Status code indicating command succeeded | |
| 0x89b | Status code indicating command failed | |
| 0x89c | Run shellcode in process |
Only the Windows samples we analysed had support for commands 0x896 and 0x89C. The DLL loading functionality seems to be based on the open-source project “Manual-DLL-Loader”25. As a sidenote, we analysed another POOLRAT Windows sample that used the “SimplePELoader” project26.
As mentioned by Palo Alto’s Unit42, PondRAT has similarities with POOLRAT. There is overlap in XOR keys, function naming and class naming. However, there are more similarities. Firstly, the Windows versions of PondRAT and POOLRAT use the format string %sd.e%sc "%s > %s 2>&1" for launching a shell command. Format strings have been discussed in the past27 and this specific format string was linked to Operation Blockbuster Sequel. Furthermore, PondRAT has a peculiar way of generating its bot ID, see the decompiled code below.
Figure 5 shows how PondRAT and POOLRAT compute their bot ID. For PondRAT, tuid is the bot ID. It computes two parts of a 32-bit integer, that are split in two based on the bit_shift variable. Some of the POOLRAT samples compute the bot ID in a similar manner. The sample 6f2f61783a4a59449db4ba37211fa331 has symbol information available and contains a function named GenerateSessionId() that has this same logic.
More similarities can be found as part of the C2 protocol. PondRAT provides feedback to commands issued by the C2 server by returning the command ID concatenated with the status code. POOLRAT uses the same concept, see Figure 6.
Another similarity can be found when comparing the Windows versions of POOLRAT and PondRAT. When running a Shell command (command ID 0x898) with PondRAT, the Windows version creates a temporary file with the prefix TLT in which it saves the command output. Then, it reads the file and sends the contents back to the C2 server and subsequently removes it. However, the way it removes the temporary file is remarkable.
It generates a buffer with random bytes and overwrites the file contents with it. Then, it renames the file 27 times, replacing all letters with only A’s, then B’s, etc. and with the last iteration renames all letters with random uppercase letters. For instance, when the file C:\Windows\Temp\tlt1bd8.tmp is deleted, it would first be renamed to C:\Windows\Temp\AAAAAAA.AAA, then to C:\Windows\Temp\BBBBBBB.BBB, and lastly to something like VYLDVAP.XQA. POOLRAT’s Windows version has the same functionality, see Figure 7.
These similarities show that apart from variable data and symbol names, PondRAT is similar to POOLRAT in coding concepts as well. This further strengthens the connection between the two.
PondRAT is a simple RAT. Judging from the symbol data of macOS samples, its authors seem to refer to the malware as firstloader, a RAT that targets all three major operating systems. In our case, we observed it in combination with social engineering campaigns, whereas others have seen PondRAT being dropped through malicious software packages. Despite being simple in nature, it seems to do the job, given the frequency in which it is used. Judging from past incidents we investigated, PondRAT is a successor of POOLRAT.
In two incident response cases we found traces of a different RAT being used in conjunction with POOLRAT or PondRAT. We named it ThemeForestRAT, based on the substring ThemeForest which it uses in its C2 protocol. It is written in C++ and contains class names such as CServer, CJobManager, CSocketEx, CZipper and CUsbMan. ThemeForestRAT has more functionalities compared to PondRAT and POOLRAT.
In an earlier incident response case in 2020, we observed ThemeForestRAT in combination with POOLRAT. In the case from 2024, we observed it together with PondRAT. Its continued activity over at least five years demonstrates that ThemeForestRAT remains a relevant and capable tool for this actor. Besides Windows, we have observed Linux and macOS versions of the malware.
We believe that on Windows, this RAT is injected and executed in memory only, for example via PondRAT, or a dedicated loader, and is used as stealthier second-stage RAT with more functionality. The fact there are no direct samples of ThemeForestRAT on VirusTotal indicates it is quite successful in staying under the radar.
On startup, ThemeForestRAT attempts to read the configuration file from disk. When absent, it generates a unique bot ID and uses the hardcoded C2 configuration settings in the binary to create the configuration file.
Interestingly, the Windows variant creates two Windows events and accompanying threads that are used for signalling purposes (see Figure 8). However, the first thread related to the class CUsbMan only creates the temporary directory Z802056 and returns, this turned out to be legacy code as we will describe later.
The second thread monitors for new Remote Desktop (RDP) sessions and notifies the main thread when one is detected. Additionally, the thread checks for new physical console sessions and can optionally spawn extra commands under this session if this is enabled in the configuration.
After creating these two threads it hibernates before connecting to the C2 server. The default hibernation period is three minutes but when it runs for the first time it checks in immediately. There are two cases where ThemeForestRAT wakes up from hibernation, either the hibernation period has passed, or one of the two events is signalled.
When it wakes up from hibernation it randomly selects a C2 server from its list and attempts to establish a connection. Upon receiving a response:OK acknowledgment, it downloads a 4-byte file that must decrypt to the 32-bit constant 0x20191127 to establish a valid C2 session. If this fails it will retry a different C2 and start over again, when the list of servers is exhausted it will go back into hibernation and try again later.
If it succeeds in establishing a C2 session, ThemeForestRAT sends basic system information including its wake-up reason to the C2 server, and the operator can now interact with the RAT as it keeps polling for new commands. When the operator sends an OnTerminate or OnSleep command (see Table 4), the C2 session ends, and the RAT goes back to hibernation.
struct SystemInfoWindows // sizeof=0x478
{
uint32 job_id; // 0x10005 = Windows
wchar bot_id[20];
wchar hostname[64];
wchar whoami[50];
uint32 dwMajorVersion;
uint32 dwMinorVersion;
uint32 dwPlatformId;
uint16 padding1;
wchar ip_address[20];
wchar timezone[50];
wchar gpu[50];
wchar memory[50];
uint16 padding2;
uint32 wakeup_reason; // 0 = hibernation, 1 = USB, 2 = RDP
wchar os_version[256];
};
struct SystemInfoPOSIX // sizeof=0x478
{
uint32 job_id; // 0x20005 = POSIX
char bot_id[16];
char unused1[24];
char hostname[128];
char username[114];
char ip_address[40];
char timezone[100];
char arch[100];
char memory[100];
char unused2[6];
char os_version[512];
};
Listing 2: ThemeForestRAT system information structure that is sent after establishing a C2 session
Listing 2 shows the structure definitions that ThemeForestRAT uses for sending system information when establishing a C2 session. The job_id field indicates the OS type, 0x10005 for Windows, and 0x20005 for both Linux and macOS as they share the same structure.
The configuration file of ThemeForestRAT is encrypted with RC4 using the hex-encoded key 201A192D838F4853E300 and contains the following settings:
cmd.exe (not used)The configuration can be parsed using the C structure definition from Listing 3.
struct ThemeForestC2Config
{
uint64 bot_id;
wchar urls[10][1024];
wchar shell[1024];
wchar wts_console_cmdline[10][1024];
char wts_console_cmdline_enabled[10];
uint32 last_checkin_epoch;
uint32 configured_hibernate_minutes;
uint32 active_hibernate_minutes;
uint16 callback_settings;
};
Listing 3: ThemeForestRAT configuration structure definition for Windows
The configuration path that the RAT reads from disk is hardcoded. On macOS and Linux, this is an absolute path, while on Windows it looks in the current working directory where the RAT is launched. In Table 3 we list the observed configuration paths and hardcoded configuration file sizes for ThemeForestRAT.
| Operating system | ThemeForestRAT configuration file on disk | File size |
|---|---|---|
| Windows | netraid.inf | 43048 bytes |
| Linux | /var/crash/cups | 43044 bytes |
| macOS | /private/etc/imap | 43044 bytes |
ThemeForestRAT communicates over HTTP(S). The filenames it uses for retrieving commands from the C2 server are prefixed with ThemeForest_. The response data is sent back to the operator as a file prefixed with Thumb_, see Figure 6. On Windows it uses the Ryeol Http Client28 library for HTTP communications, and on macOS and Linux it uses libcurl. ThemeForestRAT has a single hardcoded C2 in the binary, but its configuration can be updated by sending the SetInfo command.
In terms of command functionality, ThemeForestRAT supports over twenty commands, at least twice as much as PondRAT. The Linux and macOS versions contain debug symbols, which allows us to map the command IDs to function names where available.
| Symbol name | Command ID | Description |
|---|---|---|
| ListDrives | 0x10001000 | Get list of drives |
| CServer::OnFileBrowse | 0x10001001 | Get directory listing |
| CServer::OnFileCopy | 0x10001002 | Copy file from source to destination on victim machine |
| CServer::OnFileDelete | 0x10001003 | Delete a file |
| FileDeleteSecure | 0x10001004 | Delete a file securely |
| CServer::OnFileUpload | 0x10001005 | Open a file for writing on victim machine |
| CServer::FileDownload | 0x10001006 | Download file from victim machine |
| Run | 0x10001007 | Execute a command and return the exit code |
| CServer::OnChfTime | 0x10001008 | Timestomp file based on another file on disk |
| – | 0x10001009 | – |
| CServer::OnTestConn | 0x1000100a | Test TCP connection to host and port |
| CServer::OnCmdRun | 0x1000100b | Run command in background and return output |
| CServer::OnSleep | 0x1000100c | Hibernate for X seconds, this will also be saved in the configuration file |
| CServer::OnViewProcess | 0x1000100d | Get process listing |
| CServer::OnKillProcess | 0x1000100e | Kill process by process ID |
| – | 0x1000100f | – |
| CServer::OnFileProperty | 0x10001010 | Get file properties |
| CServer::OnGetInfo | 0x10001011 | Get current RAT configuration |
| CServer::OnSetInfo | 0x10001012 | Update and save RAT configuration file |
| CServer::OnZipDownload | 0x10001013 | Download a directory or file as a compressed Zip file |
| CServer::OnTerminate | 0x10001014 | Flush configuration to disk and hibernate until next wake up |
| (Data) | 0x10001015 | Data |
| (JobSuccess) | 0x10001016 | Job succeeded |
| (JobFailed) | 0x10001017 | Job failed |
| GetServiceName | 0x10001018 | Return current service name |
| CleanupAndExit | 0x10001019 | Remove persistence, configuration file, and terminate RAT |
| RecvMsg | 0x1000101a | Force C2 check-in |
| RunAs | 0x1000101b | Spawn a process under the user token of given Windows Terminal Services session |
| – | 0x1000101c | – |
| WriteRandomData | 0x1000101d | Write random data to file handle |
| CServer::OnInjectShellcode | 0x1000101e | Inject shellcode into process ID |
Note that the symbol names in Table 4 that start with CServer:: are from the debug symbols and the other names are deduced based on analysis of the command.
On Windows, the CServer::OnInjectShellcode command injects shellcode into a given process ID using NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory and RtlCreateUserThread Windows API calls. The shellcode is encrypted using the same algorithm used in PerfhLoader (see Listing 1). In the macOS and Linux samples we have analysed, this command is defined as an empty stub.
In 2016, Novetta released a detailed report called Operation Blockbuster29, in which a Novetta-led coalition of security companies analysed malware samples from multiple cybersecurity incidents. The investigation linked the 2014 Sony Pictures attack to the Lazarus Group and revealed that the same actor had been behind numerous other attacks against government, military, and commercial targets using related malware since 2009.
Operation Blockbuster’s malware report describes RomeoGolf, a RAT that resembles ThemeForestRAT in several ways:
Z802056, although not used in ThemeForestRAT, is still createdrand()mspaint.exeFigure 10 shows the RomeoGolf startup logic for generating its bot ID and two signalling threads that is identical to ThemeForestRAT (see Figure 5).
As can be seen in Table 5, the functionality to detect and copy data from newly attached logical drives has been removed in ThemeForestRAT, while leaving the temporary directory creation intact. Also, the thread to check for new RDP sessions has been extended in ThemeForestRAT to optionally spawn up to ten extra configured commands under the user of the active physical console session.
| RomeoGolf | ThemeForestRAT | |
|---|---|---|
| Compilation date | Fri Oct 11 01:20:48 2013 | Thu Sep 07 06:40:40 2023 |
| Known configuration file | crkdf32.inf | netraid.inf |
| Configuration file timestomped to | mspaint.exe | mspaint.exe |
| USB thread logic | 1. Creates %TEMP%\Z8020562. Checks for newly attached drives and copies data to above folder 3. Signal on newly attached drives | 1. Creates %TEMP%\Z802056 |
| RDP thread logic | 1. Signal on new active RDP sessions | 1. Start configured commands under the user of the new active console session 2. Signal on new active RDP session if configured |
| C2 communication | Fake TLS | HTTP(S) |
| Highest known command id | 0x10001013 | 0x1000101e |
While RomeoGolf used Fake TLS30 and its own custom server for its C2 communications, ThemeForestRAT uses the HTTP protocol and shared hosting for its C2 servers.
In the 2024 incident response case, we observed the actor cleaning up PondRAT and ThemeForestRAT, to deploy a more advanced RAT, which we named RemotePE. RemotePE is retrieved from a C2 server by RemotePELoader. RemotePELoader is encrypted on disk using Window’s Data Protection API (DPAPI) and is loaded by DPAPILoader. Using DPAPI enables environmental keying and makes it difficult to recover the original payload without access to the machine. DPAPILoader was made persistent through a created Windows service.
In Figure 10, we show a RemotePELoader check-in request used to retrieve RemotePE from the C2 server. RemotePE is written in C++ and is more advanced and elegant. We think that the actor uses this more sophisticated RAT for interesting or high-value targets that require a higher degree of operational security. Interestingly, it too uses the file renaming strategy PondRAT and POOLRAT Windows samples implement, except it skips the last random iteration.
We will publish a more thorough analysis of RemotePE in a future blogpost.
This blog is about a Lazarus subgroup that we have encountered multiple times during incident response engagements. This is a capable, patient, financially motivated actor who remains a legitimate threat.
We first discussed an incident response case from 2024, where this actor impersonated employees of trading companies to establish contact with potential victims. Though the method of achieving initial access remains unknown, we suspect a Chrome zero-day was used.
After initial access, two RATs were used in combination: PondRAT and ThemeForestRAT. Though PondRAT has already been discussed, there are no public analyses of ThemeForestRAT at the time of writing. For persistence, phantom DLL loading was used in conjunction with a custom loader called PerfhLoader.
PondRAT is a primitive RAT that provides little flexibility, however, as an initial payload it achieves its purpose. It has similarities with POOLRAT/SimpleTea. For more complex tasks, the actor uses ThemeForestRAT, which has more functionality and stays under the radar as it is loaded into memory only.
Lastly, we found the actor replaced ThemeForestRAT and PondRAT with the more advanced RemotePE. A detailed analysis of RemotePE will be published in the near future. So, stay tuned!
In Table 6 and 7, we list indicators of compromise related to the incident response cases we investigated and other artifacts we link to this actor.
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
| Type | Indicator | Comment |
|---|---|---|
| net.domain | calendly[.]live | Fake calendly.com |
| net.domain | picktime[.]live | Fake picktime.com |
| net.domain | oncehub[.]co | Fake oncehub.com |
| net.domain | go.oncehub[.]co | Fake oncehub.com |
| net.domain | dpkgrepo[.]com | Potentially related to Chrome exploitation |
| net.domain | pypilibrary[.]com | Unknown, visited by msiexec.exe shortly after dpkgrepo[.]com |
| net.domain | pypistorage[.]com | Unknown, connection seen under SessionEnv service |
| net.domain | keondigital[.]com | LPEClient server, connection seen under SessionEnv service |
| net.domain | arcashop[.]org | PondRAT C2 |
| net.domain | jdkgradle[.]com | PondRAT C2 |
| net.domain | latamics[.]org | PondRAT C2 |
| net.domain | lmaxtrd[.]com | ThemeForestRAT C2 |
| net.domain | paxosfuture[.]com | ThemeForestRAT C2 |
| net.domain | www[.]plexisco[.]com | ThemeForestRAT C2 |
| net.domain | ftxstock[.]com | ThemeForestRAT C2 |
| net.domain | www[.]natefi[.]org | ThemeForestRAT C2 |
| net.domain | nansenpro[.]com | ThemeForestRAT C2 |
| net.domain | aes-secure[.]net | RemotePE payload delivery and C2 |
| net.domain | azureglobalaccelerator[.]com | RemotePE payload delivery and C2 |
| net.domain | azuredeploypackages[.]net | Unknown, connection seen via injected process |
| net.ip | 144.172.74[.]120 | Fast Reverse Proxy server |
| net.ip | 192.52.166[.]253 | Used as parameter for Quasar |
| file.path | %TEMP%\tmpntl.dat | Windows keylogger output file path |
| file.path | C:\Windows\Temp\TMP01.dat | Windows keylogger error file path |
| file.name | netraid.inf | ThemeForestRAT Windows configuration filename |
| file.path | /var/crash/cups | ThemeForestRAT Linux configuration file path |
| file.path | /private/etc/imap | ThemeForestRAT macOS configuration file path |
| file.path | /private/etc/krb5d.conf | POOLRAT macOS configuration file path, CISA 2021 report |
| file.path | /etc/apdl.cf | POOLRAT Linux configuration file path |
| file.path | %SystemRoot%\system32\apdl.cf | POOLRAT Windows configuration file path |
| file.path | /tmp/xweb_log.md | POOLRAT, PondRAT Linux libcurl error log file path |
| file.name | perfh011.dat | Encrypted payload loaded by PerfhLoader |
| file.name | hsu.dat | Filename actor used for SysInternals ADExplorer output |
| file.name | pfu.dat | Filename actor used for SysInternals Handle viewer output |
| file.name | fpc.dat | Dropped Fast Reverse Proxy configuration filename |
| file.name | fp.exe | Dropped Fast Reverse Proxy executable |
| file.name | tsvipsrv.dll | DLL phantom loaded by actor (SessionEnv) |
| file.name | wlbsctrl.dll | DLL phantom loaded by actor (IKEEXT) |
| file.name | adepfx.exe | Filename actor used for legitimate SysInternals ADExplorer |
| file.name | hd.exe | Filename actor used for legitimate SysInternals Nthandle.exe |
| file.name | msnprt.exe | Filename actor uses for Proxymini, open-source socks proxy |
| file.path | %LocalAppData%\IconCache.log | Output path for custom browser credentials and cookies dumper based on Mimikatz |
| file.path | /private/etc/pdpaste | macOS keylogger file path |
| file.path | /private/etc/xmem | macOS keylogger output file path |
| file.path | /private/etc/tls3 | macOS screenshotter output directory |
| file.path | %LocalAppData%\Microsoft\Software\Cache | Windows screenshotter output directory |
| file.path | c:\windows\system32\cmui.exe | Themida-packed Quasar |
| digest.sha256 | Comment |
|---|---|
| 24d5dd3006c63d0f46fb33cbc1f576325d4e7e03e3201ff4a3c1ffa604f1b74a | Fast Reverse Proxy v0.32.1, also observed by Mandiant in the 3CX supply chain attack |
| 4715e5522fc91a423a5fcad397b571c5654dc0c4202459fdca06841eba1ae9b3 | PerfhLoader |
| 8c3c8f24dc0c1d165f14e5a622a1817af4336904a3aabeedee3095098192d91f | PerfhLoader |
| f4d8e1a687e7f7336162d3caed9b25d9d3e6cfe75c89495f75a92ca87025374b | POOLRAT Windows |
| 85045d9898d28c9cdc4ed0ca5d76eceb457d741c5ca84bb753dde1bea980b516 | POOLRAT Linux |
| 5e40d106977017b1ed235419b1e59ff090e1f43ac57da1bb5d80d66ae53b1df8 | POOLRAT macOS (CISA 2021 report) |
| c66ba5c68ba12eaf045ed415dfa72ec5d7174970e91b45fda9ebb32e0a37784a | ThemeForestRAT Windows |
| ff32bc1c756d560d8a9815db458f438d63b1dcb7e9930ef5b8639a55fa7762c9 | ThemeForestRAT Linux |
| cc4c18fefb61ec5b3c69c31beaa07a4918e0b0184cb43447f672f62134eb402b | ThemeForestRAT macOS |
| 6510d460395ca3643133817b40d9df4fa0d9dbe8e60b514fdc2d4e26b567dfbd | PondRAT Windows |
| 973f7939ea03fd2c9663dafc21bb968f56ed1b9a56b0284acf73c3ee141c053c | PondRAT Linux |
| f0321c93c93fa162855f8ea4356628eef7f528449204f42fbfa002955a0ba528 | PondRAT macOS |
| 4f6ae0110cf652264293df571d66955f7109e3424a070423b5e50edc3eb43874 | DPAPILoader |
| aa4a2d1215f864481994234f13ab485b95150161b4566c180419d93dda7ac039 | DPAPILoader |
| 159471e1abc9adf6733af9d24781fbf27a776b81d182901c2e04e28f3fe2e6f3 | DPAPILoader |
| 7a05188ab0129b0b4f38e2e7599c5c52149ce0131140db33feb251d926428d68 | RemotePELoader (decrypted from disk) |
| 37f5afb9ed3761e73feb95daceb7a1fdbb13c8b5fc1a2ba22e0ef7994c7920ef | RemotePE |
| 59a651dfce580d28d17b2f716878a8eff8d20152b364cf873111451a55b7224d | Windows keylogger |
| 3c8f5cc608e3a4a755fe1a2b099154153fb7a88e581f3b122777da399e698cca | Windows screenshotter |
| d998de6e40637188ccbb8ab4a27a1e76f392cb23df5a6a242ab9df8ee4ab3936 | macOS keylogger (getkey) |
| e4ce73b4dbbd360a17f482abcae2d479bc95ea546d67ec257785fa51872b2e3f | macOS screenshotter (getscreen) |
| 1a051e4a3b62cd2d4f175fb443f5172da0b40af27c5d1ffae21fde13536dd3e1 | macOS clipboard logger (pdpaste) |
| 9dddf5a1d32e3ba7cc27f1006a843bfd4bc34fa8a149bcc522f27bda8e95db14 | Proxymini tool, opensource SOCKS proxy tool |
| 2c164237de4d5904a66c71843529e37cea5418cdcbc993278329806d97a336a5 | Themida-packed Quasar |
import "pe"
rule Lazarus_DPAPILoader_Hunting {
meta:
description = "Hunting rule to detect DPAPILoader, a loader used to load RemotePE."
author = "Fox-IT / NCC Group"
strings:
$msg_1 = "[!] Could not allocate memory at the desired base!\n"
$msg_2 = "[!] Virtual section size is out ouf bounds: "
$msg_3 = "[!] Invalid relocDir pointer\n"
$msg_4 = "[-] Not supported relocations format at %d: %d\n"
$msg_5 = "[!] Cannot fill imports into 32 bit PE via 64 bit loader!\n"
condition:
any of them and pe.imports("Crypt32.dll", "CryptUnprotectData")
}
rule Lazarus_RemotePE_C2_strings {
meta:
description = "RemotePE strings used for C2."
author = "Fox-IT / NCC Group"
strings:
$a = "MicrosoftApplicationsTelemetryDeviceId" wide ascii xor
$b = "armAuthorization" wide ascii xor
$c = "ai_session" wide ascii xor
condition:
uint16(0) == 0x5A4D and all of them
}
rule Lazarus_RemotePE_class_strings {
meta:
description = "RemotePE class strings."
author = "Fox-IT / NCC Group"
strings:
$a = "IMiddleController" ascii wide xor
$b = "IChannelController" ascii wide xor
$c = "IConfigProfile" ascii wide xor
$d = "IKernelModule" ascii wide xor
condition:
all of them
}
rule Lazarus_PerfhLoader_XOR_key {
meta:
description = "XOR key used for shellcode obfuscation."
author = "Fox-IT / NCC Group"
strings:
$mov_1 = { C7 [1-3] 00 01 02 03 }
$mov_2 = { C7 [1-3] 04 05 06 07 }
$mov_3 = { C7 [1-3] 08 09 0A 0B }
$mov_4 = { C7 [1-3] 0C 0D 0E 0F }
$init_1 = { 41 8D ?? FD 41 8D ?? F9 }
condition:
all of them
}
rule Lazarus_ThemeForestRAT_C2_strings {
meta:
description = "ThemeForestRAT strings used for C2."
author = "Fox-IT / NCC Group"
strings:
$themeforest = "ThemeForest_%s" ascii wide
$thumb = "Thumb_%s" ascii wide
$param_code = "code" ascii wide
$param_fn = "fn" ascii wide
$param_ldf = "ldf" ascii wide
condition:
all of them
}
rule Lazarus_ThemeForestRAT_RC4_key {
meta:
description = "ThemeForest RC4 key used for config file."
author = "Fox-IT / NCC Group"
strings:
$rc4_key = { 20 1A 19 2D 83 8F 48 53 E3 00 }
$rc4_key_mov = { 20 1A 19 2D [2-8] 83 8F 48 53 [2-10] E3 00 }
condition:
any of them
}
A month or so ago a friend of mine received the following message on Steam from someone in their Friends list (they were already friends):
 | ||||||||||
| Figure 1 - 'this is for you' |
The two links are different and refer to a Gift Card on Steam's community platform. As you might have noticed, the domain is not related to Steam at all, but rather is an attempt at phishing.
The URLs are:
stermcormmunity[.]com/gift-card/
steamcoummuniity[.]com/gift-card/
The differences are subtle enough that you may just miss it. When you click on the link, you are redirected to a 'Summer Gift Marathon'.
 |
| Figure 2 - Fake Steam website |
Once you log in to the fake Steam website, your credentials are stolen and will be used to spread more phishing, likely steal your inventory items and so on.
Other phishing sites related to this campaign are:
steam-pubgvn[.]top
steamauthconnection[.]store
steamcommnunity[.]com
steamcommunitay[.]com
steamcommunitfy[.]com
steamcommunitihy[.]icu
steamcommunitiny[.]com
steamcommunitweya[.]art
steamcommunl1ty[.]com
steamcommunllity[.]com
steamcommunty[.]ru
steamcommununity[.]cam
steamcommunutiy[.]com
steamcomnunityty[.]com
steamcomnunlity[.]com
steamcomnuty[.]com
steamcomrnnunlty[.]com
steamcomun1ty[.]com
steamcomuniry[.]com
steamconmunify[.]com
steamconnection[.]store
steamcornmunlty[.]ru
steamcornrnunlty[.]ru
steamlinks-short[.]com
stearncommunjty[.]com
stearncommunnity[.]com
stearncomnunity[.]com
stearncornnunity[.]com
steeamcommunitty[.]com
unevwsteeamcommunitty[.]com
New ones do pop up from time to time, so stay vigilant.
Continue reading → AS-REP Roasting
CryptoCore is an attack campaign against crypto-exchange companies that has been ongoing for three years and was discovered by ClearSky researchers. This cybercrime campaign is focused mainly on the theft of cryptocurrency wallets, and we estimate that the attackers have already made off with hundreds of millions of dollars. This campaign was also reported by additional companies and organizations, including JPCERT/CC[1], NTT Security[2] and F-SECURE[3]. The campaign is also known as CryptoMimic, Dangerous Password and Leery Turtle. In this report we attributed this campaign to a specific actor – North Korea’s LAZARUS APT Group, known also as Hidden Cobra.
Read the full report: Attributing CryptoCore Attacks Against Crypto Exchanges to LAZARUS (North Korea)
In this report, we based our attribution with two stages of research:
Our research shows a MEDIUM-HIGH likelihood that Lazarus group, a North-Korean, state-sponsored APT group, is attacking crypto exchanges all over the world and in Israel for at least three years. This group is has successfully hacked into numerous companies and organizations around the world for many years. Until recently this group was not known to attack Israeli targets.
We would like to thank NTT Security Japan for sharing malware samples with us, and for their feedback on this research.
[1] https://blogs.jpcert.or.jp/en/2019/07/spear-phishing-against-cryptocurrency-businesses.html
[2] https://vblocalhost.com/uploads/VB2020-Takai-etal.pdf
[3] https://labs.f-secure.com/assets/BlogFiles/f-secureLABS-tlp-white-lazarus-threat-intel-report2.pdf
Jordan Drysdale // tl;dr BHIS made some interesting discoveries while working with a customer to audit their Amazon Web Services (AWS) infrastructure. At the time of the discovery, we found […]
The post Securing the Cloud: A Story of Research, Discovery, and Disclosure appeared first on Black Hills Information Security, Inc..
Yet again it is time for another edition of Sacred Cash Cow Tipping! Or, “Why do these endpoint security bypass techniques still work? Why?” The goal of this is to […]
The post PODCAST: Sacred Cash Cow Tipping 2019 appeared first on Black Hills Information Security, Inc..
John Strand // Yet again it is time for another edition of Sacred Cash Cow Tipping! Or, “Why do these endpoint security bypass techniques still work? Why?” The goal of […]
The post Webcast: Sacred Cash Cow Tipping 2019 appeared first on Black Hills Information Security, Inc..
