Security researchers have seen the vulnerabilities being exploited to deliver shells, conduct reconnaissance, and download malware.
The post Ivanti Exploitation Surges as Zero-Day Attacks Traced Back to July 2025 appeared first on SecurityWeek.
In October 2025, we discovered a series of forum posts advertising a previously unknown stealer, dubbed “Arkanix Stealer” by its authors. It operated under a MaaS (malware-as-a-service) model, providing users not only with the implant but also with access to a control panel featuring configurable payloads and statistics. The set of implants included a publicly available browser post-exploitation tool known as ChromElevator, which was delivered by a native C++ version of the stealer. This version featured a wide range of capabilities, from collecting system information to stealing cryptocurrency wallet data. Alongside that, we have also discovered Python implementation of the stealer capable of dynamically modifying its configuration. The Python version was often packed, thus giving the adversary multiple methods for distributing their malware. It is also worth noting that Arkanix was rather a one-shot malicious campaign: at the time of writing this article, the affiliate program appears to be already taken down.
Kaspersky products detect this threat as Trojan-PSW.Win64.Coins.*, HEUR:Trojan-PSW.Multi.Disco.gen, Trojan.Python.Agent.*.
In October 2025, a series of posts was discovered on various dark web forums, advertising a stealer referred to by its author as “Arkanix Stealer”. These posts detail the features of the stealer and include a link to a Discord server, which serves as the primary communication channel between the author and the users of the stealer.
Example of an Arkanix Stealer advertisement
Upon further research utilizing public resources, we identified a set of implants associated with this stealer.
The initial infection vector remains unknown. However, based on some of the file names (such as steam_account_checker_pro_v1.py, discord_nitro_checker.py, and TikTokAccountBotter.exe) of the loader scripts we obtained, it can be concluded with high confidence that the initial infection vector involved phishing.
| MD5 | 208fa7e01f72a50334f3d7607f6b82bf |
| File name | discord_nitro_code_validator_right_aligned.py |
The Python loader is the script responsible for downloading and executing the Python-based version of the Arkanix infostealer. We have observed both plaintext Python scripts and those bundled using PyInstaller or Nuitka, all of which share a common execution vector and are slightly obfuscated. These scripts often serve as decoys, initially appearing to contain legitimate code. Some of them do have useful functionality, and others do nothing apart from loading the stealer. Additionally, we have encountered samples that employ no obfuscation at all, in which the infostealer is launched in a separate thread via Python’s built-in threading module.
Variants of Python loaders executing the next stage
Upon execution, the loader first installs the required packages — namely, requests, pycryptodome, and psutil — via the pip package manager, utilizing the subprocess module. On Microsoft Windows systems, the loader also installs pywin32. In some of the analyzed samples, this process is carried out twice. Since the loader does not perform any output validation of the module installation command, it proceeds to make a POST request to hxxps://arkanix[.]pw/api/session/create to register the current compromised machine on the panel with a predefined set of parameters even if the installation failed. After that, the stealer makes a GET request to hxxps://arkanix[.]pw/stealer.py and executes the downloaded payload.
| MD5 | af8fd03c1ec81811acf16d4182f3b5e1 |
| File name | – |
During our research, we obtained a sample of the Python implementation of the Arkanix stealer, which was downloaded from the endpoint hxxps://arkanix[.]pw/stealer.py by the previous stage.
The stealer’s capabilities — or features, as referred to by the author — in this version are configurable, with the default configuration predefined within the script file. To dynamically update the feature list, the stealer makes a GET request to hxxps://arkanix[.]pw/api/features/{payload_id}, indicating that these capabilities can be modified on the panel side. The feature list is identical to the one that was described in the GDATA report.
Configurable options
Prior to executing the information retrieval-related functions, the stealer makes a request to hxxps://arkanix[.]pw/upload_dropper.py, saves the response to %TEMP%\upd_{random 8-byte name}.py, and executes it. We do not have access to the contents of this script, which is referred to as the “dropper” by the attackers.
During its main information retrieval routine, at the end of each processing stage, the collected information is serialized into JSON format and saved to a predefined path, such as %LOCALAPPDATA\Arkanix_lol\%info_class%.json.
In the following, we will provide a more detailed description of the Python version’s data collection features.
Arkanix Stealer is capable of collecting a set of info about the compromised system. This info includes:
Information collection is performed using standard shell commands with the exception of the VPN check. The latter is implemented by querying the endpoint hxxps://ipapi[.]co/json/ and verifying whether the associated IP address belongs to a known set of VPNs, proxies, or Tor exit nodes.
This stealer is capable of extracting various types of data from supported browsers (22 in total, ranging from the widely popular Google Chrome to the Tor Browser). The list of supported browsers is hardcoded, and unlike other parameters, it cannot be modified during execution. In addition to a separate Chrome grabber module (which we’ll discuss later), the stealer itself supports the extraction of diverse information, such as:
All information is decrypted using either the Windows DPAPI or AES, where applicable, and searched for relevant keywords. In the case of browser information collection, the stealer searches exclusively for keywords related to banking (e.g., “revolut”, “stripe”, “bank”) and cryptocurrencies (e.g., “binance”, “metamask”, “wallet”). In addition to this, the stealer is capable of extracting extension data from a hardcoded list of extensions associated with cryptocurrencies.
Part of the extension list which the stealer utilizes to extract data from
Telegram data collection begins with terminating the Telegram.exe process using the taskkill command. Subsequently, if the telegram_optimized feature is set to False, the malware zips the entire tdata directory (typically located at %APPDATA%\Roaming\Telegram Desktop\tdata) and transmits it to the attacker. Otherwise, it selectively copies and zips only the subdirectories containing valuable info, such as message log. The generated archive is sent to the endpoint /delivery with the filename tdata_session.zip.
The stealer includes two features connected with Discord: credentials stealing and self-spreading. The first one can be utilized to acquire credentials both from the standard client and custom clients. If the client is Chromium-based, the stealer employs the same data exfiltration mechanism as during browser credentials stealing.
The self-spreading feature is configurable (meaning it can be disabled in the config). The stealer acquires the list of user’s friends and channels via the Discord API and sends a message provided by the attacker. This stealer does not support attaching files to such messages.
The VPN collector is searching for a set of known VPN software to extract account credentials from the credentials file with a known path that gets parsed with a regular expression. The extraction occurs from the following set of applications:
File retrieval is performed regardless of the configuration. The script relies on a predefined set of paths associated with the current user (such as Desktop, Download, etc.) and file extensions mainly connected with documents and media. The script also has a predefined list of filenames to exfiltrate. The extracted files are packed into a ZIP archive which is later sent to the C2 asynchronously. An interesting aspect is that the filename list includes several French words, such as “motdepasse” (French for “password”), “banque” (French for “bank”), “secret” (French for “secret”), and “compte” (French for “account”).
We were able to identify additional modules that are downloaded from the C2 rather than embedded into the stealer script; however, we weren’t able to obtain them. These modules can be described by the following table, with the “Details” column referring to the information that could be extracted from the main stealer code.
| Module name | Endpoint to download | Details |
| Chrome grabber | /api/chrome-grabber-template/{payload_id} | – |
| Wallet patcher | /api/wallet-patcher/{payload_id} | Checks whether “Exodus” and “Atomic” cryptocurrency wallets are installed |
| Extra collector | /api/extra-collector/{payload_id} | Uses a set of options from the config, such as collect_filezilla, collect_vpn_data, collect_steam, and collect_screenshots |
| HVNC | /hvnc | Is saved to the Startup directory (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\hvnc.py) to execute upon system boot |
The Wallet patcher and Extra collector scripts are received in an encrypted form from the C2 server. To decrypt them, the attackers utilize the AES-GCM algorithm in conjunction with PBKDF2 (HMAC and SHA256). After decryption, the additional payload has its template placeholders replaced and is stored under a partially randomized name within a temporary folder.
Decryption routine and template substitution
Once all operations are completed, the stealer removes itself from the drive, along with the artifacts folder (Arkanix_lol in this case).
| MD5 | a3fc46332dcd0a95e336f6927bae8bb7 |
| File name | ArkanixStealer.exe |
During our analysis, we were able to obtain both the release and debug versions of the native implementation, as both were uploaded to publicly available resources. The following are the key differences between the two:
Login
arkanix[.]pw.Notably, the native implementation explicitly references the name of the stealer in the VersionInfo resources. This naming convention is consistent across both the debug version and certain samples containing the release version of the implant.
Version info
After launching, the stealer implements a series of analysis countermeasures to verify that the application is not being executed within a sandboxed environment or run under a debugger. Following these checks, the sample patches AmsiScanBuffer and EtwEventWrite to prevent the triggering of any unwanted events by the system.
Once the preliminary checks are completed, the sample proceeds to gather information about the system. The list of capabilities is hardcoded and cannot be modified from the server side, in contrast to the Python version. What is more, the feature list is quite similar to the Python version except a few ones.
The stealer is capable of collecting information about known RDP connections that the compromised user has. To achieve this, it searches for .rdp files in %USERPROFILE%\Documents and extracts the full server address, password, username and server port.
The stealer also targets gamers and is capable to steal credentials from the popular gaming platform clients, including:
The native version, unlike its Python counterpart, is capable of capturing screenshots for each monitor via capCreateCaptureWindowA WinAPI.
In conclusion, this sample communicates with the C2 server through the same endpoints as the Python version. However, in this instance, all data is encrypted using the same AES-GCM + PBKDF2 (HMAC and SHA256) scheme as partially employed in the Python variant. In some observed samples, the key used was arkanix_secret_key_v20_2024. Alongside that, the C++ sample explicitly sets the User-Agent to ArkanixStealer/1.0.
| MD5 | 3283f8c54a3ddf0bc0d4111cc1f950c0 |
| File name | – |
This is an implant embedded within the resources of the C++ implementation. The author incorporated it into the resource section without applying any obfuscation or encryption. Subsequently, the stealer extracts the payload to a temporary folder with a randomly generated name composed of hexadecimal digits (0-9 and A-F) and executes it using the CreateProcess WinAPI. The payload itself is the unaltered publicly available project known as “ChromElevator”. To summarize, this tool consists of two components: an injector and the main payload. The injector initializes a direct syscall engine, spawns a suspended target browser process, and injects the decrypted code into it via Nt syscalls. The injected payload then decrypts the browser master key and exfiltrates data such as cookies, login information, web data, and so on.
During the Arkanix campaign, two domains used in the attacks were identified. Although these domains were routed through Cloudflare, a real IP address was successfully discovered for one of them, namely, arkanix[.]pw. For the second one we only obtained a Cloudflare IP address.
| Domain | IP | First seen | ASN |
| arkanix[.]pw | 195.246.231[.]60 | Oct 09, 2025 | – |
| arkanix[.]ru | 172.67.186[.]193 | Oct 19, 2025 | – |
Both servers were also utilized to host the stealer panel, which allows attackers to monitor their victims. The contents of the panel are secured behind a sign-in page. Closer to the end of our research, the panel was seemingly taken down with no message or notice.
Stealer panel sign-in page
During the research of this campaign, we noticed that the forum posts advertising the stealer contained a link leading to a Discord server dubbed “Arkanix” by the authors. The server posed as a forum where authors posted various content and clients could ask various questions regarding this malicious software. While users mainly thank and ask about when the feature promised by the authors will be released and added into the stealer, the content made by the authors is broader. The adversary builds up the communication with potential buyers using the same marketing and communication methods real companies employ. To begin with, they warm up the audience by posting surveys about whether they should implement specific features, such as Discord injection and binding with a legitimate application (sic!).
Feature votes
Additionally, the author promised to release a crypter as a side project in four to six weeks, at the end of October. As of now, the stealer seems to have been taken down without any notice while the crypter was never released.
Arkanix Crypter
Furthermore, the Arkanix Stealer authors decided to implement a referral program to attract new customers. Referrers were promised an additional free hour to their premium license, while invited customers received seven days of free “premium” trial use. As stated in forum posts, the premium plan included the following features:
Referral program ad and corresponding panel interface
Speaking of technical details, based on the screenshot of the Visual Studio stealer project that was sent to the Discord server, we can conclude that the author is German-speaking.
This same screenshot also serves as a probable indicator of AI-assisted development as it shares the common patterns of such assistants, e.g. the presence of the utils.cpp file. What provides even more confidence is the overall code structure, the presence of comments and extensive debugging log output.
Example of LLM-specific patterns
Information stealers have always posed as a serious threat to users’ data. Arkanix is no exception as it targets a wide range of users, from those interested in cryptocurrencies and gaming to those using online banking. It collects a vast amount of information including highly sensitive personal data. While being quite functional, it contains probable traces of LLM-assisted development which suggests that such assistance might have drastically reduced development time and costs. Hence it follows that this campaign tends to be more of a one-shot campaign for quick financial gains rather than a long-running infection. The panel and the Discord chat were taken down around December 2025, leaving no message or traces of further development or a resurgence.
In addition, the developers behind the Arkanix Stealer decided to address the public, implementing a forum where they posted development insights, conducted surveys and even ran a referral program where you could get bonuses for “bringing a friend”. This behavior makes Arkanix more of a public software product than a shady stealer.
Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.
File hashes
752e3eb5a9c295ee285205fb39b67fc4
c1e4be64f80bc019651f84ef852dfa6c
a8eeda4ae7db3357ed2ee0d94b963eff
c0c04df98b7d1ca9e8c08dd1ffbdd16b
88487ab7a666081721e1dd1999fb9fb2
d42ba771541893eb047a0e835bd4f84e
5f71b83ca752cb128b67dbb1832205a4
208fa7e01f72a50334f3d7607f6b82bf
e27edcdeb44522a9036f5e4cd23f1f0c
ea50282fa1269836a7e87eddb10f95f7
643696a052ea1963e24cfb0531169477
f5765930205719c2ac9d2e26c3b03d8d
576de7a075637122f47d02d4288e3dd6
7888eb4f51413d9382e2b992b667d9f5
3283f8c54a3ddf0bc0d4111cc1f950c0
Domains and IPs
arkanix[.]pw
arkanix[.]ru
OpenClaw faces security vulnerabilities and misconfiguration risks despite rapid patches and its transition to an OpenAI-backed foundation.
The post OpenClaw Security Issues Continue as SecureClaw Open Source Tool Debuts appeared first on SecurityWeek.
The cyberattack disrupted information and booking systems and lasted for several hours.
The post German Rail Giant Deutsche Bahn Hit by Large-Scale DDoS Attack appeared first on SecurityWeek.
The malware has been preinstalled on many devices but it has also been distributed through Google Play and other app stores.
The post New Keenadu Android Malware Found on Thousands of Devices appeared first on SecurityWeek.
The Series A funding round, led by Bain Capital, brings the total raised by Cogent to $53 million.
The post Cogent Security Raises $42 Million for AI-Driven Vulnerability Management appeared first on SecurityWeek.
Novee researchers discovered 16 vulnerabilities in Foxit and Apryse PDF tools that could have been exploited via malicious documents or URLs.
The post Vulnerabilities in Popular PDF Platforms Allowed Account Takeover, Data Exfiltration appeared first on SecurityWeek.
The title of the post is”What AI Security Research Looks Like When It Works,” and I agree:
In the latest OpenSSL security release> on January 27, 2026, twelve new zero-day vulnerabilities (meaning unknown to the maintainers at time of disclosure) were announced. Our AI system is responsible for the original discovery of all twelve, each found and responsibly disclosed to the OpenSSL team during the fall and winter of 2025. Of those, 10 were assigned CVE-2025 identifiers and 2 received CVE-2026 identifiers. Adding the 10 to the three we already found in the Fall 2025 release, AISLE is credited for surfacing 13 of 14 OpenSSL CVEs assigned in 2025, and 15 total across both releases. This is a historically unusual concentration for any single research team, let alone an AI-driven one.
These weren’t trivial findings either. They included CVE-2025-15467, a stack buffer overflow in CMS message parsing that’s potentially remotely exploitable without valid key material, and exploits for which have been quickly developed online. OpenSSL rated it HIGH severity; NIST‘s CVSS v3 score is 9.8 out of 10 (CRITICAL, an extremely rare severity rating for such projects). Three of the bugs had been present since 1998-2000, for over a quarter century having been missed by intense machine and human effort alike. One predated OpenSSL itself, inherited from Eric Young’s original SSLeay implementation in the 1990s. All of this in a codebase that has been fuzzed for millions of CPU-hours and audited extensively for over two decades by teams including Google’s.
In five of the twelve cases, our AI system directly proposed the patches that were accepted into the official release.
AI vulnerability finding is changing cybersecurity, faster than expected. This capability will be used by both offense and defense.
More.
The vulnerability added to CISA’s KEV catalog affects ThreatSonar Anti-Ransomware and it was patched in 2024.
The post CISA: Hackers Exploiting Vulnerability in Product of Taiwan Security Firm TeamT5 appeared first on SecurityWeek.
Koi has developed an endpoint security solution that Palo Alto will use to enhance its products.
The post Palo Alto Networks to Acquire Koi in Reported $400 Million Transaction appeared first on SecurityWeek.
GTIG and Mandiant said the zero-day tracked as CVE-2026-22769 has been exploited by UNC6201 since at least 2024.
The post Dell RecoverPoint Zero-Day Exploited by Chinese Cyberespionage Group appeared first on SecurityWeek.
Update, February 25, 2026: In response to widespread pushback, Wisconsin lawmakers have removed the provision banning VPN services from S.B. 130 / A.B. 105. The bill now awaits Governor Tony Evers’ signature. While the removal of the VPN provision is a positive step, EFF continues to oppose the bill. Advocates and residents across Wisconsin are urged to maintain pressure and encourage Governor Evers to veto the bill.
Wisconsin’s S.B. 130 / A.B. 105 is a spectacularly bad idea.
It’s an age-verification bill that effectively bans VPN access to certain websites for Wisconsinites and censors lawful speech. We wrote about it last November in our blog “Lawmakers Want to Ban VPNs—And They Have No Idea What They're Doing,” but since then, the bill has passed the State Assembly and is scheduled for a vote in the State Senate tomorrow.
In light of this, EFF sent a letter to the entire Wisconsin Legislature urging lawmakers to reject this dangerous bill.
You can read the full letter here.
The short version? This bill both requires invasive age verification for websites that host content lawmakers might deem “sexual” and requires that those sites block any user that connects via a Virtual Private Network (VPN). VPNs are a basic cybersecurity tool used by businesses, universities, journalists, veterans, abuse survivors, and ordinary people who simply don’t want to broadcast their location to every website they visit.
As we lay out in the letter, Wisconsin’s mandate is technically unworkable. Websites cannot reliably determine whether a VPN user is in Wisconsin, a different state, or a different country. So, to avoid liability, websites are faced with an unfortunate choice: either resort to over-blocking IP addresses commonly associated with commercial VPNs, block all Wisconsin users’ access, or mandate nationwide restrictions just to avoid liability.
The bill also creates a privacy nightmare. It pushes websites to collect sensitive personal data (e.g. government IDs, financial information, biometric identifiers) just to access lawful speech. At the same time, it broadens the definition of material deemed “harmful to minors” far beyond the narrow categories courts have historically allowed states to regulate. The definition goes far beyond the narrow categories historically recognized by courts (namely, explicit adult sexual materials) and instead sweeps in material that merely describes sex or depicts human anatomy. This approach invites over-censorship, chills lawful speech, and exposes websites to vague and unpredictable enforcement. That combination—mass data collection plus vague, expansive speech restrictions—is a recipe for over-censorship, data breaches, and constitutional overreach.
If you live in Wisconsin, now is the time for you to contact your State Senator and urge them to vote NO on S.B. 130 / A.B. 105. Tell them protecting young people online should not mean undermining cybersecurity, chilling lawful speech, and forcing residents to hand over their IDs just to browse the internet.
As we said last time: Our privacy matters. VPNs matter. And politicians who can't tell the difference between a security tool and a "loophole" shouldn't be writing laws about the internet.
(This appeared as an op-ed published February 12, 2026 in the San Jose Spotlight, written by Huy Tran (SIREN), Jeffrey Wang (CAIR-SFBA), and Jennifer Pinsof.)
As ICE and other federal agencies continue their assault on civil liberties, local leaders are stepping up to protect their communities. This includes pushing back against automated license plate readers, or ALPRs, which are tools of mass surveillance that can be weaponized against immigrants, political dissidents and other targets.
In recent weeks, Mountain View, Los Altos Hills, Santa Cruz, East Palo Alto and Santa Clara County have begun reconsidering their ALPR programs. San Jose should join them. This dangerous technology poses an unacceptable risk to the safety of immigrants and other vulnerable populations.
ALPRs are marketed to promote public safety. But their utility is debatable and they come with significant drawbacks. They don’t just track “criminals.” They track everyone, all the time. Your vehicle’s movements can reveal where you work, worship and obtain medical care. ALPR vendors like Flock Safety put the location information of millions of drivers into databases, allowing anyone with access to instantly reconstruct the public’s movements.
But “anyone with access” is far broader than just local police. Some California law enforcement agencies have used ALPR networks to run searches related to immigration enforcement. In other situations, purported issues with the system’s software have enabled federal agencies to directly access California ALPR data. This is despite the promises of ALPR vendors and clear legal prohibitions.
Communities are saying enough is enough. Just last week, police in Mountain View decided to turn off all of the city’s Flock cameras, following revelations that federal and other unauthorized agencies had accessed their network. The cameras will remain inactive until the City Council provides further direction.
Other localities have shut off the cameras for good. In January, Los Altos Hills terminated its contract with Flock following concerns about ICE. Santa Cruz severed relations with Flock, citing rising tensions with ICE. Most recently, East Palo Alto and Santa Clara County are reconsidering whether to continue their relationships with Flock, given heightened concern for the safety of immigrant communities.
California law prohibits local police from disclosing ALPR data to out-of-state or federal agencies. But at least 75 California police agencies were sharing these records out-of-state as recently as 2023. Just last year, San Francisco police allowed access to out-of-state agencies and 19 searches were related to ICE.
Even without direct access, ICE can exploit local ALPR systems. One investigation found more than 4,000 cases where police had made searches on behalf of federal law enforcement, including for immigration investigations.
Increasing the risk is that law enforcement routinely searches these networks without first obtaining a warrant. In San Jose, police aren’t required to have any suspicion of wrongdoing before searching ALPR databases, which contain a year’s worth of data representing hundreds of millions of records. In a little over a year, San Jose police logged more than 261,000 ALPR searches, or nearly 700 searches a day, all without a warrant.
Two nonprofit organizations, SIREN and CAIR California, represented by Electronic Frontier Foundation and the ACLU of Northern California, are currently suing to stop San Jose’s warrantless searches of ALPR data. But this is only the first step. A better solution is to simply turn these cameras off.
San Jose cannot afford delay. Each day these cameras remain active, they collect sensitive location data that can be misused to target immigrant families and violate fundamental freedoms. It is a risk materializing across California. City leaders must act now to shut down ALPR systems and make clear that public safety will not come at the expense of privacy, human dignity or community trust.
A practical framework for security leaders to build AI-ready teams. Learn to assess capabilities, prioritize training, and balance AI with foundational skills.
The post Building an AI-Ready Cybersecurity Team appeared first on OffSec.
SAN FRANCISCO — A new report released today offers journalists tips on cutting through the sales hype about police surveillance technology and report accurately on costs, benefits, privacy, and accountability as these invasive and often ineffective tools come to communities across the nation.
The “Selling Safety” report is a joint project of the Electronic Frontier Foundation (EFF), the Center for Just Journalism (CJJ), and IPVM.
Police technology is often sold as a silver bullet: a way to modernize departments, make communities safer, and eliminate human bias from policing with algorithmic objectivity. Behind the slick marketing is a sprawling, under-scrutinized industry that relies on manufacturing the appearance of effectiveness, not measuring it. The cost of blindly deferring to advertising can be high in tax dollars, privacy, and civil liberties.
“Selling Safety” helps journalists see through the spin. It breaks down how policing technology companies market their tools, and how those sales claims — which are often misleading — get recycled into media coverage. It offers tools for asking better questions, understanding incentives, and finding local accountability stories.
“The industry that provides technology to law enforcement is one of the most unregulated, unexamined, and consequential in the United States,” said EFF Senior Policy Analyst Matthew Guariglia. “Most Americans would rightfully be horrified to know how many decisions about policing are made: not by public employees, but by multi-billion-dollar surveillance tech companies who have an insatiable profit motive to market their technology as the silver bullet that will stop crime. Lawmakers often are too eager to seem ‘tough on crime’ and journalists too often see an easy story in publishing law enforcement press releases about new technology. This report offers a glimpse into how the police-tech sausage gets made so reporters and lawmakers can recognize the tactics of glossy marketing pitches, manufactured effectiveness numbers, and chumminess between companies and police.”
“Surveillance and other police technologies are spreading faster than public understanding or oversight, leaving journalists to do critical accountability work in real time. We hope this report helps make that work easier,” said Hannah Riley Fernandez, CJJ’s Director of Programming.
"The surveillance technology industry has a documented pattern of making unsubstantiated claims about technology,” said Conor Healy, IPVM's Director of Government Research. “Marketing is not a substitute for evidence. Journalists who go beyond press releases to critically examine vendor claims will often find solutions are not as magical as they may seem. In doing so, they perform essential accountability work that protects both taxpayer dollars and civil liberties."
EFF also maintains resources for understanding various police technologies and mapping those technologies in communities across the United States.
For the “Selling Safety” report: https://www.eff.org/document/selling-safety-journalists-guide-covering-police-technology
For EFF’s Street-Level Surveillance hub: https://sls.eff.org/
For EFF’s Atlas of Surveillance: https://www.atlasofsurveillance.org/
The latest funding round was led by Sorenson Capital and brings the total investment to $45 million.
The post VulnCheck Raises $25 Million in Series B Funding to Scale Vulnerability Intelligence appeared first on SecurityWeek.
Written by: Peter Ukhanov, Daniel Sislo, Nick Harbour, John Scarbrough, Fernando Tomlinson, Jr., Rich Reece
Mandiant and Google Threat Intelligence Group (GTIG) have identified the zero-day exploitation of a high-risk vulnerability in Dell RecoverPoint for Virtual Machines, tracked as CVE-2026-22769, with a CVSSv3.1 score of 10.0. Analysis of incident response engagements revealed that UNC6201, a suspected PRC-nexus threat cluster, has exploited this flaw since at least mid-2024 to move laterally, maintain persistent access, and deploy malware including SLAYSTYLE, BRICKSTORM, and a novel backdoor tracked as GRIMBOLT. The initial access vector for these incidents was not confirmed, but UNC6201 is known to target edge appliances (such as VPN concentrators) for initial access. There are notable overlaps between UNC6201 and UNC5221, which has been used synonymously with the actor publicly reported as Silk Typhoon, although GTIG does not currently consider the two clusters to be the same.
This report builds on previous GTIG research into BRICKSTORM espionage activity, providing a technical deep dive into the exploitation of CVE-2026-22769 and the functionality of the GRIMBOLT malware. Mandiant identified a campaign featuring the replacement of older BRICKSTORM binaries with GRIMBOLT in September 2025. GRIMBOLT represents a shift in tradecraft; this newly identified malware, written in C# and compiled using native ahead-of-time (AOT) compilation, is designed to complicate static analysis and enhance performance on resource-constrained appliances.
Beyond the Dell appliance exploitation, Mandiant observed the actor employing novel tactics to pivot into VMware virtual infrastructure, including the creation of "Ghost NICs" for stealthy network pivoting and the use of iptables for Single Packet Authorization (SPA).
Dell has released remediations for CVE-2026-22769, and customers are urged to follow the guidance in the official Security Advisory. This post provides actionable hardening guidance, detection opportunities, and a technical analysis of the UNC6201 tactics, techniques, and procedures (TTPs).
During analysis of compromised Dell RecoverPoint for Virtual Machines, Mandiant discovered the presence of BRICKSTORM binaries and the subsequent replacement of these binaries with GRIMBOLT in September 2025. GRIMBOLT is a C#-written foothold backdoor compiled using native ahead-of-time (AOT) compilation and packed with UPX. It provides a remote shell capability and uses the same command and control as previously deployed BRICKSTORM payload. It's unclear if the threat actor's replacement of BRICKSTORM with GRIMBOLT was part of a pre-planned life cycle iteration by the threat actor or a reaction to incident response efforts led by Mandiant and other industry partners. Unlike traditional .NET software that uses just-in-time (JIT) compilation at runtime, Native AOT-compiled binaries, introduced to .NET in 2022, are converted directly to machine-native code during compilation. This approach enhances the software’s performance on resource-constrained appliances, ensures required libraries are already present in the file, and complicates static analysis by removing the common intermediate language (CIL) metadata typically associated with C# samples.
UNC6201 established BRICKSTORM and GRIMBOLT persistence on the Dell RecoverPoint for Virtual Machines by modifying a legitimate shell script named convert_hosts.sh to include the path to the backdoor. This shell script is executed by the appliance at boot time via rc.local.
Mandiant discovered CVE-2026-22769 while investigating multiple Dell RecoverPoint for Virtual Machines within a victim’s environment that had active C2 associated with BRICKSTORM and GRIMBOLT backdoors. During analysis of the appliances, analysts identified multiple web requests to an appliance prior to compromise using the username admin. These requests were directed to the installed Apache Tomcat Manager, used to deploy various components of the Dell RecoverPoint software, and resulted in the deployment of a malicious WAR file containing a SLAYSTYLE web shell.
After analyzing various configuration files belonging to Tomcat Manager, we identified a set of hard-coded default credentials for the admin user in /home/kos/tomcat9/tomcat-users.xml. Using these credentials, a threat actor could authenticate to the Dell RecoverPoint Tomcat Manager, upload a malicious WAR file using the /manager/text/deploy endpoint, and then execute commands as root on the appliance.
The earliest identified exploitation activity of this vulnerability occurred in mid-2024.
During the course of the recent investigations, Mandiant observed continued compromise of VMware virtual infrastructure by the threat actor as previously reported by Mandiant, CrowdStrike, and CISA. Additionally, several new TTPs were discovered that haven’t been previously reported on.
Mandiant discovered the threat actor creating new temporary network ports on existing virtual machines running on an ESXi server. Using these network ports, the threat actor then pivoted to various internal and software-as-a-service (SaaS) infrastructures used by the affected organizations.
While analyzing compromised vCenter appliances, Mandiant recovered several commands from Systemd Journal executed by the threat actor using a deployed SLAYSTYLE web shell. These iptable commands were used for Single Packet Authorization and consisted of:
Monitoring incoming traffic on port 443 for a specific HEX string
Adding the source IP of that traffic to a list and if the IP is on the list and connects to port 10443, the connection is ACCEPTED
Once the initial approved traffic comes in to port 10443, any subsequent traffic is automatically redirected
For the next 300 seconds (five minutes), any traffic to port 443 is silently redirected to port 10443 if the IP is on the approved list
iptables -I INPUT -i eth0 -p tcp --dport 443 -m string --hex-string <HEX_STRING>
iptables -A port_filter -i eth0 -p tcp --dport 10443 --syn -m recent --rcheck --name ipt -j ACCEPT
iptables -t nat -N IPT
iptables -t nat -A IPT -p tcp -j REDIRECT --to-ports 10443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 --syn -m recent --rcheck --name ipt --seconds 300 -j IPTThe following investigative guide can assist defenders in analyzing Dell RecoverPoint for Virtual Machines.
The following artifacts are high-value sources of evidence for incident responders conducting full disk image analysis of Dell RecoverPoint for Virtual Machines.
Web logs for Tomcat Manager are stored in /home/kos/auditlog/fapi_cl_audit_log.log. Check log file for any instances of requests to /manager. Any instances of those requests should be considered suspicious
Any requests for PUT /manager/text/deploy?path=/<MAL_PATH>&update=true are potentially malicious. MAL_PATH will be the path where a potentially malicious WAR file was uploaded
Uploaded WAR files are typically stored in /var/lib/tomcat9
Compiled artifacts for uploaded WAR files are located in /var/cache/tomcat9/Catalina
Tomcat application logs located in /var/log/tomcat9/
Catalina - investigate any org.apache.catalina.startup.HostConfig.deployWAR and org.apache.catalina.startup.HostConfig.deployWAR events
Localhost - Contains additional events associated with WAR deployment and any exceptions generated by malicious WAR and embedded files
Persistence for BRICKSTORM and GRIMBOLT backdoors on Dell RecoverPoint for Virtual Machines was established by modifying /home/kos/kbox/src/installation/distribution/convert_hosts.sh to include the path to the backdoor
To assist the wider community in hunting and identifying activity outlined in this blog post, we have included IOCs in a free GTI Collection for registered users.
|
Family |
File Name |
SHA256 |
|
GRIMBOLT |
support |
|
|
GRIMBOLT |
out_elf_2 |
|
|
SLAYSTYLE |
default_jsp.java |
|
|
BRICKSTORM |
N/A |
|
|
BRICKSTORM |
splisten |
|
|
BRICKSTORM |
N/A |
|
|
BRICKSTORM |
N/A |
|
|
BRICKSTORM |
N/A |
|
|
Family |
Indicator |
Type |
|
GRIMBOLT |
|
C2 Endpoint |
|
GRIMBOLT |
|
C2 IP |
rule G_APT_BackdoorToehold_GRIMBOLT_1
{
meta:
author = "Google Threat Intelligence Group (GTIG)"
strings:
$s1 = { 40 00 00 00 41 18 00 00 00 4B 21 20 C2 2C 08 23 02 }
$s2 = { B3 C3 BB 41 0D ?? ?? ?? 00 81 02 0C ?? ?? ?? 00 }
$s3 = { 39 08 01 49 30 A0 52 30 00 00 00 DB 40 09 00 02 00 80 65 BC 98 }
$s4 = { 2F 00 72 00 6F 00 75 00 74 00 65 79 23 E8 03 0E 00 00 00 2F 00 70 00 72 00 6F 00 63 00 2F 00 73 00 65 00 6C 00 66 00 2F 00 65 00 78 00 65 }
condition:
(uint32(0) == 0x464c457f) //linux
and all of ($s*)
}rule G_Hunting_BackdoorToehold_GRIMBOLT_1
{
meta:
author = "Google Threat Intelligence Group (GTIG)"
strings:
$s1 = "[!] Error : Plexor is nul" ascii wide
$s2 = "port must within 0~6553" ascii wide
$s3 = "[*] Disposing.." ascii wide
$s4 = "[!] Connection error. Kill Pty" ascii wide
$s5 = "[!] Unkown message type" ascii wide
$s6 = "[!] Bad dat" ascii wide
condition:
(
(uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550) or
uint32(0) == 0x464c457f or
uint32(0) == 0xfeedface or
uint32(0) == 0xcefaedfe or
uint32(0) == 0xfeedfacf or
uint32(0) == 0xcffaedfe or
uint32(0) == 0xcafebabe or
uint32(0) == 0xbebafeca or
uint32(0) == 0xcafebabf or
uint32(0) == 0xbfbafeca
) and any of them
}rule G_APT_BackdoorWebshell_SLAYSTYLE_4
{
meta:
author = "Google Threat Intelligence Group (GTIG)"
strings:
$str1 = "<%@page import=\"java.io" ascii wide
$str2 = "Base64.getDecoder().decode(c.substring(1)" ascii wide
$str3 = "{\"/bin/sh\",\"-c\"" ascii wide
$str4 = "Runtime.getRuntime().exec(" ascii wide
$str5 = "ByteArrayOutputStream();" ascii wide
$str6 = ".printStackTrace(" ascii wide
condition:
$str1 at 0 and all of them
}Google Security Operations (SecOps) customers have access to these broad category rules and more under the “Mandiant Frontline Threats” and “Mandiant Hunting Rules” rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:
Web Archive File Write To Tomcat Directory
Remote Application Deployment via Tomcat Manager
Suspicious File Write To Tomcat Cache Directory
Kbox Distribution Script Modification
Multiple DNS-over-HTTPS Services Queried
Unknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services Communication
Unknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication
Unknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication
We appreciate Dell for their collaboration against this threat. This analysis would not have been possible without the assistance from across Google Threat Intelligence Group, Mandiant Consulting and FLARE. We would like to specifically thank Jakub Jozwiak and Allan Sepillo from GTIG Research and Discovery (RAD).
Here are three papers describing different side-channel attacks against LLMs.
“Remote Timing Attacks on Efficient Language Model Inference“:
Abstract: Scaling up language models has significantly increased their capabilities. But larger models are slower models, and so there is now an extensive body of work (e.g., speculative sampling or parallel decoding) that improves the (average case) efficiency of language model generation. But these techniques introduce data-dependent timing characteristics. We show it is possible to exploit these timing differences to mount a timing attack. By monitoring the (encrypted) network traffic between a victim user and a remote language model, we can learn information about the content of messages by noting when responses are faster or slower. With complete black-box access, on open source systems we show how it is possible to learn the topic of a user’s conversation (e.g., medical advice vs. coding assistance) with 90%+ precision, and on production systems like OpenAI’s ChatGPT and Anthropic’s Claude we can distinguish between specific messages or infer the user’s language. We further show that an active adversary can leverage a boosting attack to recover PII placed in messages (e.g., phone numbers or credit card numbers) for open source systems. We conclude with potential defenses and directions for future work.
“When Speculation Spills Secrets: Side Channels via Speculative Decoding in LLMs“:
Abstract: Deployed large language models (LLMs) often rely on speculative decoding, a technique that generates and verifies multiple candidate tokens in parallel, to improve throughput and latency. In this work, we reveal a new side-channel whereby input-dependent patterns of correct and incorrect speculations can be inferred by monitoring per-iteration token counts or packet sizes. In evaluations using research prototypes and production-grade vLLM serving frameworks, we show that an adversary monitoring these patterns can fingerprint user queries (from a set of 50 prompts) with over 75% accuracy across four speculative-decoding schemes at temperature 0.3: REST (100%), LADE (91.6%), BiLD (95.2%), and EAGLE (77.6%). Even at temperature 1.0, accuracy remains far above the 2% random baseline—REST (99.6%), LADE (61.2%), BiLD (63.6%), and EAGLE (24%). We also show the capability of the attacker to leak confidential datastore contents used for prediction at rates exceeding 25 tokens/sec. To defend against these, we propose and evaluate a suite of mitigations, including packet padding and iteration-wise token aggregation.
“Whisper Leak: a side-channel attack on Large Language Models“:
Abstract: Large Language Models (LLMs) are increasingly deployed in sensitive domains including healthcare, legal services, and confidential communications, where privacy is paramount. This paper introduces Whisper Leak, a side-channel attack that infers user prompt topics from encrypted LLM traffic by analyzing packet size and timing patterns in streaming responses. Despite TLS encryption protecting content, these metadata patterns leak sufficient information to enable topic classification. We demonstrate the attack across 28 popular LLMs from major providers, achieving near-perfect classification (often >98% AUPRC) and high precision even at extreme class imbalance (10,000:1 noise-to-target ratio). For many models, we achieve 100% precision in identifying sensitive topics like “money laundering” while recovering 5-20% of target conversations. This industry-wide vulnerability poses significant risks for users under network surveillance by ISPs, governments, or local adversaries. We evaluate three mitigation strategies – random padding, token batching, and packet injection – finding that while each reduces attack effectiveness, none provides complete protection. Through responsible disclosure, we have collaborated with providers to implement initial countermeasures. Our findings underscore the need for LLM providers to address metadata leakage as AI systems handle increasingly sensitive information.
Before tools, before frameworks, before hype, offensive security has always been about one thing: Thinking like an attacker. That foundation now defines the offensive AI security skills practitioners will need as AI reshapes the attack surface. AI systems introduce new behaviors and new failure modes, but the core mindset remains the same: understand how a
The post The Skills That Will Matter for Offensive AI Security in 2026 appeared first on OffSec.
Researchers at ETH Zurich have tested the security of Bitwarden, LastPass, Dashlane, and 1Password password managers.
The post Password Managers Vulnerable to Vault Compromise Under Malicious Server appeared first on SecurityWeek.
