Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing
Threat actors are no longer just using automation to execute tasks, they are leveraging prepackaged, safeguard-free AI, weaponizing stolen session data, and directly targeting defenders’ security stacks.
The threat landscape has developed at a striking pace with Flashpoint tracking over 22 million illicit AI discussions, 7.4 million compromised hosts yielding 1.7 billion stolen credentials, and over 21,600 disclosed vulnerabilities in just six months. Beyond these staggering numbers, the on-demand session detailed something even more alarming: a fundamental shift in adversary operational tradecraft.
Here are the five critical shifts every cyber threat intelligence (CTI), Vulnerability Management, and SOC team needs to know.
The Death of Signal: Threat Actors are Shifting to “Private AI”
The public discussion surrounding criminal artificial intelligence (AI) has reached a critical inflection point. Early in the AI boom, Flashpoint observed threat actors collaboratively experiment across underground forums, jailbreaking commercial frontier models or advertising surface-level tools like WormGPT and DarkGPT.
Today, adversaries are shifting from public forums to running fine-tuned, open-source models locally on private servers, which greatly hampers traditional signature-based detection. Flashpoint analysts are now seeing attackers generate unique, highly tailored malware variants, flawless phishing lures, and custom exploit scripts at extremely low costs—completely offline and shielded from public monitoring.
“A few months ago, a lot of this was collaborative… public outsourcing. Now what we’re seeing is scarier: pre-packaged cybercrime models run locally on private infrastructure. Malicious code, exploit scripts, and targeted phishing are all being generated inside closed environments.”
Ian Gray, VP of Intelligence, Flashpoint
Weaponizing the Defender’s Own Tooling
Another eye-opening tactical insight shared during the session was how threat actors are repurposing defender infrastructure for automated initial access and extortion. In the webinar, we pointed to recent campaigns where adversaries specifically targeted misconfigurations and zero-day vulnerabilities inside open-source vulnerability scanners, secrets-detection tools, Kubernetes clusters, and Infrastructure-as-Code(IaC) environments.
What this means for defenders is that the attack surface is no longer bounded by traditional enterprise network boundaries: it extends directly into CI/CD pipelines, security orchestration tooling, and third-party SaaS integrations. Security teams are finding themselves in a race against attackers who use automated scanning scripts to weaponize vulnerabilities in the security tools themselves.
The Global Infostealer Threat and Identity-First Attacks
Flashpoint tracked 7.4 million hosts compromised by infostealers in H1 2026—a 27% increase period-over-period—harvesting 1.7 billion credentials and identity information.
While the top infostealer strains remain familiar, law enforcement operations have created vacuums that competitors rapidly fill.
Threat actors are leveraging drive-by downloads, watering holes, and pirated software packages to plant stealers. Once a machine is compromised, the logs capture corporate SSO credentials, active browser cookies, VPN keys, and SaaS session tokens. This enables adversaries to simply log in without having to leverage complex technical exploits.
The Structural Failure of CVE/NVD and the Importance of KEV
The Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) have failed to keep pace with the velocity of AI-assisted vulnerability discovery. As such, vulnerability management teams are facing significant operational delays.
Metric
Flashpoint GTIR Midyear H1 2026 Data
Operational Impact
Total Disclosures
21,667
Remediation volume exceeds defender bandwidth.
Exploit Availability
19% (4,015 CVEs)
Functional code is ready before patches are deployed.
Public Catalog Lag
Growing Backlog (NVD/KEV)
Delay in official scoring leaves teams blind to active risk.
Therefore, waiting for NVD enrichment before prioritizing a patch is a dangerous strategy. To compensate, security teams require Vulnerability Intelligence (VI) that provides primary-source confirmation of weaponization, exploit availability, and actionable mitigation guidance long before public databases update.
Ransomware Evolution: From Encryption to Cloud Extortion
Ransomware-as-a-Service (RaaS) activity surged by 45% period-over-period, reaching 6,256 verified victim postings on data leak sites. However, total on-chain payout revenue dropped by 8% to $820 million, with victim pay-rates hitting a record low of 28%.
Faced with declining payouts and resilient enterprise backups, extortion syndicates are adapting. Rather than relying exclusively on technical file-encrypting malware, groups are executing pure data extortion campaigns—frequently targeting cloud platforms or extracting data through third-party vendor access.
Protect Your Organization Using Flashpoint
Defending against machine-speed attacks requires moving beyond reactive, post-incident telemetry. Flashpoint arms security, CTI, and vulnerability management teams with the primary-source intelligence required to preempt adversary operations:
Unrivaled Deep & Dark Web Visibility: Flashpoint’s Primary Source Collection actively monitors closed criminal communities, illicit Telegram channels, and private forums, giving you early warning when threat actors build custom AI toolkits or trade credentials targeting your organization.
Comprehensive Vulnerability Intelligence (VI): Flashpoint tracks zero-days and vulnerability disclosures independently, delivering immediate exploit availability data and threat-informed prioritization so you patch what actually matters.
Continuous Compromised Credential Monitoring: Instantly surface exposed enterprise credentials, active session tokens, and stealer logs tied to your domain or third-party supply chain before they lead to an account takeover (ATO).
In the first half of 2026, the global threat landscape reached a clear operational inflection point: threat operations have fundamentally transitioned from human-led campaigns to machine-speed, AI-driven exploitation. As threat actors gain commoditized access to open-source AI technologies and actively deploy automated, safeguard-free tooling locally on private infrastructure, organizations face an accelerating hybrid risk environment.
Flashpoint’s Global Threat Intelligence Report: 2026 Midyear Edition
The Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition anchors security leaders—from threat intelligence, vulnerability management, to executive leadership—in the data required to navigate this evolving threat landscape. Covering the period from January 1 to June 30, 2026, the report delivers timely insights backed by Flashpoint’s proprietary primary-source collection from over 3.9 petabytes of continuously monitored illicit sources.
Our midyear findings reveal several key metrics that highlight the speed and scale of the H1 2026 threat landscape:
22M+ threat actor posts discussed, shared, or advertised artificial intelligence toolkits for criminal deployment.
1.7B credentials and identity data points extracted across more than 7.4M unique compromised hosts globally.
Nearly one-in-five (19%) of all vulnerability disclosures dropped with ready-made, functional exploit code.
45% period-over-period surge in Ransomware-as-a-Service (RaaS), with total victim volume reaching 6,256 even as victim payout rates dropped to a historic low of 28%.
A Clear Understanding of the Convergence Between AI and Cyber Threats From generating flawless phishing campaigns to automating vulnerability scanning and code obfuscation, discover how adversaries are optimizing for speed and cost-efficiency — utilizing AI as a force multiplier in their various illicit campaigns.
A Comprehensive Top-Down View of the Evolving Threat Landscape Gain full visibility of the threat landscape with Flashpoint’s primary-source collections and real-time threat intelligence.
Strategies for Proactive Defense and Risk Mitigation Move your organization beyond reactive incident response by leveraging Flashpoint’s comprehensive threat intelligence. Gain the foresight needed to strengthen defenses and optimize your security posture.
“AI is compressing the time between opportunity and exploitation. Capabilities that once took significant expertise, coordination, and time to develop are becoming faster to build, easier to scale, and harder to detect. Security teams are facing an adversary ecosystem that can use AI to iterate at unprecedented speed — the only way to keep pace is with primary-source intelligence that surfaces adversary behavior before attacks unfold.”
Josh Lefkowitz, Flashpoint Co-Founder & CEO
The Four Driving Themes Shaping the 2026 Threat Landscape
Artificial Intelligence (AI) Threats
During the first half of 2026, Flashpoint captured over 22M illicit posts discussing or advertising AI for criminal-related activities. By stripping ethical safeguards, custom malicious LLMs allow unsophisticated threat actors to automate complex phases of the attack lifecycle, including target profiling, malware evasion script creation, and zero-day exploit generation.
Information-Stealing Malware Threats
Infostealer malware harvested 1.7 billion credentials across 7.4 million compromised systems in H1 2026 alone, turning digital identity into the main entry point for enterprise intrusions.
Vulnerability Intelligence and Patching Management
19% (4,015) of all H1 2026 vulnerability disclosures arrived with ready-made exploit code. Adversaries deploy automated replication scripts almost immediately upon disclosure, eliminating manual remediation windows.
Ransomware Operations, Multi-Extortion Cartels, and Financial Risk
Despite a 45% surge in victim volume (6,256 overall), total on-chain revenue fell by 8% to $820M. Improved enterprise backups and incident response have driven payout rates down to 28%, prompting syndicates to demand larger sums from paying victims.
Proactive Security in 2026 and Beyond
The data shows that traditional enterprise security organizations are struggling to keep pace with modern threat cycles that are accelerated by illicit uses of AI. This continued convergence of AI engines and initial access vectors have further compressed attack timelines, making it nearly impossible for security teams to defend against them—especially if they are limited by traditional approaches to threat intelligence.
Equipping your team with primary-source threat intelligence is critical for protecting critical assets in 2026. Download the Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition to gain the visibility and strategic clarity required to defend your organization.
We have been tracking two new backdoors, OctLurk and SilkLurk, observed in attacks against government organizations primarily in Central Asia since January 2025. Identified victims are located in Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan, and the Syrian Arab Republic. These organizations operate across several sectors, including healthcare, research, government offices, ministries of foreign affairs, logistics, law‑enforcement agencies, urban planning and facilities management, and public educational establishments.
The backdoor loaders are customized for each victim and use information from the victim’s machine to decrypt the payload. Both the loaders and the backdoors are heavily obfuscated, making analysis more complicated. OctLurk and SilkLurk can download and inject additional plugins to perform further malicious actions, including launching command shells, performing file system activity, synthesizing keyboard and mouse events, network scanning, credential dumping, keylogging, password theft from browsers, email collection, and remote access. Furthermore, the attackers deployed a specialized utility we named LurkProxy, which we also cover in this report. While it has a highly similar architecture to the OctLurk backdoor, it is not a backdoor itself.
Our investigation shows that the same threat actor operates both SilkLurk and OctLurk , and some victims infected with SilkLurk also contain OctLurk. We assess with medium confidence that the same actor is behind both backdoors, and that they are Chinese‑speaking. However, at the time of publication, we couldn’t attribute this activity to any known group.
OctLurk
OctLurk Deployment
The attacker created a scheduled task named GoogleUpDate on remote machines using admin credentials. The task runs once with System account privileges right after it was created, executing the batch script located at C:\Users\<username>\Videos\1.bat (MD5 6ecf84fb18f6747ed08d7598364d853a). Prior to executing the task, the actor queries its status. It is then run, as shown below.
The 1.bat script creates a service named NgcCIntSvc, which loads the loader DLL named oleasapi.dll (MD5 082d49ef9f14e6811d68c7e0e82e5069). The ServiceMain parameter in the service’s registry entry is set to invoke the RegisterService function of oleasapi.dll as shown below.
LurkPoxy Deployment
In another case, the attacker at first checked connectivity to the domain dns[.]ssentialserv[.]xyz as shown below. At the time of our research, the domain was resolving to the address 154[.]196[.]162[.]76 which is used as a LurkProxy C2 server.
After confirming that the C2 server was reachable, the attacker executed the batch script C:\Users\[username]\Desktop\auto.bat (MD5 b874123a80fc4f40e06872b9cb54ebc6). The script created a service named Cusrxsrv, which loads a DLL named msbasesysdc.dll. In the service registry, the ServiceMain parameter was set to call the RegisterService function of msbasesysdc.dll as shown below.
We identified several service names — specitsrc, cmtastsvc, PNRPHostSvc, vmictimerosync, and vmicagent — that the attackers used to load a malicious DLL onto compromised machines.
OctLurk loader
The loader DLL exports two methods, Refresh and RegisterService. The previously created service first calls RegisterService, which in turn invokes Refresh, the method that contains the malicious code. To locate the payload, the loader double-XOR-decrypts and then zlib-decompresses a set of hard‑coded bytes, yielding the payload file path. The payload bytes itself undergoes the same double‑XOR decryption and zlib decompression to produce the backdoor DLL bytes.
The double‑XOR decryption uses two distinct multibyte keys:
Key 1: hard‑coded in the loader
Key 2: derived from the serial number of the C: drive
The backdoor DLL is reflectively injected into memory and its entry point is executed. The loader can then call the DLL’s exported methods either by name or by ordinal; both the method name and the ordinal number are hard‑coded in the loader and are decrypted using the same double‑XOR and zlib‑decompression process applied to the payload path and bytes.
OctLurk backdoor
The loader invokes the backdoor’s curl_easy_escape function (ordinal 2). The backdoor then creates a stream socket using a hard‑coded C2 address (dns[.]multitoconference[.]com) and port 443. It gathers the following information from the victim machine:
OS information as RTL_OSVERSIONINFOW structure
Computer name
User name
Local host name
Local IP address in format %u.%u.%u.%u, with local hostname-to-IP-address translation
Current local date and time as SYSTEMTIME struct
To encrypt the collected data, the backdoor employs a hard‑coded XOR key, which in most cases we observed was the string FDrertgr##@QEWASGkio865ehyf98foidsjzhug874392dfsREFDfdsAGH43wea98h. In addition, it generates 0x53 (83) random bytes — this length is also hard‑coded in the sample — and uses them as a second XOR key. The collected victim information is first compressed with zlib (deflate), and then XOR‑encrypted twice, first with the hard‑coded string key and then with the randomly generated byte sequence. The final data is arranged as follows:
The backdoor initially transmits a 16‑byte header that specifies the size of the incoming data packet, as shown below. It then sends the actual data packet.
0x00: randomly picked 10 chars from the string “zyxwvutsrqponmlkjihgfedcbaABCDEFGHIJKLMNOPQRSTUVWXYZ9876543210-_”
0x0A: \x00\x00
0x0C: next_packet_size
The first packet received is 16 bytes long, and its last four bytes specify the size of the subsequent data packet. The format of the subsequent data packet is shown below.
0x00: XOR key; size 83 bytes
0x53: compressed data size
0x57: compressed data in the format: <uncompressed_size> <deflate(data)>
The received data is decrypted using a double‑XOR method: first with the XOR key contained in the packet, then with a hard‑coded XOR key. After the XOR decryption, the data is zlib decompressed. The data may be a command or a plugin code.
OctLurk loads plugins from the C2 server directly into memory to perform various tasks. Each plugin exports two methods — ins_ctl_db and oct_lk_col — with the actual functionality implemented in oct_lk_col. Our analysis shows that the plugins listed below are commonly deployed on victim machines.
Command Shell: provides a command shell
File Manager: performs filesystem interaction
Interaction Manager: synthesizes keyboard and mouse events
The table below provides a detailed description of operations performed by these plugins, where each switch case value denotes command ID.
Plugin type
Description
File Manager
● case 0x10020: for each drive, retrieve the following information: volume GUID path, drive letter, volume name, file system name, drive type, volume serial number, total size in bytes, and free space in bytes.
● case 0x10030: search for a file that matches a specified name and retrieve the following information: file attributes, creation time, last access time, last write time, file size, the file’s name, and its short (8.3) name.
● case 0x10040: recursively list all files in a specified location, including only those whose size, creation time, last write time, and last access time fall within the threshold values defined by C2. For each listed file, retrieve the following details: file attributes, creation time, last access time, last write time, file size, file name and alternative name for the file
● case 0x10050: use the ShellExecuteExW API to open the specified file path, which may be an executable, a document, or a folder.
● case 0x10051: execute the specified command line using the CreateProcessAsUserW API.
● case 0x10060: perform the following file‑system operations: copy, delete, move, and rename — using the SHFileOperationW API.
● case 0x10070: create a directory.
● case 0x10080: set the attributes for a file or directory.
● case 0x10090: for the filename provided by C2, set the file created, last accessed, and last modified timestamps to the values received from C2.
● case 0x20010: get the size of a file.
● case 0x20020: read a file from the system in chunks, starting at a specified offset.
● case 0x20030: calculate the CRC32 of each file data chunk, and retrieve the file created, last accessed, and last written times.
● case 0x20040: close the file handle and free the associated metadata (file path, handle, and size).
● case 0x20110: create a file at the specified path and write the bytes received from C2 into it. Then set the file created, last accessed, and last modified times using the timestamps supplied by C2.
Command Shell
● case 0x3E9: launch cmd.exe as shell.
● case 0x3EA: send the exit command to close the command shell.
● case Default: if a command string is received from the C2 and the shell is running, write the command to the shell. Then read the shell’s output and send it back to the C2.
If a command string is received from the C2 server and the shell is not already running, execute the command using C:\Windows\System32\cmd.exe /S /C "<command_string>" > %TEMP%\tmp%d%x.tmp where %d and %x are random values. Afterwards, read the output from the temporary file tmp%d%x.tmp and then delete the file.
Interaction Manager
● case 0x3E9: capture the entire screen as a BMP image.
● case 0x3EA: capture the entire screen at specified intervals.
● case 0x3EC: retrieve clipboard data.
● case 0x3ED: copy the data to the clipboard.
● case 0x3F3: MOUSEEVENTF_LEFTDOWN: set the cursor to the specified position and press the left mouse button.
● case 0x3F5: MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP: move the cursor to the specified position, then press and release the left mouse button.
● case 0x3F6: MOUSEEVENTF_RIGHTDOWN: set the cursor to the specified position and press the right mouse button.
● case 0x3F7: MOUSEEVENTF_RIGHTUP: set the specified cursor position and release the right mouse button.
● case 0x3F8: MOUSEEVENTF_MOVE: move the mouse cursor to specific coordinates, simulating a mouse movement event.
● case 0x3F9: MOUSEEVENTF_WHEEL: move the mouse wheel by a specified amount.
● case 0x3FD: press the key indicated by the virtual‑key code.
● case 0x3FE: KEYEVENTF_KEYUP: release the key identified by the virtual-key code.
● case DEFAULT: MOUSEEVENTF_LEFTUP: move the cursor to the specified position and release the left mouse button.
Post-compromise activity
The attacker used the command‑shell plugin installed via the OctLurk backdoor to perform the following actions:
Victim fingerprinting
The attacker used admin credentials to create a scheduled task named GoogleUpDate on remote machines. This task runs once with System account privileges, executing the script located at C:\windows\temp\in.bat (MD5 45cf5916fab4272a1313c26e67aa9220, 4e6d5c4770d5a822d7fcce6a74f7ad73). After querying the task’s status, the attacker triggers its execution, as shown below.
The batch script runs a series of commands that collect comprehensive information about the machine’s hardware, software, and network configuration as shown in the table below. The results are saved in three files — info.txt, <hostname>.datb, and <hostname>_logs.datb — all stored in the %TEMP% directory.
Command
Description
chcp 1256
Changes the system’s code page to 1256, which supports Arabic characters.
powershell $PSVersionTable
Retrieves the version information of PowerShell.
qwinsta
Views all active sessions on the local machine.
klist sessions
Displays a list of logon sessions on this computer (Including Kerberos).
TASKLIST /V
Lists all running tasks with detailed information.
findstr /i /c:”explorer.exe”
Searches for explorer.exe in a case-insensitive manner. Used together with TASKLIST /V.
wevtutil qe Security /f:text /c:5 /rd:true /q:”*[System[(EventID=4624)]] and *[EventData[Data[@Name=’LogonType’]=10]]”
Retrieves the last 5 events from the Security event log where the event ID is 4624 (successful logon event) and the logon type is 10 (remote interactive logon e.g., Remote Desktop Protocol).
Displays detailed information about the current user, including their security identifiers (SIDs), privileges, group memberships, and authentication details.
Searches the Windows Registry under HKEY_LOCAL_MACHINE (HKLM) for entries where the value name is “ProfileImagePath” and the type is REG_EXPAND_SZ. It points to the location of a user’s profile folder.
cmd.exe /c dir /b c:\users
Lists the contents of the C:\Users directory.
wmic startup get caption,command | findstr exe
Filters startup items for executable files.
powershell “get-MpComputerStatus”
Retrieves the status and configuration details of Microsoft Defender Antivirus (formerly Windows Defender) on a Windows system.
Queries exclusion settings for Microsoft Defender Antivirus. This is where you can configure files, folders, processes, and extensions that should be excluded from being scanned by Defender.
wevtutil gli Security
Configures the Security event log.
wevtutil gl Security /f:xml
Retrieves events from the Security log in XML format.
wevtutil gli “Windows PowerShell”
Configures the Windows PowerShell event log.
wevtutil gl “Windows PowerShell” /f:xml
Retrieves events from the Windows PowerShell log in XML format.
wevtutil gli System
Configures the System event log.
wevtutil gl System /f:xml
Retrieves events from the System log in XML format.
schtasks /query /fo LIST /v | findstr “TaskName> Status> ‘Task To Run’> ‘Run As User’>”
Lists all scheduled tasks in verbose mode and extracts the following fields: Status, Task To Run, Run As User, and TaskName.
Provides network configuration details, such as IP address, DNS, DHCP status, etc.
ipconfig /all
Displays detailed network configuration.
netstat -e -s
Displays detailed network protocol statistics.
certutil -urlcache
Displays URL cache entries.
ipconfig /displaydns
Displays the contents of the DNS client resolver cache.
Event log collection
The attackers ran commands to export successful logon events for remote interactive logons (e.g., Remote Desktop Protocol) and to query those events for specific users.
Credential harvesting
Impacket — secretsdump
Attackers ran a malicious file named Adobe.exe (MD5 32a5985543433a4f60da2fafd873b927), which is a portable‑executable version of Impacket’s secretsdump.py tool. Using this tool, they extracted password hashes from domain controllers, the critical servers in an Active Directory environment. Immediately after harvesting the hashes, they issued commands to list all members of the “Domain Controllers” group, likely to identify and target additional domain controllers for further compromise.
Keylogger
Attackers dropped and executed a keylogger located at C:\Users\Public\Pictures\AnyDesk.exe (MD5: 2a571f6cee42a17d873f4c942649813f). They then created a scheduled task named AnyDesk to run the keylogger whenever any user logged on as shown below.
The keylogger creates two files: C:\Users\Public\Libraries\msect\dev0, which stores captured keystrokes, and C:\Users\Public\Libraries\msect\dev1, which holds clipboard data. Before writing to these files, the captured data is encoded by subtracting 2 from each byte.
Browser Password Decryptor
The Browser Password Decryptor tool C:\users\[username]\libraries\64.exe (MD5 37dc84e4bcad92fa28f1e7778d088283) is used to extract passwords from browsers. The tool offers two options: -help to extract passwords from Chrome and -exit to extract passwords from Firefox. For Chrome, the tool targets the Login Data and Local State databases located at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data and %LOCALAPPDATA%\Google\Chrome\User Data\Local State, respectively. The Local State contains the master key, which is essential for decrypting encrypted login information stored in the Login Data database file. For Firefox, the tool targets the logins.json file located at %APPDATA%\Mozilla\Firefox\Profiles\{profile folder}. The logins.json file in Firefox stores encrypted usernames and passwords for websites.
Pandora RC agent provides remote control of a victim’s computer, allowing attackers to monitor and manipulate the system. Using administrative credentials, the attacker creates a scheduled task named GoogleUpDate on the compromised machines. This task runs once with System account privileges and executes the script 1.bat, which can be found at either C:\Users\[username]\1.bat or C:\ProgramData\1.bat (MD5 5e26df131ff0a679a0a2699b723b46e3). The task’s status is first queried, then it is executed, as shown below.
The batch script 1.bat executes a command that downloads and installs the Pandora RC agent using the arguments shown below.
EHUSER: a Pandora RC user
STARTEHORUSSERVICE: start the agent after the installation finishes (default = 1)
EHORUSINSTALLFOLDER: specify the folder where you want to install the agent (default: %ProgramFiles%\_agent)
DESKTOPSHORTCUT: 0: do not create a desktop shortcut
Network scan: FSCAN
Fscan is a comprehensive internal‑network scanning tool that offers a range of functions, including network discovery, vulnerability assessment, reverse‑shell creation, and brute forcing of common services. The executable is dropped to %TEMP%\fc.exe (MD5: cf903e4a1629aa0582fd0363b5786676) and writes its output to %TEMP%\result.txt. Using Fscan, both internal and public networks were scanned to identify services running on specific ports, such as Secure Shell (SSH) on port 22 and MySQL on port 3306. The tool also attempted to access these services using credentials from the password file pp.txt.
Email harvesting
The attackers used the curl command to connect to an email server, authenticate with a username and password, and issue a command to select the Inbox folder. Typically, the goal is to:
Verify that a connection to the email server is working
Authenticate the user
Prepare the Inbox folder for reading or manipulating messages (e.g., listing, fetching, or deleting emails)
LurkProxy
In a similar manner to the OctLurk backdoor, the attacker also deployed another implant we named LurkProxy, which uses a heavily obfuscated version of the OctLurk loader. While LurkProxy has a nearly identical architecture to the OctLurk backdoor, its primary role is to proxy network traffic. Like the OctLurk, it exports a function named curl_escape_easy, which the loader invokes. Once executed, LurkProxy listens on all interfaces on hard‑coded port 64980 and establishes a TLS‑encrypted connection to the C2 server (154[.]196[.]162[.]76). The C2 communication uses a proprietary binary protocol, where each packet is compressed with zlib, encrypted with a double‑XOR scheme, and follows the structure outlined below.
Offset
Data
Type
0x00 (00)
Unused
–
0x08 (08)
Packet control flags. Bit 0 indicates high priority packet, bit 1 indicates single packet
bit array
0x0C (12)
Command number
int
0x10 (16)
Handler number (unique identifier for each proxy client in the first mode)
int
0x14 (20)
Command integer argument
int
0x18 (24)
Unused
–
0x1C (28)
Data 1 payload size
int
0x20 (32)
Data 2 payload size
int
0x24 (36)
Data 1 byte stream
bytes
0x24 (36) + N
Data 2 byte stream
bytes
LurkProxy can function as a reverse proxy in two distinct modes as described below. The mode is selected by a static flag, meaning the proxy can operate in only one mode at a time. In the implant we examined, the first (SOCKS5) mode was used.
Mode 1: SOCKS5 proxy
When a client connects, LurkProxy sends to the C2 the command 0x1000010, indicating that the connection has been established and includes the target address in the packet data. The C2 server then opens a connection to that address, enabling bidirectional communication through the appropriate commands.
Mode 2: transparent proxy
In this mode, the target address and port are hard‑coded. Upon startup, LurkProxy immediately connects to the predefined target via the C2 channel using the same command. All subsequent client connections are routed through this single, fixed target. This mode handles raw network traffic directly, bypassing the SOCKS5 layer.
Command ID
Direction
Description
Arguments
0x1000010
Implant -> C2
When a new proxy client connects, it creates a proxy session and notifies C2 of the successful configuration
Target port in command integer argument
UTF-16 encoded connection hostname in data 1
0x1000010
C2 -> Implant
Used to control the session, allowing it to pause or stop proxying
Action in command integer argument (1 to pause, or any other value to terminate)
0x1000030
Implant -> C2
Sent when the LurkProxy is shut down
–
0x1000050
Implant -> C2
Forwards the received bytes from the client to C2
Raw TCP bytes in data 1
0x1000050
C2 -> Implant
Forwards the received bytes from the proxy target to the client
Raw TCP bytes in data 1
SilkLurk
Deployment
The attacker created a service that executes legitimate binaries, such as NetSetSvc.exe (NVIDIA debug dump), nvgwls.exe (NVIDIA background tool responsible for autotuning), RtkSmbus.exe (Realtek Semiconductor’s noise‑cancelling program), and RtkNGUI64.exe (Realtek High‑Definition Audio Manager), to side‑load malicious loader DLLs: nvml.dll, vulkan-1.dll, RtkSmbusLoc.dll, and RtkNGUI64Loc.dll, respectively. These DLLs act as a loader that will inject SilkLurk backdoor into the process memory.
SilkLurk loader
SilkLurk loader working logic
The loader first verifies that it is running within the legitimate executable that loads it. Next, it moves the payload file (in the analyzed sample, it was named OneDrive.dat) from its module location (C:\ProgramData\Microsoft\Network\Connections in the analyzed sample) to the hard‑coded payload path (C:\ProgramData\Microsoft OneDrive\setup in the analyzed sample). Note that the hard-coded payload path may vary depending on the loader.
Next, the loader creates a service named RmSs to maintain persistence. The service will run the legitimate module binary (C:\ProgramData\Microsoft\Network\Connections\nvgwls.exe) that loads the malicious loader (vulkan-1.dll). The service is configured with the parameters mentioned below. Additionally, the service configuration is modified to restart the service in the event of a failure. Finally, the loader starts the service.
Service Type:SERVICE_WIN32_OWN_PROCESS
Start Type:SERVICE_AUTO_START
Error Control:SERVICE_ERROR_NORMAL
On service start, loader calls StartServiceCtrlDispatcher, which will invoke ServiceProc. The ServiceProc then calls the routine s_1800078F0_decrypt_and_run_payload. This routine computes a 32-bit hash (dword) of the victim’s computer name. The dword hash is used by a custom algorithm made up of arithmetic and logical operations to decrypt the hardcoded payload file path. The payload bytes themselves are decrypted with the same algorithm that decoded the file path. By using the victim’s computer name in the decryption of both the file path and the payload bytes, the loader becomes specific to each victim. The decrypted bytes contain shellcode with the following structure:
Shellcode offset
Description
0x000 (0)
Stub code, which performs reflective code injection
0x770 (1904)
Hardcoded value 0x11113F68, XORed with the computer name hash
0x774 (1908)
Hardcoded byte 0xD9, used as XOR key to decrypt import DLL names and APIs
0x775 (1909)
Size of the encrypted backdoor
0x779 (1913)
Encrypted backdoor data blob
The stub code decrypts and injects the backdoor blob into memory. To decrypt the blob, it first computes a dword hash of the computer’s name. This hash is then fed into a custom algorithm — a series of arithmetic and logical operations — that performs the decryption. This algorithm differs from the one used to decrypt the payload file.
The IMAGE_DOS_HEADER of the backdoor binary is zeroed out. Information in the IMAGE_NT_HEADERS, such as ImageSize and NumberOfSections, is XOR-decrypted using the hash of the computer name. The first three sections are decrypted again using a custom algorithm (a series of arithmetic and logical operations) before being injected into memory.
During import resolution, DLL names and API names are XOR‑decrypted using a hard‑coded single‑byte key. After the import DLL is loaded and the API addresses are resolved, the DLL and API name strings are zeroed out.
During relocation, the size of each relocation block, the value of each relocation entry, and the bytes to be relocated are XOR‑decrypted using the dword hash of the computer name. Afterward, the entry point is also XOR‑decrypted with the same hash and then invoked.
SilkLurk backdoor
The backdoor contains a hardcoded configuration of 0x4AC (1196) bytes, with the first 0x10 (16) bytes holding a mutex string and the remaining 0x49C (1180) bytes comprising encrypted configuration data; this configuration is written to a hardcoded filename (e.g., 2470b666bece868f, 27879a4df1a740ff) that differs across samples and is placed in the %APPDATA% directory. The configuration is decrypted using a custom algorithm involving a series of arithmetic and logical operations that is distinct from the algorithm used to decrypt the encrypted backdoor blob and payload file. The configuration has the following structure:
Offset
Description
0x00 (000)
C2 Host 1
0x64 (100)
C2 Host 2
0xC8 (200)
C2 Host 3
0x12C (300)
C2 Host 4
0x190 (400)
Port for C2 Host 1
0x192 (402)
Port for C2 Host 2
0x194 (404)
Port for C2 Host 3
0x196 (406)
Port for C2 Host 4
0x198 (408)
Unknown 21 bytes
0x1AD (429)
Proxy address 1
0x22A (554)
Proxy username 1
0x2A7 (679)
Proxy password 1
0x324 (804)
Proxy address 2
0x3A1 (929)
Proxy username 2
0x41E (1054)
Proxy password 2
The backdoor creates a TCP socket and connects to the C2 server defined in the configuration. If proxy details are provided, it attempts to establish the C2 connection through the proxy. The proxy request uses the following format:
After successfully connecting to the C2 server, it generates a random 32‑byte (0x20) network key that will be used to encrypt and decrypt network packets. This key is appended to the magic dword, as shown in the table below, creating a 40‑byte block that is then encrypted with a custom algorithm: a series of arithmetic and logical operations that differs from the one used to decrypt the configuration.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
0x0C7FFBE86h (magic dword)
0x04 (04)
0x04 (04)
0
0x08 (08)
0x20 (32)
Network key (will be used to encrypt and decrypt network traffic)
It then prepares a packet to send the key to the command‑and-control server, as shown in the table below. The packet contains a 0xC (12‑byte) header, a 0x28 (40‑byte) block of encrypted network‑key data (see the table above), and a randomly generated payload whose size ranges from 0x14 (20) to 0xB4 (180) bytes.
Encrypted network key data (as mentioned in above table)
0x34 (52)
size between 0x14 (20) and 0xB4 (180)
Random data bytes
After sending the key, the backdoor collects the following victim information: local computer name, DNS domain assigned to the local computer, user’s logon name, processor architecture, OS major version and build number, host IP address, current process ID, tick count value, and backdoor module name. The collected victim information is first compressed and then encrypted using the network key. The custom algorithm (a series of arithmetic and logical operations) used to encrypt collected victim information is different from the algorithms used to decrypt the configuration and encrypt the network key. Before sending the victim information, a 0x0F (15) byte header is generated and encrypted using the same custom algorithm used to encrypt the collected victim data. The header follows the format as shown in the table below.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
0xC7FFBE86 (magic dword)
0x04(04)
0x04 (04)
Message type (1 means victim information)
0x08 (08)
0x04 (04)
Data size (size of encrypted victim information)
0x0C (12)
0x01 (01)
Compression flag (1 means compressed)
0x0D (13)
0x02 (02)
Size of random bytes, between 0x14 and 0x96 bytes
Finally, the encrypted header and victim information are formatted as shown below and transmitted to the C2 server.
Once the backdoor has transmitted the victim information, it waits for a 0x13‑byte (19‑byte) response from the C2 server. This response follows the structure presented in the table below.
Field offset
Field size (in bytes)
Field value
0x00 (00)
0x04 (04)
Random dword
0x04 (04)
0x0F (15)
Encrypted header data
The encrypted header contained in the response is decrypted with the network key that was generated and shared with the C2 server. After decryption, the header retains the same size and structure as the one used in the victim information message.
The message type field in the header (offset 0x04) determines which operation (command) to perform. Next, the backdoor figures out the size of the command data to receive by adding up the size of the encrypted data (found at position 0x08 in the received header) and the size of the random bytes (found at position 0x0D in the received header). The received command data is first decompressed, based on the compression flag located at position 0x0D in the received header, and then decrypted using the custom algorithm that was used to encrypt the sent data. The backdoor supports the following commands:
Command (message type)
Description
03
Based on subcommand, perform the following operations:
00: Get target system’s local time
01: Set sleep time in milliseconds, after which to reconnect to the C2 server
04
Send current backdoor configuration
05
Update backdoor configuration
06
Receive and inject additional payloads (plugins) into memory. Based the on subcommand, perform the following operations:
01: Inject payload (plugin) bytes into memory and execute payload’s entry point
03: Call export method of injected plugin
Post-compromise activity
The threat actor operating the SilkLurk backdoor first used it to invoke cmd.exe to launch PowerShell. Within PowerShell, they ran commands such as net use to connect to shared network resources with administrative credentials. After establishing the connection, they searched the shared drives for confidential documents to exfiltrate. Once the search was complete, they disconnected from the network share to erase evidence of which internal servers had been accessed. To archive the stolen data, they employed legitimate archiving tools: WinRAR and 7‑Zip.
Below are the paths and names of the WinRAR and 7Zip binaries used by the attackers.
The SilkLurk backdoor opened a command shell (cmd.exe). Using this shell, the attacker executed the file C:\ProgramData\microsoft\html help\kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c). The kmsonline.exe binary acted as a dropper for the PlugX malware, deploying the malicious files listed below.
Our Kaspersky Threat Attribution Engine (KTAE) also identified a strong degree of similarity between kmsonline.exe (MD5: 3c9a1ba8e0c7475706adc6376e9d7b7c) and PlugX.
PlugX was configured to communicate with the C2 domain gycudore[.]kozow[.]com and the IP address 64[.]7[.]198[.]130. Below are the extracted configuration fields from PlugX.
Config field name
Value
Injection Target Process
%SystemRoot%\system32\svchost.exe
Home Directory
%ALLUSERSPROFILE%\Symantec
Persistence Name
SymantecRAS
Service Display Name
SymantecRAS
Service Description
Symantec RAS Services
Campaign ID
KG_MFA
Infrastructure
The threat infrastructure relies on VPS servers. Some OctLurk and LurkProxy C2 addresses are referenced in a public report by Kazakhstan’s State Technical Service (STS) company. According to available data, a campaign targeting critical infrastructure in Kazakhstan was discovered in March 2025. During this campaign, attackers employed the TrustFall (STS internal designation) remote access malware, also known as MystRodX (Qianxin) and SilentRaid (Cisco) and designed for Linux-based operating systems. Subsequently, in October 2025, STS researchers found additional TrustFall samples, while also discovering its new C2 servers via active probing. Notably, three observed TrustFall C2 addresses were also leveraged by OctLurk and LurkProxy. This overlap points to shared infrastructure across multiple OS-targeting campaigns, though it remains unclear whether these activities ran concurrently or at different times.
Attribution
We identified multiple artifacts confirming that OctLurk and SilkLurk are operated by the same threat actor. Several users infected with OctLurk were also found to be infected with SilkLurk, and in some cases both malware families used the same staging directory. Below are examples of these artifacts.
In one incident, the attackers created the service C:\Windows\system32\svchost.exe -k ExAstSrc -s ExAstSrc to deploy OctLurk. They used OctLurk to obtain a command shell and were observed dropping the SilkLurk loader vulkan-1.dll (MD5 be4731c09734da2e8eb6814a9c82f266) via this shell, as shown below.
In another incident, we observed attackers using the same directory C:\ProgramData\intel\ to drop both the OctLurk and SilkLurk loader DLLs.
In one incident, the attacker used SilkLurk to obtain a command shell (cmd.exe) and then deployed and executed the PlugX malware. The PlugX sample was configured to contact gycudore[.]kozow[.]com as its command‑and‑control (C2) server, while the SilkLurk backdoor used ctyuhjerf[.]kozow[.]com for C2. PlugX is a well‑known modular remote‑access Trojan (RAT) that has been active since at least 2008 and historically linked to Chinese-speaking threat actors. This suggests that both OctLurk and SilkLurk were also developed and operated by a Chinese‑speaking actor, although at this time, we cannot attribute this activity to a known threat group.
Conclusions
The emergence of the OctLurk and SilkLurk multi‑plugin malware framework highlights how threat actors continuously refine their tactics to evade detection and maintain control over compromised networks. Both families operate primarily in memory, leaving only a minimalistic loader on disk that relies on machine‑specific data (OctLurk uses the drive serial number, and SilkLurk uses the computer name) to decode payload locations and contents. This victim‑specific encoding makes reverse engineering and automated detection considerably harder.
In addition to sophisticated obfuscation, the attackers establish redundant access channels, harvest credentials, and deploy well‑known remote access and monitoring tools. These secondary pathways ensure persistence even if the original infection vector is discovered or neutralized.
Sometimes it happens. You’re happily playing a game on your phone or laptop when suddenly alarms pop up out of nowhere:
“Your device is infected!”
“Your iCloud is full!”
“Your account is restricted for watching porn!”
Some games can be played for free if you agree to watch ads, and in others you can get extra lives, perks, or boosters by watching ads. That’s fine, as long as you’re given a choice and the ads are legitimate.
Unfortunately, cybercriminals sometimes manage to buy advertising space and use it to defraud gamers.
Let’s look at some examples.
The iCloud storage scam, or its OneDrive equivalent, is a well-known and long-running scam that claims you need to expand your storage or all your files will be deleted. The websites these messages link to come in many forms, but they all ask for personal and payment details to complete the upgrade.
“Your account has been restricted. We have detected that your device has been hacked after visiting adult websites. Solution: 1:Click the “OK” button below;
2:You will be redirected to App Store;
3:Install and open the app, then run the cleanup program.”
This ad is a scam and uses a classic scare tactic. It falsely claims your device has been hacked and tries to pressure you into clicking “OK” and installing a cleanup app.
Messages like this sometimes claim to be from your ISP, a “Security Department,” or a generic “Safety Center.”
“Apple Security Alert 8 viruses have been detected on your iPhone. Now iOS is damaged by 72%. Further damage to the system will result in device lockup and loss of all data within two minutes. Please click the button below to remove all viruses.”
This is another fake warning, commonly used by scammers to trick users into clicking links or downloading unnecessary or harmful software. Apple doesn’t send alerts like this, and these messages use vague threats to get your attention.
What kind of app you’re really installing if you follow the instructions depends on your device and your location. If you’re “lucky,” it’s just adware, but you might just as easily end up with an infostealer.
In many cases, you’ll end up with fleeceware, a type of deceptive mobile app where developers lure users in with short free trials that quickly convert into hidden subscription fees, sometimes costing hundreds of dollars per month. These apps often offer some functionality to stay on the barely legal side of things, but at wildly inflated prices.
How to stay safe
The best response to these messages is simply to ignore them.
Real system alerts come from the OS, not from inside a game window or browser tab. Here’s a simple test: If you can switch apps and the “warning” disappears with the browser/game, it was not a system‑level alert.
Check the destination URLs before proceeding. Apple, Google, and major ISPs use predictable domains. A familiar-looking URL is not proof that a message is legitimate, but if the URL looks suspicious, it should definitely be treated as a scam.
You may arrive at something that looks like the official App Store or Google Play Store. Be wary of lookalike app stores and unofficial download sites, but if you are on the real store, the app is generally safer to install. However, it’s still worth checking reviews, permissions, and the developer before proceeding.
Visit the official website of the organization the message claims to be from and log in there. If there’s a genuine problem with your account, storage, or device, you’ll find information about it through official channels.
Use an up-to-date, real-time anti-malware solution on your devices that can detect and block malicious apps.
Scammers know more about you than you think.
Malwarebytes Mobile Security protects you from phishing, scam texts, malicious sites, and more. With real-time AI-powered Scam Guard built right in.
Threat actors are already gearing up for this year’s biggest football (soccer) event, the World Cup 2026. With millions of fans looking for ways to stream matches online, many will turn to IPTV apps to watch live TV broadcasts over the internet. It’s no surprise, then, that cybersecurity researchers have discovered multiple campaigns over the past few months where malware was disguised as fake Android IPTV apps.
In this post, we discuss what IPTV apps are, how criminals use fake versions to spread malware, what this malware is capable of, and, most importantly, how to avoid becoming a victim.
What are IPTV apps?
IPTV stands for Internet Protocol Television. This technology delivers TV content over the internet instead of through cable, over-the-air antennas, or satellites. Naturally, the simplest and most common examples of IPTV are the official platforms of TV networks, which can include both websites and dedicated apps.
However, alongside official options, pirate IPTV services also exist. They usually lure users with free or dirt-cheap access to content that can otherwise be hard to find without expensive subscriptions — most notably broadcasts of various sporting events; football matches in particular.
As is typically the case with pirated content, these apps are blocked from official app stores, forcing users to download them from third-party sites. Consequently, the risk of using these services isn’t tied to IPTV technology itself, but rather to the fake apps and modified APK files distributed under the guise of well-known platforms — both official and pirated.
Massiv banking Trojan disguised as IPTV apps
For instance, in February researchers found the Massiv banking Trojan distributed under the guise of fake IPTV apps. Even then, experts noted that this wasn’t the only malware leveraging this tactic — several others were also spotted in the wild. The primary targets of these IPTV-mimicking malicious fakes have mostly been users in Portugal, Spain, France, and Türkiye.
In most cases, the discovered fake IPTV apps lacked the advertised functionality, so users didn’t get access to any content after installing the apps. Instead, the fake app would open the website of a legitimate IPTV service in a built-in browser to mimic normal functioning and avoid raising user suspicion.
Of course, the most interesting activity happened out of the user’s sight. These are some of the features the malware did have:
Displaying fake windows on top of legitimate ones: fake forms for entering bank details or signing in to official services, as shown in the screenshot below.
Activating a keylogger: recording and transmitting screen keyboard taps to the attackers.
Hijacking control of the compromised device.
The Massiv banking Trojan mimics the interface of the Portuguese government app Chave Móvel Digital in a fake pop-up window, looking even more convincing than the official version from Google Play. Source
Perseus steals valuable information from users’ notes
In March, researchers reported on a new campaign where several fake IPTV apps were used to distribute an even more advanced and feature-rich malware strain: Perseus.
Research into Perseus shows that the malware is based on the source code of an Android banking Trojan called Cerberus, which leaked nearly six years ago. Perseus comes in two different versions: Turkish and English. The English-language version is more advanced and shows clear signs of AI-driven refinement.
Perseus abuses Accessibility Services, a set of Android features originally designed to make life easier for users with severe visual impairments. Fraudsters learned long ago how to leverage this tool to steal data from Android devices — a topic we’ve covered in detail across several of our posts.
An example of a malicious APK disguised as Roja Directa TV, another IPTV app. Source
By abusing Accessibility Services, Perseus gains remote control over the victim’s device. Here’s what it can do:
Continuously capture and exfiltrate screenshots.
Send a structured map of the device’s UI for remote manipulation.
Mimic taps, swipes, text input, long presses, and other UI interactions.
Turn on the screen, launch apps, and block them from running.
Trigger a pitch-black screen overlay to hide its activities.
Log keystrokes.
On top of that, the English-language version of Perseus boasts another notable feature. The malware can hunt for sensitive information like passwords, recovery phrases, and financial data across an entire range of note-taking apps: Google Keep, Xiaomi Notes, Samsung Notes, ColorNote, Evernote, Microsoft OneNote, and Simple Notes.
All of these capabilities help criminals drain football fans’ money not just from various banking services, but from cryptocurrency apps as well.
How not to let cybercrooks ruin your World Cup
The World Cup is just around the corner, and millions of fans worldwide will definitely want to tune in to this year’s premier football event. Past experience shows that cybercriminals frequently cash in on major spectacles like this. So, how can you watch the matches safely?
Don’t download apps from unofficial stores.
Even when downloading an app from an official store — since malware occasionally slips through the cracks there, too— read the reviews carefully. Users who have been burned by fakes and malware often leave comments to warn others.
Avoid storing passwords or other sensitive information in note-taking apps. To ensure your data and finances stay secure, use a reliable password manager. By the way, Kaspersky Password Manager includes an encrypted note-taking feature, allowing you to store your valuable information safely.
You can’t even watch TV safely anymore these days! Check out other threats facing TV lovers:
The 2026 World Cup presents major cyber risks from ransomware groups, state-aligned actors, and other groups targeting critical infrastructure. Learn more here.
Imagine handing your smartphone over for repair. A couple of days later, you pick it up — and great, it’s working again! But you won’t even realize that your device has been injected with malicious code, allowing attackers to access your smartphone even when it’s locked.
This is the beginning of the story shared by Kaspersky ICS CERT researchers, Alexander Kozlov and Sergey Anufrienko, at the Black Hat Asia 2026 conference. They managed to uncover a vulnerability that flips conventional assumptions about smartphone and IoT security on their head. Its core lies at the very heart of Qualcomm chips.
What is BootROM?
To grasp the severity of this discovery, we first need to look at how a modern device powered by a Qualcomm chip boots up. Think of it as a fortress with multiple layers of security. Each subsequent layer verifies the pass issued by the previous one. The bedrock foundation — the most trusted layer of them all — is the BootROM, a read-only memory baked directly into the silicon that can’t be modified once it comes off the fab.
The BootROM is the very first thing to run when a device powers on. It verifies the signature of the next bootloader, which in turn verifies the next, building a chain of trust all the way up to the operating system. If an attacker can compromise this chain at the BootROM level, it’s game over: the malicious code will execute before the main operating system even has a chance to load.
This is exactly what attackers can do by exploiting the CVE-2026-25262 vulnerability discovered by Kaspersky ICS CERT researchers.
Emergency Download Mode as an entry point
The research began with a protocol called Sahara. This is a component of Emergency Download Mode (EDL). Manufacturers and service centers use it to revive bricked devices: the phone is connected to a computer via USB, and a special utility program signed by the manufacturer (in this case, Qualcomm) is uploaded to it.
Sahara is implemented directly within the ARM PBL (Primary Boot Loader) — the BootROM itself. This means the protocol runs before any operating system boots, before any user access privileges are checked, and before any security controls are activated. The device simply waits for a USB connection, ready to accept data.
The communication scheme looks simple: the device sends a handshake (HELLO) to the computer, the computer selects the mode, a cycle begins to upload the utility program in chunks, and finally, the device executes the uploaded code. And it was within the verification logic of these very file chunks that the vulnerability was identified.
Write-what-where: the core of the vulnerability
In technical terms, the bug introduced by the developers is classified as CWE-123: Write-What-Where Condition. This is about as bad as it gets when it comes to flaws in low-level programming. An attacker can write arbitrary data to an arbitrary address in the device memory.
Without diving too deep into the technical weeds, suffice it to say that by exploiting the discovered vulnerability, attackers can gain access to any data on the device, including user-entered passwords, files, contacts, geolocation data, as well as the hardware sensors like the camera and microphone. In certain scenarios, complete control over the device is possible. Just a few minutes of physical access to the device via a cable connection, and the gadget has been compromised. This creates a risk if you hand your smartphone over to a repair shop, pass it to someone else to set up and install apps on, or just leave it unattended.
Which devices are affected
The CVE-2026-25262 vulnerability affects the following Qualcomm chip series: MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, and SDX50 — every single version released to date, until the vulnerability is patched by the manufacturer.
These are no obsolete museum pieces. The MDM9207, which we used for the bulk of our research, is integrated into modem modules for the internet of things (IoT), industrial equipment, smart home devices, healthcare monitoring systems, logistics trackers, and banking terminals. The MSM8916 powers many budget smartphones, while the SDX50 is used in automotive control units.
How vulnerable devices get attacked
The catch is that the attacker needs physical access to the device to pull this off. In the real world, this translates to:
Smartphone repairs at third-party repair shops, where the phone is left for several hours
Customs checkpoints in certain countries, where devices are withheld, inspected, and then returned
Lost and found scams, where your phone is stolen, tampered with, and then mysteriously found
Corporate espionage via an insider or a rogue employee
With just a few minutes of physical access to the device an attacker can plant a backdoor so deep inside that standard research tools won’t even detect it in most cases.
Why there’s no patch — and what to do
Qualcomm was notified of the discovery in March 2025 and confirmed the vulnerability in its chips. To identify it, the vendor reserved CVE-2026-25262, and on April 20, 2026, Kaspersky ICS CERT published technical information on the vulnerability and recommendations for users.
Qualcomm included this vulnerability in its May security bulletin. While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability.
If you currently own a device with an affected chip, use our recommendations below to help mitigate the risk of infection.
Enforce strict physical control: don’t leave your devices unattended, especially when traveling or on business trips.
Choose only authorized service centers for repairs and maintenance.
Regularly update your firmware — this won’t patch the BootROM vulnerability, but it can eliminate many related vulnerabilities at higher levels.
Use a Kaspersky for Android on your device. This will safeguard your gadget from other threats that, combined with this vulnerability, could lead to unpredictable consequences.
If you notice that your gadget with a vulnerable Qualcomm chip starts acting up — overheating when idle, reporting unexpected spikes in network traffic, or exhibiting strange app behavior — you may have fallen victim to this vulnerability. You can wipe the malicious code and reset your device to its baseline state simply by completely cutting its power. This means either pulling the battery or letting it drain all the way to zero until the gadget shuts down entirely. In this case, the malicious code will most likely not persist on the device — during our research, we were unable to confirm that it could achieve persistence in non-volatile memory.
Want to learn more about severe vulnerabilities in Android phones? Check out these posts:
Netflix, Apple TV+, Disney+, Hulu, Amazon Prime, YouTube Premium… The average law-abiding family today pays for five to 10 subscriptions just to watch their shows of choice, with the monthly bill easily crossing the hundred-dollar mark. It’s no surprise, then, that social media and online marketplaces are seeing a surge in demand for the “magic boxes” that popped up at the end of 2025: Android-powered TV boxes that promise to unlock thousands of channels and every streaming service subscription-free for a one-time purchase.
Ads for these devices are flooding TikTok and Instagram: smiling influencers unbox the SuperBoxes, plug them into a TV, and browse endlessly through channels. It looks like the ultimate life hack against subscription fatigue, right? In reality, it’s one of the easiest ways to invite a botnet into your home network.
A promotional video on TikTok explaining how great it is when the cheese is free you can just go ahead and cancel all your subscriptions
What’s wrong with these cheap TV boxes?
Stories about malicious TV boxes have surfaced before, but right now, their marketing has reached a truly alarming scale.
At the end of 2025, analysts examined several models of the popular SuperBox device available from major retail stores and online marketplaces. The findings were deeply concerning: immediately upon powering up, the devices began pinging the servers of the Chinese messaging app Tencent QQ, as well as the Grass proxy service — effectively renting out the owner’s internet bandwidth to third parties.
Inside the firmware, researchers discovered applications completely uncharacteristic of a media player: a network scanner, a traffic analyzer, and tools for DNS hijacking. Consequently, the device not only streams pirated content but also scans the local network for other targets (including industrial SCADA interfaces), and stands ready to participate in DDoS attacks. The SuperBoxes were also found to contain folders with the telltale name “secondstage”, a textbook indication of multi-stage malware.
More recently, in April 2026, the Darknet Diaries podcast featured an interview with a security researcher known by the alias D3ada55, who shared plenty of intriguing details about these boxes — including the fact that they were still openly sold on major platforms like Amazon, Walmart, and Best Buy.
The infection chronicles: BADBOX to Keenadu
The SuperBox case is far from the only instance where Android devices have been turned into botnet nodes — or sold infected right out of the box. Here’s a look at the most recent cases:
BADBOX 2.0. In July 2025, Google filed a lawsuit against the operators of a botnet that compromised over 10 million Android devices — mostly cheap TV boxes, tablets, and projectors lacking Google Play Protect certification. As we reported earlier, BADBOX 2.0 specifically targets TV boxes, operating simultaneously as a proxy network and an ad fraud engine.
Kimwolf. In December 2025, the QiAnXin XLab team uncovered a DDoS botnet that had hijacked around 1.8 million Android devices. The infected hardware included generic models from off-brand manufacturers sporting high-profile names like TV BOX, SuperBox, XBOX, SmartTV, and others. The infection footprint was massive, with compromised devices shipped worldwide. Among the hardest-hit countries were Brazil, India, the U.S., Argentina, South Africa, the Philippines, and Mexico.
Keenadu. Our experts discovered this malware lurking in the firmware of brand-new devices back November 2025, though it didn’t gain widespread attention until after we published a study about it in February 2026. Keenadu masquerades as legitimate system components, embedding itself even into facial-recognition unlock apps, potentially granting attackers access to biometrics, banking data, and personal messages.
All of these stories share the same origin: the Triada Trojan, first documented by our researchers back in 2016 and dubbed at the time “one of the most advanced mobile Trojans”. Over the past decade it has evolved from a standard piece of malware into a modular backdoor baked directly into firmware during manufacturing.
How the infection scheme works
Manufacturers of cheap TV boxes cut corners on absolutely everything: Google Play Protect certification, firmware audits, and security updates. Many of these devices run on the Android Open Source Project without any security guarantees whatsoever. Somewhere along the supply chain — whether at the factory, through a middleman, or at a distributor — a backdoor gets injected into the firmware image. Our experts suspect that the manufacturer itself might not even be aware of the compromise.
The sheer scale of the infection turns millions of identical boxes into the perfect foundation for a botnet: every compromised device represents a unique IP address that can be rented out to anyone. Botnet operators like Kimwolf monetize this not only through distributed DDoS attacks but also by reselling the bandwidth of infected smart TVs and streaming boxes.
What this means for you
An infected TV box sits right in your living room, connected to your home Wi-Fi. That means it can see smartphones running banking apps, network-attached storage (NAS) units holding family archives, IP cameras, smart locks, work laptops, and any other the devices connected to your Wi-Fi network.
With this kind of beachhead inside your home network, an attacker can intercept unencrypted traffic, spoof DNS requests, scan ports, and hunt for vulnerabilities on neighboring devices. On top of that, they can use your IP address for fraudulent activity. As a result, in the best-case scenario, your IP will end up blacklisted, and legitimate services will start blocking you for suspicious activity; in the worst-case scenario, law enforcement could come knocking on your door.
How to spot a potentially dangerous gadget
You should be on alert if a device:
Is sold under a no-name brand like T95, X96Q, MX10, TV BOX, SuperBox, or some such
Promises free lifetime access to paid premium services for a one-time fee
Requires you to disable Google Play Protect, or install third-party APK files during the initial setup
Lacks Play Protect certification entirely
Is promoted through aggressive spam campaigns on social media
How to avoid hosting a botnet node
Buy certified TV boxes that feature Google Play Protect, or purchase devices directly from reputable telecom operators and internet service providers.
Isolate all smart home devices. Set up a separate Wi-Fi network on your home router for TV boxes, cameras, smart speakers, robot vacuums, and similar gear, while keeping smartphones, NAS units, and computers on the main network. This prevents malware from spreading to your critical gadgets.
Regularly update the firmware on all your devices, and don’t forget about your router — it’s another vulnerable link in the chain.
Remove any applications from your Android TV box that you didn’t install yourself, especially alternative app stores, Wi-Fi “boosters”, and “system cleaners”.
Monitor your traffic. Modern routers and Kaspersky Premium can display which devices are connecting to where. Frequent connections from a media player to servers in China are a major security red flag.
Install Kaspersky Premiumon all your devices — it protects against Trojans, and blocks the phishing pages often used to distribute infected APK files.
Don’t disable Google Play Protect, and avoid installing APKs from shady sources — this is the primary infection vector that bypasses the official app store.
If in doubt, return the TV box. A cheap streaming device isn’t worth risking your biometrics, banking data, or the reputation of your IP address.
Want to know how else to protect your smart home devices? Read more in our related posts:
In May of last year, a warning about AI came from somewhere unexpected: The Auschwitz-Birkenau State Museum.
Posting publicly on social media, the museum warned about a Facebook account using generative AI to create fake images of people who died in the Holocaust. Despite using AI to generate fake images, the people in said images were sometimes real. They had real names, birthplaces, and stories of deportation that the Auschwitz-Birkenau State Museum itself had shared before. They had real faces captured in real surviving photographs, which were likely abused to generate the false images.
In other words, someone, or some team of people online, was deepfaking the Holocaust.
“These are not real photos of the victims. They are digital inventions, often stylized or sanitized, that risk turning remembrance into fictionalized performance. The history of Auschwitz is a well-documented story. Altering its visual record with AI imagery introduces distortion, no matter the intent.”
Months later, the public found out what that intent was: money.
A BBC investigation found an international network of Facebook accounts posting AI-generated images to earn money from those images’ potential virality. It’s a problem sometimes referred to as “AI slop” but it comes with a major incentive. When accounts that make these kinds of images are invited to Facebook’s content monetization program, they can make $1,000 a month for posting anything that gets clicks.
And on Facebook, the BBC found, that means several accounts posting AI-generated images about the Holocaust. As the BBC reported:
“AI spammers have posted fake images purporting to be from inside [Auschwitz], such as a prisoner playing a violin or lovers meeting at the boundaries of fences—attracting tens of thousands of likes and shares.”
The economics of lying are concrete today. People can use AI to make fake images that make people feel good about terrible things or feel scared about untrue things, and they can make money until shut down by the Big Tech platforms themselves, which, in this case, only happened because of the BBC’s investigation. In fact, it’s that type of inaction from social media platforms that compelled the German government and multiple Holocaust memorial institutions to send an open letter earlier this year that asked for better controls and restrictions against this type of content.
As the signatories warned in their letter, the economic appeal for these accounts to distort history is too high a risk to allow. You can read the full letter here.
Today, on the Lock and Code podcast with host David Ruiz, we speak with Clara Mansfeld, a historian working on digital communications at one of the institutions signed onto the open letter—the Foundation of Hamburg Memorials and Learning Centers Commemorating the Victims of Nazi Crimes. In their conversation, Mansfeld discusses digital access to history, the manipulation of factual records through AI-generated imagery, and the threat that society faces when it becomes harder to evaluate the truth.
“What happens when the first thought we have with every historical image is, ‘Is that even real or is that AI?’ I don’t think we have really grasped what that means for us as a society.”
Google Chrome has been quietly downloading a 4GB AI model onto users’ devices without asking first.
Security researcher Alexander Hanff, aka ThatPrivacyGuy, reports that Chrome has been silently installing Gemini Nano, Google’s on-device AI model, as a file called weights.bin stored in the OptGuideOnDeviceModel directory within users’ Chrome profiles. This 4GB download happens automatically when Chrome determines your device meets the hardware requirements. It does not ask for consent, and sends no notification—not even one of those annoying cookie banners you’ve learned to dismiss without reading.
The Gemini Nano model powers features like “Help me write” text composition assistance, on-device scam detection, and a Summarizer API that websites can call directly. These features are enabled by default in some recent Chrome versions. And here’s the kicker: if you discover the file and delete it, Chrome simply downloads it again.
Why this matters
Let’s start with the obvious problem: a 4GB download isn’t trivial for everyone. If you’re lucky enough to have unlimited fiber internet, you might not notice. But for users on metered connections, mobile hotspots, or in developing countries where data is expensive, Google just cost them real money without permission. For rural users or those with bandwidth caps, this kind of silent transfer can blow through monthly limits in minutes.
Hanff focuses on the environmental angle. He calculated that if this model were pushed to just 1 billion Chrome users (roughly 30% of Chrome’s user base), the distribution alone would consume 240 gigawatt-hours of energy and generate 60,000 tons of CO2 equivalent. That’s not including actually using the model, just the downloads.
But to us, the most troubling aspect is the broader pattern this represents. Just a few weeks ago, we reported another unsolicited AI invasion on our personal computers discovered by Hanff. He documented how Anthropic’s Claude Desktop app, which silently installed browser integration files across multiple Chromium browsers, including five browsers he didn’t even have installed. The integration would reinstall itself if removed, and it also happened without any meaningful user disclosure.
Hanff argues that both cases likely violate EU privacy law, specifically the ePrivacy Directive’s rules about storing data on user devices and the GDPR’s requirements around transparency and lawful processing. While these claims haven’t been tested in court, they highlight a fundamental tension: can companies just install whatever they want on your computer as long as they say it’s a feature of an app you installed?
Google might argue that having an AI on your device provides better privacy than cloud-based alternatives. Which is generally true, but it does not apply here, since Chrome’s most prominent AI feature—the “AI Mode” pill in the address bar—doesn’t even use the local model. According to Hanff’s analysis, it routes queries to Google’s cloud servers anyway.
All in all, users see a 4GB local AI model and reasonably assume their data stays private, when in reality, the most visible AI feature sends everything to Google’s servers.
Tech companies need to stop treating silent deployment as acceptable practice. We see no valid excuse for this. Your device is yours. The storage is yours. The bandwidth is yours. And the electricity bill is yours.
What happened to asking for permission? And when I remove it, I want it gone permanently—not automatic reinstallation.
When are the tech giants going to learn that we don’t want to be left discovering after the fact that our devices have become deployment targets for features we never asked for.
Update May 12, 2026 with do it yourself instructions
How to check if the AI model is on your computer (Windows)
Open File Explorer
At the top of the File Explorer window, click the address bar and paste:
%LOCALAPPDATA%\Google\Chrome\User Data
Press Enter
Look for a folder named:
OptGuideOnDeviceModel
If you see it, Chrome has likely downloaded the AI model
Properties of the folder
How to check on a Mac
Open Finder
In the menu bar at the top of the screen, click Go > Go to Folder
Paste:
~/Library/Application Support/Google/Chrome/
Look for a folder named:
OptGuideOnDeviceModel
Now, remember, this isn’t malware, and its presence doesn’t mean your computer is infected.
Turn off Chrome AI features
This part is relatively easy. You may find online instructions telling you to edit the Windows registry or use Chrome policies, but for most people the simplest and safest approach is to disable the features directly in Chrome.
We don’t recommend manually editing the registry unless you fully understand what you’re doing. Incorrect changes can cause system problems.
Instead, try this first:
Open Chrome
You can copy and paste this directly into Chrome’s address bar and press Enter:
chrome://settings/ai
On the page that opens, you can turn off features such as:
“Help me write”
AI summaries
On-device AI features
The exact options may vary depending on your Chrome version and region.
Then restart Chrome to make sure the changes take effect.
This may stop Chrome from downloading or using the AI model, although some users report the files can return after browser updates.
There is probably no need to delete the files unless you specifically need the storage space.
If chrome://settings/ai does not work, the feature may not yet be available in your region, you may be using a managed work or school account, or your version of Chrome may not support these settings yet.
Do you need to delete the OptGuideOnDeviceModel folder?
You can, but there is probably no need to.
If you disable Chrome’s AI features, the downloaded model should no longer be actively used for those features. Leaving the files in place may also prevent Chrome from downloading them again at a later point.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
Malicious actors have developed a new way to steal data stored by Chrome for Windows. Researchers discovered the technique while analyzing a fresh build of an infostealer known as VoidStealer. The new method allows the malware to bypass Chrome’s Application-Bound (App-Bound) Encryption (ABE), a mechanism intended to protect session cookies and other valuable information stored in the browser.
Google hoped this mechanism would secure the master key Chrome uses to encrypt all sensitive data. Unfortunately, this isn’t the first time malware authors have found a workaround for this defense — leaving secrets stored in Chrome vulnerable once again.
How App-Bound Encryption works in Chrome
Google introduced App-Bound Encryption in July 2024 with the release of Chrome version 127. The company’s announcement mentioned infostealers snatching cookies from Chrome users on Windows as the primary problem ABE was intended to solve. We’ve already covered in detail what these files are and the consequences of their theft, so we’ll only briefly recap the main facts here.
Cookies are small files that the browser saves to the user’s device at a website’s request to remember various site settings. Of particular value to attackers are session cookies, which are used for automatic authentication on websites. It’s thanks to these files that we don’t have to enter a username and password every time we revisit a site.
But this convenience carries a risk: stealing these files allows an attacker to use an already-authenticated session without entering a username or password. This allows them to impersonate the user, which can lead to account hijacking, theft of personal or financial data, and other adverse consequences.
Infostealer Trojans are particularly dangerous for Chrome users on Windows. This is because, on this OS, Chrome previously relied solely on the standard built-in Data Protection API (DPAPI). With this system encryption mechanism, applications don’t need to create and store encryption keys to protect data.
The limitation of DPAPI is that it doesn’t protect data from malware that’s already successfully compromised the system and is capable of executing code on behalf of the logged-in user. This is exactly what stealers exploit: since they typically run with the user’s privileges, they can simply request DPAPI to decrypt the browser’s protected data.
The ABE mechanism was designed to solve that specific problem. The core idea is right in the name: App-Bound Encryption means the encryption is tied to a specific application. To achieve this, a separate service running with system privileges is responsible for protecting the key used to encrypt Chrome’s data. It verifies which application is requesting access to the key, and denies the request if it doesn’t originate from Chrome.
Chrome’s App-Bound Encryption (ABE) was designed so that only Chrome itself could retrieve the master key needed to decrypt the browser’s stored data. Source
As a result, the architects of this feature assumed that to access ABE-protected browser data, an infostealer would either need to escalate its privileges to system-level, or inject malicious code directly into Chrome. In theory, this should have made attacking Chrome significantly harder and reduced the effectiveness of mass-market infostealers. As you might have guessed, things didn’t go quite that smoothly in practice.
Previous successful bypasses of Chrome’s ABE
Just a couple of months after Google announced the implementation of App-Bound Encryption in Chrome, many infostealer developers claimed they’d already bypassed the protection. Among them were the creators of Meduza Stealer, Whitesnake, Lumma Stealer, and Lumar (also known as PovertyStealer).
Lumma stealer developers announce a bypass for Chrome’s App-Bound Encryption in a new version of the malware
Of course, you shouldn’t take malware developers at their word, but legitimate security researchers were able to confirm at least some of the claims. Bypasses for Google Chrome’s new data protection feature did become available almost immediately after its release.
A month later, in October 2024, tech enthusiast Alex Hagenah published a tool on GitHub called Chrome-App-Bound-Encryption-Decryption to bypass Google’s new security mechanism. Analysis of the tool’s code revealed that its author used roughly the same methods that attackers were already heavily exploiting.
What followed was a game of cat and mouse: security researchers and stealer developers came up with new tricks to circumvent App-Bound Encryption, while Google patched the newly discovered loopholes with varying degrees of success.
VoidStealer — a new data-nabbing menace
This brings us to recent events: in March 2026, news broke about a stealer named VoidStealer, which utilizes a brand-new and, by all accounts, highly effective method for bypassing ABE.
VoidStealer developers advertising a new method for bypassing ABE. Source
The malware authors developed an attack technique that targets the brief moment when the master key sits in the browser’s memory in plaintext. This occurs because, at a certain point, the browser inevitably has to decrypt its data to actually use it — for instance, to automatically sign in to a website with the relevant session cookie or to access saved credentials.
To exploit this window of opportunity, the malware attaches itself to the Chrome process as a debugger — a tool that allows one to control a program’s execution, pause it, and inspect its memory. In legitimate scenarios, these tools are used by developers to find and fix bugs, analyze application behavior, and test performance.
The malware identifies the specific section of code where data decryption takes place. It then sets a breakpoint at that location; when the program’s execution reaches that point, the browser effectively freezes. This is how the malware catches the exact moment the master key is sitting in RAM in plaintext; it then reads the key directly from memory.
It’s worth noting that everything mentioned above also applies to other Chromium-based browsers that use ABE, including Microsoft Edge, Brave, Opera, Vivaldi, and others.
How to avoid falling victim to infostealers
The scale of VoidStealer’s reach could be significant, as its developers operate under the malware-as-a-service (MaaS) model. This means they rent out the ready-made tool to other attackers, so they don’t need to develop custom malware from scratch.
This situation demonstrates that relying solely on built-in security mechanisms isn’t enough. Unfortunately, stealer developers are coming up with new workarounds faster than browser and operating system developers can roll out patches.
Here’s what users can do about it:
Avoid installing programs from suspicious sources. This will minimize the chances of malware infiltrating your system.
Learn how ClickFix attacks Lately, stealers have frequently been distributed using this specific malicious tactic.
Keep your OS and software updated on all devices. Timely updates help patch many of the vulnerabilities that malware exploits.
Install a robust security solution on all your devices. It’ll block suspicious activity in real time and alert you to potential threats.
As an added precaution, avoid storing passwords and bank card info in Google Chrome or your Notes app, as these are the first places any self-respecting stealer looks. Instead, use a secure password manager.
Stealers are hunting for your data, finding ways to infiltrate both computers and smartphones alike. To protect yourself from theft, check out our other related posts:
When a major cyber incident hits, the first decisions aren’t technical—they’re human. Who takes the lead? How quickly can information be shared? When should governments step in, and how do you protect public trust while keeping essential services running?
These questions are at the heart of Microsoft’s Advancing Regional Cybersecurity (ARC) initiative, launched in 2025 to help governments strengthen cyber preparedness through practical, public-private collaboration. Today, we’re sharing the first tangible output of that work: the ARC Kenya Exercise Report & Toolkit, developed through a tabletop exercise held in Nairobi in December 2025.
Developed with Kenya’s National Computer and Cybercrime Coordination Committee (NC4) and RiskSight, the toolkit is a practical planning resource designed to help government and cross-sector leaders prepare for cyber crises before they occur. It is grounded in real conversations among leaders from government, regulators, critical infrastructure operators, law enforcement, academia, and the private sector working through what a serious cyber incident would demand of them, together.
Stress‑testing decisions before a crisis hits
The ambition of the “Silicon Savannah” makes Kenya a compelling setting for this work. Its digital economy is expanding rapidly—from mobile‑first financial services to cloud‑enabled public infrastructure—positioning the country as a regional technology leader. But rapid digital growth also brings increased exposure to more sophisticated cyber threats. As systems become more interconnected, a serious cyber incident can quickly disrupt essential services, undermine public trust, and threaten economic stability.
Kenya’s approach recognizes this reality and reflects a critical principle: cybersecurity is not separate from innovation; it is one of the conditions that allows digital transformation to scale safely. The ARC initiative embodies this philosophy and helps decision makers confront the practical realities of coordination, escalation, and response in this complex environment.
This is exactly what the ARC Kenya tabletop exercise was designed to do. The objective was not to test tools but to stress‑test decision making under pressure. Participants were challenged with complex scenarios—including AI‑enabled breaches, ransomware attacks, and infrastructure‑level disruptions. The focus was not on technical fixes but on leadership clarity, cross‑agency coordination, and real‑time decision making in high‑pressure environments.
The outcome was both a roadmap for the unknown and a clear recognition of the need for shared expectations before a crisis begins—particularly around leadership and authority, trusted information sharing channels, and agreed response frameworks. These gaps, identified by participants themselves, now form the backbone of the ARC Kenya Toolkit.
What the ARC Kenya toolkit delivers
The toolkit translates the lessons of the exercise into concrete actions that leaders can take now—before the next incident occurs. It also serves as a practical and specific 12‑month roadmap for strengthening Kenya’s cyber preparedness, moving from lessons identified to durable, institutional capability. Specifically, the toolkit provides recommendations to:
Clarify national leadership during major cyber incidents, enabling government, regulators, law enforcement, and critical infrastructure operators to coordinate more quickly, with fewer gaps and overlaps.
Establish practical, standards‑aligned incident response models for the entire country, including priority playbooks that teams can train on and execute consistently.
Strengthen operational readiness across sectors, with better coordination between security operations centers (SOCs), clearer escalation thresholds, and more reliable incident reporting pathways.
Deepen trusted information sharing and public‑private collaboration through common handling rules, safer “good‑faith” reporting mechanisms, and regular joint exercises to build muscle memory before a crisis.
Taken together, these elements enable leaders not only to respond more effectively to cyber incidents, but to institutionalize preparedness, coordination, and resilience across the national cyber ecosystem. For African countries more broadly, the model also offers a practical pathway to strengthen regional cyber cooperation—by aligning expectations around escalation, information sharing, and public‑private coordination before a cross‑border incident occurs. By translating high‑level principles into practical, repeatable approaches to crisis readiness, the toolkit underscores the value of trusted international partnerships and alignment with global norms for responsible state behavior in cyberspace.
Why Kenya’s approach matters beyond its borders
Many countries across the Global South are grappling with similar challenges: fragmented ownership of critical infrastructure, uneven cyber capacity across sectors, and the need to coordinate rapidly under pressure. While firmly grounded in Kenya’s national context, the lessons from ARC Kenya are therefore intentionally designed to resonate far beyond its borders and to be highly transferable.
Importantly, this work does not end in Kenya. We are already building on these lessons through ARC engagements in other regions, including a new workstream in Mexico, applying the same approach to strengthen preparedness, coordination, and resilience across different national contexts.
By design, the ARC initiative is not simply a record of a single exercise. It is a foundation others can build on—at a national or regional level—offering leaders a practical starting point to turn shared responsibility into sustained capability.
For more than a decade, the Microsoft Digital Crimes Unit (DCU) has persistently disrupted cybercrime and nation-state threats targeting people, organizations, and critical infrastructure. Explore major disruptions—and the ongoing cases and operations behind them here: Disrupting cyberthreats since 2008 | Microsoft
Half a million Britons signed up to help cure cancer. Their data ended up for sale on Alibaba.
The UK Biobank charity informed the British government of an incident concerning the medical data belonging to 500,000 British citizens being offered for sale on the Chinese e-commerce website Alibaba.
The National Data Guardian, Dr Nicola Byrne, said in a statement:
“People who generously share their health data to benefit others through medical research rightly expect it to be kept safe and for there to be accountability when things go wrong.”
Officials said the researchers downloaded the data under a legitimate contract, but its appearance on Alibaba shows how “approved” access can still turn into public exposure.
UK Biobank holds more than 15 million biological samples and detailed health records from volunteers recruited between 2006 and 2010, and researchers worldwide use it to study cancer, dementia, diabetes, and other chronic diseases.
UK Biobank normally signs contracts with vetted universities and private companies before it lets them access the data, but investigators traced the Alibaba listings to three research institutions. UK Biobank revoked their access and paused new data access while it strengthens security controls.
At least one listing reportedly contained data on all 500,000 volunteers, and Alibaba and Chinese authorities removed the adverts before anyone could confirm a sale.
The dataset comes from UK Biobank’s long‑running research cohort and includes genetic sequences, blood samples, medical imaging, and detailed lifestyle information used for global health research.
UK Biobank emphasizes that the data was “de‑identified,” meaning it didn’t include names, addresses, or NHS numbers. But it still contained granular demographics, such as gender, age, birth month/year, socioeconomic indicators, lifestyle details, and health measures. We have repeatedly seen that such data can be re‑linked to individuals by cross‑referencing with other public or commercial records.
Why China cares
US intelligence, policy reports, and academic work paint a consistent picture: China treats large, diverse human genomic and health datasets as a strategic resource for both economic and security reasons.
The US National Counterintelligence and Security Center (NCSC) explicitly states that the People’s Republic of China views bulk healthcare and genomic data as a “strategic commodity” to drive its biotech, AI, and precision medicine industries, and has invested billions in national genomics and precision‑medicine initiatives.
Large datasets from non‑Chinese populations are particularly valuable for building AI models and improving the global commercial competitiveness of Chinese pharma and biotech.
From an attacker’s or foreign intelligence perspective, UK Biobank is a “crown jewel” asset: It’s curated, high‑quality, population‑scale, and much more useful than random breach dumps. And because genetic data is immutable (unlike a password, it cannot be replaced), any compromise has very long‑term intelligence usefulness.
Last year, the Guardian reported that one in five successful UK Biobank access applications came from Chinese entities, including BGI, China’s flagship genomics company that was later placed on the US Entity List over concerns about its role in surveillance of minority populations.
China is not just stockpiling DNA for curiosity’s sake. It is building a global genomic map that covers adversaries as well as its own citizens.
Your genome data
There have been major concerns about genetic data ending up in the wrong hands, and for good reason. But I’m not going to say that volunteering your medical data for research is bad. Researchers often put the data to good use to help others.
But there are some good questions to ask before doing so.
Who runs the project and where is it based? Prefer non‑profit or academic biobanks with clear public‑interest mandates and strong oversight, rather than opaque commercial data brokers.
How do they store the collected data? Ask specifically about genomic data, raw sequencing files, links to medical records, and whether data is encrypted at rest and in transit.
Who can access the data and under what controls? Look for a formal access committee, strict contracts, and technical controls like secure analysis environments and limited export options, not “download CSV and walk away” models like the one that enabled the UK Biobank incident.
Are foreign entities allowed to access or copy the data? In light of US and UK government warnings about Chinese access to Western genomic data, it’s reasonable to ask whether data can be accessed, processed, or stored in jurisdictions with different security expectations.
How do they handle re‑identification risk? As we’ve discussed, “de‑identified” is not a magic word. Privacy experts and US intelligence have warned that health and genomic data can often be re‑identified when combined with other datasets.
If data containing your DNA is in someone else’s hands, you can’t put it back, but you can demand better governance, push institutions to treat genomic data as national‑security‑grade sensitive.
It also requires more skepticism of highly targeted scams. Attackers can use large combined datasets to craft convincing spear‑phishing or health‑related scams, for example, contacting you about a specific condition you or a family member has. Treat unsolicited health or DNA‑related emails, calls, and apps with extra suspicion.
What do cybercriminals know about you?
Use Malwarebytes’ free Digital Footprint scan to see whether your personal information has been exposed online.
If you use the internet, you’ve likely been affected by cybercrime in some way. Even when an attack is aimed at a company, the fallout usually lands on ordinary people.
The most obvious harm is stolen data. When attackers break into a business, it is usually customer information that ends up in criminal hands, and that can lead to identity theft, tax fraud, credit card fraud, and a long tail of scam attempts that can continue for months or years. For consumers, the breach itself is often just the start of the cleanup.
That work is annoying, time-consuming, and sometimes expensive. People may have to freeze credit, replace cards, change passwords, be on the lookout for suspicious transactions, and dispute charges. The Federal Trade Commission (FTC) specifically advises consumers to use IdentityTheft.gov after a breach and recommends steps like credit freezes and fraud alerts to reduce the chance of further abuse.
When sensitive data is exposed, the harm is not only financial. Medical, insurance, and other deeply personal records can be used to create more convincing phishing or extortion attempts, and the stress of knowing that private information is circulating among criminals can linger long after the technical incident is over. In other words, breach victims are not just cleaning up a data problem, they are dealing with a loss of trust.
Breaches happen every day. Don’t be the last to know.
Cybercrime also hits consumers through service disruption. Ransomware and intrusion campaigns can interrupt payment systems, telecom services, shipping, energy distribution, booking platforms, and other infrastructure people rely on every day. In those cases, the consumer impact is immediate: you may not be able to pay, travel, call, buy, or even work normally. The CSIS timeline and Canada’s cyberthreat assessment both show that these disruptions are increasingly tied to high-value targets and can be part of broader state or criminal campaigns.
Not all these incidents are driven by cybercriminals. Recently, Britain’s cybersecurity chief warned that the UK is handling 4 nationally significant cyberincidents every week, with the majority now traced back to foreign governments rather than cybercriminal groups.
Another cost is easy to overlook: disinformation and confusion. When attackers steal data, disrupt services, or impersonate trusted brands, they can also flood the public with fake support messages, scam calls, refund schemes, and phishing emails pretending to be the breached company. The breach becomes a launchpad for more fraud, and consumers are left trying to separate legitimate notifications from those sent by attackers.
Then there is the security backlash. After a breach, companies usually tighten access rules, add more multi-factor authentication prompts, force reauthentication, shorten sessions, and increase fraud checks. Those measures are often necessary, but they also make ordinary digital life more cumbersome. The consumer ends up paying with time and frustration for security problems they did not create.
That is why company-targeted cybercrime is not really only a business problem. It is a consumer issue, a public-trust issue, and sometimes even a national security issue. A single breach can leak data, trigger fraud, interrupt essential services, amplify scams, and make using the internet more frustrating for everyone else. The real cost is rarely confined to the company that got hit.
Knowing this, it’s worth thinking carefully about which companies to trust with your data and how much you’re willing to share . You cannot stop every attack against every company you deal with, but you can limit the fallout by being more selective. Some considerations:
Do they need all the information they are asking for?
Would it hurt anything if you leave some fields blank or give less specific answers?
Has this company been breached in the past, and how did they handle it?
How long will they store the data you provide?
Can you easily have your data removed at your request?
Your name, address, and phone number are probably already for sale.
Data brokers collect and sell your personal details to anyone willing to pay. Malwarebytes Personal Data Remover finds them and gets your information removed, then keeps watch so it stays that way.
Have you ever been on a website when a pop-up suddenly asked for access to your camera, microphone, location, or notifications? Whether you clicked “allow,” dismissed it, or just wondered why it appeared, those permission requests aren’t always harmless. Some sites can abuse those permissions.
With Access Control, a new feature in Browser Guard, you decide exactly which websites can access your device and stop the rest. That means you choose which websites can:
Use your camera
Use your microphone
Access your location
Send you notifications
Further, not only can you control which websites have access to your devices, but you can also block websites or even require those specific sites to request permission every single time they try to gain access to your machines. You can always allow trusted sites to access your camera or location while blocking everything else.
Access Control is now available for Malwarebytes subscribers using Chrome and Edge browsers on a Windows device.
How to use Access Control
We designed Access Control to be both powerful and simple because we know every moment you spend getting set up is another moment you’re left unprotected.
How to use Access Control:
Install/Open Browser Guard: Click the Malwarebytes icon in your browser’s header
Access Dashboard: Click the Dashboard tab at the bottom of the extension panel.
Navigate to Access Control: On the left sidebar of the web page, select Access Control.
Manage Permissions: See visited websites, click “Allow” to enable or disable Malwarebytes’ ability to see visited sites.
Access Control requires some access to your browsing to protect you online
Access Control lets you choose individual sites to block and allow
This feature is rolling out in beta first, so you might see improvements and updates as we refine it. Currently, the feature works across Chrome and Edge, but will roll out to other browsers soon.
Access Control is another step toward making privacy simple and accessible. Not a subscriber yet? Check out Malwarebytes’ plans today to unlock this feature and more.
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.
GoPix is an advanced persistent threat targeting Brazilian financial institutions’ customers and cryptocurrency users. It represents an evolved threat targeting internet banking users through memory-only implants and obfuscated PowerShell scripts. It evolved from the RAT and Automated Transfer System (ATS) threats that were used in other malware campaigns into a unique threat never seen before. Operating as a LOLBin (Living-off-the-Land Binary), GoPix exemplifies a sophisticated approach that integrates malvertising vectors via platforms such as Google Ads to compromise prominent financial institutions’ customers.
Our extensive analysis reveals GoPix’s capabilities to execute man-in-the-middle attacks, monitor Pix transactions, Boleto slips, and manipulate cryptocurrency transactions. The malware strategically bypasses security measures implemented by financial institutions while maintaining persistence and employing robust cleanup mechanisms to challenge Digital Forensics and Incident Response (DFIR) efforts.
GoPix has reached a level of sophistication never before seen in malware originating in Brazil. It’s been over three years since we first identified it, and it remains highly active. The threat is recognized for its stealthy methods of infecting victims and evading detection by security software, using new tricks to stay operable.
The threat differs in its behavior from the RATs already seen in other Brazilian families, such as Grandoreiro. GoPix uses C2s with a very short lifespan, which stay online only for a few hours. In addition, the attackers behind this threat abuse legitimate anti-fraud and reputation services to perform targeted delivery of its payload and ensure that they have not infected a sandbox or system used in analysis. They handpick their victims, financial bodies of state governments and large corporations.
The campaign leverages a malvertisement technique which has been active since December 2022. The strategic use of multiple obfuscation layers and a stolen code signing certificate showcases GoPix’s ability to evade traditional security defenses and steal and manipulate sensitive financial data.
The Brazilian group behind GoPix is clearly learning from APT groups to make malware persistent and hide it, loading its modules into memory, keeping few artifacts on disk, and making hunting with YARA rules ineffective for capturing them. The malware can also switch between processes for specific functionalities, potentially disabling security software, as well as executing a man-in-the-middle attack with a previously unseen technique.
Initial infection
Initial infection is achieved through malvertising campaigns. The threat actors in most cases use Google Ads to spread baits related to popular services like WhatsApp, Google Chrome, and the Brazilian postal service Correios and lure victims to malicious landing pages.
We have been monitoring this threat since 2023, and it continues to be very active for the time being.
When the user ends up on the GoPix landing page, the malware abuses legitimate IP scoring systems to determine whether the user is a target of interest or a bot running in malware analysis environments. The initial scoring is done through a legitimate anti-fraud service, with a number of browser and environment parameters sent to this service, which returns a request ID. The malicious website uses this ID to check whether the user should receive the malicious installer or be redirected to a harmless dummy landing page. If the user is not considered a valuable target, no malware is delivered.
Website shown if the user is detected as a bot or sandbox
However, if the victim passes the bot check, the malicious website will query the check.php endpoint, which will then return a JSON response with two URLs:
JSON response from a malicious endpoint
The victim will then be presented with a fake webpage offering to download advertised software, this being the malicious “WhatsApp Web installer” in the case at hand. To decide which URL the victim will be redirected to, another check happens in the JavaScript code for whether the 27275 port is open on localhost.
WebSocket request to check if the port is open
This port is used by the Avast Safe Banking feature, present in many Avast products, which are very popular in countries like Brazil. If the port is open, the victim is led to download the first-stage payload from the second URL (url2). It is a ZIP file containing an LNK file with an obfuscated PowerShell designed to download the next stage. If the port is closed, the victim is redirected to the first URL (url), which offers to download a fake WhatsApp executable NSIS installer.
At first, we thought this detection could lead the victim to a potential exploit. However, during our research, we discovered that the only difference was that if Avast was installed, the victim was led to another infection vector, which we describe below.
Malware delivered through a malicious website
Infection chain
First-stage payload
If no Avast solution is installed, an executable NSIS installer file is delivered to the victim’s device. The attackers change this installer frequently to avoid detection. It’s digitally signed with a stolen code signing certificate issued to “PLK Management Limited”, also used to sign the legitimate “Driver Easy Pro” software.
Stolen certificate used to sign the malicious installer
The purpose of the NSIS installer is to create and run an obfuscated batch file, which will use PowerShell to make a request to the malicious website for the next-stage payload.
NSIS installer code creating a batch file
However, if the 27275 port is open, indicating the victim has an Avast product installed, the infection happens through the second URL. The victim is led to download a ZIP file with an LNK file inside. This shortcut file contains an obfuscated command line.
The purpose of this command line is to download and execute the next-stage payload from the malicious URL referenced above.
It’s highly likely this method is used because Avast Safe Browser blocks direct downloads of executable files, so instead of downloading the executable NSIS installer, a ZIP file is delivered.
Once the PowerShell command from either the LNK or EXE file is executed, GoPix executes yet another obfuscated PowerShell script that is remotely retrieved (in the GoPix downloader image below, it’s defined as “PowerShell Script”).
GoPix delivery chain
Initial PowerShell script
This script’s purpose is to collect system information and send it to the GoPix C2. Upon doing so, the script obtains a JSON file containing GoPix modules and a configuration that is saved on the victim’s computer.
System information collection
The information contained within this JSON is as follows:
Folder and file names to be created under the %APPDATA% directory
Obfuscated PowerShell script
Encrypted PowerShell script ps
Malicious code implant sc containing encrypted GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix implant
GoPix configuration file pf
Once these files are saved, an additional batch file is also created and executed. Its purpose is to launch the obfuscated PowerShell script.
Upon execution, the obfuscated PowerShell script decrypts the encrypted PowerShell script ps, starts another PowerShell instance, and passes the decrypted script through its stdin, so that the decrypted script is never loaded to disk.
Deobfuscated PowerShell script
Decrypted PowerShell script “ps”
The purpose of this memory-only PowerShell script is to perform an in-memory decryption of the GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix malware implant into allocated memory. After that, it creates a small piece of shellcode within the PowerShell process to jump to the GoPix dropper shellcode previously decrypted.
PowerShell script shellcode jumps to the malware loader shellcode
The GoPix dropper shellcode is built for either the x86 or x64 architecture, depending on the victim’s computer.
Building the GoPix shellcode depending on the targeted architecture
Shellcode
This shellcode is bundled with the malware and stays in encrypted form on disk. It is utilized at two separate stages of the infection chain: first to launch the GoPix dropper and subsequently to execute the main GoPix malware. We’ve observed two versions of this shellcode. The main difference is the old one resolves API addresses by their names, while the latest one employs a hashing algorithm to determine the address of a given API. The API hash calculation begins by generating a hash for the DLL name, and this resulting hash is then used within the function name to compute the final API hash.
The old sample (left) used stack strings with API names. The new sample (right) uses the API hashing obfuscation technique
The first time GoPix is dropped into memory through PowerShell, its structure is as follows:
Memory dropper shellcode
Memory dropper DLL
Main payload shellcode
Main payload DLL
Both DLLs have their MZ signature erased, which helps to evade detection by memory dumping tools that scan for PE files in memory.
MZ signature zeroed
GoPix dropper
When the main function from the dropper is called, it verifies if it is running within an Explorer.exe process; if not, it will terminate. It then sequentially checks for installed browsers — Chrome, Firefox, Edge, and Opera — retrieving the full path of the first detected browser from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. A significant difference from previously analyzed droppers is that this version encrypts each string using a unique algorithm.
After selecting the browser, the dropper uses direct syscalls to launch the chosen browser process in a suspended state. This allows it to inject the main GoPix shellcode and its parameters into the process. The injected shellcode is tasked with extracting and loading the main GoPix implant directly into memory, subsequently calling its exported main function. The parameters passed include the number 1, to trigger the main GoPix function, and the current Process ID, which is that of Explorer.exe.
The dropper uses a syscall instruction and calls the GoPix in-memory implant’s main function
Main GoPix implant
Clipboard stealing functionality
Boleto bancário was added as one of the targets to the malware’s clipboard stealing and replacing feature. Boleto is a popular payment method in Brazil that functions similarly to an invoice, being the second most popular payment system in the country. It is a standardized document that includes important payment information such as the amount due, due date, and details of the payee. It features a typeable line, which is a sequence of numbers that can be entered in online banking applications to pay. This line is what GoPix targets with its functionality. An example of such a line is “23790.12345 60000.123456 78901.234567 8 76540000010000”.
Boleto bancário targeted in clipboard-stealing functionality
When GoPix detects a Pix or Boleto transaction, it simply sends this information to the C2. However, when a Bitcoin or Ethereum wallet is copied to the clipboard, the malware replaces the address with one belonging to the threat actor.
Unique man-in-the-middle attack
PAC (Proxy AutoConfig) files are nothing new; they’ve been used by Brazilian criminals for over two decades, but GoPix takes this to another level. While in the past, criminals used PAC files to redirect victims to a fake phishing page, the purpose of the PAC file in GoPix attacks is to manipulate the traffic while the user navigates the legitimate financial website.
In order to hide which site GoPix wants to intercept, it uses a CRC32 algorithm in the host field of the PAC file. It is formatted on the fly using a pf configuration file: the items in it determine which proxy the victim will be redirected to. To hide its malicious proxy server, once a connection is opened to the proxy server, the malware enumerates all connections and finds the process that initiated it. It then takes the process executable name CRC32C checksum and compares it with a hardcoded list of browsers’ CRC checksums. If it doesn’t match a known browser, the malware simply terminates the connection.
PAC file excerpt
To uncover GoPix targets, we compiled a list of many Brazilian financial institution domains and subdomains, computed their CRC32 checksums, and compared them against GoPix hardcoded values. The table below shows each CRC32 and its target.
CRC32
Target
8BD688E8
local
8CA8ACFF
www2.banco********.com.br
AD8F5213
autoatendimento.********.com.br
105A3F17
www2.****.com.br
B477FE70
internetbanking.*******.gov.br
785F39C2
loginx.********.br
C72C8593
internetpf.*****.com.br
75E3C3BA
internet.*****.com.br
FD4E6024
internetbanking.*******.com.br
HTTPS interception
Since every communication is encrypted via HTTPS, GoPix bypasses this by injecting a trusted root certificate into the memory of a web browser while on the victim’s machine. This allows the attacker to sniff and even manipulate the victim’s traffic. We have found two certificates across GoPix samples, one that expired in January 2025 and another created in February 2025 that is set to expire in February 2027.
GoPix trusted root certificate
Conclusion
With the ability to load its memory-only implant that employs a malicious Proxy AutoConfig (PAC) file and an HTTP server to execute an unprecedented man-in-the-middle attack, GoPix is by far the most advanced banking Trojan of Brazilian origin. The injection of a trusted root certificate into the browser enhances its ability to intercept and manipulate sensitive financial data while maintaining its stealth profile, as the malicious certificate is not visible to operating system tools. Additionally, GoPix has expanded its clipboard monitoring capability by adding Boleto slips to its arsenal, which already includes Pix transactions and cryptowallets addresses.
This is a sophisticated threat, with multiple layers of evasion, persistence, and functionality. The investigation into the malware’s shellcode, dropper, and main module uncovered intricate mechanisms, including process jumping to leverage specific functionalities across processes. This technique, combined with robust string encryption methods applied to both the dropper and main payload, indicates that the threat actor has gone to great lengths to hinder detection. Interestingly enough, attackers adopted the use of a legitimate commercial anti-fraud service to pre-qualify their targets, aiming to avoid sandboxes and security researchers’ investigations. Additionally, the persistence and cleanup mechanisms implemented by the malware enhance its durability during incident response efforts, with very short C2 lifespans.