De ziekenhuizen van AZ Monica hebben alle operaties uitgesteld vanwege een IT-storing. Door die storing is het netwerk uitgeschakeld en zijn patiΓ«ntendossiers niet bereikbaar. Volgens een bron van VTM Nieuws gaat het om een cyberaanval.
Reisplatform Interrail meldt dat er door een beveiligingslek klantgegevens zijn gestolen. Het gaat daarbij onder meer om naw-gegevens, maar mogelijk ook om paspoort- of ID-kaartinformatie. Het is niet duidelijk hoeveel klanten betrokken zijn.
Instagram heeft een probleem opgelost waardoor 'een externe partij' e-mails naar Instagram-gebruikers kon verzenden met het verzoek om hun wachtwoord opnieuw in te stellen. Het platform ontkent dat er is ingebroken in zijn systemen, hoewel er wel meldingen zijn van een datalek.
Het Nederlandse Nationaal Cyber Security Centrum adviseert om een kwetsbaarheid in automatiseringssoftware n8n snel te repareren. Onlangs werd er een bug ontdekt in n8n die kan leiden tot een remote code execution en inmiddels is er een proof-of-concept verschenen van zo'n aanval.
Elektrische rolstoelen van het merk Whill waren over te nemen door derden, omdat de rolstoelen geen authenticatie op de bluetoothverbinding forceerden. Een aangepaste versie van een getroffen rolstoel is in gebruik op Schiphol en het is onbekend of die ook kwetsbaar was of is.
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.
RESI RACK
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.
DORT & SNOW
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.
BYTECONNECT, PLAINPROXIES, AND 3XK TECH
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 Intelligencefound 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.
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.
MASKIFY
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.
BOTMASTERS LASH OUT
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.
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.β
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.
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
Selected industries
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
Diversity of detected malicious objects
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.
Main threat sources
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.
The main categories of threats from the internet blocked on ICS computers in Q3 2025 were malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 4.57% in Northern Europe to 10.31% in Africa.
The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password-protected archive or a multi-layered script embedded in an office document. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.78% in Russia to 6.85% in Southern Europe.
The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from this source were blocked ranged from 0.05% in Australia and New Zealand to 1.43% in Africa.
The main categories of threats that spread through network folders were viruses, AutoCAD malware, worms, and spyware. The percentages of ICS computers where threats from this source were blocked ranged from 0.006% in Northern Europe to 0.20% in East Asia.
Threat categories
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.
Malicious objects used for initial infection
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.
Next-stage malware
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:
spyware: 4.04% (up 0.20 pp);
ransomware: 0.17% (up 0.03 pp).
The percentage of ICS computers on which miners of both categories were blocked decreased. The rates were:
miners in the form of executable files for Windows: 0.57% (down 0.06 pp), itβs the lowest level since Q3 2022;
web miners: 0.25% (down 0.05 pp). This is the lowest level since Q3 2022.
Self-propagating malware
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.
AutoCAD malware
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).
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
Selected industries
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
Diversity of detected malicious objects
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.
Main threat sources
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.
The main categories of threats from the internet blocked on ICS computers in Q3 2025 were malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 4.57% in Northern Europe to 10.31% in Africa.
The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password-protected archive or a multi-layered script embedded in an office document. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.78% in Russia to 6.85% in Southern Europe.
The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from this source were blocked ranged from 0.05% in Australia and New Zealand to 1.43% in Africa.
The main categories of threats that spread through network folders were viruses, AutoCAD malware, worms, and spyware. The percentages of ICS computers where threats from this source were blocked ranged from 0.006% in Northern Europe to 0.20% in East Asia.
Threat categories
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.
Malicious objects used for initial infection
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.
Next-stage malware
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:
spyware: 4.04% (up 0.20 pp);
ransomware: 0.17% (up 0.03 pp).
The percentage of ICS computers on which miners of both categories were blocked decreased. The rates were:
miners in the form of executable files for Windows: 0.57% (down 0.06 pp), itβs the lowest level since Q3 2022;
web miners: 0.25% (down 0.05 pp). This is the lowest level since Q3 2022.
Self-propagating malware
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.
AutoCAD malware
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).
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.
What do ASUS users need to do?
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.
Right-click the ASUS Live Update icon at the bottom-right corner of your Windows screen
Click About to see the version information as the shown in the picture below.
If you are on an older version, open the program and click Check update immediately
ASUS Live Update will automatically find the latest driver and utility.
Click Install
After updating, recheck and ensure it shows βNo updates.β
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:β
Go to theΒ ASUS Official Website (asus.com)
Use the search box to find your exact modelΒ (e.g.,Β UX580GD)
Open the product page and clickΒ SupportΒ βΒ Driver & Tools
Select your operating system (e.g., Windows 10/11 64-bit).β
In theΒ UtilitiesΒ section, locateΒ ASUS Live UpdateΒ and clickΒ Download
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.
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.
What do ASUS users need to do?
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.
Right-click the ASUS Live Update icon at the bottom-right corner of your Windows screen
Click About to see the version information as the shown in the picture below.
If you are on an older version, open the program and click Check update immediately
ASUS Live Update will automatically find the latest driver and utility.
Click Install
After updating, recheck and ensure it shows βNo updates.β
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:β
Go to theΒ ASUS Official Website (asus.com)
Use the search box to find your exact modelΒ (e.g.,Β UX580GD)
Open the product page and clickΒ SupportΒ βΒ Driver & Tools
Select your operating system (e.g., Windows 10/11 64-bit).β
In theΒ UtilitiesΒ section, locateΒ ASUS Live UpdateΒ and clickΒ Download
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.
Hamas-affiliated threat actor Ashen Lepus (aka WIRTE) is conducting espionage with its new AshTag malware suite against Middle Eastern government entities.
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.
A Telegram from Pyongyang
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:
Social engineering: the actor impersonates an existing employee of a trading company on Telegram and sets up a meeting with the victim, using fake meeting websites.
Exploitation: the victim machine gets compromised and shortly afterwards PondRAT is deployed. We are uncertain how the compromise was achieved, though we suspect a Chrome zero-day vulnerability was used.
Discovery: the actor uses various tooling to explore the victim network and observe daily activities.
Next phase: after three months, the actor removes PerfhLoader, PondRAT and ThemeForestRAT and deploys a more advanced RAT, which we named RemotePE.
Figure 1: Overview of the attack chain from a 2024 incident response case involving a Lazarus subgroup
Social Engineering
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.
Figure 2: Lazarus subgroup impersonating an employee at a trading company interested in the cryptocurrency sector
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.
Persistence with PerfhLoader
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.
Figure 3: PerfhLoader loaded through SessionEnv service via Phantom DLL Loading which in turn loads PondRAT or POOLRAT
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.
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.
Discovery
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
Table 1: Tools observed during incident response case (public and actor-developed)
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
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.
Overview
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.
Command and Control
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: PondRAT check-in request
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.
Commands
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
Table 2: PondRAT command IDs and their descriptions
Windows
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.
POOLRATβs Little Brother
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: Bot ID generation for PondRAT (left) and POOLRAT (right)
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.
Figure 6: Command status concatenation for PondRAT (left) and POOLRAT (right)
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.
Figure 7: Windows file name generation for PondRAT (left) and POOLRAT (right)
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.
Summary
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.
Run, ThemeForest, Run!
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.
Overview
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.
Figure 8: ThemeForestRAT startup code creating two Windows events and threads for signalling
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.
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.
Configuration
The configuration file of ThemeForestRAT is encrypted with RC4 using the hex-encoded key 201A192D838F4853E300 and contains the following settings:
64-bit unique bot ID
List of ten C2 server URLs
Command interpreter, for example cmd.exe (not used)
List of optional commands to execute under the user of the active console session (Windows only, empty by default)
Matching array to enable the optional console command
Last check-in timestamp
Hibernation time between C2 sessions in minutes, default value is 3
C2 callback settings, for example to immediately check in on a new active RDP connection
The configuration can be parsed using the C structure definition from Listing 3.
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
Table 3: Observed ThemeForestRAT configuration paths and their file sizes on Windows, Linux and macOS
Command and Control
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.
Figure 9: ThemeForestRAT sending encrypted system information to C2 server on initial check-in
Commands
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
Table 4: ThemeForestRAT command IDs and their descriptions
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.
Shellcode Injection
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.
RomeoGolfβs Little Brother
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:
Uses the temporary folder Z802056, although not used in ThemeForestRAT, is still created
Overlapping command IDs and functionality
Same unique identifier generation using 4 calls to rand()
Configuration file with extension *.inf on Windows
Timestomping of the configuration file based on mspaint.exe
Two signalling threads for USB and RDP events
Figure 10 shows the RomeoGolf startup logic for generating its bot ID and two signalling threads that is identical to ThemeForestRAT (see Figure 5).
Figure 10: RomeoGolf startup creates two signalling threads, comparable 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%\Z802056 2. 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
Table 5: Differences and similarities between RomeoGolf and ThemeForestRAT
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.
Onto the next stage with RemotePE
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.
Figure 10: RemotePELoader check-in request to retrieve RemotePE payload
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.
Summary
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.
Incident Response Support
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.
Indicators of Compromise
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
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 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:
New ones do pop up from time to time, so stay vigilant.Β
TipsΒ Β
Only log in on the legitimate Steam community website, this being https://steamcommunity.com/. An extra tip is to bookmark the legitimate site, so even if you do get a message like this, you can go straight to your bookmark and search what you need from there.
Β
If someone new tries to add you as a Friend and immediately sends a message like the above, alarm bells should start ringing.
Β
If someone already on your Friends list suddenly sends a random message with an even more random link out of the blue, cue the alarm bells again.Β
Β
If you want to check the website out in a safe manner, then you can use URLscan.io, which will give you a verdict of the website as well as an image preview. In addition, you can use VirusTotal to review a website's reputation.
Β
Note that an 'all clean' does not necessarily mean it is. Caution above all!Β
Β
Follow Steam's Account Security Recommendations to stay safe.
Active Directory users that have the Kerberos pre-authentication enabled and require access to a resource initiate the Kerberos authentication process by sending an Authentication Serverβ¦
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.
In this report, we based our attribution with two stages of research:
First stageβ connecting all research documents to the same campaign: Β a comparative study of all the research documents trying to prove they are all referring to the same campaign.
Second stage β Attribution to Lazarus: We adopted F-SECUREβs attribution to LAZARUS. Then we reaffirmed this attribution by comparing the attack tools Β found in this campaignΒ to other Lazarus campaignsΒ and found strong similarities.
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.
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 [β¦]