Data Exposure Report Mexico Education WhatsApp Communications Published Unverified
INBI School of English WhatsApp Data Claim Includes 3.34 Million Messages and 171,967 Phone Numbers
Claimed messages3,337,394
Phone numbers171,967
CountryMexico
Data typeWhatsApp messages
SeverityHIGH
Overview
An actor using the handle “libreboot2016” claims to have published a WhatsApp message dataset associated with INBI School of English, a private conversational English school network in Mexico.
The post states that the dataset contains 3,337,394 WhatsApp messages and 171,967 individual mobile phone numbers using +52 and +1 country codes. A visible field list includes message body, creation and sent timestamps, direction, error fields, sender and recipient fields, messaging-service identifiers, media-related fields, pricing fields, message SID, status, feedback, media metadata and URI data. The dataset, its source, the stated counts and current availability have not been independently verified.
Post details
OrganizationINBI School of English
CountryMexico
SectorPrivate education / English-language training
Actor“libreboot2016”
Claimed messages3,337,394
Claimed phone numbers171,967
Number ranges named+52 and +1
Post date shown
What the post claims
3,337,394 WhatsApp messages
171,967 individual mobile phone numbers
+52 and +1 number ranges represented
Message-body field included
Creation, sent and update timestamps included
Message-direction field included
Error-code and error-message fields included
Sender and recipient fields included
Messaging-service identifier included
Media-count and media metadata fields included
Segment-count field included
Pricing and price-unit fields included
Message SID field included
Status field included
Feedback and subresource-URI fields included
Download mirrors provided
The visible field list resembles structured messaging-platform export data rather than a simple contact list. The screenshot does not show individual message contents, so the sensitivity and subject matter of the communications cannot be independently assessed from the supplied material alone.
The supplied capture shows the INBI School of English claim, the stated WhatsApp message and phone-number counts, a structured message-field list and direct download mirrors. Those download links are not reproduced here.
IOCs & identifiers
Identifiers directly visible or supported by the supplied material. These support correlation and do not independently verify the dataset claim.
Type
Identifier
Source
Actor handle
libreboot2016
Screenshot 1
Named organization domain
inbi[.]mx
Screenshot 1
The organization domain identifies the entity named in the claim, not malicious infrastructure. No Tox ID, Session ID, Telegram handle, malware hash or attacker-controlled IP address is visible in the supplied screenshot. Direct download mirrors shown in the source material are intentionally not reproduced here.
Mapped techniques
Claimed identifies behavior explicitly described by the actor. Inferred identifies an analytical mapping supported by the supplied material. Neither label means the activity has been independently verified.
Collection T1213.006 Data from Information Repositories: Databases Inferred The listing presents a structured message dataset containing communications metadata and phone-number information. The supplied material does not reveal how the data was obtained or independently establish unauthorized access to INBI systems.
Potential impact
If authentic, the claimed dataset could expose large-scale messaging metadata, mobile phone numbers and potentially the content of communications involving students, prospects, graduates or staff. Depending on the underlying message bodies, the material could enable targeted phishing, impersonation, spam, social engineering or significant privacy violations.
Status Unverified
Dark Web Informer has not independently verified the dataset’s authenticity, source, completeness, 3,337,394-message count, 171,967-number count or current availability. The supplied screenshot documents the listing and visible field structure, not independent confirmation of the underlying data.
Want everything on this threat? Paid subscribers get the full unredacted claim details and more. After subscribing, check out the threat feed and search there for this alert.
In September 2026, the SOCRadar Threat Research Unit (STRU) discovered an exposed staging server holding the live workspace of an operator tied to the n0n ransomware group. The open directory exposed the operation’s full September workflow: breach and exfiltration tooling, original locker source code, extortion infrastructure, and an AI coding agent environment backed by more than $7,000 in paid LLM API usage.
The findings implicate at least 23 organizations across 14 countries, including a US sports retailer, a cloud provider, a teachers’ union, a Venezuelan ISP, an Argentine ministry and a pharmaceutical subsidiary. No vulnerability exploitation was identified: every documented compromise relied on weak or stolen credentials. Where n0n does not encrypt, it destroys data and backups after exfiltration.
Exposed workspace: An open directory at 185.157.161[.]148 exposed 1,719 files from a n0n operator’s workspace across two September 2026 snapshots, including 829 scripts and 5 C++ encryptor sources
Credential-only access: Entry points included a credential stuffing campaign against 305 FortiGate SSL-VPN devices, exposed AWS keys, weak RDP/WinRM credentials and compromised hosting management portals
Security tools turned against victims: The operator hijacked Cisco Firepower Management Center instances to switch all access policies to BLOCK, which the actor claimed caused widespread service disruption
AI-built tooling: An AI coding agent configured with about 150 models produced hundreds of attack scripts, with more than $7,216 in usage costs
Scale: As of October 19, n0n listed 93 victims with total ransom demands of $283.7M
Who Is n0n?
n0n is a data-exfiltration and destructive-extortion actor tracked by SOCRadar since September 2026. The group insists on the exact spelling of its name, “two lowercase n letters with a zero between them,” uses the slogan “n0n | no js | no mercy” across its Tor and clearnet portals, and appends the .n0n extension to encrypted files.
Public leak site of the n0n ransomware group
The operation has scaled quickly. On October 12, 2026, the group added 38 maritime, port and logistics organizations across 18 countries to its Dark Web leak site in a single batch. Maritime security research linked at least 21 of them to customers of South Korean maritime software provider CyberLogitec, though CyberLogitec has not confirmed an incident and the supply-chain connection remains unverified. None of the 38 listings was marked as settled after the October 19 deadline, and all were published.
Discovery and Infrastructure
STRU found a Python HTTP file server on 185.157.161[.]148:8877 (AS42675, Sweden) exposing the operator’s working directory in two snapshots on September 25 and 26, 2026. The files map a segmented setup: an agent box hosting the AI coding agent and C2 panel, a “raas” node running the leak site backend and per-victim Bitcoin wallet generation, a “monster” server where all stolen data lands, and a VPN-bound seedbox that distributes leak torrents.
n0n operator’s infrastructure
Campaign Timeline
n0n’s tracked operations ran from September 17 to October 22, 2026. Across three publication rounds and the ChiBiTek listing on October 11, the group exposed 15 of the 23 organizations identified in the workspace, typically leaking data four days after public disclosure.
n0n campaign timeline
Modus Operandi
Every case follows the same lifecycle, with the main impact shifting between exfiltration, encryption, destruction and network disruption depending on the target.
Initial access: Credential stuffing against 305 FortiGate SSL-VPN appliances through residential proxies, plus weak RDP/WinRM credentials, exposed AWS keys and reused hosting portal sessions
Persistence and collection: Hidden admin accounts disguised as services, covert proxies, and theft of browser credentials, session tokens, mailboxes and emailed MFA codes
Exfiltration: Per-target pipelines with data budgets, sending everything to the operator’s central storage
Encryption and destruction: Wrapper scripts stop services, delete shadow copies and wipe free space before the locker runs; in some cases, the operator deleted data and backups instead of encrypting
Extortion and publication: Ransom notes, countdowns, negotiation rooms and direct extortion emails, followed by scrubbed ZIP and torrent leaks
FortiGate gateway credential checker
The n0n Encryptor
The locker is a lightweight AES-256-CBC encryptor with Windows, Linux and PowerShell variants, plus an OpenSSL stage for firewall appliances. Most destructive steps live in external wrapper scripts. Each build uses a single hardcoded key, and one key is likely shared across two victims, so a decryptor for one could unlock the other.
n0n execution chain
Extortion Playbook
Demands range from 0.5 BTC to 33 BTC per victim, and up to $28M per organization in the October port wave. Each victim gets a unique Bitcoin address, and opening a negotiation room requires a 10% upfront payment. A check of all 55 collected addresses showed zero transactions as of October 16, 2026. To raise pressure, n0n contacts victims’ clients, MSPs, unions and the media, and in one case emailed PayPal’s security team over a breach at its contact-center provider.
Negotiation room for FinSoftExtortion email to PayPal for third-party leverage
Case Highlights
Dediserve (cloud hosting): Taken over through stolen admin browser credentials, with tenant backups extracted and the only Linux locker deployment
Inter (Venezuelan ISP): The operator flipped every firewall rule on the ISP’s Cisco FMC to BLOCK, claimed to have severed national network traffic, and demanded 15 BTC
Fanatics (sports e-commerce): An exposed AWS key led to exfiltration from 40 S3 buckets and deletion of a bank-transaction archive and twelve buckets, with a 30 BTC demand
ChiBiTek (managed IT services): Breached end to end through the FortiGate credential stuffing pipeline
AI-Assisted Operations
The operator uses opencode, an open-source AI coding agent, configured with 154 model entries across seven providers, including “uncensored” and “abliterated” models with safety training removed and a self-hosted model. The agent wrote and debugged hundreds of attack scripts, and gateway spending passed $7,216 by October 22, 2026. The evidence points to a human-directed operation supported by AI; no fully autonomous attack system was observed.
LLM key status
Victimology and Attribution
Geographic distribution of victims
Of the 23 organizations identified in the workspace, 15 were published on the leak site, 4 were compromised but not published, and 4 saw access attempts with no outcome shown. Victims span 15 sectors, and all demands are financial.
STRU assesses with medium confidence that the server is a private workspace for a single operator or small team, while the group’s broader framework, tooling and master wallet control indicate a multi-operator operation. The corpus provides no definitive geographic or national attribution.
Recommendations
Harden remote access: Enforce phishing-resistant MFA on RDP, SSL-VPNs and admin portals, monitor /remote/logincheck for credential stuffing, and invalidate credentials found in infostealer logs
Lock down firewall management: Restrict FortiManager and FMC interfaces with IP allow-lists and MFA, require approvals for policy changes, and flag REST token creation from unknown IPs
Reduce cloud key risk: Replace long-lived keys with short-lived roles, separate S3 list, read and delete permissions, enable Object Lock and versioning, and alert on high-volume DeleteObjects calls
Keep offline backups: Use air-gapped or immutable backups, since n0n purges shadow copies, wipes free space and deletes provider-hosted backups
Hunt now: Search EDR, CloudTrail, WinRM/RDP and firewall logs for the indicators and behaviors below
Behavioral Detections
Endpoint: Creation of C:\Users\Public\n0n\ or *.n0n, *.n0n.tmp and n0n_READ_ME* files; rapid renames to .n0n after MSSQL/W3SVC/MySQL termination and vssadmin shadow deletion
PowerShell: Net.WebClient.DownloadFile requests to HTTPS hex URLs with ServerCertificateValidationCallback={$true}, followed by Get-FileHash SHA1 checks
Persistence: SYSTEM scheduled tasks referencing C:\Users\Public\n0n\ (such as [NAME]Sync*, [NAME]Audit, [NAME]Exfil, NetAssist, ChromeDbg*), Registry Run key n0nNote, and hidden local admins with non-expiring passwords and UserList=0
Browser: Chrome launched with –remote-debugging-port on cloned profiles, or portproxy forwarding port 9223 to 127.0.0.1:9222
Firewall appliances: FMC REST tokens from non-management IPs, default policy flips to BLOCK, Snort rule “n0n-lock” (sid 2100001), OpenSSL-encrypted *.n0n files under /Volume/lib, and authorized_keys entries ending in root@3090-AI
Cloud: CloudTrail sequences of ListBuckets, sustained GetObject and DeleteObjects in 1,000-item batches, PutObject writing n0n_READ_ME.txt, and ssm:SendCommand from new or inactive keys
Hosting platforms: New OnApp recipes or Zabbix scripts with “maintenance” names, backup-to-template conversions and VMs tagged mnt-*
Network: JSON POSTs to /x/i containing “ippay-web” with card data; FortiGate /remote/logincheck requests carrying Cookie: APBSID=n0n
n0n is a data-exfiltration and destructive-extortion ransomware group active since September 2026. It encrypts files with the .n0n extension, destroys data and backups where it does not encrypt, and runs a Tor leak site with keyed negotiation rooms. As of October 19, 2026, it listed 93 victims with total demands of $283.7M.
How Does n0n Gain Initial Access?
Every documented n0n intrusion relied on weak or compromised credentials, and no exploit payloads or CVE references were found in the operator’s files. Entry points include credential stuffing against FortiGate SSL-VPN portals through residential proxies, weak RDP/WinRM credentials, exposed AWS IAM keys and reused hosting provider sessions.
How Does n0n Use AI?
The operator uses the opencode AI coding agent, configured with 154 model entries across seven providers, including uncensored, abliterated and self-hosted models. The agent produced and debugged hundreds of attack scripts, with gateway spending above $7,216. The evidence shows a human-directed operation supported by AI; no fully autonomous attack system was observed.
Can Files Encrypted by n0n Be Recovered?
Each n0n build uses a single hardcoded AES-256 key with no per-victim derivation, and one key is likely reused across two victims, which creates recovery opportunities for affected organizations. Because the operator also deletes shadow copies, wipes free space and removes provider-hosted backups, offline or immutable backups remain the only reliable recovery path.
Cron and its spares. Clear root’s crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
Credentials. Only now rotate the secrets in the 17 files and across every account on the host.
Conclusion
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Indicators of Compromise
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
Network: outbound HTTP POSTs from a PBX to any /hima_data/ path or to either staging host. A PBX seldom needs outbound web access beyond vendor updates, so egress allow-listing closes this channel.
Carrier: alert on trunk registrations from outside your own IP ranges, and on premium or international destinations, off-hours calling, and unusual concurrency. Set spend caps and destination blocks where your carrier offers them.
For Law Enforcement Agencies and CERTs
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
Two Staging Hosts, Split by Encoding
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
Reference
Encoding
Points to
k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback
Plain text
160[.]119[.]69[.]4
Camouflaged cron payloads, login-triggered stager
Base64
45[.]95[.]147[.]178
Credential upload
Base64
Both
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
The Webshell: Same Program, New Identifiers
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Figure 3: The panel’s Freepbx and Elastix buttons forge an admin session without a password
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
The .htaccess Door and the Access-Log Gap
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell byits filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
What the FreePBX Console Won’t Show You
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Figure 4: Our lab trunk, known to Asterisk and carrying calls, invisible in the FreePBX console
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
What Keeps It There
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
Figure 5: Persistence channels that rebuild each other, and the backdoors they stay open
Detecting It Without IOCs
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
Check
What it flags
Packed shells
Several identical, same-size PHP files across unrelated directories
Locked files
chattr +i or +a under the web root or in hidden directories
Unowned .htaccess
An .htaccess no installed package accounts for
Self-rebuilding cron
A cron line that downloads a file and hands it to a shell
Accounts
An extra UID-0 account, or a full-permission FreePBX admin, nobody created
Blocklist
Addresses dropped in and out by iptables outside fail2ban’s chains
Figure 6: beagle.sh (Source: 0x1da5 GitHub)
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
Layer
Behavior
What it catches
Host
crond spawns a shell that downloads a file and runs it
The takeover script on its single run, before persistence and before credentials leave
Host
The web server account spawns a shell
The webshell’s command box in use
Host
A cron child rewrites the crontab every minute without reading it first
Beacon reinstallation
Host
chattr +i or touch -r on a file in the web root
The lock and the borrowed timestamp
Host
Twelve PHP files were written to the web root in the same second
The webshell copies, as they are written; fan-out
Network
The PBX contacts staging host roughly every 60 seconds
The beacon’s rhythm, whatever the address
Network
Many configuration files read, then outbound POST requests
Credentials leaving
Web
A request with leading encoded whitespace returns 200 for a path not on disk
The .htaccess door
Decoy
Any read of a decoy config file that the implant reads, but nothing legitimate does
Credential collection, with no false positives by design
Phone
Channels originate over AMI or the CLI outside your dial plan
A call asking for nothing legitimate
Phone
CDRs with premium destinations, off-hours calling and unusual concurrency
The fraud itself
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
Why Cleanup Fails, and the Order That Works
First move
Why it fails on its own
Delete the webshell
Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags.
Patch FreePBX
Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system.
Change the admin password
The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login.
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
Preserve first
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Cut the host off from the internet, or at least block all outbound traffic except to your SIP carrier. Blocking only the two known staging hosts is not enough if the operator has moved. With no route out, the minute-by-minute downloads fail, and nothing more is uploaded. One local loop survives: a watchdog cron line re-runs the cached copy of k.php at /var/lib/asterisk/bin/zen2 every minute, rebuilding the webshells offline, which is why cron comes first in the cleanup below.
Capture all crontabs and the eight backups listed below, /etc/passwd, /etc/shadow, shell profiles, and the web root with lsattr output and change times.
Export the FreePBX ampusers table, the call records database, and the Asterisk full log, and ask your carrier to preserve CDRs and registration logs.
Then clean, in this order
Cron and its spares. Clear root’s crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
Credentials. Only now rotate the secrets in the 17 files and across every account on the host.
Conclusion
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Indicators of Compromise
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
Credentials leave on every run. k.php uploads 17 configuration files to both staging hosts every minute the host stays infected.
The fraud no longer needs your PBX. A stolen trunk secret lets the operator register and place calls as you from anywhere.
Last report’s identifiers have expired. Each build now carries its own watermark, and the webshell gate hash was rotated.
Two staging hosts. Plain-text commands now point to 160[.]119[.]69[.]4, while base64-encoded ones still use 45[.]95[.]147[.]178.
Clean-looking logs and consoles prove nothing. Requests through an encoded space reach the shell without being named in the access log, and trunks are written directly to /etc/asterisk; they do not appear in the FreePBX console.
The Campaign So Far
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
Figure 1: INJ3CTOR3 attack chain, September generation. (Source: 0x1da5 GitHub)
What Changed Since Our Last Report
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
Credential Exfiltration: The Implant Is No Longer the Product
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Figure 2: k.php line 34, decoded into 17 file uploads
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there
Outbound mail
/etc/postfix/sasl_passwd
The SMTP relay account, with your mail provider
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
Detection
Network: outbound HTTP POSTs from a PBX to any /hima_data/ path or to either staging host. A PBX seldom needs outbound web access beyond vendor updates, so egress allow-listing closes this channel.
Carrier: alert on trunk registrations from outside your own IP ranges, and on premium or international destinations, off-hours calling, and unusual concurrency. Set spend caps and destination blocks where your carrier offers them.
For Law Enforcement Agencies and CERTs
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
Two Staging Hosts, Split by Encoding
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
Reference
Encoding
Points to
k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback
Plain text
160[.]119[.]69[.]4
Camouflaged cron payloads, login-triggered stager
Base64
45[.]95[.]147[.]178
Credential upload
Base64
Both
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
The Webshell: Same Program, New Identifiers
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Figure 3: The panel’s Freepbx and Elastix buttons forge an admin session without a password
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
The .htaccess Door and the Access-Log Gap
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell byits filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
What the FreePBX Console Won’t Show You
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Figure 4: Our lab trunk, known to Asterisk and carrying calls, invisible in the FreePBX console
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
What Keeps It There
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
Figure 5: Persistence channels that rebuild each other, and the backdoors they stay open
Detecting It Without IOCs
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
Check
What it flags
Packed shells
Several identical, same-size PHP files across unrelated directories
Locked files
chattr +i or +a under the web root or in hidden directories
Unowned .htaccess
An .htaccess no installed package accounts for
Self-rebuilding cron
A cron line that downloads a file and hands it to a shell
Accounts
An extra UID-0 account, or a full-permission FreePBX admin, nobody created
Blocklist
Addresses dropped in and out by iptables outside fail2ban’s chains
Figure 6: beagle.sh (Source: 0x1da5 GitHub)
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
Layer
Behavior
What it catches
Host
crond spawns a shell that downloads a file and runs it
The takeover script on its single run, before persistence and before credentials leave
Host
The web server account spawns a shell
The webshell’s command box in use
Host
A cron child rewrites the crontab every minute without reading it first
Beacon reinstallation
Host
chattr +i or touch -r on a file in the web root
The lock and the borrowed timestamp
Host
Twelve PHP files were written to the web root in the same second
The webshell copies, as they are written; fan-out
Network
The PBX contacts staging host roughly every 60 seconds
The beacon’s rhythm, whatever the address
Network
Many configuration files read, then outbound POST requests
Credentials leaving
Web
A request with leading encoded whitespace returns 200 for a path not on disk
The .htaccess door
Decoy
Any read of a decoy config file that the implant reads, but nothing legitimate does
Credential collection, with no false positives by design
Phone
Channels originate over AMI or the CLI outside your dial plan
A call asking for nothing legitimate
Phone
CDRs with premium destinations, off-hours calling and unusual concurrency
The fraud itself
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
Why Cleanup Fails, and the Order That Works
First move
Why it fails on its own
Delete the webshell
Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags.
Patch FreePBX
Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system.
Change the admin password
The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login.
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
Preserve first
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Cut the host off from the internet, or at least block all outbound traffic except to your SIP carrier. Blocking only the two known staging hosts is not enough if the operator has moved. With no route out, the minute-by-minute downloads fail, and nothing more is uploaded. One local loop survives: a watchdog cron line re-runs the cached copy of k.php at /var/lib/asterisk/bin/zen2 every minute, rebuilding the webshells offline, which is why cron comes first in the cleanup below.
Capture all crontabs and the eight backups listed below, /etc/passwd, /etc/shadow, shell profiles, and the web root with lsattr output and change times.
Export the FreePBX ampusers table, the call records database, and the Asterisk full log, and ask your carrier to preserve CDRs and registration logs.
Then clean, in this order
Cron and its spares. Clear root’s crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
Credentials. Only now rotate the secrets in the 17 files and across every account on the host.
Conclusion
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Indicators of Compromise
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
In May, Cyble Research & Intelligence Labs (CRIL) documented JOMANGY, a PHP webshell generation deployed by INJ3CTOR3 with self-healing persistence channels and a built-in toll-fraud dialer.
Back then, the fraud ran through the victim’s own PBX, so removing the implant would have stopped it. Artifacts we collected from the operator’s C2 staging servers during mid-September 2026 show that this is no longer true: the installer now sends credentials off the box on every run, and a second staging host serves it.
INJ3CTOR3’s FreePBX implant now uploads the victim’s SIP trunk, AMI, database, and mail-relay credentials to the operator, so disinfecting or rebuilding an infected host no longer ends the exposure. Anyone running FreePBX, Issabel, or Elastix who suspects compromise must rotate the secrets in 17 configuration files, and only after the host is clean.
The infection and persistence code is nearly unchanged; what the operator rotated are the identifiers that were available to defenders since the last time. Each section below pairs a finding with what to do about it.
Key Takeaways
Credentials leave on every run. k.php uploads 17 configuration files to both staging hosts every minute the host stays infected.
The fraud no longer needs your PBX. A stolen trunk secret lets the operator register and place calls as you from anywhere.
Last report’s identifiers have expired. Each build now carries its own watermark, and the webshell gate hash was rotated.
Two staging hosts. Plain-text commands now point to 160[.]119[.]69[.]4, while base64-encoded ones still use 45[.]95[.]147[.]178.
Clean-looking logs and consoles prove nothing. Requests through an encoded space reach the shell without being named in the access log, and trunks are written directly to /etc/asterisk; they do not appear in the FreePBX console.
The Campaign So Far
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
Figure 1: INJ3CTOR3 attack chain, September generation. (Source: 0x1da5 GitHub)
What Changed Since Our Last Report
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
Credential Exfiltration: The Implant Is No Longer the Product
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Figure 2: k.php line 34, decoded into 17 file uploads
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there
Outbound mail
/etc/postfix/sasl_passwd
The SMTP relay account, with your mail provider
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
Detection
Network: outbound HTTP POSTs from a PBX to any /hima_data/ path or to either staging host. A PBX seldom needs outbound web access beyond vendor updates, so egress allow-listing closes this channel.
Carrier: alert on trunk registrations from outside your own IP ranges, and on premium or international destinations, off-hours calling, and unusual concurrency. Set spend caps and destination blocks where your carrier offers them.
For Law Enforcement Agencies and CERTs
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
Two Staging Hosts, Split by Encoding
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
Reference
Encoding
Points to
k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback
Plain text
160[.]119[.]69[.]4
Camouflaged cron payloads, login-triggered stager
Base64
45[.]95[.]147[.]178
Credential upload
Base64
Both
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
The Webshell: Same Program, New Identifiers
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Figure 3: The panel’s Freepbx and Elastix buttons forge an admin session without a password
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
The .htaccess Door and the Access-Log Gap
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell byits filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
What the FreePBX Console Won’t Show You
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Figure 4: Our lab trunk, known to Asterisk and carrying calls, invisible in the FreePBX console
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
What Keeps It There
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
Figure 5: Persistence channels that rebuild each other, and the backdoors they stay open
Detecting It Without IOCs
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
Check
What it flags
Packed shells
Several identical, same-size PHP files across unrelated directories
Locked files
chattr +i or +a under the web root or in hidden directories
Unowned .htaccess
An .htaccess no installed package accounts for
Self-rebuilding cron
A cron line that downloads a file and hands it to a shell
Accounts
An extra UID-0 account, or a full-permission FreePBX admin, nobody created
Blocklist
Addresses dropped in and out by iptables outside fail2ban’s chains
Figure 6: beagle.sh (Source: 0x1da5 GitHub)
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
Layer
Behavior
What it catches
Host
crond spawns a shell that downloads a file and runs it
The takeover script on its single run, before persistence and before credentials leave
Host
The web server account spawns a shell
The webshell’s command box in use
Host
A cron child rewrites the crontab every minute without reading it first
Beacon reinstallation
Host
chattr +i or touch -r on a file in the web root
The lock and the borrowed timestamp
Host
Twelve PHP files were written to the web root in the same second
The webshell copies, as they are written; fan-out
Network
The PBX contacts staging host roughly every 60 seconds
The beacon’s rhythm, whatever the address
Network
Many configuration files read, then outbound POST requests
Credentials leaving
Web
A request with leading encoded whitespace returns 200 for a path not on disk
The .htaccess door
Decoy
Any read of a decoy config file that the implant reads, but nothing legitimate does
Credential collection, with no false positives by design
Phone
Channels originate over AMI or the CLI outside your dial plan
A call asking for nothing legitimate
Phone
CDRs with premium destinations, off-hours calling and unusual concurrency
The fraud itself
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
Why Cleanup Fails, and the Order That Works
First move
Why it fails on its own
Delete the webshell
Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags.
Patch FreePBX
Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system.
Change the admin password
The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login.
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
Preserve first
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Cut the host off from the internet, or at least block all outbound traffic except to your SIP carrier. Blocking only the two known staging hosts is not enough if the operator has moved. With no route out, the minute-by-minute downloads fail, and nothing more is uploaded. One local loop survives: a watchdog cron line re-runs the cached copy of k.php at /var/lib/asterisk/bin/zen2 every minute, rebuilding the webshells offline, which is why cron comes first in the cleanup below.
Capture all crontabs and the eight backups listed below, /etc/passwd, /etc/shadow, shell profiles, and the web root with lsattr output and change times.
Export the FreePBX ampusers table, the call records database, and the Asterisk full log, and ask your carrier to preserve CDRs and registration logs.
Then clean, in this order
Cron and its spares. Clear root’s crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
Credentials. Only now rotate the secrets in the 17 files and across every account on the host.
Conclusion
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Indicators of Compromise
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
In May, Cyble Research & Intelligence Labs (CRIL) documented JOMANGY, a PHP webshell generation deployed by INJ3CTOR3 with self-healing persistence channels and a built-in toll-fraud dialer.
Back then, the fraud ran through the victim’s own PBX, so removing the implant would have stopped it. Artifacts we collected from the operator’s C2 staging servers during mid-September 2026 show that this is no longer true: the installer now sends credentials off the box on every run, and a second staging host serves it.
INJ3CTOR3’s FreePBX implant now uploads the victim’s SIP trunk, AMI, database, and mail-relay credentials to the operator, so disinfecting or rebuilding an infected host no longer ends the exposure. Anyone running FreePBX, Issabel, or Elastix who suspects compromise must rotate the secrets in 17 configuration files, and only after the host is clean.
The infection and persistence code is nearly unchanged; what the operator rotated are the identifiers that were available to defenders since the last time. Each section below pairs a finding with what to do about it.
Key Takeaways
Credentials leave on every run. k.php uploads 17 configuration files to both staging hosts every minute the host stays infected.
The fraud no longer needs your PBX. A stolen trunk secret lets the operator register and place calls as you from anywhere.
Last report’s identifiers have expired. Each build now carries its own watermark, and the webshell gate hash was rotated.
Two staging hosts. Plain-text commands now point to 160[.]119[.]69[.]4, while base64-encoded ones still use 45[.]95[.]147[.]178.
Clean-looking logs and consoles prove nothing. Requests through an encoded space reach the shell without being named in the access log, and trunks are written directly to /etc/asterisk; they do not appear in the FreePBX console.
The Campaign So Far
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
Figure 1: INJ3CTOR3 attack chain, September generation. (Source: 0x1da5 GitHub)
What Changed Since Our Last Report
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
Credential Exfiltration: The Implant Is No Longer the Product
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Figure 2: k.php line 34, decoded into 17 file uploads
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there
Outbound mail
/etc/postfix/sasl_passwd
The SMTP relay account, with your mail provider
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
Detection
Network: outbound HTTP POSTs from a PBX to any /hima_data/ path or to either staging host. A PBX seldom needs outbound web access beyond vendor updates, so egress allow-listing closes this channel.
Carrier: alert on trunk registrations from outside your own IP ranges, and on premium or international destinations, off-hours calling, and unusual concurrency. Set spend caps and destination blocks where your carrier offers them.
For Law Enforcement Agencies and CERTs
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
Two Staging Hosts, Split by Encoding
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
Reference
Encoding
Points to
k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback
Plain text
160[.]119[.]69[.]4
Camouflaged cron payloads, login-triggered stager
Base64
45[.]95[.]147[.]178
Credential upload
Base64
Both
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
The Webshell: Same Program, New Identifiers
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Figure 3: The panel’s Freepbx and Elastix buttons forge an admin session without a password
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
The .htaccess Door and the Access-Log Gap
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell byits filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
What the FreePBX Console Won’t Show You
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Figure 4: Our lab trunk, known to Asterisk and carrying calls, invisible in the FreePBX console
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
What Keeps It There
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
Figure 5: Persistence channels that rebuild each other, and the backdoors they stay open
Detecting It Without IOCs
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
Check
What it flags
Packed shells
Several identical, same-size PHP files across unrelated directories
Locked files
chattr +i or +a under the web root or in hidden directories
Unowned .htaccess
An .htaccess no installed package accounts for
Self-rebuilding cron
A cron line that downloads a file and hands it to a shell
Accounts
An extra UID-0 account, or a full-permission FreePBX admin, nobody created
Blocklist
Addresses dropped in and out by iptables outside fail2ban’s chains
Figure 6: beagle.sh (Source: 0x1da5 GitHub)
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
Layer
Behavior
What it catches
Host
crond spawns a shell that downloads a file and runs it
The takeover script on its single run, before persistence and before credentials leave
Host
The web server account spawns a shell
The webshell’s command box in use
Host
A cron child rewrites the crontab every minute without reading it first
Beacon reinstallation
Host
chattr +i or touch -r on a file in the web root
The lock and the borrowed timestamp
Host
Twelve PHP files were written to the web root in the same second
The webshell copies, as they are written; fan-out
Network
The PBX contacts staging host roughly every 60 seconds
The beacon’s rhythm, whatever the address
Network
Many configuration files read, then outbound POST requests
Credentials leaving
Web
A request with leading encoded whitespace returns 200 for a path not on disk
The .htaccess door
Decoy
Any read of a decoy config file that the implant reads, but nothing legitimate does
Credential collection, with no false positives by design
Phone
Channels originate over AMI or the CLI outside your dial plan
A call asking for nothing legitimate
Phone
CDRs with premium destinations, off-hours calling and unusual concurrency
The fraud itself
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
Why Cleanup Fails, and the Order That Works
First move
Why it fails on its own
Delete the webshell
Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags.
Patch FreePBX
Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system.
Change the admin password
The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login.
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
Preserve first
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Cut the host off from the internet, or at least block all outbound traffic except to your SIP carrier. Blocking only the two known staging hosts is not enough if the operator has moved. With no route out, the minute-by-minute downloads fail, and nothing more is uploaded. One local loop survives: a watchdog cron line re-runs the cached copy of k.php at /var/lib/asterisk/bin/zen2 every minute, rebuilding the webshells offline, which is why cron comes first in the cleanup below.
Capture all crontabs and the eight backups listed below, /etc/passwd, /etc/shadow, shell profiles, and the web root with lsattr output and change times.
Export the FreePBX ampusers table, the call records database, and the Asterisk full log, and ask your carrier to preserve CDRs and registration logs.
Then clean, in this order
Cron and its spares. Clear root’s crontab in one go, so the restore and watchdog lines are removed. Then kill any running zen2, devnull2, or serv processes; killed earlier, the watchdog restarts them within a minute. Remove the k.php beacons (/var/lib/asterisk/bin/zen2, devnull2, zen222, devnull312, devnull212, /tmp/.cache/update, /dev/shm/.systemd/kernel). Unlock (chattr -i, -a) and delete the eight crontab backups: /usr/lib/.systemd/.cache, /usr/share/.fonts/.config, /var/lib/.dbus/.data, /var/tmp/.X11/.Xauthority, /opt/.local/.bashrc, /var/cache/.fontconfig/.cfg, /etc/.ssl/.cert, and /root/.config/.pref.
Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
Accounts and SSH. Remove every extra UID-0 account and any account whose /etc/shadow hash begins with $1$nRz1Cbtk$ (legitimate service accounts with that hash need new passwords, not deletion). Restore sshd_config, where root login was re-enabled.
Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
Credentials. Only now rotate the secrets in the 17 files and across every account on the host.
Conclusion
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Indicators of Compromise
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
L’Université de Leipzig a été victime d’une cyberattaque. Les serveurs connectés à Internet ont été mis hors ligne le mercredi pour prévenir tout dommage. L’attaque a affecté le site web et le système de messagerie, empêchant les étudiants et le personnel de communiquer. Les autorités mènent des analyses pour déterminer la nature de l’attaque, la méthode d’intrusion et si des données ont été exfiltrées.
Access timely breach intelligence, ransomware monitoring, in-depth reporting, high-resolution evidence, unredacted threat feeds, and an archive of more than 5,100 articles. Explore available plans to find the coverage you need.
The major cyber attacks of September 2026 hit federal law enforcement, a rival cybercrime gang, and the companies that verify identities. ShinyHunters hijacked the Clop ransomware gang’s Dark Web leak site and, four days later, claimed a breach of the Federal Bureau of Investigation (FBI). Identity data drove the month’s biggest numbers, led by a data breach linked to a Dark Web service advertising more than 153 million driver’s license scans.
AI agents also moved from research into real campaigns. One actor used hundreds of agents to compromise 395 organizations, while several espionage groups adopted the same Chrome and Windows zero-day chain within days. A US utility, a healthcare technology company, and a major fintech firm rounded out the month with disclosures involving sensitive customer and patient data.
Here are the major cyber attacks, breaches, and threat campaigns reported or significantly updated in September 2026.
ShinyHunters Claimed FBI Breach With 5,000 Purported Staff Records
On September 22, 2026, ShinyHunters claimed it had breached FBI systems through a new, unpatched Oracle PeopleSoft zero-day and stolen data on bureau employees and job applicants. The FBIJobs.gov recruitment site displayed a “seized by ShinyHunters” banner and went offline.
ShinyHunters’ defacement and breach claim
The group said it moved from PeopleSoft into Amazon Web Services (AWS) GovCloud, took 2 to 3 TB of data, and shared about 5,000 purported employee records with reporters, who verified parts of the set. It also claimed to be using the zero-day against Fortune 500 companies, which remains unverified. ShinyHunters exploited an earlier PeopleSoft flaw, CVE-2026-35273, in June 2026 and framed this attack as retaliation for a May 2026 FBI warning about its Canvas campaign.
The FBI’s own account points to a missed patch. On October 5, 2026, its Cyber Division said a contractor had failed to apply an available patch and that the bureau had removed the contractor. On October 9, 2026, FBI Director Kash Patel said the intrusion occurred on a third-party vendor’s platform and announced the arrest of another suspected ShinyHunters co-conspirator. As of October 27, 2026, Oracle has not confirmed a new PeopleSoft zero-day, and SOCRadar’s analysis of the FBI breach claim covers the incident in more depth.
IDScan Confirmed Breach Linked to 153 Million License Scans
Identity verification provider IDScan.net confirmed that an unauthorized party accessed customer data in its cloud platform. The disclosure followed reporting on September 1, 2026, that linked the company to Nexus, a Dark Web service advertising more than 153 million US and Canadian driver’s license scans, plus about 10 million ID cards, 3 million travel documents, and 579,000 medical cards. The FBI’s New Orleans field office opened an investigation the same day.
IDScan’s breach notice, first posted on September 4, 2026, is hidden from search engines. A September 29, 2026, update says the access ran from April 4 to September 2, 2026, and was limited to the VeriScan platform. Exposed data may include full names, contact details, dates of birth, and driver’s license, passport, or other government ID numbers, though the notice still does not mention the scans.
At least nine class actions were filed by September 4, 2026. Unlike passwords, licenses cannot be reset, so the scans can fuel account takeover, synthetic identity fraud, and Know Your Customer (KYC) bypass for years.
ShinyHunters Hijacked Clop’s Leak Site and Set a 72-Hour Deadline
On September 18, 2026, ShinyHunters abused a flaw in the Grav content management system (CMS) behind the Clop ransomware gang’s Dark Web leak site and defaced it. The group claimed it stole server data, source code, plugins, logs, and the private keys for Clop’s onion service. It gave Clop 72 hours to make contact, added the gang to its own leak site, and tied the attack to a dispute over Clop’s 2025 Oracle E-Business Suite campaign.
Clop’s Dark Web leak site, stating “Domain Seized by ShinyHunters.”
Clop moved its leak site to a new Tor address and confirmed the compromise came through a Grav path traversal flaw, CVE-2026-42608. Grav fixed the bug in version 2.0 in April 2026, but Clop ran the 1.7 branch, which had no patch until version 1.7.53.4 shipped on September 24, 2026. Clop said the server held only website content and denied any contact with ShinyHunters, which later removed Clop from its leak site.
If victim files were on the server, organizations that already paid Clop could face a second extortion attempt, a risk SOCRadar examined in its coverage of the Clop leak site hijack.
Suspected North Korean Hackers Stole $387.5 Million From Bitget
Cryptocurrency exchange Bitget detected unauthorized transfers from a limited number of hot and warm wallets on September 24, 2026. It first put losses at $351.6 million, then raised the figure to $387.5 million after adding Zcash and TRON transfers. Cold wallets were not affected, and withdrawals resumed in phases from September 28, 2026, with all assets reopened by October 2, 2026.
Bitget traced the root cause to a zero-day in unnamed third-party security products, which gave the attacker privileged internal credentials. The attacker then compromised a critical backend system in the wallet infrastructure, spoofed transaction data, and triggered the exchange’s own authorization process. The stolen ETH, XRP, BNB, AVAX, USDT, and USDC moved across seven chains, and Bitget’s User Protection Fund is covering the loss.
Bitget’s CEO said the attack matched known North Korean patterns, and blockchain analysts linked the funds to wallets used to launder earlier North Korea-attributed heists, including the 2025 Bybit theft. One analysis pointed to the TraderTraitor group, but as of October 27, 2026, no government has attributed the attack. If the attribution holds, suspected North Korean crypto theft in 2026 passes $1 billion, the second-largest year on record.
AI Agents Compromised 395 Organizations Through PaperCut Flaws
A likely Russian-speaking actor used hundreds of AI agents to build and run a global exploitation campaign against PaperCut NG/MF print management servers between August 27 and September 2, 2026. Researchers counted at least 440 compromised instances across 395 organizations in 48 countries, and 204 of those instances belonged to education.
Running on OpenAI’s Codex harness with a DeepSeek model, the agents developed, tested, and used exploits for CVE-2026-81578 and CVE-2026-82078, drawing on public proof-of-concept (PoC) code and patched builds. Both flaws were already disclosed: PaperCut published its advisory on August 27, 2026, and the Cybersecurity and Infrastructure Security Agency (CISA) added them to its Known Exploited Vulnerabilities (KEV) catalog on August 31, 2026.
The attacker built target lists through the Netlas scanning platform, harvested credentials from 280 victims, pulled operating system or domain secrets from 147, and reached domain administrator access at 12. The agents also did not consistently honor instructions to avoid 28 countries, and 20 victims sat in eight of them. PaperCut’s fix is Emergency Patch Release 2 for the 24.x, 25.x, and 26.x branches, after the first emergency patch was bypassed; version 23.x and older will not receive a fix.
BlueMoon Zero-Day Chain Reached at Least Four Espionage Clusters
A single exploit kit, dubbed BlueMoon, chained three Google Chrome and Microsoft Windows zero-days and spread across at least four espionage clusters within days. APT31 was the first observed user, on August 28, 2026, and later installed the LONGTALE malicious browser extension. On September 1, 2026, a cluster Volexity tracks as UTA0560 phished US-based non-governmental organizations (NGOs) to deliver the GRIMWEDGE JScript backdoor, and UTA0565 ran fake websites on September 3 and 4, 2026, against Asian government entities to drop CLEANGULP. Other clusters targeted a US aerospace company, a Vietnamese manufacturer, and organizations in Indonesia and Singapore.
The chain starts with CVE-2026-85046, a V8 type confusion flaw for code execution, and CVE-2026-87491, a V8 out-of-bounds write that escapes the V8 sandbox. CVE-2026-85880, a Windows Advanced Local Procedure Call (ALPC) heap overflow, then escapes the renderer sandbox and elevates privileges. The first Chrome bug was fixed in upstream Chromium on August 7, 2026, but the fix did not reach stable Chrome until September 3, 2026, a patch gap that left Chrome users exposed.
Google fixed the two Chrome flaws in versions 152.0.7977.82 and 153.0.8010.36, and Microsoft fixed the Windows flaw in its September 8, 2026, Patch Tuesday release. CISA added all three to the KEV catalog between September 4 and 9, 2026. Researchers assess the clusters as China-linked, and a 2024 US indictment tied APT31 to China’s Ministry of State Security, though no government has attributed the BlueMoon activity itself.
SOCRadar Found NetScaler C2 Hunting Up to 120,000 Hosts per Run
Citrix disclosed on September 27, 2026, that two critical NetScaler ADC and Gateway flaws were under attack. CVE-2026-88771 (9.5 CVSS v4.0) lets unauthenticated attackers run arbitrary commands, even on default configurations. CVE-2026-88772 (9.5 CVSS v4.0) is a memory overflow that can lead to RCE or denial of service on appliances with Datagram Transport Layer Security (DTLS) enabled, the default for VPN virtual servers.
Exploitation started before disclosure. An exploitation attempt was spotted three days earlier, and incident responders traced CVE-2026-88772 activity back to early September 2026. Intrusions led to web shells, credential theft, and lateral movement, and mass exploitation of CVE-2026-88771 began on September 28, 2026. CISA added both flaws to the KEV catalog on September 27, 2026, and Citrix’s fixed builds start at 14.1-73.37 and 13.1-64.23.
On October 1, 2026, SOCRadar’s Threat Research Unit identified NetScaler C2, an autonomous framework that runs every 30 minutes. Each cycle pulls exposed hosts from FOFA, fingerprints their versions, exploits CVE-2026-88771, and deploys an agent that polls for operator commands.
NetScaler C2’s attack pipeline
A single run can enumerate up to 120,000 candidate hosts, against roughly 23,000 exposed NetScaler instances online. Simplified Chinese code comments point to a Chinese-speaking operator using AI-assisted development, while the number of appliances it compromised remains unknown.
CenterPoint Energy Data Theft Reached More Than 1 Million Texans
US utility CenterPoint Energy confirmed that an attacker obtained customer personal information through one of its external-facing systems. The disclosure came after a threat actor leaked data allegedly stolen from the company.
The actor, using the alias “4d722e4d656f77”, claims it took 7.49 million customer records containing names, phone numbers, service and billing addresses, account numbers, billing amounts, and partial Social Security numbers (SSNs). It said it pulled the records from a public application programming interface (API) that lacked rate limiting, and leaked them after the company ignored its messages.
CenterPoint’s Form 8-K, filed with the US Securities and Exchange Commission (SEC) on September 14, 2026, confirms the theft but gives no victim count or data types, and says electric and gas service was not affected. A later notice to the Texas Attorney General puts the number of affected Texans at 1,062,060, with exposed data including names, addresses, SSNs, and driver’s license numbers. Proposed class actions allege the intrusion ran from August 17 to September 1, 2026.
Gyazo Breach Exposed 23.62 Million User Records
Kyoto-based Helpfeel disclosed on September 16, 2026, that a breach of its Gyazo image-sharing service exposed about 23.62 million user records, including email addresses and password hashes. The figure includes anonymous accounts, and Helpfeel is still determining how many individuals are affected. The attacker also reached about 490 million image metadata records, mostly for images uploaded in January 2019 or earlier.
Those metadata records hold the IDs that make up Gyazo image links, so they could be used to view private images without permission. Helpfeel temporarily disabled viewing for some affected images and asked every user to change their password, along with any matching password reused on other services. No payment card data was exposed.
The intrusion began on September 11, 2026, through a vulnerability in Gyazo’s image upload server that let the attacker run arbitrary commands and reach the Gyazo database. Helpfeel fixed the flaw by the next day and reported the breach to Japan’s Personal Information Protection Commission on September 15, 2026. While images were failing to load, Gyazo’s public notices described the outage as maintenance.
Revolut Handed Customer Data to a Fake Government Request
Fintech company Revolut confirmed on September 12, 2026, that it shared data on an undisclosed number of customers with a threat actor impersonating a government agency. The request came from a legitimate government email domain and passed domain authentication checks, so Revolut fulfilled it in the belief that it was genuine. Reports trace the request to an Italian government email account, though Revolut has not named the agency.
The disclosed data included identity and contact details, copies of passports or driver’s licenses, KYC verification selfies, International Bank Account Numbers (IBANs), and other financial records. Revolut, which serves more than 80 million customers, said only a limited number were affected and that its systems and customer funds were untouched. Crypto fraud investigator ZachXBT said the activity appeared aimed at high-net-worth users, and a group calling itself “iamnotavillain” later demanded 6,000 XMR, about $3 million, though Revolut said it received no direct demand.
No network intrusion took place, which puts this incident beyond the reach of most technical controls. Any organization that answers government data requests faces the same exposure when a fraudulent request arrives from a legitimate agency domain.
The Gentlemen Claimed 3.5 Million Veradigm Patient Records
Healthcare technology company Veradigm, formerly Allscripts, disclosed in a Form 8-K on September 8, 2026, that one of its third-party vendors suffered a cybersecurity incident affecting data tied to a small number of its customers. The unauthorized party used credentials from the vendor’s environment against a Veradigm API to download copies of patient personal data, in some cases including SSNs. Veradigm said no clinical or medical data was involved.
The filing came three days after the ransomware group The Gentlemen added Veradigm to its Dark Web leak site on September 5, 2026.
Veradigm listing on The Gentlemen’s leak site
The group claims it holds 3.5 million patient records and threatened to publish them unless Veradigm paid. SOCRadar’sbreach record for Veradigm shows The Gentlemen claimed 237 victims in the 60 days before the listing. As of October 27, 2026, Veradigm has not released a patient count.
How SOCRadar Can Help
September showed how often a breach starts outside an organization’s own network, through a vendor’s credentials, an exposed API, an unpatched server, or a post on a ransomware leak site. Catching those signals early gives security teams time to act before stolen data or access is used against them. SOCRadar provides several modules for monitoring this external risk:
Dark Web Monitoring: Detects leaked data, compromised credentials, and ransomware leak site posts that mention your organization.
Attack Surface Management: Discovers internet-facing assets such as VPN gateways, print servers, and APIs, and flags exposures attackers could use.
Vulnerability Intelligence: Prioritizes patching with exploited-in-the-wild context for zero-days like those seen in PeopleSoft, PaperCut, Chrome, and Windows this month.
Staying proactive with integrated threat intelligence and continuous monitoring remains essential as attack vectors evolve rapidly across third-party networks and zero-day vulnerabilities.
Ransomware operators are scaling their attacks, and the barriers to entry continue to fall. In the first half of 2026, Flashpoint identified 6,256 ransomware attacks across industries, representing a 45% increase between 2025 and 2026, as Ransomware-as-a-Service (RaaS) operations expanded and threat actors increasingly leveraged AI, stolen credentials, and vulnerability exploits to accelerate their campaigns.
The impact is widespread. Manufacturing accounted for 18% of observed attacks, followed by business services and consulting (13%) and healthcare (9%). Meanwhile, prolific ransomware groups such as Qilin and Akira continue to demonstrate the scale at which these operations can function.
Understanding how ransomware attacks develop, and where they can be interrupted, is critical for defenders.
Introducing Ransomware in the Age of AI: A Survival Guide for Defenders
Flashpoint’s new guide, Ransomware in the Age of AI: A Survival Guide for Defenders, provides cyber threat intelligence professionals, threat hunters, and security leaders with a practical look at the modern ransomware attack lifecycle, from initial reconnaissance and access to incident response and recovery.
Drawing on Flashpoint’s primary-source intelligence and analysis of evolving threat actor tactics, the guide explores how organizations can identify opportunities to disrupt attacks before they escalate, strengthen incident response, and reduce the risk of repeat compromise.
Access the guide to learn:
How modern ransomware attacks unfold: Follow the attack lifecycle, from reconnaissance, phishing, and initial access through lateral movement, encryption, and ransom negotiations.
Where defenders can intervene: Understand how compromised credential monitoring, vulnerability intelligence, and visibility into underground activity can help identify threats before attackers reach critical systems.
How AI is reshaping ransomware operations: Explore how AI-enabled capabilities, commoditized tooling, and RaaS ecosystems are changing the economics and execution of ransomware attacks.
How to strengthen response and recovery: Learn strategies for containing active incidents, restoring operations, improving cross-team coordination, and reducing exposure to repeat attacks.
“In H1 2026, Flashpoint observed a 45% surge in ransomware activity, with critical sectors like manufacturing, business consulting, and healthcare taking the brunt of these attacks. As RaaS syndicates like Qilin and Akira scale their operations alongside a 27% rise in infostealers, access is becoming faster and cheaper. Effective defense requires grounding incident response in primary-source intelligence across every phase of the attack lifecycle.”
Ian GrayVP of Intelligence, Flashpoint
Understanding the Modern Ransomware Attack Lifecycle
Ransomware attacks rarely begin with encryption. Long before systems are locked or ransom demands appear, threat actors may be gathering intelligence on potential targets, exploiting exposed vulnerabilities, or acquiring stolen credentials through underground marketplaces.
Flashpoint observed a 27% increase in infostealer operations in H1 2026 compared to H1 2025, underscoring the growing role of compromised identities in the ransomware ecosystem. Stolen credentials and session data can provide attackers with access to organizational environments, potentially allowing them to bypass traditional defenses and establish a foothold.
These initial access methods are increasingly interconnected with broader criminal operations. RaaS groups can leverage specialized tools and services throughout the attack chain, while AI-enabled capabilities offer additional opportunities to automate and accelerate certain activities.
This creates multiple opportunities for defenders to act. Intelligence about exposed credentials, emerging exploitation activity, and threat actor behavior can help security teams identify risks earlier and prioritize defensive action before an intrusion progresses.
The guide examines these opportunities across the ransomware lifecycle, outlining how proactive intelligence and coordinated response can help organizations minimize operational disruption and strengthen resilience.
Build a More Proactive Defense Against Ransomware
As ransomware operations continue to evolve, organizations need visibility into the threats targeting their environments and the intelligence to respond at every stage of an attack.
From identifying compromised credentials and monitoring emerging threats to containing incidents and preventing repeat attacks, a lifecycle-based approach helps security teams make more informed decisions before, during, and after a ransomware incident.
Get the Ransomware in the Age of AI: A Survival Guide for Defenders to explore the modern ransomware attack lifecycle and learn how Flashpoint’s threat intelligence can help your organization anticipate, disrupt, and recover from ransomware attacks.
Australia’s cyber security authority responded to 1,524 cyber security incidents in the 2025-26 financial year, a 20% increase from the previous year and a 36% rise over five years. The latest Annual Cyber Threat Report shows that phishing, compromised accounts, unpatched systems, ransomware and data theft remain the main operational pressures.
Artificial intelligence is increasing the speed and scale of many established techniques, but the report’s central message is practical: organisations need to patch faster, protect identities, improve logging, manage supplier access and prepare to continue operating during an incident. The Australian Signals Directorate’s Australian Cyber Security Centre also expanded proactive warning activity, issuing more than 4,400 notifications about potential malicious activity during the year.
What Did Australia Record in 2025-26?
Measure
2025-26 result
Change or context
Cyber security incidents
1,524
Up 20% year over year
Potential malicious activity notifications
More than 4,400
Up almost 80%
Cybercrime reports
More than 82,000
About one every 6 minutes
Ransomware incidents
139
Broadly consistent with last year
Data breach incidents
98
Up 66%
Average business cost per report
A$93,500
Up 16% overall
These figures come from different reporting and response channels. Cybercrime reports, incidents handled and proactive notifications should not be added together as if they represent unique victims. Read together, however, they show both high public reporting volume and a larger operational workload for government responders.
What Changed in Australia’s Threat Picture?
The incident count increased, but the more important shift was in impact. Extensive compromises rose from 26 to 40, even though only one Category 2 (C2) incident, the second-highest severity level, was recorded. Ransomware and distributed denial-of-service activity also produced more extensive compromises despite stable or falling overall volumes.
Improved visibility also contributed to the rise. ASD’s ACSC identified 362 incidents after proactively warning organisations about suspicious activity, while more than half of its individual notifications originated from declassified intelligence. The increase therefore reflects a combination of worsening risk, stronger detection and greater reporting awareness.
How Much Did Cybercrime Cost Australians?
More than 82,000 cybercrime reports were submitted through ReportCyber, or about one every six minutes. Identity fraud remained the most frequently reported cybercrime, although reports in that category fell 18%. The Australian Cyber Security Hotline received more than 37,500 calls, down 12% from the previous year.
The average self-reported cost for individuals remained A$33,000. The business average rose 16% to A$93,500 per report. Small businesses reported an average cost of A$55,400, medium businesses A$141,300 and large businesses A$148,100. The 45% rise for medium businesses stands out because these organisations may combine valuable data and connected systems with fewer specialist security resources than large enterprises.
Which States Reported the Most Cybercrime?
Victoria accounted for 27% of cybercrime reports, followed by Queensland at 26% and New South Wales at 22%. Western Australia represented 12%, South Australia 7%, while the Northern Territory, Australian Capital Territory and Tasmania each accounted for 2%. The report notes that Australia’s three most populous states continued to generate the highest reporting volumes, with disproportionately high reporting rates relative to their populations.
Share of cybercrime reports submitted through ReportCyber by state and territory in 2025-26.
Which Attack Paths Appeared Most Often?
Phishing appeared in 39% of analysed incidents, followed by compromised accounts at 21%, user execution at 17%, valid accounts at 15%, and social engineering at 13%. These percentages overlap because one incident can involve several techniques. The pattern shows why email filtering alone is not enough: identity monitoring, secure recovery processes and post-login detection are also necessary.
Prevalence of the top 10 MITRE ATT&CK techniques observed in Australian cyber security incidents during 2025-26.
Data exposure also became more prominent. ASD’s ACSC responded to 98 data breach incidents, up 66%, while the Office of the Australian Information Commissioner received 1,205 breach notifications during 2025, its highest annual total since the Notifiable Data Breaches scheme began. Stolen personal information can support identity fraud, targeted phishing and account recovery abuse long after the original breach.
Why Did Flat Ransomware Volume Still Matter?
ASD’s ACSC responded to 139 ransomware incidents, broadly consistent with the previous year. However, extensive ransomware incidents increased from 16 to 24. Health Care and Social Assistance, Professional, Scientific and Technical Services, and Manufacturing remained the three most affected industry divisions.
This distinction matters because a stable incident count can hide rising operational harm. Modern ransomware campaigns may combine service disruption, data theft and public extortion, while Ransomware-as-a-Service lowers the barrier for affiliates. Defenders should measure recovery time, systems affected and data exposure, not only the number of attacks.
How Quickly Are Vulnerabilities Being Exploited?
Publicly reported common vulnerabilities and exposures (CVEs) increased 30%. ASD’s ACSC says most vulnerability exploitation occurs within two weeks, while some flaws are exploited within 48 hours of patch or mitigation guidance. It also recorded successful exploitation of a vulnerability first identified in 2008, showing that organisations must address both newly disclosed flaws and unsupported legacy systems.
A useful lesson is that patch speed depends on preparation before a vulnerability is disclosed. Organisations need a current inventory of internet-facing systems, clear ownership, tested emergency change procedures and a way to verify that a fix reached the running service. A policy target has limited value if teams cannot identify the affected asset or confirm deployment.
How Did Proactive Warnings Reduce Risk?
The report provides two examples of threat intelligence changing outcomes. A collective notification about cPanel vulnerabilities was sent to 340 entities and resulted in more than 60 incidents being confirmed. In a separate Akira ransomware investigation, reports from multiple organisations helped ASD’s ACSC connect activity to exploitation of a known SonicWall vulnerability.
ASD’s ACSC then identified almost 1,000 potentially vulnerable devices and around 40 potentially vulnerable Australian organisations, many in critical infrastructure, and issued targeted warnings. Similar reported incidents declined after the public alert. The practical insight is that reporting is not only a compliance task: shared evidence can reveal a campaign early enough to protect organisations that have not yet detected it.
Where Did Cyber Risk Concentrate?
Federal government accounted for 32% of incidents reported to ASD’s ACSC, followed by state and local government at 16%. The report cautions that government reporting obligations influence these totals. Health Care and Social Assistance was the leading non-government sector at 7%, while Manufacturing entered the top ten and recorded the largest increase in reports.
Critical infrastructure accounted for 154 incidents, or 10% of the total, down almost 7%. Phishing was the leading initial-access method in these incidents at 36%, followed by valid accounts at 16% and drive-by compromise at 10%. Financial and insurance services represented 30% of critical infrastructure incidents, ahead of public administration and safety at 21%, and electricity, gas, water and waste services at 17%.
State-sponsored actors continued to seek sensitive information and access that could support later espionage or disruption. The report specifically notes that China-nexus actors increasingly use covert networks built from compromised small-office/home-office routers, Internet of Things devices and smart devices to conceal the origin of malicious activity. This makes asset ownership and secure configuration important beyond conventional servers and employee endpoints.
How Is AI Changing the Operating Tempo?
The report does not present AI as a separate attack type. Instead, it describes AI as an accelerator for reconnaissance, vulnerability research, exploit development, phishing, impersonation, stolen-data analysis and malicious code adaptation. The immediate risk is less about an unfamiliar technique and more about familiar techniques becoming faster, cheaper and easier to personalise.
AI can also improve defence by analysing security data, identifying vulnerabilities, monitoring unusual behaviour and supporting incident response. Those benefits depend on governance. Organisations should limit the sensitive data available to AI systems, apply least privilege, retain audit records and require human review for consequential actions. Security teams should evaluate AI as both a new dependency and a defensive tool.
Why Are Supply Chains and Code Repositories a Priority?
Third-party access and software dependencies can spread one compromise across many organisations. ASD’s ACSC observed attackers using social engineering, stolen credentials and authentication tokens to enter code repositories, expose private source code, steal secrets and modify trusted software packages.
The report uses the self-replicating Shai-Hulud campaign as an example. After a maintainer account was compromised, malicious package versions harvested credentials and cloud metadata, exposed stolen secrets in public repositories and used captured access to compromise other packages. Organisations therefore need an accurate inventory of dependencies and deployed versions, tightly controlled maintainer privileges, secret scanning and rapid token revocation.
What Should Organisations Do Now?
Accelerate patching. Prioritise internet-facing and actively exploited vulnerabilities, replace unsupported technology and verify remediation in production.
Protect identities and sessions. Use phishing-resistant authentication, restrict privileges, secure recovery processes and monitor unusual token or session use.
Improve event logging. Retain the identity, endpoint, cloud, application and network evidence needed to understand access, impact and data exposure.
Reduce supplier and software risk. Map third-party access, dependencies, privileged integrations, code repositories and secrets, then test revocation and containment.
Plan for disruption. Adopt an assumed-breach mindset, test incident response and recovery, and define how critical services will continue when systems are unavailable.
Govern AI use. Limit data exposure, enforce least privilege, validate outputs and retain human oversight for actions that affect systems or customers.
Report suspicious activity early. Technical details and indicators can help authorities identify a wider campaign and warn other potential targets.
What Is the Main Takeaway?
Australia’s 2025-26 threat data shows an environment moving faster without abandoning familiar weaknesses. AI is compressing response time, but credentials, phishing, unpatched systems, supplier access and recovery readiness continue to shape real-world outcomes.
The report’s most useful message is operational: proven controls need to work at greater speed and across the full environment. Organisations that know their assets, protect legitimate access, preserve evidence and practise recovery are better placed to contain both established attacks and AI-assisted variants.
Frequently Asked Questions
What Is the Annual Cyber Threat Report 2025-26?
It is the Australian Signals Directorate’s annual assessment of cyber threats affecting Australian individuals, businesses, government and critical infrastructure. It combines incidents handled by ASD’s ACSC, public cybercrime reports, threat intelligence, notifications and case studies from the 2025-26 financial year.
How Many Cyber Security Incidents Did Australia Record?
ASD’s ACSC responded to 1,524 incidents, up 20% from the previous year and 36% over five years. This is the number of incidents handled by the national cyber security authority, not a complete count of every incident that occurred in Australia.
What Is the Difference Between a Cybercrime Report, an Incident and a Notification?
A cybercrime report is submitted through ReportCyber by a member of the public or an organisation. A cyber security incident is activity that ASD’s ACSC assessed or assisted with, while a notification is a warning sent to an entity about potential malicious activity or exposure. The categories can overlap, so their totals should not be combined.
What Was the Most Common Attack Technique?
Phishing was the most prevalent MITRE ATT&CK technique, appearing in 39% of analysed incidents. Compromised accounts, user execution and valid accounts were also common, showing that attackers frequently combine social engineering with legitimate credentials or sessions.
How Much Did Cybercrime Cost Australian Victims?
The average self-reported cost was A$33,000 for individuals and A$93,500 for businesses. These are averages for reports that included a cost, not an estimate of Australia’s total economic cost, and the business figure varied substantially by organisation size.
Did Ransomware Increase in 2025-26?
The total remained broadly stable at 139 incidents, but extensive ransomware compromises increased from 16 to 24. This means the volume was flat while the number of more consequential incidents rose.
How Serious Was the Data Breach Trend?
ASD’s ACSC responded to 98 data breach incidents, a 66% increase. Stolen personal information can be reused for identity fraud, targeted social engineering and account recovery attacks, so the effects may continue well beyond the initial intrusion.
How Is AI Affecting Cyber Security?
AI is reducing the time and skill needed for reconnaissance, exploit development, phishing and data analysis. It can also help defenders find vulnerabilities, analyse events and respond faster. The report recommends using AI with controlled data access, auditability and human oversight.
How Fast Do Organisations Need to Patch?
There is no single safe deadline for every vulnerability. ASD’s ACSC has observed most exploitation within two weeks and some within 48 hours of patch or mitigation guidance, so internet-facing and actively exploited flaws require urgent action. Organisations should also identify and replace unsupported systems that cannot receive fixes.
Which Sectors Reported the Most Incidents?
Federal government reported the largest share at 32%, followed by state and local government at 16%. Health Care and Social Assistance led non-government sectors at 7%. These percentages reflect reporting to ASD’s ACSC and are influenced by sector-specific obligations and reporting maturity.
What Should Smaller Organisations Prioritise First?
Start with a small set of controls that reduce common attack paths: automatic updates, phishing-resistant authentication, protected backups, secure account recovery, basic event logging and a tested incident contact process. Choosing products that are secure by default can reduce the operational burden where specialist resources are limited.
Why Does Reporting an Incident Matter?
A single report may reveal infrastructure, indicators or techniques affecting other organisations. The Akira and cPanel examples show how combined evidence and proactive notifications can identify vulnerable entities and reduce further incidents. Australian organisations can report even when compromise has not yet been confirmed.
SOCRadar Threat Research Unit identified an open directory on 96.126.130.81 that exposed the working files of an operator who ran an extortion campaign against Japanese real estate websites and then turned to PHP2Shell, the pair of unauthenticated PHP flaws tracked as CVE-2026-109618 and CVE-2026-109619. The server held more than 3,800 files, including a weaponized copy of the PHP2Shell reproducer package, scripts for web shell deployment and lateral movement, beacon logs, ransom pages and data stolen from victims. The ransom pages and contact addresses use the handle kkkkevin777.
The campaign focused on Japanese real estate and property-buying websites in October 2026. The intrusion resembled a supply chain attack. After compromising the website of a Japanese real estate services company, the operator used access material found in that environment to reach nearly 20 other sites on the same shared hosting infrastructure and to pull data on their customers.
The PHP2Shell tooling only arrived on the server on October 21, about ten days after this extortion wave, and the files show no link between PHP2Shell and these intrusions.
What This Report Does and Does Not Show
Initial access: The server does not show how the operator first got into the real estate sites. The October 9-11 extortion wave did not rely on PHP2Shell
PHP2Shell timeline: The PHP2Shell tooling reached the server on October 21, about ten days after the extortion wave
Current stage: The operator was adapting the public reproducer, building exploit, probe and pipeline scripts around it. The files contain no record of a successful exploitation against a live target
Why it matters: An operator who has already monetized shared-hosting access is now preparing PHP2Shell as a follow-on capability, likely for broader targeting
The stolen member data also creates third-party exposure. Customer records taken from the victims include email addresses on major Japanese telecom, mobile and ISP mail domains, which puts those end users at risk of phishing and credential stuffing well beyond the breached sites.
Key Takeaways
An exposed staging server at 96.126.130.81 held a weaponized copy of the PHP2Shell reproducer package for CVE-2026-109618 and CVE-2026-109619, added on October 21, about ten days after the extortion wave
The campaign started with one Japanese real estate services company and used it as a stepping stone to nearly 20 other Japanese websites, most of them real estate and property-buying businesses, between October 9 and 11, 2026
Shared hosting accounts were reached with a stored SSH key and a database password reused across sites, which turned one compromise into many
Ransom page templates and deployment scripts target public homepages with a fake maintenance notice and admin panels with a ransom note, with a negotiation deadline of October 11, 2026, 04:00 JST
The operator turned the initial victim’s customers into leverage, with a script built to mail its members in bulk and a drafted public forum post accusing the company of not reporting the breach
Stolen data on the server includes 16,061 member records with plaintext passwords, income and savings details, plus five SQL Server database backups and 730 business emails from a Taiwanese company
About 20 Japanese websites, mostly real estate and property buying, plus a Taiwanese company’s Windows server
Activity window
Extortion wave October 9 to 11, 2026; PHP2Shell tooling added October 21, 2026
Impact
Web shells, data theft, defacement, extortion of the company and its customers
Motivation
Financial extortion
PHP2Shell on the Attacker’s Server
The staging server held two copies of the PHP2Shell package. The packages include:
Weaponization notes describing how the lab stages chain toward remote code execution
Loop and single-child scripts for repeated exploitation attempts against live targets
Helper and debugger scripts used during development
A second build of the package with Docker files and its own tools folder
Both packages, and every file inside them, are dated October 21, 2026, about ten days after the extortion wave against Japanese real estate sites. Exploit, pipeline and probe scripts that build on the package appear on the server from that date onward, which marks PHP2Shell as the operator’s next capability rather than the tool behind the earlier intrusions. The files contain no saved output showing a successful PHP2Shell exploitation of a live site. Any PHP site running a vulnerable version should still be treated as exposed.
How the Exposed Server Was Found
The server at 96.126.130.81 exposed its working directory over an unauthenticated HTTP directory listing on port 9999. The listing included shell scripts, Python tools, PHP payloads, beacon and command-and-control (C2) logs, ransom page templates, an SSH private key and archives of stolen mail and databases.
File timestamps place most activity between October 8 and October 27, 2026, with peaks on October 10, October 15 and October 21 to 23. The server’s SSH service had been moved to port 888 and fail2ban installed, a sign that the host was meant for long-term use.
From One Compromise to About 20 Victims
Attack flow of the campaign, from the staging server to extortion
Initial Victim
Scripts dated from October 9 show the attacker already holding web shell access to the initial victim’s website. How that access was first obtained is not recorded on this server, and comments in the scripts say they were run from a separate machine. The attacker:
Placed PHP web shells under an image upload directory, using random 32-character file names
Injected a beacon into the site’s database configuration file that called back to 96.126.130.81 on port 9001
Seeded a self-propagating PHP hook across the web root
Overrode the site owner’s deny rules in .htaccess and installed a cron job that rewrote them every minute, so the owner’s lockout attempts were reverted automatically
Tested outbound mail from the company’s info@ address to an external Gmail address
The server also held a member database export from the site, containing customer names, contact details, addresses and passwords stored in plaintext.
Pivot Across Shared Hosting
The initial victim’s environment gave the attacker what was needed to go further. An SSH private key stored on the staging server was used to log in to several other accounts on the same shared hosting provider. Scripts on the server also show one database password reused across multiple victim sites that share the same member table structure, which points to a common web platform or a common developer behind them.
The beacon log records callbacks from about 20 Japanese domains between October 9 and October 11, 2026. Most belong to real estate agencies, property-buying services and related local businesses. The attacker also probed internal database ports from inside the hosting network and tried FTP logins with harvested credentials on further accounts.
Distinct sites calling back to the beacon listener per hour, October 9 to 11, 2026 (server time)
Other Targets
Recon scripts and port lists also reference a Japanese food manufacturer’s webmail, with no confirmed compromise. A Taiwanese company the operator researched through WHOIS lookups did not remain a reconnaissance target; its data appears on the server, as described below.
What Data Was Taken
The server holds the results of the operator’s data theft, not only the tools. The haul spans Japan and Taiwan and covers customer records, internal databases and business email.
Data recovered from the operator’s server
Customer Records From the Initial Victim
The initial victim’s member export holds 16,061 records, and each one goes well beyond contact details. Alongside names, phone numbers, email addresses and home addresses, the export stores plaintext passwords, annual income, savings, occupation, household details and each member’s property search, including budget, preferred area and purchase timing. That combination gives an attacker what is needed for credential stuffing, convincing real estate or financial phishing and targeted fraud.
Fields in the initial victim’s member export, with no customer data shown
Proof of Access Across Nearly 20 Sites
The beacon listener on the staging server logged callbacks from 20 domains between October 9 and 11, 2026, each one a site carrying the operator’s injected code. Scripts on the server also used the shared database password to query member tables on other victim sites.
First callback from each site in the operator’s beacon log, with hostnames redacted
A Taiwanese Company’s Databases and Mailbox
On October 22 and 23, 2026, the operator pulled data from a Windows server hosted in Taiwan through a web shell: five SQL Server database backups totaling about 345 MB, 663 FoxPro database files totaling about 703 MB and 730 emails from a company mailbox dated 2024 to 2026. A script on the server was written to crack a password-protected archive from the same haul. How the operator first got into that server is not recorded in the files.
Large Organizations in the Blast Radius
SOCRadar’s analysis of the stolen customer data found email addresses on domains belonging to major Japanese banking, telecommunications and technology organizations, including companies with annual revenues ranging from hundreds of millions to tens of billions of dollars. Most of these are consumer mail services, so the exposed people are subscribers who were customers of the victim sites. A smaller number are corporate domains, which puts those organizations’ employees within reach of targeted phishing. None of these organizations was breached in this campaign.
Organizations whose email domains appear in the stolen customer data, with names redacted
The Extortion Playbook
The server holds two page templates and the scripts that deploy them:
Public site: Overwrites the homepage with a Japanese “system maintenance” notice listing a contact address
Admin panel: Overwrites the management page with a warning that names the same address as the negotiation contact and shows a countdown to October 11, 2026, 04:00 JST
Fake maintenance notice built for victims’ public homepages, rendered from the attacker’s templateRansom note built for victims’ admin panels, rendered from the attacker’s template after the deadline expired
The scripts back up the original index pages before overwriting them. Repeated “relock” scripts, along with a saved copy of a site owner’s own lockout rules, indicate that owners were removing the pages and the operator kept restoring them. Scripts also ran database processing jobs on several victim accounts and swept victims’ home directories for backup files, which would reduce their options for recovery.
A later script searched victims’ web roots for the original Tutamail contact address and replaced it with a Gmail address, the same address targeted by a test message sent from the initial victim’s mail server. Whether the second address belongs to the same person, a partner or a buyer of access is not established in the files.
Scripts that swap the ransom contact address and restore the ransom pages on victim sites
Pressure on Customers
The operator also turned the initial victim’s customers into leverage. A script on the server, staged on October 10, was built to send pre-written messages in bulk through sendmail, with progress tracking and a kill switch. A drafted public forum post claims that notices went out from the initial victim’s official mail server to every member, each containing the recipient’s own details and those of 49 other members, and that data on 167,000 members was taken. These figures are the operator’s claims; the server itself holds a member export of more than 16,000 records from the initial victim.
Direct Threats and Public Exposure
Victims were contacted outside the ransom pages as well. A “final warning” email drafted for staff at one victim company states that ignoring LINE messages or taking the site offline would not let them escape, and demands an immediate reply. On October 11, the operator drafted a thread for the 5ch newsplus board accusing the initial victim of failing to report the breach to Japan’s Personal Information Protection Commission. The saved responses stop at the board’s confirmation page, so publication is not confirmed.
Windows C2 and a Second Operation
The server also ran a small Python C2 on port 8443 paired with a PowerShell agent that polls for commands every 30 seconds and posts results back. Comments in both files label it as a beacon for a separate “finance line” operation, which indicates the operator was set up to run commands on Windows machines outside the real estate campaign. Results folders for this C2 were empty at the time of collection.
Who Is Behind the Campaign?
The ransom pages, contact addresses and scripts point to an operator using the handle kkkkevin777. Script comments and working notes are written in Simplified Chinese, while every victim-facing message is written in Japanese, and SSH keys authorized on the server carry the comment administrator@chenzicccc.
The files show no affiliate program, data leak site or ransomware-as-a-service panel. Each step, from web shell access to customer pressure, is scripted by hand. After the Japanese wave, the operator compiled 3,913 Hong Kong and Taiwan IP ranges and ran mass scans against them on October 21, 2026, the same day the PHP2Shell tooling arrived, and the separate “finance line” C2 points to more than one operation running in parallel. These are investigative leads drawn from the operator’s own files, not a confirmed identity.
Third-Party Exposure From the Stolen Member Data
The stolen member databases hold the personal data of the victim sites’ customers. Analysis of the email domains in this data shows heavy concentration on major Japanese telecom, mobile carrier and ISP mail services, alongside a smaller number of corporate domains.
Those customers were not breached through their own providers. Their names, contact details and home addresses are now in the attacker’s hands, along with plaintext passwords for the initial victim’s members, which makes them likely targets for phishing, extortion follow-ups and credential stuffing against other services where the same password was reused.
96.126.130.81 (staging server; open directory on 9999/tcp, SSH on 888/tcp)
96.126.130.81:9001 (PHP beacon listener)
96.126.130.81:8443 (PowerShell C2)
Beacon URI patterns:
/b?h=<hostname>
/h?h=<hostname>&t=bk_hook
/c?h=<hostname>
/c and /d on port 8443
Email addresses:
kkkkevin777@tutamail.com
theudinhthi421@gmail.com
Files and artifacts on victim hosts:
.whk.php in the web root
index.php.orig20261010 and manage/index.php.orig20261010 (backups of overwritten pages)
htaccess.their20261010 (backup of the owner’s .htaccess)
A cron entry rewriting .htaccess to “Require all granted” every minute
PHP files with 32-character hexadecimal names in image or upload directories
Calls to file_get_contents pointing to 96.126.130.81:9001 inside index.php or database configuration files
SSH key comment:
administrator@chenzicccc
How to Check Whether Your Site Was Compromised
Search web roots for the string 96.126.130.81 and for the email addresses above
Look for .whk.php, *.orig20261010 files and PHP files with random hexadecimal names in upload or image directories
Review the hosting account’s crontab for entries that rewrite .htaccess
Check web server logs for multipart requests with unusually long filenames that return HTTP 500, a pattern associated with PHP2Shell exploitation attempts
Audit authorized_keys files and SSH login history on shared hosting accounts
Compare database table contents against recent backups to confirm whether data was altered
Mitigation and Recommendations
Patch PHP: Update to a PHP release that fixes CVE-2026-109618 and CVE-2026-109619 and review the vendor’s guidance on session upload progress settings
Rotate credentials: Replace every SSH key, database password and FTP password used on affected hosting accounts, especially where the same credentials serve multiple sites
Separate customer environments: Web developers and agencies managing several client sites should stop reusing keys and database passwords across clients
Reset customer passwords: Victim sites should force password resets, move to hashed password storage and notify affected customers
Keep offline backups: Store backups outside the web hosting account so an attacker with account access cannot find or remove them
Block the infrastructure: Deny traffic to and from 96.126.130.81 at the network and hosting level
Do not pay: Verify the actual state of databases before engaging with any ransom demand, since the attacker already copied the data off the servers
Frequently Asked Questions
What Is PHP2Shell?
PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, two unauthenticated memory corruption flaws in PHP’s session upload progress handling. A reproducer package shows how the flaws can lead to remote code execution. The operator’s staging server held a weaponized copy of that package, added after the real estate extortion wave.
Is PHP2Shell Being Exploited in the Wild?
A weaponized PHP2Shell toolkit and follow-on exploit and probe scripts were found on the server of an active extortion operator, added after the operator’s attacks on Japanese real estate sites. The files contain no saved output confirming a successful exploitation of a live target, but the tooling was prepared for use against internet-facing PHP hosts.
Which Organizations Were Affected?
The initial victim is a Japanese real estate services company. From its environment, the attacker reached nearly 20 other Japanese websites, mostly real estate agencies and property-buying services, through shared hosting access. A Taiwanese company’s Windows server was also accessed later in October, and its databases and email were pulled. Customers of the victim sites are affected too, because their member records were stolen. Email addresses at major banking, telecom and technology organizations appear in that customer data, but those organizations were not breached in this campaign.
Who Is Behind the Attacks?
The ransom pages and contact addresses use the handle kkkkevin777, and the operator’s scripts carry Simplified Chinese comments. The files point to a hands-on, financially motivated extortion operator with no sign of a ransomware affiliate program. These are leads from the operator’s own files, not a confirmed identity.
What Data Was Stolen?
The server held member databases with customer names, contact details and home addresses; the initial victim’s export of 16,061 records also includes plaintext passwords, annual income, savings and property search details. From a Taiwanese company, the operator pulled five SQL Server database backups, 663 FoxPro database files and 730 emails. The operator then used that data to pressure victims through their own customers.
Is Patching PHP Enough?
No. Patching closes the PHP2Shell flaws, but the real estate intrusions described here were not traced to PHP2Shell. Affected sites also need to remove web shells and cron entries, rotate every SSH key and database password, and restore clean pages and data. Sites that shared credentials with a compromised site should be treated as compromised even if PHP was patched.
Should Victims Pay the Ransom?
Victims should first verify the actual state of their databases and whether clean backups exist. The attacker copied data off the servers before making the demand, so payment does not guarantee –it never does– the data will be deleted or kept private.
Mexico
Table Of Contents
