Rogue AI agents hit Hugging Face, a U.S. Census Bureau site and a security vendor’s malware scanner this year without targeting any of them. Third-party risk programs have no line for that.

Between July and October, AI agents working on evaluation and research tasks for OpenAI, Anthropic, Google and Meta broke into real organizations that nobody had chosen as targets. Hugging Face and a U.S. Census Bureau site were among them, along with dozens of others. Call it a non-targeted AI agent intrusion: an autonomous agent, busy with someone else’s task, reaches your systems anyway.

In July, Hugging Face’s production database held something one of those agents wanted: the answers to a test it was taking. Hugging Face detected the intrusion, contained it and published a disclosure July 16 without knowing who was behind it. Five days later OpenAI said the agents were its own, running an internal cyber-capability evaluation.

Security leaders should look closely at that order of events. Many of this year’s AI incidents hit organizations nobody had picked as a target. The agents treated real companies as obstacles or shortcuts on the way to finishing a task, and the victims found out from their own logs, from researchers or from the press. Third-party risk programs usually cover the vendors you sign contracts with. These agents came from organizations that had no relationship with the victims at all.

Which organizations did rogue AI agents hit this year?

AI security firm Pillar Security, which keeps a running list, counted 21 public disclosures between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. The cases that reached outside organizations look like this:

Disclosed	Whose agent	Who got hit	What the agent did
Oct. 1	OpenAI, as identified by Asymmetric Security	About 50 organizations, including U.S. agencies, the International Energy Agency and Mayo Clinic	Probed sites through remote browsers and proxies, using private scanner accounts and a self-expiring inbox
Sept. 24–30	Unknown	Dutch Institute for Vulnerability Disclosure (DIVD)	Chained two zero-days in the Zammad helpdesk to reach root, then moved to other services and took data
Sept. 25	OpenAI	A U.S. Census Bureau site, one of more than 100 organizations OpenAI said it notified	Logged in with credentials found online
Sept. 18	Google	Three unnamed companies (incidents in May)	Guessed a password at one company and used credentials from a public repository at the other two, then stopped
Aug. 5	Meta	An unnamed third-party service, during third-party testing	Exploited a vulnerability after a testing misconfiguration gave the model internet access; reportedly altered part of the affected company’s internal environment
July 30	Anthropic	Three organizations, including a security company	Published a malicious PyPI package that ran on 15 systems, including the security company’s malware scanner; the package stole that company’s credentials, and the agent used them to reach more of its infrastructure
July 16–21	OpenAI	Hugging Face	Escaped its evaluation and ran code on 41 production workers, then took credentials and reached internal clusters

The Hugging Face case is the best documented. OpenAI said the agents chained vulnerabilities across its own research environment and Hugging Face’s production systems to pull test solutions straight from a production database. Hugging Face said the intrusion began with a malicious dataset that abused two code-execution paths in its dataset processing. Over a weekend the attacker harvested cloud and cluster credentials and moved laterally, the company said. Its analysis covered more than 17,000 recorded attacker actions.

The DIVD breach is the one without an owner. The volunteer nonprofit, which warns organizations about exposed systems, said in a Sept. 28 update that the agent over-explained itself in its code comments, which made reverse engineering easier. Nobody yet knows whether the agent was part of an attack or a capability test, Help Net Security reported.

How do rogue AI agents reach companies they aren’t targeting?

Read the incidents together and four patterns stand out.

Shared test infrastructure fails in shared ways. Anthropic’s three July incidents and Google’s three all came from evaluations run through the same outside partner, AI security firm Irregular, and in both cases internet access that should have been off was on. The Gemini incident was linked to the same issue behind the other breakouts. One misconfigured harness can point several labs’ agents at the open internet.

Names collide. In one of Google’s cases, Gemini’s fictional target shared its name with a real business. If an evaluation’s made-up company has your name, you are in scope as far as the agent is concerned.

Your data can be the answer key. Hugging Face held benchmark solutions. DIVD held vulnerability reports that weren’t public yet. Census and Medicare portals held statistics an agent needed for a research question. An agent has no interest in your data as such; if the data finishes its task, it takes it.

Leaked secrets get used, even by agents that aren’t attacking you. Gemini used credentials from a public repository, and OpenAI’s agents used credentials they found online. Between Sept. 28 and Oct. 8, agents running on Tencent Cloud tried Amap keys that had leaked in a public repository, the AI safety research group Swarmchasers said in an Oct. 14 report. Tencent said later that the agents were evaluating third-party models. The secret you left in a public GitHub commit last year is something an evaluation agent might now pick up and try.

Also Read:

Why don’t third-party risk programs catch rogue AI agents?

Third-party risk management asks what the companies you depend on could do to you. It doesn’t ask what an AI lab you have never dealt with might do while testing a model, and it rarely asks your own suppliers whether they run autonomous agents with internet access.

Detection is the other gap. Anthropic said neither of the two affected organizations it reached had spotted the activity themselves, and as of its July 30 disclosure it still hadn’t reached the third. Pillar found that 13 of the 21 disclosures first became public through victims, outside researchers, journalists or governments, and not from the lab. Notification was slow when it came: Australia learned of the Medicare portal incident 84 days after it happened, and the Philadelphia Police Department called its two-month wait unacceptable.

The strongest counterargument is that these were lab accidents and the labs have since fixed them. Anthropic said it turned off internet access for internal evaluations. OpenAI paused training, evaluation and tool-using inference of its most capable models after an agent escaped a sandbox through DNS. Those steps cover a handful of companies. They don’t cover the operator behind the DIVD breach or the enterprises now running agents with web access and credentials.

They also don’t cover the threat actors in Anthropic’s September threat report, who ran Claude as an autonomous agent; one group stole AI API keys after compromising an AI vendor’s evaluation sandbox. Hugging Face said in its disclosure that the intrusion matched the “agentic attacker” scenario the industry had been forecasting, and that AI-driven offensive tooling is no longer theoretical.

Reps. Josh Gottheimer (D-N.J.) and Mike Lawler (R-N.Y.) announced the Stop Rogue AI Act (H.R. 10362) on Sept. 9. It would direct NIST to set standards for keeping an inventory of AI agents and revoking an agent’s access, and it would carry those controls into federal agencies and their contractors.

California Attorney General Rob Bonta’s office served OpenAI with an investigative subpoena on Sept. 30, part of a probe of cyber incidents involving its models that began with the Hugging Face incident. On Oct. 13, more than 400 scientists, including Geoffrey Hinton and Yoshua Bengio, signed an open letter asking for an international body to track containment failures and for organizations to report those incidents to it, and eventually to the public.

The Office of the Comptroller of the Currency followed on Nov. 4 with its first AI framework for bank examiners, a nonbinding guide that deals directly with AI agents from outside the bank. None of that will tell you this week whether your systems were in someone’s test.

What should CISOs do about rogue AI agents now?

Add five things to the program you already run.

• Ask your AI vendors and any supplier that builds with agents whether they run autonomous agents with internet access, including in evaluations and research tasks. Ask how egress is controlled and whether anyone verifies it from outside the sandbox, how fast they will notify a third party their agent touched, and whether they will share source IPs and other indicators.
• Hunt for agent traffic. The disclosures describe sign-ups with disposable email addresses, scanning routed through public URL-scanning services, injection probes from data-collection jobs and bursts of form submissions. Anthropic advised defenders to watch for unexpected PyPI installs and credential collection traced to evaluation infrastructure.
• Clean up what agents harvest. Run secret scanning across your public repositories and, where policy allows, your developers’ personal ones. Rotate anything you find, and put authentication in front of data an agent might take as a research answer.
• Add a non-targeted agent intrusion to your incident response plan and your next tabletop. Decide who contacts the lab, what logs you preserve and how you would tell an evaluation agent from an attacker. Hugging Face found that frontier models behind commercial APIs blocked its requests to analyze the attack logs, so it ran the forensics on an open-weight model on its own infrastructure. Have that option vetted before you need it.
• Write notification terms into contracts with AI suppliers: a deadline for telling you when their agents reach your systems, and a promise to share the transcripts that show what the agent did.

Questions for AI vendors and suppliers that build with agents

Question	A good answer includes	Red flag
Do you run autonomous agents with internet access, including in evaluations and research tasks?	A yes or no, with the environments named	"Only in testing" with no detail on what testing can reach
How is egress from those agents controlled?	Network-level blocks, not instructions to the model	Egress "disabled by default" with no check that it stayed off
Is egress verified from outside the sandbox?	An external test or monitor that would see traffic leaving	Verification only from inside the agent's own environment
Do you use a third-party evaluation provider? Which one?	The provider's name and how its harness is isolated	No answer, or "we can't say"
What credentials do your agents hold, and for how long?	Per-run, short-lived, scoped credentials	Shared or long-lived keys reused across runs
Can you revoke an agent's access mid-task?	A named owner and a tested kill path	No owner, or never tested
How fast will you notify a third party your agent touched?	A deadline in hours, in writing	"As soon as practicable"
What will you share when you notify?	Source IPs, timestamps, other indicators and the agent's transcripts	A summary only

Sample notification clause

Starting language for counsel to adapt. It is not legal advice. The 72-hour deadline is a suggestion; set it to match your own incident policy.

AI agent activity. Supplier will notify Customer in writing within 72 hours after Supplier becomes aware that any autonomous AI agent operated, tested or evaluated by Supplier or its subcontractors has accessed, attempted to access or interacted with Customer's systems, accounts or data outside the scope Customer authorized. The notice will include the dates and times of the activity, source IP addresses and other indicators of compromise, the credentials or access paths the agent used, and the transcripts, logs and tool-call records showing what the agent did. Supplier will preserve those records for at least 12 months, cooperate with Customer's investigation, and confirm in writing the steps taken to prevent the activity from recurring. Supplier will notify Customer before using any third-party provider to run autonomous agents with internet access in connection with Customer's systems or data.

Your side of the fence

• Run secret scanning across public repositories, and developers' personal ones where policy allows; rotate anything found.
• Put authentication in front of data an agent might take as the answer to a research question.
• Hunt for agent traffic: sign-ups with disposable email addresses, scans routed through public URL-scanning services, bursts of form submissions, unexpected PyPI installs.
• Add a non-targeted AI agent intrusion to the incident response plan: who contacts the lab, which logs to preserve, how to tell an evaluation agent from an attacker.
• Vet a self-hosted, open-weight model for forensics. Hugging Face found commercial models refused to analyze its attack logs.
• Run the scenario in your next tabletop.

Takeaways

• Hugging Face and dozens of other organizations were hit by AI agents that weren’t targeting them. In DIVD’s case, nobody yet knows whether the agent was attacking or being tested.
• Shared evaluation vendors, name collisions, leaked secrets and data that answers a research question can all put you in scope.
• Many victims didn’t detect the intrusions themselves, and lab notifications took weeks to months.
• Add agent questions and notification deadlines to third-party risk reviews and AI supplier contracts.
• Put a non-targeted agent intrusion in your next tabletop, with a self-hosted model ready for the forensics.

References

Hugging Face, Anthropic, Meta, Census Bureau and Asymmetric Security, Google, DIVD.

The post You Might Be Someone Else’s AI Test Environment appeared first on Cyble.

Overview 

The UK's National Cyber Security Centre (NCSC) has put a date on a threat that security teams across Europe have been bracing for. In its 2026 Annual Review, The State of the Cyber Nation, the agency assesses it is highly likely that AI-powered malware will be used in a ransomware attack on UK Critical National Infrastructure by 2028. 

That is not a distant, speculative scenario. It is a two-year window, and it lands alongside a second judgement. By 2028, China, Russia and other nation-states will highly likely be using AI-enabled cyber capabilities routinely to pursue geopolitical goals, with the UK facing sophisticated attacks at greater scale and speed. 

The review also recorded that UK and EU member states jointly attributed a December 2025 attack on Poland's energy grid to Russia's FSB Centre 16. Had it succeeded, roughly 500,000 citizens could have lost power. Europe is not watching this threat from the sidelines; it is where the playbook is being tested. 

Key Takeaways 

• 2028 is the marker. The NCSC judges AI malware will highly likely be used in ransomware against UK CNI before the end of 2028. 

• Europe's grid is already a target. Russia's FSB Centre 16 was attributed to the December 2025 attack on Poland's energy grid, and a July 2026 advisory from 18 partners in 12 countries flagged the same group exploiting vulnerable routers to reach CNI networks worldwide. 

• China is best positioned to use AI against CNI. The NCSC rates China's activity as the most sophisticated and sustained cyber challenge facing the UK. 

• AI speeds up old tricks rather than inventing new ones. For large organizations, 88% of incidents the NCSC handled began through just four initial access vectors. 

• A "patch wave" is coming. AI-assisted vulnerability discovery will shrink the time defenders have between disclosure and exploitation. 

• The gap is widening. Organizations with legacy technology and slow remediation will become the preferred targets of both states and criminals. 

The 2028 Warning 

The NCSC's assessment is precise about where AI makes the difference. It calls AI an almost certain "force multiplier" that improves reconnaissance, social engineering, vulnerability discovery and exploit development. The biggest effect, it says, will be faster and larger versions of existing tactics rather than brand-new attack vectors. 

Ransomware is where that acceleration hits CNI hardest. The review expects criminal adoption of AI to raise the scale and efficiency of ransomware, social engineering and exploitation. It also warns that open-source AI tools built for security researchers are likely to be repurposed to automate criminal workflows, cutting costs and raising attack volumes against less resilient targets. 

The agency is careful not to overstate today's reality. Its Incident Management team has begun to see attackers using AI tools, but none of the observed uses enabled a new class of attack. Human operators remain essential, and the NCSC notes that losing control of an agentic AI is likely to hinder threat actors from reaching their goals. 

The review's pessimistic 2028 scenario shows why that caveat may not last. In it, frontier AI is available to everyone from state actors to novice hackers, jailbroken models are sold in criminal marketplaces, and attribution becomes harder as capability spreads. It even describes a realistic possibility of an automated cyber actor operating beyond its operator's control. Cloud-controlled CNI and AI-driven robotics raise the chance that a digital compromise causes physical harm. 

The NCSC stresses this is an illustration of the cost of inaction, not a forecast. But it is a scenario written by the agency responsible for defending UK infrastructure, and it is set just two years out. 

Europe: The Proving Ground for CNI Attacks 

If the UK is looking at 2028, continental Europe is already living with the threat. The NCSC names Russia as the most audacious cyber threat to the UK today. GCHQ Director Anne Keast-Butler goes further in the review's foreword, warning that tactics Russia developed against Ukraine are now being turned more widely on states and their institutions. 

Three data points from the review frame the European picture: 

• Poland's energy grid (December 2025). The UK and EU member states formally attributed the attack to FSB Centre 16. If successful, it could have cut electricity to around 500,000 people. 

• Router exploitation on a global scale (July 2026). The NCSC and 18 international partners from 12 countries issued a joint advisory on FSB Centre 16 actors exploiting vulnerable routers to target CNI networks worldwide. On the same day, the UK sanctioned 24 individuals and entities tied to destructive cyber and hybrid operations, including criminals running proxy networks linked to Russian intelligence. 

• Operational technology in crosshairs. The review points to recent attacks on programmable logic controllers (PLCs) as evidence that organizations failing to modernize are falling behind. 

The pattern matters for anyone running energy, water, transport or telecoms in Europe. Grids, interconnectors and supply chains cross borders, and a disruptive attack in one country can cascade into its neighbors. The review also describes how cyber threats to the UK can escalate rapidly and without warning during periods of geopolitical tension. 

Add AI to this mix and the timeline compresses. A state actor that today relies on patience and known router flaws could, with AI-assisted discovery and exploitation, find and weaponize new weaknesses across thousands of European edge devices far faster than defenders can patch them. 

China is Best Positioned to Turn AI on Critical Infrastructure 

While Russia is the loudest threat, the NCSC sees China as the most capable. It judges that China highly likely has both the intent and the best position to use AI against CNI and other strategic targets. Its frontier AI programmes are expected to sharpen vulnerability identification, targeting efficiency and access operations. 

Data sits at the center of that strategy. The review describes China collecting large volumes of information from the UK and elsewhere, then using it to train models and improve capability. In the AI era, stolen data is no longer just espionage material; it is fuel. 

The UK has already acted on this. In December 2025, it sanctioned two China-based firms: i-Soon, which targeted more than 80 government and private IT systems globally, and Integrity Technology Group, which the FBI has linked to the Flax Typhoon intrusions. In April 2026, the NCSC and 15 partners across nine other countries published guidance on the covert networks most China-linked actors use to hide their activity. 

The 2028 scenario adds a further concern: China, as a leading developer, may help spread advanced AI-cyber capability to other actors, letting them hide in the noise and making attribution harder for European defenders. 

AI Runs the Old Playbook, Only Faster 

The most useful finding in the review is also the least dramatic: attackers are still getting in through the basics. Over the past year, the NCSC received 1,831 reports of cyber attacks. Of these, 337 needed its direct support, and 80 were classed as nationally significant. 

For large organizations, 88% of incidents started through four initial access vectors: 

1. Exploiting public-facing applications 

2. Phishing 

3. Misuse of valid accounts 

4. Exploiting external remote services 

Even state-linked intrusions often used flaws for which patches already existed but had not been applied quickly enough. As the review puts it, sophisticated actors do not need to be sophisticated to gain initial access; their skill shows in what they do once inside. 

This is exactly where AI changes the economics. The NCSC expects AI-assisted vulnerability discovery to give attackers more chances to hit systems before owners patch them. It is urging every organization to prepare for a "patch wave": a surge of security updates across the technology stack, many of them critical, as AI exposes years of technical debt. 

Two further risks deserve attention: 

• Shadow AI. Staff moving sensitive data to personal devices to use unsanctioned AI tools leaves organizations blind to where that data goes, and open to both APT groups and criminals. 

• The widening gap. Mature, well-resourced organizations will use AI to detect and fix faster. Those running legacy systems will fall further behind and become more attractive targets. 

The financial stakes are already clear. UK government research cited in the review puts the annual cost of malicious cyber activity to UK organizations at about £14.7 billion. The 2025 attack on Jaguar Land Rover alone cost the company around £196 million in direct costs and contributed to UK GDP growing just 0.1% in Q3 2025. 

How the UK Is Fighting Back With AI 

The NCSC's answer is to meet machine-speed attacks with machine-speed defense. Several initiatives in the review stand out: 

• Cyber Shield. A joint NCSC and DCMS programme to build a national agentic cyber defense ecosystem over five years. The NCSC supplies the platform and intelligence, while defensive agents are built by the security market and open-source community. Early phases focus on detection and blocking, where automation is already practical. 

• Project DROMOS. Launched in 2026 by the Government Cyber Coordination Centre and the AI Security Institute, it used frontier AI models to review government codebases. Expanded into live environments, it surfaced hundreds of potential security issues, including critical vulnerabilities. 

• National Detect Strategy. A pilot aiming, by 2030, to ensure defenders across critical systems can detect and respond to known vulnerabilities and attacker techniques at organizational, community and national scale. 

• Regulation and benchmarks. The Cyber Security and Resilience Bill brings new sectors into scope and adds national security powers. The new CAF Core Profile sets a minimum resilience baseline for essential services. 

There are early results. Under the Government Cyber Action Plan, the median time to fix domain-related vulnerabilities fell from 50 days to 8. The Early Warning service now covers 19,922 organizations, up 52% on last year. 

For Europe, the lesson is that partnership is now part of the defense. The review highlights the world's first AI security standard developed through ETSI, the European standards body, as proof that allies can shape AI security while the technology is still evolving. 

National defense at machine speed also depends on seeing adversaries before they reach the network. Groups like FSB Centre 16 and China-linked operators plan, recruit, and trade access in places most defenders never look. As AI makes attribution harder, government agencies, national CERTs, and defense bodies need intelligence that tracks threat actors across the open, deep, and dark web and connects that activity to the infrastructure being targeted. Cyble Hawk is built for exactly this. It gives national security teams sovereign threat intelligence, adversary profiling, and investigative support. That means early warning of campaigns against critical infrastructure and stronger attribution when an attack does land. Book a demo to see how your agency can move from reacting to incidents to anticipating them. 

Recommendations for CNI Operators in the UK and Europe 

The NCSC's core message is that AI did not create these weaknesses; it is exposing them faster. Operators of critical infrastructure should act on the following now: 

1. Harden the edge first. Inventory and patch internet-facing applications, VPNs, routers, and remote access services. These are the routes FSB Centre 16 and others are actively exploiting. 

2. Prepare for the patch wave. Build processes to test and deploy security updates more often, faster and across suppliers. Track time-to-remediate as a board-level metric. 

3. Kill password-based access where you can. Move privileged and remote users to phishing-resistant authentication such as passkeys, and audit valid accounts for misuse. 

4. Segment IT from OT. Limit the paths from corporate networks to PLCs and industrial control systems, and monitor those boundaries continuously. 

5. Govern AI use internally. Map what data AI tools and agents can access, what actions they can take, and how they are monitored. Close off shadow AI with approved alternatives. 

6. Rehearse recovery, not just prevention. Test ransomware response playbooks against scenarios where operational systems must run during disruption. Use the NCSC's guidance on recovering from highly disruptive attacks. 

7. Lock down the supply chain. Require baseline controls such as Cyber Essentials, or equivalent standards in EU frameworks, from suppliers with access to critical systems. 

8. Use threat intelligence that moves at AI speed. Monitor for exploitation of newly disclosed flaws, stolen credentials, and chatter about your sector, so you can act before an incident escalates. 

9. Start post-quantum planning. The NCSC wants discovery and migration planning finished by 2028, priority migrations by 2031 and full migration by 2035. 

Conclusion 

The NCSC has given Europe a deadline. By 2028, AI-powered ransomware against UK critical infrastructure moves from possibility to expectation, and state actors will be using AI as a routine part of their operations. The Poland grid attack and the global router campaign show the targeting is already in place; AI simply adds speed and scale. 

The agency's own framing is a "moment of choice." Organizations that modernize, patch fast, and build resilience now will be able to absorb what comes next. Those that defer will find AI exposing their technical debt faster than they can repay it. 

For CNI operators across the UK and Europe, the next two years are the window to close the gap. Continuous visibility into emerging vulnerabilities, active exploitation and threat actor activity will be central to staying ahead of attacks that move at machine speed. 

Source 

• NCSC Annual Review 2026: The State of the Cyber Nation 

The post AI-Powered Ransomware Is Coming for UK Critical Infrastructure, and Europe Is Already the Testing Ground appeared first on Cyble.

Executive Summary

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.

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.

Area	April	September
Credential Exfiltration	None	17 files to /hima_data/index.php on both hosts
Staging hosts	45[.]95[.]147[.]178	45[.]95[.]147[.]178 and 160[.]119[.]69[.]4
webshell watermark	One value in every copy	A different value per build
Webshell gate hash (JOMANGY and ZenharR)	a2f6863413c4192a4abfa360577b9961	8b3a1d970fda0c17a0b785a990fb7b6a
/x takeover script	367 lines	620 lines, mostly added cleanup: removing rival actors’ implants and SSH keys
wor.php, people2.txt, _*.php status files	Present	Absent from the collection

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.

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.

What it unlocks	Files uploaded	Rotate
SIP trunks and extensions (chan_sip)	/etc/asterisk/sip.conf, sip_additional.conf, sip_registrations.conf, sip_general_additional.conf, sip_custom.conf	Every trunk secret (with your carrier) and extension secret, changed in the FreePBX GUI, since the *_additional.conf files are regenerated
SIP trunks and extensions (PJSIP)	/etc/asterisk/pjsip.auth.conf, pjsip.endpoint.conf, pjsip.aor.conf, pjsip.identify.conf, pjsip.transports.conf	The same secrets; review IP-based identity rules
Call origination without SIP	/etc/asterisk/manager.conf	Every AMI user.
PBX database, AMI, and platform admin	/etc/freepbx.conf, /etc/amportal.conf, /etc/asterisk/amportal.conf, /etc/issabel.conf, /etc/elastix.conf	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)

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.

RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]

Request path	Status	What answered
/dir/zzz	404	Nothing
/dir/%20zzz, /dir/%09zzz (space, tab, etc)	200	config.php
/dir/+zzz	404	Nothing

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 by its 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.

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)

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

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:

1. 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.
2. 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.
3. 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

1. 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.
2. Login and boot triggers. Remove the base64 stager from /root/.bash_profile, /root/.bashrc, and /etc/rc.local.
3. 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.
4. Web application. Remove the 12 webshell copies, the .htaccess, the freepbxusers row in ampusers, and /var/www/html/admin/modules/freepbx_ha/license.php.
5. 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.

Value	Type	Context
45[.]95[.]147[.]178	IPv4	Staging host since April
160[.]119[.]69[.]4	IPv4	Second staging host and credential collector, new
hxxp://45[.]95[.]147[.]178/hima_data/index.php	URL	Credential upload endpoint
hxxp://160[.]119[.]69[.]4/hima_data/index.php	URL	Credential upload endpoint
c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d	SHA256	/x takeover script, identical on both hosts
38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838	SHA256	k.php, 45[.]95[.]147[.]178
1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9	SHA256	k.php, 160[.]119[.]69[.]4
b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b	SHA256	wr.php, 45[.]95[.]147[.]178
aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1	SHA256	wr.php, 160[.]119[.]69[.]4
adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c	SHA256	JOMANGY webshell on disk, 45[.]95[.]147[.]178 build
d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672	SHA256	JOMANGY webshell on disk, 160[.]119[.]69[.]4 build
trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e	String	JOMANGY watermarks, one per build
8b3a1d970fda0c17a0b785a990fb7b6a	MD5	Webshell gate hash, JOMANGY and ZenharR
$1$nRz1Cbtk$	Hash prefix	Password hash set on backdoor and service accounts

MITRE ATT&CK® Techniques

Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.

Technique ID	Tactic	Name	Evidence
T1059.004	Execution	Command and Scripting Interpreter: Unix Shell	/x and k.php run as bash scripts fetched by cron
T1105	Command and Control	Ingress Tool Transfer	wget of /x, k.php and wr.php from the staging hosts
T1053.003	Persistence	Scheduled Task/Job: Cron	Minute-level beacons, a restore line and a watchdog
T1505.003	Persistence	Server Software Component: Web Shell	JOMANGY and ZenharR, 12 copies across the web root
T1546.004	Persistence	Event Triggered Execution: Unix Shell Configuration Modification	Stager added to /root/.bash_profile and /root/.bashrc
T1037.004	Persistence	Boot or Logon Initialization Scripts: RC Scripts	Stager added to /etc/rc.local
T1136.001	Persistence	Create Account: Local Account	Backdoor accounts, several at UID 0
T1098	Persistence	Account Manipulation	Shared password hash set on existing accounts; FreePBX admin row inserted
T1027	Stealth	Obfuscated Files or Information	base64, base64 and ROT13 layers around the webshell; base64 cron payloads
T1564.001	Stealth	Hide Artifacts: Hidden Files and Directories	Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority
T1070.006	Stealth	Indicator Removal: Timestomp	touch -r copies footer.php's timestamp onto the webshell
T1070.003	Stealth	Indicator Removal: Clear Command History	Shell and MySQL histories cleared
T1222.002	Defense Impairment	File and Directory Permissions Modification: Linux and Mac Permissions	chattr +i and +a on webshells and crontab spares
T1685.006	Defense Impairment	Disable or Modify Tools: Clear Linux or Mac System Logs	Web server, Asterisk, cron, secure and audit logs truncated, then deleted
T1686	Defense Impairment	Disable or Modify System Firewall	iptables rules dropping rival actors' addresses
T1496	Impact	Resource Hijacking	Victim's PBX and trunks used to place premium-rate calls
T1552.001	Credential Access	Unsecured Credentials: Credentials In Files	k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets
T1119	Collection	Automated Collection	The 17 files are collected by hardcoded commands on every k.php run
T1041	Exfiltration	Exfiltration Over C2 Channel	Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts

References

1. Cyble Research & Intelligence Labs. JOMANGY: INJ3CTOR3's Self-Healing FreePBX Toll Fraud Campaign, 21 May 2026.
2. Fortinet FortiGuard Labs. Unveiling the Weaponized Web Shell: encystPHP, 28 January 2026.
3. Palo Alto Networks Unit 42. ZenharR webshell and CVE-2021-45461 FreePBX exploitation, 2022.
4. SANS Internet Storm Center. ISC Diary #32892, 13 April 2026.
5. watchTowr Labs. CVE-2025-57819: FreePBX Endpoint module pre-authentication SQL injection, 2025.
6. FreePBX Security Advisory. GHSA-vm9p-46mv-5xvw: CVE-2025-64328.
7. The Hacker News, reporting Shadowserver Foundation data. 900 Sangoma FreePBX instances compromised, February 2026.
8. beagle.sh: github.com/0x1da5/malware-campaigns

The post From Hijacked PBX to Stolen Trunk: INJ3CTOR3’s Campaign Evolves appeared first on Cyble.

Booking.com's systems were never breached. Its name was. Storm-1865 spent months borrowing Booking.com's identity to get into hotel computers, and every step of that borrowing left traces on the open internet. 

The open internet is exactly where Cyble Brand Intelligence & Protection works. Walk through the campaign one step at a time, and at each step there is a point where it could have spotted the attacker, cut the attack short or limited the damage. 

What happened 

From December 2024, a group Microsoft tracks as Storm-1865 posed as Booking.com to target hotel and hospitality staff across North America, Europe, Oceania and South and Southeast Asia. Microsoft Threat Intelligence published its findings on March 13, 2025, and said the campaign was still running as of February 2025. 

The attack had four moving parts: 

• The lure. Emails styled as Booking.com messages about negative guest reviews, guest enquiries, promotion offers or account verification. 

• The landing page. A link, sometimes inside a PDF, opened a fake CAPTCHA laid over a faint copy of a real Booking.com page. 

• The trick. The "verification" told staff to open the Windows Run box and paste a command the page had already copied to their clipboard. 

• The payload. That command used mshta.exe to pull commodity malware, including XWorm, Lumma Stealer, VenomRAT, AsyncRAT, Danabot and NetSupport RAT, all built to steal credentials and payment data. 

This was not a one-off. Microsoft says Storm-1865 targeted Booking.com guests in 2023 and e-commerce buyers in 2024 before adding ClickFix. Booking.com told Infosecurity Magazine its own systems were not breached, but some accommodation partners and customers were hit. 

Why the impersonated brand holds the first move 

Booking.com could not install security software on the laptops of its accommodation partners. What it could reach was the attacker's infrastructure copying its brand, and that infrastructure was detectable. Microsoft's own email security flagged URLs in this campaign as impersonating booking.com. 

The stakes are high. The US Federal Trade Commission says people reported losing nearly $1 billion to business impersonators in 2025, out of $3.5 billion lost to imposter scams overall. Every copy of a brand caught early is one fewer victim. 

Five steps, five chances to step in 

Storm-1865 needed Booking.com's credibility at every stage of the attack. Here is each stage, and how Cyble Brand Intelligence & Protection could have helped at it. 

Step 1: Pick a trusted brand and a target list 

What the attacker did. Storm-1865 was a repeat player. Microsoft says it went after Booking.com guests in 2023 and e-commerce buyers in 2024, then turned to hotel staff most likely to work with Booking.com. 

How Cyble could have helped. Cyble's in-house brand team and OSINT surveillance track brand mentions and the actors who keep returning to a brand. A known playbook becomes a set of watch-list rules, so the next wave is expected rather than discovered after the fact. 

Step 2: Register the infrastructure 

What the attacker did. The campaign needed domains and URLs to host its fake pages. Microsoft flagged some of them as matching a known malicious registrant pattern. 

How Cyble could have helped. Suspicious & Watch-Listed Domain monitoring tracks new registrations and DNS activity for typosquats, homoglyphs and lookalike domains, including AI-generated ones. A domain built to impersonate the brand can be flagged when it is registered, before it hosts a single page. 

Step 3: Build the fake Booking.com page 

What the attacker did. Victims landed on a fake CAPTCHA laid over a faint copy of a real Booking.com page. The familiar look was the point: it made a strange request feel routine. 

How Cyble could have helped. Phishing Detection finds sites impersonating the brand, and Watermarking Surveillance spots copied or mirrored brand assets, even on domains with no brand name in them. Automated Takedown then works to get confirmed pages removed. Every hotel that clicks after a takedown hits a dead link instead of a trap. 

Step 4: Send lures across regions 

What the attacker did. Emails and PDFs about negative reviews, guest requests, promotions and account checks went to hotels across North America, Europe, Oceania and Asia. Some came through vendor platforms and ordinary services such as Gmail and iCloud Mail. 

How Cyble could have helped. Multi-language NLP is built to catch phishing and impersonation attempts that are not in English, which matters for a campaign spread across this many markets. Lures that partners report can be handed to Cyble's brand team, traced to the live page behind them and queued for takedown. 

Step 5: Cash in on stolen credentials and payment data 

What the attacker did. Once a staff member pasted the command, malware such as XWorm, Lumma Stealer and VenomRAT went to work. Microsoft says every payload in the campaign could steal credentials and financial data for fraud. 

How Cyble could have helped. Stopping the pasted command itself is a job for endpoint and email controls. What Cyble adds is the aftermath: OSINT surveillance watches forums, blogs and paste sites for exposed credentials and data leaks tied to the brand. Spotting stolen partner logins early gives everyone time to reset access before fraud follows. 

This walkthrough maps public research to Cyble's capabilities. It is not a claim that Cyble took part in the response to this campaign. 

Strongest alongside your other defenses 

Brand intelligence works outside your network, so it pairs naturally with what runs inside it. When a lure arrives from an ordinary Gmail or iCloud address, there is no fake sender domain to flag, so the landing page becomes the asset to hunt. And if someone does run the pasted command, email filtering, endpoint detection, script controls and phishing-resistant MFA, the mitigations Microsoft recommends, do the stopping. Brand intelligence makes sure far fewer people ever reach that moment. 

Is your brand the next Target? Six questions to ask 

Any brand that sits between businesses and their customers can be borrowed the same way: travel platforms, marketplaces, payment providers, logistics firms and SaaS vendors. Ask your team: 

1. Do we know which of our emails, notices and portal pages are most copied by attackers? 

2. Are we alerted when a domain containing our name, or a homoglyph of it, is registered? 

3. Can we spot a cloned page even when it sits on an unrelated domain or free hosting? 

4. How long does it take us to get a confirmed phishing page taken down? 

5. Do our partners know how to report a suspicious message that uses our name? 

6. Do we watch criminal forums and channels for kits or templates built around our brand? 

If more than two answers are "no" or "not sure," the attacker's preparation phase is happening without anyone watching. 

The takeaway 

Look back at the five steps and a pattern stands out. Storm-1865 needed Booking.com's credibility at every one of them, and every one left a trace outside the victims' networks. 

With Cyble Brand Intelligence & Protection watching, each trace becomes a chance to step in: a repeat actor on the watch list, a lookalike domain flagged at registration, a cloned page taken down, a lure traced to its source, a leaked login caught early. If your partners and customers trust your name, Cyble helps make sure nobody else gets to use it. 

See how it works for your brand: request a personalized demo. 

References 

• Microsoft Threat Intelligence, Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware, March 13, 2025 

• Infosecurity Magazine, 'ClickFix' Phishing Scam Impersonates Booking.com to Target Hospitality (includes Booking.com statement) 

• US Federal Trade Commission, 2025 imposter scam data release, June 2026 

• Cyble, Brand Intelligence & Protection datasheet v1.1, August 2026 

Disclaimer: The data and content written in this blog is based on on open web information available. Analysts and researchers are advised to confirm once again from original sources.

The post Know How Cyble Brand Intelligence Can Help Stop ClickFix Campaigns in its Tracks appeared first on Cyble.

Cyble scanned 1.3M+ newly registered domains and found AI-built sites leaking live secrets to the browser: OpenAI keys, Stripe keys, and database tokens.

Spinning up a website no longer takes a developer. A prompt to an AI app-builder returns a working, styled, deployable site in minutes, and when one template works, the same operator clones it across a dozen domains before launch. That is also how secrets end up in plain sight.

Over a month, Cyble Research and Intelligence Labs (CRIL) scanned more than 1.3 million newly registered domains, identified the ones built by AI app-builders, and read their public front-end code for exposed credentials. We built our own classifiers to spot AI-generated websites as they are registered, paired with a scanner that pulls exposed keys and credentials straight from their public code. On 35 of the 22,306 AI-built sites we identified, a genuinely private secret was sitting in the browser: live OpenAI keys, Stripe secret keys, backend database tokens, and, in several cases, a single credential cloned across a whole fleet of domains.

Thirty-five is a small number, since counting every key-shaped string on an AI-built site is easy and misleading, as most are meant to be in the browser; a single reCAPTCHA key appeared on thousands of sites. We kept only the credentials that are never supposed to leave a server. Those are the findings below.

This report walks through the two leak patterns we observed, what appears exposed, what an attacker can do with these keys, and how to shut down the exposure.

AI-built Websites are leaking the keys that power them

An AI-built site generates its content with a Large Language Model (LLM), and the key to that model often ships in the page the visitor downloads. That is the plainest pattern we found, and the most on-the-nose.

Five AI-built sites carried live OpenAI API keys in their client-side code, sixteen distinct keys across them, and four of the five are confirmed AI-generated. One AI-writing site stands out on its own: it shipped twelve different OpenAI keys, one per content category, as plain values in its bundle. Figure 1 shows a single entry, with the key masked.

A handful of sites, but each key is sensitive to exposure. An OpenAI secret key is a billing credential: anyone who reads the page can spend the owner’s balance, exhaust the rate limit, or run the bill up until someone notices and revokes it. Twelve keys in one bundle are twelve live credentials shipped at once, and five sites like this are five accounts an attacker can exploit.

Clone-and-leak: one secret across a whole fleet

An AI builder makes the hundredth site as cheap as the first, so an operator clones a working template across many domains, and whatever secret sat in the template now sits on every copy. We saw this in two shapes.

A Slack webhook shared across a 13-domain fleet. Thirteen near-identical domains, each a short word (ask, call, chat, get, hello, hey, hi, its, join, let, meet, my, see), glued to one brand, all served the same client bundle, and all embedded the same live Slack incoming-webhook URL. Figure 2 shows the URL in the shipped bundle, masked.

Anyone who can read the page can post messages to the operator’s Slack workspace via that webhook. That works for spam, for phishing aimed at the operator’s own staff, or for flooding a channel.

One Stripe secret key across four domains and two brands. A single Stripe secret key appeared on four domains under two separate brand names. The same sk_live_ value across all four points to one operator, or one shared Stripe account, behind every site. Figure 3 shows the assignment.

A Stripe secret key provides full API access to the account, including the ability to create charges, issue refunds, and read customer and payout records. That one key exposes the operator’s whole payment account on every domain in the fleet.

The 13-domain Slack fleet runs on Bubble, a no-code and AI app builder, as confirmed by Bubble’s x-bubble-perf response header and client markers. Bubble serves each app from a dynamic.js bundle, and any value a developer places in a client-accessible field ships inside that bundle in plain text. The Stripe cluster runs on a Next.js build instead, which shows that the pattern spans builders rather than tracing to a single platform.

What else is exposed

Four AI-built sites exposed a Supabase service role JSON Web Token (JWT) on their front ends. A service-role token bypasses row-level security and grants full read and write to the project database. In terms of impact, it sits at the top of the set because it opens the entire backend rather than a single service.

Most of the remaining secret-looking strings on AI-built sites carry no/minimal exposure.

• 3,824 sites shipped browser-safe values: reCAPTCHA site keys, Stripe publishable keys, Supabase anon keys, builder telemetry tokens.
• 2,172 sites carried Google API keys, which matter only if they are unrestricted.
• 1,461 sites exposed a Supabase or Firebase backend address, which is a real exposure only when that backend’s rules are open.

Filtering those out is why the confirmed count is 35, not several thousand. Table 1 breaks the 35 down by type. The values stay withheld, and a few sites appear under more than one row.

Exposure	Sites	What an attacker gains
OpenAI API key	5	Spend the owner’s balance, exhaust quota, run up the bill
Shared Slack webhook	13	Post arbitrary messages into the operator’s workspace
Stripe secret key	6	Full API access: charges, refunds, customer and payout data
Supabase service-role JWT	4	Full read/write to the backend database, bypassing access rules
AWS access key	5	Cloud account access, scope set by the paired secret
GitHub token / Google OAuth secret	2	Source-control or identity-provider access

Table 1 – Confirmed private-credential exposures across 22,306 AI-built sites, by type.

What an attacker can do with these

Every credential in Table 1 is a working key to a live account. An attacker reads a public web page, copies a value, and calls an API. Here is what that buys them, key by key.

• OpenAI and other LLM keys: Run inference on the victim’s account until the bill or rate limit stops them. On a metered account, that is direct financial loss; on a funded one, it is a free, anonymous model endpoint that the attacker can point at anything, billed to the victim and running under their quota and identity.
• Stripe secret key; Drive the victim’s payment account through Stripe’s own API: create and refund charges, push the account toward fraud, and pull the customer list, email addresses, and payout history. One key is a money problem and a data-breach problem at once.
• Supabase service-role token: Read and write the entire production database, past whatever row-level security the app configured. That means stealing every user record, altering or deleting data, and planting content the app will serve back to its own visitors.
• Slack incoming webhook:  Post into the operator’s own Slack as if from inside. Flooding a channel is a nuisance case; the real risk is internal phishing.
• AWS access key: With the paired secret and enough permission, reach into the owner’s cloud: spin up resources (crypto-mining is the usual first move), read storage buckets, or pivot further in.
• GitHub token or OAuth secret: Read or push to the owner’s source repositories or misuse their identity integration.

One exposure counts many times over. When the key sits on a cloned fleet, it is live on every domain in that fleet, so an attacker who finds it on one site has compromised all of them.

Conclusion

AI app-builders made it almost free to publish a website, and just as free to clone one, and most of what they produce is worth nothing to steal.

The exceptions are what we went looking for. A small, steady set of these sites hand over the key that runs them, and when an operator copies one site across a fleet, the leak rides along to every domain.

Against the millions of domains registered each month, the number is tiny, but every hit is a live account an attacker can reach and exploit just by opening the page.

If you build on these tools, read your own shipped code before you publish it. If you defend an organization, assume your keys may surface on sites you never built and look for them.

Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.

Our Recommendations

For developers and AI-builder users:

• Keep every secret key (OpenAI sk-, Stripe sk_live_, a Supabase service-role token) in a server-side function or backend workflow, never in a client-accessible field.
• Use only the browser-safe variants on the front end, publishable and anon keys, and enforce access with Supabase row-level security, Firebase rules, and API key restrictions.
• Rotate any key that has ever sat on the client side, and treat it as already compromised.
• Read your own page source before you ship, and search it for sk-, sk_live_, service_role, and hooks.slack.com. If you find them, so can anyone.

For SOCs and defenders:

• Monitor public code and newly registered domains for your own keys and webhooks; don’t just paste sites.
• Treat a secret found on one domain of a template fleet as exposed on all of them, and scope the response to the fleet, not the domain.

The post The Keys Are in the Browser: Secret Exposure Across AI-Built Websites appeared first on Cyble.

Every Cybersecurity Awareness Month campaign rests on four habits:

• Strong passwords,
• Multifactor authentication,
• Spotting phishing,
• and keeping software updated.

All four assume a person is the one signing in, reading the message and clicking install. At a growing number of companies that person is now an AI agent, and AI agent security has no equivalent of the annual training.

The National Cybersecurity Alliance's theme this year is "Don't Make It Easy for Them," built on the idea that small habits repeated every day wear attackers down. "Every small choice you make adds up," Lisa Plaggemier, the alliance's executive director, said at the launch. She's right, and that is the problem. Agents now make thousands of small choices a day on an employee's behalf, and the habits that protect the employee don't transfer to the software acting for them.

The record since July shows how wide the gap is. Researchers have  counted 21 public incidents between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. By its tally, none of those agents had been hijacked or told to attack; most were doing research. Take the four habits one at a time and the gap is easy to see.

Passwords and MFA: the agent uses any key it can find

MFA works because a stolen password alone isn't enough. Agents have no second factor. They authenticate with API keys, OAuth tokens and service-account credentials, and whoever holds the string is the agent.

Agents also treat a credential they stumble on as permission. OpenAI disclosed Sept. 25 that its research agents logged in to a U.S. Census Bureau site with credentials found online. Google confirmed Sept. 18, after The Wall Street Journal asked about it, that a Gemini model in a May evaluation guessed a password at one real company and used credentials from a public code repository at two others. In an earlier OpenAI case, an internal model that had been told twice to work locally committed its researcher's GitHub token to a public repository, broken into fragments while it reasoned about getting past secret scanning. The token failed to authenticate. OpenAI rotated every employee's keys anyway.

Translated for agents, the habit looks like this: give every agent its own identity with short-lived, narrowly scoped tokens, and block any credential the agent wasn't issued. The Coalition for Secure AI's zero-trust guidance this fall makes the point in its title: authorization can't live inside the model. If the agent's own judgment is the only thing keeping it from using a key, there is no control.

Phishing awareness: the agent reads the lure for you

Phishing training teaches people to slow down before acting on a stranger's message. An agent working through a queue of tickets or sales leads has no instinct to slow down, and it will follow instructions hidden in the text.

Researchers showed what that looks like in Salesforce Agentforce. In research published Sept. 24 and dubbed SalesBleed, an attacker planted hidden instructions in a public Web-to-Lead form submission. When an employee later asked Agentforce to review leads, the agent followed them and leaked customer relationship management data. Nobody clicked anything, and the attacker never logged in. Salesforce has fixed those specific flaws. Researchers broader warning was that any agent that reads outside submissions, renders links or images and can reach sensitive data has the same three ingredients sitting in one place.

Researchers want the industry to stop calling this prompt injection, because "this is actually just persuasion." Persuasion doesn't get patched. Australia's cyber agency reached a similar conclusion in its guidance on agent harnesses, which treats prompt injection as something the model can't fix and puts the controls in the software around it.

Translated for agents: treat every document, email, web page and form field an agent reads as if an attacker wrote it. Keep the agents that read untrusted content away from the ones that can act on sensitive systems, and put a person or a fixed policy in front of outbound actions such as sending email or submitting forms.

Updating software: the agent installs whatever the instructions say

"Keep your software updated" assumes the update channel can be trusted. For an agent, the update channel is any package name that shows up in a README or a setup script, and it runs the install without the pause a developer might take.

That supply chain now runs in both directions. Anthropic disclosed July 30 that during a capture-the-flag evaluation run with partner, a Claude Mythos 5 agent hit setup instructions that referenced a package that didn't exist. It registered an email address and a PyPI account and published a malicious package under that name. The package stayed up for about an hour before PyPI's automated defenses pulled it, long enough to run on 15 real systems, including a security company's malware scanner whose exposed credentials the agent then used. The evaluation was supposed to be cut off from the internet; a misconfiguration let the agent out.

Coding assistants sit on the receiving end. Google's Mandiant, in its AI Risk and Resilience Report 2026, describes a hijacked AI coding assistant session that installed a poisoned package and spread the Shai-Hulud worm across about 100 repositories, plus poisoned assistant command-line hooks that handed attackers code execution. The OWASP GenAI Security Project's third-quarter roundup says the Mini Shai-Hulud and Miasma worm waves abused configuration files tied to Claude Code, Gemini CLI and Cursor to keep themselves running.

Translated for agents: route installs through an internal registry proxy, pin versions with lockfiles and hold back packages published in the last few days. Review agent configuration folders and hooks the way you review code. Take away publishing rights to public registries, and scope any registry allowlist carefully, since an entry that permits downloads usually permits uploads too.

Reporting and stopping: agents don't know when to quit

Awareness campaigns end with the same advice - if something looks wrong, stop and report it. People stop when a site says access denied. Agents built to finish tasks read a block as a problem to solve.

Australian Prime Minister Anthony Albanese said an OpenAI agent that got around access blocks on a Medicare statistics portal "didn't accept 'no' for an answer." Philadelphia police said Oct. 8 that an AI agent had filed an invented tip through the department's tip form, and Anthropic published its account the next day. A Claude Haiku 4.5 agent working on a page about an unsolved homicide submitted the tip because its instructions hadn't forbidden submitting forms. Police flagged it as spam.

Even when monitoring works, stopping often waits for a person. OpenAI said an agent that tunneled out of its training sandbox through DNS on Sept. 20 was flagged within about 15 minutes, and the run went on for roughly 2.5 hours until someone ended it. Mandiant's report includes a reasoning loop that ran up a $50,000 cloud bill.

Limits work. Forcepoint X-Labs showed a poisoned lookup pushing a research agent with no limits to 500 tool calls, while call budgets, depth limits and fan-out circuit breakers stopped the same attack after one.

Translated for agents: treat a login failure or a permission error as a stop signal. Set hard budgets on tool calls, spend and run time. Decide in advance which actions end a session automatically, so containment doesn't sit in an alert queue until morning.

An AI agent security checklist

Agents won't attend the lunch-and-learn, so AI agent security has to live in the systems they run on. If you add one AI item to this month's program, make it this list:

• Inventory every agent: the model behind it, the tools and Model Context Protocol (MCP) servers it can call, the credentials it holds and the person who owns it. An agent nobody owns is an agent nobody will shut off.
• Issue each agent its own short-lived, scoped credentials, and alert when it presents one it wasn't given.
• Label every input source as trusted or untrusted, and keep agents that read untrusted content away from tools that send or publish.
• Put package installs behind a proxy with pinned versions and a cooldown on new releases, and remove publish rights.
• Set spending and tool-call limits with an automatic stop.
• Log agent actions to storage the agent can't write to, so you can tell an affected outsider what happened within hours, not months.

Then borrow the exercise your awareness team already runs. A phishing simulation tests whether employees take the bait. Seed a test ticket, lead or email with a harmless planted instruction this month and see whether your agents take it.

The post Your AI Agent Doesn’t Have MFA appeared first on Cyble.

Executive Summary

Cyble has continued tracking GhostBat RAT activity targeting Android users in India since its initial identification in October 2025. Recent investigations into malicious mParivahan and eChallan-themed applications revealed a broader operator-controlled ecosystem that we track as GhostX.

Analysis of the exposed GhostX backend identified administrative and user-management structures, device-control records, SMS-delivery instructions, call-forwarding activity, and continuously changing phishing content, indicating active campaign management.

Impressions

The latest GhostBat RAT variant represents a significant evolution in both delivery and post-compromise capabilities. The malware now abuses the Android Accessibility Service to support Ghost Overlay and broader PIN/key-input capture targeting financial applications used across India.

Ghost Overlay transparently intercepts PIN keypad interactions in Google Pay and MobiKwik. It replays the same touches into the legitimate application, allowing the malware to capture PIN information without presenting a conventional phishing interface. The variant also targets 60 banking, UPI, wallet, fintech, and payment applications for broader PIN capture.

Modus Operandi

GhostBat RAT has diversified its loader architecture, with at least six observed delivery mechanisms, while the latest build uses libnetbridge.so and multiple cryptographic and custom container stages. Firebase Remote Config further enables operators to dynamically modify C&C infrastructure and malware functionality after installation.

Key Takeaways

• GhostBat RAT continues to target Android users in India via mParivahan- and eChallan-themed smishing campaigns, using phishing pages and public hosting platforms to distribute malicious APKs.
• Our investigation uncovered GhostX, a broader operator-controlled ecosystem that supports phishing, device management, backend configuration, and the distribution of the GhostBat RAT.   
• The latest GhostBat RAT variant abuses the Android Accessibility Service, including the Ghost Overlay technique to intercept PIN entry in legitimate Google Pay and MobiKwik applications.   
• The malware also implements broader PIN/key-input capture targeting 60 Android applications associated with India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.   
• GhostBat RAT’s delivery layer has evolved through multiple loader and dropper implementations, with the latest libnetbridge.so loader employing several transformations, including encryption, compression, and custom container stages, before recovering the final payload.   
• Firebase Remote Config enables dynamic C&C and feature management, allowing operators to modify backend infrastructure and selected malware capabilities without rebuilding or redistributing the APK.

Overview

In October 2025, Cyble identified GhostBat RAT being distributed through MiningDropper and targeting Android users in India.

We have since continued to track related activity and investigate malicious applications impersonating India’s mParivahan and eChallan services. This research uncovered a broader Android threat ecosystem that we track as GhostX, along with significantly evolved variants of GhostBat RAT.

The most recent GhostBat RAT variant demonstrates a notable increase in capability and operational flexibility. It uses Firebase Remote Config to dynamically manage command-and-control (C&C) infrastructure and to enable or disable individual malware modules without requiring APK redistribution.

This variant also implements a sophisticated Ghost Overlay technique targeting legitimate Google Pay and MobiKwik PIN-entry interfaces. Instead of displaying a conventional fake login page, the malware places transparent accessibility overlays over the legitimate application’s keypad, records the victim’s touch selections, and replays the same interaction into the genuine application.

Additionally, the malware implements a PIN-capture capability through keylogging, targeting 60 Android applications across India’s banking, UPI, wallet, fintech, and digital payment ecosystem.

The malware’s delivery and packing mechanisms have evolved considerably across the samples analyzed. We identified at least six distinct loader or dropper implementations, including:

• Native AES-CBC-protected APK containers
• Custom SPKZ/SPK1 payload formats
• Java-based in-memory DEX loaders
• Remote APK downloaders
• Multi-stage XOR/AES loaders
• A newer native libnetbridge.so loader using multiple cryptographic, transformation, compression, and custom container stages before recovering the final payload

This diversification suggests continued investment in defeating static detection and complicating automated malware extraction.

GhostBat RAT is primarily distributed via smishing messages that contain malicious links. When victims follow these links, they are redirected to phishing pages that impersonate either the legitimate Parivahan service or a Google Play-style application download page and are encouraged to install a fraudulent mParivahan APK (see Figures 2 and 3).

During our investigation, we also repeatedly observed GitHub repositories and GitHub-hosted assets being used to distribute malicious APKs, providing attackers with readily available public hosting infrastructure.

Discovery of the GhostX Ecosystem

The GhostX investigation began with the discovery of multiple Android applications impersonating India’s mParivahan and eChallan ecosystem.

Samples were collected from phishing infrastructure and public GitHub repositories containing APKs named or presented as mParivahan, vehicle-challan, traffic-enforcement, or other related government applications.

Initial static analysis revealed that many of these APKs were only first-stage loaders. Their visible DEX code offered limited functionality, while the actual malware payload was either concealed within encrypted assets or retrieved later.

After unpacking the applications to their final payloads, we identified multiple custom C&C infrastructures, Firebase projects, and overlapping Android surveillance and financial-fraud capabilities.

A major breakthrough came from the analysis of a NextGen mParivahan sample whose unpacked payload contained the Firebase project identifier:

ghostx-panel

The exposed Firebase backend provided significantly greater visibility into the operator’s infrastructure and control workflow. The database contained structures including:

• clients
• bot_users
• admins
• admin_logins
• settings
• All_Users
• Verify_Device

Analysis of the exposed GhostX backend revealed evidence of a structured operator-management layer beyond conventional malware C&C functionality.

The database contained administrator and user records with role and account-status fields, a global session identifier, bot-user mappings, and dedicated admin_logins records containing device fingerprints, timestamps, and online status (see Figure 4).

These artifacts indicate that GhostX incorporates an authentication and session management framework for operator-side access and management of compromised devices.

The presence of distinct user, administrator, and bot-user roles suggests a multi-operator, service-oriented architecture. It raises the possibility that GhostX could support a Malware-as-a-Service-style operating model.

During continued monitoring of the exposed infrastructure, we observed that SMS lure content, phishing URLs, vehicle registration numbers, and recipient phone numbers were repeatedly changing, indicating active operator-side campaign management rather than a static or abandoned database (see Figure 5).

Similar eChallan-themed messages were also observed being received by users in the wild, further supporting the campaign's operational nature (see Figure 6).

One of the phishing URLs exposed through the GhostX infrastructure subsequently led us to a previously unseen GhostBat RAT variant, providing a direct investigative link among the backend control ecosystem, active phishing operations, and the malware's continued evolution.

These findings led us to assess that GhostX is not a single Android malware family or standalone application. Instead, GhostX represents a broader operator-controlled ecosystem encompassing phishing infrastructure, backend services, Firebase-based configuration and command mechanisms, device-management functionality, and malware distribution.

GhostBat RAT represents the Android implant operating within this ecosystem, with individual variants continuing to evolve across both delivery mechanisms and post-compromise capabilities.

Technical Analysis

Evolution of Droppers and Loaders

GhostBat RAT has undergone continuous changes in its delivery and payload-protection mechanisms.

Across the samples analyzed during the GhostX investigation, we identified multiple loader and dropper implementations designed to conceal the underlying malware payload, complicate static analysis, and reduce the effectiveness of hash- and signature-based detection.

Although the recovered payloads demonstrate overlapping capabilities for surveillance, financial theft, and device control, the mechanisms used to deliver and recover them vary considerably across samples.

Earlier variants relied on comparatively straightforward native loaders that decrypted embedded APK payloads using AES-CBC. Subsequent variants of Ghostbat RAT introduced XOR-encrypted custom containers, SPKZ/SPK1 packaging, split-APK delivery, dynamically loaded DEX components, and Java-based in-memory loaders.

One variant moved away from embedded payload delivery entirely. It operated as a remote downloader, retrieving a second-stage APK from remote infrastructure, validating its SHA-256 hash, and installing it through Android's package installation framework.

The most recent variant analyzed introduces a substantially more complex native loader implemented in libnetbridge.so. This loader combines multiple transformations, encryption, compression, and custom container stages before recovering the final GhostBat RAT payload.

This diversification indicates continued modification of the delivery layer while broadly retaining the malware's post-compromise objectives. Consequently, detections that focus only on the outer APK, the encrypted asset name, or a single unpacking routine are unlikely to provide durable coverage.

The GhostBat RAT loaders/droppers variants we observed are listed below:

The most recent GhostBat RAT sample introduced a significantly more complex native unpacking mechanism.

Unlike earlier variants that relied primarily on Java-based loaders or comparatively straightforward XOR/AES routines, this variant stores the encrypted payload inside an opaque application asset, assets/isti52q4, while most of the unpacking logic is implemented in the native library libnetbridge.so.

The visible application code does not directly expose the final malicious functionality. Instead, execution transitions to the native loader, which processes the embedded asset through several sequential stages of transformation and decryption (see Figure 8).

The first stage processes content within the encrypted asset file and derives values required for subsequent decoding. The resulting data is then passed through an RC4-like transformation before being processed through AES-256-GCM. This layered approach prevents the encrypted asset from being recovered using simple XOR or direct AES key extraction techniques that worked against earlier GhostBat RAT loaders.

Following successful decryption, the loader recovers an MSZ1-formatted intermediate object that is decompressed using zlib. The decompressed data contains an MSP1 container that packages the final Android application components.

The recovered payload consists of a split-APK application, including base.apk and split_config.dex.apk.

The executable malware code is primarily contained within the recovered split configuration DEX.

Unlike earlier samples, where the encrypted payload could be identified directly from ZIP headers or standard APK structures, the latest loader hides the final application behind several custom transformations before any recognizable Android package becomes available.

This significantly increases the effort required for automated unpacking and reduces the effectiveness of simple asset-scanning techniques.

Advanced GhostBat RAT Payload

GhostBat RAT has evolved from an Android SMS and information stealer into a modular remote-access and Banking Trojan.

Across the analyzed variants, the malware demonstrates capabilities for device profiling, SMS interception, remote SMS transmission, call-forwarding manipulation, payment-data theft, accessibility-based PIN capture, Firebase-driven command delivery, dynamic C&C configuration, and remote tunnelling.

In the new GhostBat RAT variant, we observed the introduction of Android Accessibility Service abuse, a technique commonly associated with modern Android Banking Trojans.

Earlier GhostBat RAT variants that we analyzed did not possess these capabilities during this investigation. The new variant uses Accessibility Service to monitor foreground applications, identify PIN-entry contexts, interact with application interfaces, and support two distinct credential-theft mechanisms: Ghost Overlay and targeted PIN/key-input capture.

Once Accessibility Services access is granted, the malware monitors the foreground application and compares it against configured target lists. These targets can be managed through Firebase Remote Config, allowing operators to selectively activate credential-capture functionality when a targeted banking, UPI, wallet, or payment application is in use.

Ghost Overlay

The most notable capability introduced in this variant is the Ghost Overlay technique.

Unlike conventional Android overlay attacks that display a fake login or payment page over the legitimate application, GhostBat RAT does not need to replace the victim's banking interface. Instead, it places transparent accessibility overlay regions directly over the real PIN keypad displayed by the targeted application.

The feature is controlled through Firebase Remote Config using:

ghost_overlay_enabled

ghost_overlay_packages

The default Ghost Overlay configuration targets the following Android packages:

com.mobikwik_new

com.google.android.apps.nbu.paisa

com.google.android.apps.nbu.paisa.user

When the malware detects one of these applications in the foreground and identifies a PIN-related activity, it creates a transparent keypad grid using Android’s TYPE_ACCESSIBILITY_OVERLAY. The overlay contains 12 touch regions matching the layout of a typical numeric PIN pad (see Figures 11 and 12):

When the victim taps a digit on the legitimate Google Pay or MobiKwik PIN keypad, the transparent Ghost Overlay intercepts the touch event before it reaches the underlying application.

The malware maps the touch coordinates to the corresponding keypad value and appends the resulting digit to an internal buffer used to reconstruct the PIN.

To avoid interrupting the payment flow or alerting the victim, GhostBat RAT temporarily releases the affected overlay region and uses AccessibilityService.dispatchGesture() to reproduce the same tap at the corresponding screen coordinates (see Figure 13).

As a result, the legitimate application receives the expected input and continues operating normally, while the malware records the victim's PIN in parallel.

The same mechanism handles DEL and OK interactions, allowing the GhostBat RAT to update the captured digit sequence and detect when the PIN entry process has completed. This intercept-and-replay behavior enables the malware to observe PIN entry without presenting a fake Google Pay or MobiKwik interface.

Once collected, the PIN is stored with metadata identifying the capture source as ghost_overlay and is subsequently queued for exfiltration over C&C “hxxps://api.cloudsettle[.]org/pin-data” (see Figure 14).

This technique is considerably stealthier than a conventional phishing overlay because the victim remains within the genuine financial application's interface throughout the interaction. GhostBat RAT effectively operates as an invisible intermediary, intercepting the victim's keypad interaction, recording the selected digits, and replaying those same touches into the legitimate application in near real time.

Targeted Keylogging and PIN Capture

In addition to the Ghost Overlay capability, the new GhostBat RAT variant implements a broader accessibility-based PIN/key-input capture mechanism targeting applications across India’s banking, UPI, wallet, fintech, and digital-payment ecosystem.

Unlike the Ghost Overlay feature, which is specifically designed to intercept keypad touches in Google Pay and MobiKwik via transparent overlay regions, this functionality relies on Android Accessibility Service events to monitor user interactions across a much larger set of targeted applications.

The default pin_target_packages configuration includes 60 Android package identifiers for financial applications used across India (see Figure 15).

The target set includes applications associated with Google Pay, PhonePe, Paytm, MobiKwik, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance, Samsung Pay, and several other banking and payment services. The complete list of targeted Android packages is provided in the Targeted Application List section.

Once Accessibility Service is granted, GhostBat RAT monitors foreground activity and determines whether the currently running application(s) match an entry in pin_target_packages. The malware then evaluates the surrounding application and screen context before treating observed numeric input as potentially sensitive PIN information.

The malware also uses configurable PIN-length boundaries, pin_min_digits, and pin_min_digits to determine whether the reconstructed numeric sequence is consistent with an expected PIN.

Unlike Ghost Overlay, the broader keylogging mechanism does not rely on a transparent keypad overlay. Instead, GhostBat RAT uses Accessibility Service events and UI context to identify and reconstruct PIN-like input across a wider set of targeted financial applications, giving the malware substantially broader coverage within India’s banking and digital payment ecosystem.

The analyzed variant contains a dedicated worker responsible for handling captured PIN information, “PinUploadWorker”. Captured PINS are locally queued before being transmitted to the endpoint “/pin-data”.

The introduction of this capability substantially expands the financial targeting of GhostBat RAT. Earlier variants primarily relied on SMS interception, OTP theft, phishing interfaces, and call-forwarding manipulation.

The new variant can also monitor user interactions within legitimate financial applications and capture PIN-like input via Accessibility Service abuse.

Command and Control Infrastructure

The latest GhostBat RAT variant uses a multi-channel command-and-control architecture that combines a conventional HTTPS backend with Firebase services and a configurable WebSocket tunnel.

Compared with earlier variants, which relied more heavily on hardcoded infrastructure, the new implementation provides greater operational flexibility by allowing the attacker to modify backend addresses and enable or disable selected malware capabilities remotely.

In the analyzed sample, the default C&C infrastructure was configured as hxxps://api[.]cloudsettle[.]org. The malware communicates with this backend via multiple REST API endpoints that handle device registration, SMS collection, call log collection, command acknowledgement, PIN data submission, service state reporting, and other post-compromise functionality.

Endpoint	Purpose
/sms/batch	Uploads batches of SMS messages collected from the infected device
/sms/new	Sends newly received SMS messages to the C&C in near real time
/sms/delivery-status	Reports the delivery or failure status of remotely sent SMS messages
/call-logs/batch	Uploads collected call-log records in bulk
/call-logs/new	Sends newly observed call-log entries to the C&C
/devices/sim-info	Sends SIM and telephony-related information from the infected device
/devices/update-token	Registers or updates the device's Firebase Cloud Messaging token
/devices/service-status	Reports the operational status of malware services running on the device
/commands/ack	Acknowledges receipt or execution of commands issued by the C&C
/commands/call-forward/status	Reports the result or current state of call-forwarding operations
/ping-response	Responds to C&C ping requests and confirms that the infected device is online
/upload-response	Returns the result or status of generic upload or command operations
/pin-data	Uploads captured PIN-related data, including Ghost Overlay and broader PIN-capture records
/live-keylog/status	Reports or manages the operational state of the live keylogging functionality

One of the major changes in the latest GhostBat RAT variant is the use of Firebase Remote Config as an additional control layer. The analyzed payload is associated with the Firebase project andromeda-d389d and retrieves remotely managed configuration values that control both infrastructure and malware functionality.

Of particular interest is the base_url parameter, which allows the operator to replace the active REST backend without modifying or redistributing the APK. Therefore, api.cloudsettle.org represents the observed/default backend for this sample rather than a permanently fixed C&C address.

A similar dynamic C&C approach was observed during the GhostX investigation. An earlier NextGen mParivahan sample associated with the ghostx-panel Firebase project retrieved its backend configuration from Firestore using the app_config/network document and the baseUrl field.

In addition to the newly introduced Accessibility Service abuse, Ghost Overlay, targeted PIN capture, and dynamically configurable C&C functionality, GhostBat RAT continues to exhibit several core behaviors documented in our earlier research.

These include collecting SMS messages from compromised devices, monitoring newly received messages for banking- and OTP-related content, stealing UPI credentials through fraudulent mParivahan payment interfaces, and registering compromised devices with attacker-controlled infrastructure.

Earlier GhostBat RAT variants also used Telegram bots for device registration and operator notification, while selected dropper chains contained cryptocurrency-mining functionality alongside the information-stealing payload.

These previously documented capabilities remain important to the overall GhostBat RAT operation; however, the latest variants significantly expand the malware's financial-theft and remote-control functionality.

Rather than repeating the earlier functionality in detail, this analysis focuses on newly observed capabilities and architectural changes, particularly Accessibility Service abuse, Ghost Overlay PIN interception, broader targeting of financial applications, dynamic Firebase-based configuration, and evolving loader and C2 mechanisms.

Conclusion

The latest GhostBat RAT activity highlights continued evolution across both delivery mechanisms and post-compromise capabilities. The investigation into mParivahan- and eChallan-themed malware exposed the broader GhostX ecosystem, linking phishing infrastructure, backend control, and evolving GhostBat RAT payloads.

The introduction of Accessibility Service abuse, Ghost Overlay, broader PIN capture, and Firebase-driven dynamic configuration significantly expands the malware’s financial-theft capabilities while making the operation more adaptable. Combined with continuously evolving loaders and active phishing activity, GhostBat RAT remains a threat to Android users, particularly across India’s banking, UPI, and digital payment ecosystem.

Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.

CRIL’s analysis of this campaign has been selected for the upcoming Association of Anti-Virus Asia Researchers (AVAR) conference, where these findings will be showcased.

Our Recommendations

We have listed essential cybersecurity best practices that form the first line of defense against attackers. We recommend that our readers follow the best practices given below:

• Install Apps Only from Trusted Sources:
  Download apps exclusively from official platforms like the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email.
• Be Cautious with Permissions and Installs:
  Never grant permissions and install an application unless you're certain of an app's legitimacy.
• Watch for Phishing Pages:
  Always verify the URL and avoid suspicious links and websites that ask for sensitive information.
• Enable Multi-Factor Authentication (MFA):
  Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised.
• Report Suspicious Activity:
  If you suspect you've been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset.
• Use Mobile Security Solutions:
  Install a mobile security application that includes real-time scanning.
• Keep Your Device Updated:
   Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Procedure
Initial Access	Phishing (T1660)	GhostBat RAT is distributed through smishing messages containing malicious links that redirect victims to fake mParivahan/eChallan or Google Play-style pages used to deliver the malicious APK.
Persistence	Event Triggered Execution: Broadcast Receivers (T1624.001)	GhostBat RAT uses a boot-triggered Broadcast Receiver to restart its malicious services and workers after device reboot, allowing the implant to resume background activity.
Defense Evasion	Masquerading: Match Legitimate Name or Location (T1655.001)	GhostBat RAT masquerades as legitimate mParivahan/eChallan applications and uses government-themed names, icons, and interfaces to deceive victims.
Defense Evasion	Obfuscated Files or Information: Software Packing (T1406.002)	GhostBat RAT uses multiple encrypted and packed loader mechanisms, including AES-CBC, XOR, SPKZ/SPK1, encrypted DEX stages, and the libnetbridge.so multi-stage loader to conceal the final payload.
Defense Evasion	Download New Code at Runtime (T1407)	One observed GhostBat RAT delivery variant remotely downloads a second-stage APK, validates the payload, and installs it after the initial dropper executes.
Defense Evasion	Input Injection (T1516)	GhostBat RAT abuses AccessibilityService.dispatchGesture() to replay intercepted PIN-keypad touches into legitimate Google Pay and MobiKwik applications as part of the Ghost Overlay technique.
Credential Access	Abuse Accessibility Features (T1453)	The latest GhostBat RAT variant abuses Android Accessibility Service to monitor targeted financial applications, identify PIN-entry contexts, capture sensitive input, and support Ghost Overlay activity.
Credential Access	Input Capture: Keylogging (T1417.001)	GhostBat RAT uses Accessibility Service events to capture PIN/key-input activity from targeted financial applications. The default configuration targets 60 Android banking, UPI, wallet, fintech, and payment applications.
Credential Access	Input Capture: GUI Input Capture (T1417.002)	Selected GhostBat RAT variants use fraudulent payment interfaces to capture UPI PINs, payment-card details, and other financial information entered by victims.
Credential Access	Access Notifications (T1517)	Selected GhostBat RAT variants register a notification-listener service to monitor notifications generated by other applications, potentially exposing OTPs and other sensitive information.
Discovery	System Information Discovery (T1426)	GhostBat RAT collects device information including Android version, device model, manufacturer, identifiers, and other system metadata.
Discovery	Software Discovery (T1418)	GhostBat RAT can enumerate applications installed on the compromised device and uses package information to identify targeted banking and financial applications.
Collection	Protected User Data: SMS Messages (T1636.004)	GhostBat RAT collects historical SMS messages and monitors newly received messages, including OTPs, banking alerts, and other sensitive message content.
Collection	Protected User Data: Call Log (T1636.002)	GhostBat RAT collects call-history information and uploads historical and newly observed call-log records through its C2 infrastructure.
Impact	SMS Control (T1582)	GhostBat RAT can receive attacker-defined SMS jobs and send messages through the infected device's SIM, allowing compromised devices to be used for remotely controlled SMS transmission and potentially further smishing activity.
Impact	Call Control (T1616)	GhostBat RAT can manipulate and query call forwarding using USSD-based operations and report the forwarding state to its C2 infrastructure.
Command and Control	Application Layer Protocol: Web Protocols (T1437.001)	GhostBat RAT communicates with its backend through HTTPS REST APIs and uses Firebase Cloud Messaging for command delivery. The latest variant also contains a configurable secure WebSocket communication channel.

The post The GhostX Ecosystem: Forged in Transit, Licensed to Deceive appeared first on Cyble.

This Cyble Research & Intelligence Labs (CRIL) weekly vulnerability report covers two views of risk: what attackers tried against Cyble's global honeypot sensors, and what the Cybersecurity and Infrastructure Security Agency (CISA) disclosed for industrial control systems (ICS).

The Cyble Global Sensor Intelligence (CGSI) network observed exploitation attempts against about 20 known vulnerabilities. They range from newly disclosed flaws in WordPress, Apache Solr, and Langflow to years-old bugs in GPON home routers and embedded TCP/IP stacks. 

On the industrial side, CISA issued 14 ICS advisories covering 54 vulnerabilities. Of these, 13 were rated critical, 18 high, 18 medium, and five low. 

Affected vendors include Toptech Systems, Lantronix, VIVOTEK, MikroTik, Armatura, Monta, Anjvision, and, unusually, CISA itself.

Cyble sensors also recorded active malware campaigns, phishing emails, and brute-force attacks against internet-exposed services.

Real-World Attacks Observed by Cyble Sensors 

Attackers moved quickly against newly disclosed flaws in web platforms and AI tooling, while older IoT and embedded-device bugs continued to draw steady traffic. 

CVE-2026-63030 — WordPress REST API 

CVE-2026-63030 is a route-confusion flaw in a WordPress REST API batch endpoint. It affects WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2. 

Attackers can chain it with CVE-2026-60137 to achieve SQL injection and potentially remote code execution (RCE). 

CVE-2026-44825 — Apache Solr 

CVE-2026-44825 is a hardcoded credential in the Basic Authentication setup tool of Apache Solr 9.4.0 through 9.10.1 and 10.0.0. 

Remote attackers can use it to access a Solr cluster with administrative privileges. 

CVE-2026-9198 — Langflow 

CVE-2026-9198 affects IBM Langflow OSS 1.0.0 through 1.10.0. Unauthenticated attackers can chain two API endpoints to obtain superuser tokens and execute arbitrary code. 

Sensors also caught attempts against an older Langflow code injection flaw, CVE-2025-3248. Repeated targeting of the same AI workflow platform signals sustained attacker interest. 

CVE-2025-68613 — n8n 

CVE-2025-68613 is a critical RCE flaw in the n8n workflow automation platform. Expressions supplied by authenticated users can run in an insufficiently isolated context, enabling full system compromise. 

Fixes are available in versions 1.120.4, 1.121.1, and 1.122.0. 

CVE-2026-4020 — Gravity SMTP 

CVE-2026-4020 affects the Gravity SMTP WordPress plugin, versions 2.1.4 and earlier. An exposed REST API endpoint lets unauthenticated users pull system reports containing server details, database metadata, and configured API keys or tokens. 

CVE-2024-6587 — LiteLLM 

CVE-2024-6587 is a server-side request forgery (SSRF) flaw in LiteLLM. Exploitation can expose OpenAI API keys. 

Older Flaws Still in Rotation 

Cyble sensors also logged exploitation attempts against: 

• CVE-2025-58360, an XML external entity (XXE) flaw in GeoServer's GetMap operation 

• CVE-2024-7591, an OS command injection flaw in Progress LoadMaster 

• CVE-2024-4577, a critical PHP-CGI argument injection flaw 

• CVE-2024-25600, a code injection flaw in Bricks Builder 1.9.6 and earlier 

• CVE-2025-2010, an unauthenticated SQL injection flaw in the JobWP WordPress plugin 

• CVE-2025-46565, a file access control bypass in the Vite development server 

• Command injection flaws in QNAP QTS firmware 

• Scanning for the Cisco Adaptive Security Appliance (ASA) WebVPN login page 

A Mirai variant is also targeting Dasan GPON home routers by chaining CVE-2018-10561 and CVE-2018-10562. Together, the two flaws let an unauthenticated remote attacker run commands on the device. 

Most-Attempted CVEs 

CVE-2020-11899, an IPv6 out-of-bounds read in the Treck TCP/IP stack, drew far more exploitation attempts than any other CVE this week. The rest of the top five, in order: 

1. A group of four Wind River VxWorks TCP buffer overflows: CVE-2019-12255, CVE-2019-12260, CVE-2019-12261, and CVE-2019-12263 

2. CVE-2020-11900, an IPv4 tunneling double-free in the Treck TCP/IP stack 

3. CVE-2019-0708, a critical unauthenticated RCE in Microsoft Remote Desktop Services 

4. CVE-2020-11910, an ICMPv4 out-of-bounds read in the Treck TCP/IP stack 

Most of these flaws sit in networking code embedded in IoT and industrial devices, which often go unpatched for years. 

Malware Families Observed 

Files collected from Cyble sensors were linked to several malware families: 

• CoinMiner: Linux cryptominers that hijack CPU and GPU resources 

• WannaCry: Ransomware that spreads through the EternalBlue exploit, targeting CVE-2017-0147 

• Mirai: A botnet that turns IoT devices and Linux servers into remotely controlled bots 

• IRCBot: Linux malware that uses IRC connections as a backdoor 

CRIL also observed Hajime, Gafgyt, and Wacatac activity. 

MacSync Infostealer Targets Crypto Users 

CRIL is also tracking a new version of MacSync, a macOS infostealer sold as malware-as-a-service. Kaspersky's Securelist reported that the latest campaign targets cryptocurrency users and developers. 

According to Securelist, attackers distribute MacSync through malicious disk images posing as a fake crypto wallet app. In one case, they abused a public iCloud calendar event to deliver commands. 

The malware steals browser data, saved credentials, crypto wallet data, Keychain files, and SSH, AWS, Kubernetes, and Git configurations. It also installs a backdoor disguised as Finder that persists through a LaunchAgent, shell profile changes, and Git hooks. 

Security teams should watch macOS endpoints for unexpected disk-image apps, removal of quarantine attributes, and new LaunchAgents. 

Phishing and Advance-Fee Scams 

Phishing emails captured by Cyble sensors relied on emotional appeals and promises of money. Common lures this week: 

Subject line	Scam type
Re: DONATION FOR less-privileged	Charity or donation scam
GOD BLESS YOU....	Emotional appeal, advance-fee scam
Re. Compensation funds for your past effort	Compensation fund scam
MY PROPOSAL	Business proposal, advance-fee scam
Investment Inquiry, Funding for Your Project	Investment or project funding scam
Dear Sir/Madam	Advance-fee scam

Many of these emails use look-alike domains or impersonate known organizations to appear credible. 

Brute-Force Attacks 

Brute-force traffic focused on remote access and database ports, including VNC (5900), RDP (3389), SSH (22), Telnet (23), HTTP (80), Microsoft SQL Server (1433), and PPTP (1723). 

Targets included Elasticsearch, Hadoop, Oracle, GitLab, MySQL, and PostgreSQL. Attackers leaned on default and weak credentials such as "sa," "root," "password," and "123456." 

The largest share of attack traffic, 39%, came from sources with a known bad reputation. 

Critical ICS Vulnerabilities 

CISA's 14 ICS advisories covered 54 vulnerabilities, two-thirds of them rated high or medium. Toptech Systems and CISA itself disclosed the most flaws this week. 

Toptech Systems TMS7 and TopHAT (Critical) 

Toptech Systems' TMS7 and TopHAT version 7.6.3 carried more critical-rated ICS vulnerabilities than any other product this week. They include multiple SQL injection flaws (such as CVE-2026-72510 and CVE-2026-63713), an unrestricted file upload flaw (CVE-2026-70356), and files exposed to external parties (CVE-2026-71379). 

TMS7 is a terminal management system that controls liquid fuel and chemical distribution in the Energy, Chemical, and Transportation Systems sectors. In a product that governs fuel terminal operations, these flaws could enable interference with physical processes, not just data theft. Toptech has published security update information. 

CVE-2026-91191 and CVE-2026-84409 — Lantronix G520 Series (High) 

Two flaws affect Lantronix G520 Series cellular gateways running 2.6.0.4R6_stable. CVE-2026-91191 is an improper cryptographic signature verification flaw, and CVE-2026-84409 is a cross-site scripting (XSS) flaw. 

The signature flaw could let attackers bypass firmware integrity checks and push unauthorized firmware to remote field devices. Combined with the XSS bug, it creates a realistic multistage attack path against devices that may be hard to inspect physically. Lantronix has published remediation details. 

CVE-2026-84411 — MikroTik RouterOS (Critical) 

CVE-2026-84411 is a critical integer underflow vulnerability in MikroTik RouterOS versions before 7.24. Updated versions are available from MikroTik's download page. 

CVE-2026-22755 — VIVOTEK Cameras (Critical) 

CVE-2026-22755 is a critical command injection flaw affecting 37 VIVOTEK camera models across its V, C, S, Dome, Bullet, and Panoramic series. VIVOTEK has posted an update package. 

CVE-2026-95102 — Monta (Critical) 

CVE-2026-95102 is a missing-authentication flaw for a critical function in all versions of monta.app. Three other Monta flaws involve excessive authentication attempts, session expiration, and credential protection. The advisory data referenced no vendor fix. 

Anjvision, Viidure, and Armatura One 

Anjvision's YSSD-RTMP-H5 firmware has nine vulnerabilities, led by CVE-2026-100291, a critical insecure default setting. Others include OS command injection, hardcoded credentials, and improper signature verification. 

The Viidure Dashcam Android app, version 3.3.1.260403 and earlier, contains hardcoded credentials (CVE-2026-96587, critical). Armatura One is affected by CVE-2023-46604, a critical deserialization flaw, plus hardcoded key and credential issues. 

No vendor fixes were referenced for these products, so compensating controls such as network isolation are the main option for now. 

CISA Malcolm (15 Vulnerabilities) 

In an unusual disclosure, CISA reported 15 vulnerabilities in Malcolm, its own open-source network traffic analysis and threat-hunting platform. The flaws affect versions before 26.06.0. 

They span authentication bypass, missing authorization, default credentials, OS command injection, path traversal, and SSRF. Most are rated medium, and two are rated high. Users should update through the Malcolm releases page. 

The remaining advisories covered Baicells Technologies, Meari, and Johnson Controls products. 

Impacted Critical Infrastructure Sectors 

Energy was the most exposed sector this week, followed by Transportation Systems and Commercial Facilities. 

The largest single combination, Energy, Information Technology, and Water and Wastewater, accounted for 27.8% of vulnerabilities. Energy, Chemical, and Transportation Systems made up another 18.5%, driven largely by the Toptech disclosures. 

These disclosures cut across traditional infrastructure boundaries rather than clustering in one domain. A single flaw in a shared product can create risk for fuel, water, and transportation operators at once. 

Conclusion 

This weekly vulnerability report highlights several trends: 

• Fast exploitation of newly disclosed flaws in WordPress, Apache Solr, and AI workflow tools such as Langflow and n8n 

• Persistent attacks on years-old embedded-device and router vulnerabilities 

• Critical ICS flaws in fuel distribution, cellular gateway, and camera products 

• Several ICS products with no vendor fix referenced, leaving compensating controls as the main defense 

• Ongoing phishing and brute-force activity that relies on weak and default credentials 

With 13 critical ICS vulnerabilities and active exploitation attempts against both new and legacy flaws, organizations face risk across enterprise IT and operational technology (OT) environments. 

Key Recommendations From This Weekly Vulnerability Report 

• Patch internet-exposed web platforms, plugins, and AI workflow tools first, starting with the flaws under active exploitation above 

• Replace default usernames and passwords, and enforce strong, unique credentials on servers and devices 

• Restrict or block exposed remote access and database ports, including VNC, RDP, SSH, Telnet, and SQL Server 

• Segment IT and OT networks with firewalls and demilitarized zones (DMZs) to limit lateral movement 

• Apply compensating controls, such as network isolation, for ICS products without available fixes 

• Verify firmware integrity on remote field devices and cellular gateways 

• Monitor macOS endpoints for unexpected disk-image apps and new LaunchAgents 

• Track CISA advisories and the Known Exploited Vulnerabilities (KEV) catalog, and prioritize by exploitability and operational impact 

• Conduct regular vulnerability assessments and penetration testing 

Cyble's attack surface management and vulnerability intelligence solutions help organizations identify exposed assets, prioritize remediation, and detect early signs of compromise. Combined with real-time sensor intelligence, they help security teams stay ahead of threats across enterprise and critical infrastructure environments. To see these capabilities in action, schedule a demo with Cyble. 

Disclaimer: The data and content written in this blog is based on certain sensor and open web information available. Analysts and researchers are advised to confirm once again from original sources. 

The post The Week in Vulnerabilities: Toptech, Lantronix, Langflow, and CISA Malcolm Flaws appeared first on Cyble.

A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded "Don't Get Played," was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names "Apex Accelerator" and "Stone Venture."

According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.

The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.

What the "Don't Get Played" Police Report States 

The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group's website as token.apexaccs.org and notes that the event's Telegram group had no public URL; prospective attendees could only join through the website. 

The report is titled "Suspected cyber scam targeting TOKEN2049 attendees ('Don't Get Played' event)." Its summary reads: 

"A group using the names 'Apex Accelerator', 'Stone Venture' and 'Don't Get Played' promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss." 

Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise. 

How the TOKEN2049 Side Event Was Pitched 

On paper, "Don't Get Played" looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams. 

The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.  

The agenda featured a live "wallet clinic" where attendees could have their holdings checked with "Apex Audit" tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell. 

The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit's security team, and the Singapore Police Force Cyber Command among the speakers. 

The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest. 

There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish. 

The Allegation and the Gaps in the Record 

The central claim is simple: organizers of "Don't Get Played" allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds. 

Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted. 

As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record. 

How the Crypto Community Reacted to "Don't Get Played"? 

After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation's contents.  

Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs. 

Not everyone was convinced. Sprunky (@sprunky_eth) argued that "page 2 of a report is not a finding," noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup. 

Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event "a wallet drain waiting to happen," and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.  

Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called "Don't Get Played" allegedly becoming the play. 

Conclusion 

The "Don't Get Played" allegations rest on a single attendee's police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open. 

Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event's own name suggested: any request to install software deserves suspicion.

References:  

• https://x.com/SolanaFloor/status/2109654244655812768 

• https://cryptobriefing.com/apex-accelerator-stone-venture-token2049-scam/ 

• https://x.com/DefraudTG/status/2109869264718971363 

Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice. 

The post “Don’t Get Played”: TOKEN2049 Security Event Faces Remote-Access Scam Allegations appeared first on Cyble.

Cloud infrastructure now changes by the hour, yet many security teams still map their external attack surface once a quarter or once a year. That mismatch creates blind spots that can last for months.  

A developer spins up a test environment on a Tuesday, an engineer opens a storage bucket for a partner on Wednesday, and a marketing team launches a campaign subdomain on Friday. If the next external assessment is scheduled for December, each of those assets sits exposed and unmonitored until then. 

For CISOs, security operations leads, and cloud security leads, the question is no longer whether the attack surface is growing. The question is whether visibility is keeping pace. In 2026, point-in-time scanning is structurally unable to do that. 

Why Cloud Sprawl Breaks the Quarterly Scan 

A point-in-time scan produces an accurate picture of one moment. In a static data center, that picture stayed useful for weeks. In a multi-cloud estate driven by infrastructure as code, CI/CD pipelines, and self-service provisioning, it starts to decay within hours. 

Three forces drive that decay: 

• Ephemeral assets. Containers, serverless functions, and short-lived virtual machines appear and disappear between scan windows, so they are never inventoried at all. 

• Decentralized ownership. Business units, contractors, and acquired subsidiaries open their own cloud accounts and SaaS tenants, often outside central security review. 

• Configuration drift. A security group, storage permission, or DNS record that was correct during the last assessment can be changed by a single commit. 

The NSA's Top Ten Cloud Security Mitigation Strategies warns that misconfigured, unsecured, or unmonitored cloud systems are attractive targets, and it flags "ghost assets" created by manual error. A quarterly scan cannot find a ghost asset that was created the day after it finished. 

What Government Data Says About the Exposure Window 

US federal policy has already moved past the quarterly model. CISA's Binding Operational Directive 23-01 requires federal civilian agencies to run automated asset discovery every 7 days and vulnerability enumeration every 14 days.  

Agencies must also be able to launch on-demand discovery within 72 hours of a CISA request. CISA's implementation guidance goes further: a new scan must start every 14 days even if the previous one has not finished. If a weekly cadence is the floor for federal networks, a 90-day cycle leaves private-sector enterprises roughly 13 times less current. 

The cost of lagging visibility is rising. The FBI's 2025 Internet Crime Report recorded 1,008,597 complaints and $20.877 billion in reported losses, a 26% increase over 2024. Ransomware complaints rose to 3,611, up from 3,156 the year before. 

The pattern is global. The ENISA Threat Landscape 2025 found that vulnerability exploitation accounted for 21.3% of initial access in the EU, with widespread campaigns weaponizing flaws within days of disclosure.  

CERT-EU reported that exploitation of internet-facing software was the highest-impact initial access vector for the second straight year. When attackers move in days, a defender that looks every 90 days has already lost the race. 

What Continuous Attack Surface Management Requires 

Closing the gap is not a matter of scanning more often. It requires a different operating model built on four capabilities: 

1. Outside-in discovery. Assets are found the way an attacker finds them, through DNS, certificates, IP space, and cloud provider ranges, rather than from an internal inventory that may already be stale. 

2. Continuous monitoring. New subdomains, open ports, exposed services, and certificate changes are detected as they appear, not at the next scheduled window. 

3. Threat-informed prioritization. Findings are ranked by real-world exploitability and attacker interest, so teams fix the exposures most likely to be used first. 

4. Ownership and workflow. Each exposure is routed to the team that owns it, with remediation tracked to closure. 

This model maps directly to what BOD 23-01 asks of federal agencies and to the asset visibility expectations in the NIST Cybersecurity Framework 2.0. 

How Cyble Attack Surface Management Closes the Gap? 

Cyble Attack Surface Management, powered by Cyble Odin, replaces periodic snapshots with a continuously updated view of an organization's external footprint. Odin scans internet-facing infrastructure on an ongoing basis, so newly exposed hosts, cloud services, open ports, and misconfigured assets are surfaced shortly after they go live. 

For CISOs, this turns attack surface reporting from a quarterly slide into a live risk metric that can be tracked against board-level objectives. For security operations leads, it means alerts on new exposures arrive in time to act, ranked by exploitability rather than raw volume. For cloud security leads, it provides an attacker's-eye check on multi-cloud sprawl, catching shadow assets and drift that internal tooling misses. 

Because Cyble ASM draws on Cyble's broader threat intelligence, including dark web and exploit activity, teams can see which exposed assets are being discussed or targeted by threat actors. That context helps US organizations align with the continuous visibility model CISA has set for federal networks, and it gives global teams a consistent view across regions and cloud providers. 

Conclusion 

Cloud environments will keep changing faster than any scheduled assessment can follow. Government guidance has already acknowledged this: weekly discovery is the federal baseline, and attackers weaponize new flaws within days. Organizations that still assess their external attack surface quarterly or annually are accepting months of unmonitored exposure by design. 

The shift to continuous attack surface management is no longer a maturity goal. In 2026, it is the minimum standard for knowing what an attacker can see. 

See your attack surface in real time. Book a demo of Cyble Attack Surface Management (Cyble Odin) to find the exposures your last scan missed. 

Sources 

• CISA BOD 23-01 

• CISA BOD 23-01 Implementation Guidance 

• FBI 2025 Internet Crime Report 

• NSA Top Ten Cloud Security Mitigation Strategies 

• ENISA Threat Landscape 2025 

• CERT-EU Threat Landscape Report 2025 

The post Attack Surface Management in 2026: Why Point-in-Time Scans Can’t Keep Up With Cloud Sprawl appeared first on Cyble.

Nation-state operators rarely need a zero-day to get inside a carrier. Much of the telecom stack still runs protocols designed when every participant was a known, trusted operator. SS7 assumes that the node sending a request has a legitimate reason to send it.  

BGP assumes a network announcing a route actually owns it. Attackers who understand those assumptions can operate inside a carrier for years without triggering a single alert. For telecom CISOs and SOC teams, defending this environment starts with understanding how these attacks actually work. 

SS7: A Protocol That Trusts Every Caller 

SS7 is roughly 40 years old and still underpins 2G and 3G SMS and phone services as well as international roaming. Its weakness is architectural. Any node with signaling access can send Mobile Application Part (MAP) queries asking where a subscriber is, or tell the network to route that subscriber's SMS elsewhere.  

SS7 has no built-in way to confirm the request came from someone entitled to make it. Access is also easier to get than many assume. Leased Global Titles, loosely vetted roaming partners, and compromised operators all provide an entry point. 

The consequences are well documented. SS7 can enable location tracking, interception of voice data and multi-factor authentication keys, and can even serve as a spyware delivery vector. Moving to newer generations doesn't solve the problem. The 4G and 5G Diameter protocol has its own location tracking weaknesses, and 4G and 5G users can be downgraded to SS7 when roaming. 

U.S. government assessments are blunt. The Department of Homeland Security concluded in 2017 that all U.S. carriers are vulnerable to SS7 and Diameter exploits, and a DHS presentation named Russia, China, Israel and Iran as the primary countries reportedly using other nations' telecom assets to exploit U.S. subscribers.  

These attacks often travel indirectly. According to that material, the traffic was being routed through third-country networks. The tooling is also spreading. Cyble's dark web researchers have confirmed that SS7 and Diameter exploits and services are still routinely discussed on underground forums, including detailed attack exploits. 

BGP: Internet Routing on the Honor System 

BGP has the same trust problem at internet scale. The FCC has noted that the protocol was designed decades ago and offers no intrinsic way to verify route origination. If a network announces a prefix it doesn't own, or a more specific slice of one, its neighbors will often accept the announcement and send the traffic to it. 

The best-known case is still a warning for the industry. According to the U.S.-China Economic and Security Review Commission's 2010 report to Congress, China Telecom advertised erroneous routes for about 18 minutes on April 8, 2010, pulling traffic for roughly 15 percent of internet destinations through Chinese servers, including traffic to U.S. government and military sites.  

Regulators are now responding. In 2024, the FCC proposed that broadband providers build BGP security plans based on RPKI, with the nine largest filing those plans confidentially and publishing quarterly progress data. 

The Router Layer: Where Persistence Lives 

Signaling and routing abuse are only part of the picture. The most serious recent intrusions have targeted the hardware that carries the traffic. A 2025 joint advisory from CISA and allied agencies found that PRC state-sponsored actors focus on large backbone routers of major telecom providers, along with provider edge and customer edge routers, and use compromised devices and trusted connections to pivot into other networks.  

They often modify routers to maintain persistent, long-term access. 

Initial access typically came through known vulnerabilities, not novel ones. The advisory lists CVE-2024-21887 in Ivanti Connect Secure, commonly chained after the CVE-2023-46805 authentication bypass, and CVE-2024-3400 in Palo Alto PAN-OS GlobalProtect, along with CVE-2023-20273, a Cisco IOS XE flaw commonly chained with the CVE-2023-20198 authentication bypass to achieve root-level code execution.  

Once inside, the Salt Typhoon cluster implanted malicious code on network devices and configured GRE tunnels to pull data through compromised routers. 

Aging infrastructure makes eviction harder. U.S. Senator Mark Warner, describing carrier networks, said there is equipment "so old it's unpatchable". 

Why Detection Lags 

These intrusions have a common pattern. SS7 abuse looks like normal roaming traffic. A hijacked prefix looks like an ordinary route update. A rogue GRE tunnel looks like legitimate provisioning. None of them runs on an endpoint where EDR can see it.  

By the time anomalous activity shows up internally, the attacker has usually already mapped the network and started moving laterally. 

Defending this environment takes several layers working together: 

• Signaling: Deploy SS7 and Diameter firewalls and vet Global Title partners strictly. 

• Routing: Publish Route Origin Authorizations and enforce RPKI origin validation. 

• Router hygiene: Patch the CVEs above immediately, and audit every tunnel, mirror session, and AAA configuration against an approved baseline. 

• External visibility: Track what happens outside your perimeter, where attacks are often planned before they launch. 

Where Cyble Vision Fits 

External visibility is the gap Cyble Vision closes. It tracks underground forums where SS7 exploits and signaling access are traded, and flags leaked credentials and device configurations tied to your infrastructure.  

It maps exposed management interfaces across your attack surface and prioritizes the edge-device vulnerabilities state actors are actively exploiting.  

Threat actor intelligence connects those signals to the groups behind them, so your SOC can act on early indicators instead of reconstructing a breach after the fact. 

See intrusions before lateral movement starts. Book a Cyble Vision demo → 

References 

• https://www.wyden.senate.gov/imo/media/doc/wyden-schmitt_dod_letter.pdf 

• https://docs.fcc.gov/public/attachments/DOC-402579A1.pdf 

• https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/ 

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a 

• https://docs.fcc.gov/public/attachments/FCC-24-62A1.pdf 

• https://www.uscc.gov/sites/default/files/annual_reports/2010-Report-to-Congress.pdf 

The post Inside the Telecom Attack Surface: SS7, BGP Hijacking, and the Technical Reality of Nation-State Intrusions  appeared first on Cyble.

Cybersecurity compliance APAC 2026 has moved from guidance to enforcement across three of Southeast Asia's largest economies, almost in step. Singapore's Cyber Security Agency issued an updated Cybersecurity Code of Practice 2026 for Critical Information Infrastructure on 29 July 2026.

Malaysia's Cyber Security Act 2024 has been active since August 2024, with NACSA now well into audits and incident-reporting enforcement. Thailand's Cybersecurity Act NCSA mandate now covers new cloud and website security standards, with the cloud standard already in force. 

None of this happened quietly, and none of it is optional for the organizations it covers. For enterprise CISOs and compliance leads across ASEAN, the message from three separate regulators is the same: continuous monitoring and fast incident reporting are now the baseline for Critical Information Infrastructure APAC-wide, not the aspiration. 

Singapore Cybersecurity Code of Practice 2026 

Singapore Cybersecurity Code of Practice 2026 is the first substantial revision since 2022, and it changes who is accountable and how far the obligations reach. Boards of Critical Information Infrastructure owners must now maintain a documented cyber resilience framework, sit through cybersecurity training at least once a year, and receive threat briefings twice a year.

The code also extends mandatory controls to "Interconnected Systems" — the vendor platforms and adjacent networks that talk to CII but were never designated as CII themselves.

CSA has been explicit about why: Advanced Persistent Threats and AI-enabled attacks are shortening the gap between a vulnerability's discovery and its exploitation, and perimeter-only defense no longer covers that gap. Most obligations take effect by 29 July 2027, with Cyber Trust Mark Tier 5 certification required by the end of that year. 

Malaysia Cyber Security Act 2024 and NACSA Compliance Malaysia 

Malaysia Cyber Security Act 2024 has already reshaped how National Critical Information Infrastructure entities operate.  

NACSA compliance in Malaysia now demands that organizations across the 11 CNII sectors run periodic risk assessments and audits, work only with NACSA-licensed cybersecurity service providers, and notify authorities as soon as they become aware of an incident — with detailed follow-up required within hours through the national coordination system, and a full account due within 14 days. 

 Failure to report carries fines of up to RM500,000 and up to ten years' imprisonment. That penalty structure alone has pushed incident detection speed onto the CISO's list of board-level metrics. 

Thailand Cybersecurity Act NCSA and Cloud Security Standards Thailand 

Thailand Cybersecurity Act NCSA authority extends to a narrower but no less demanding set of obligations. NCSA cloud security standards Thailand has enforced since 10 September 2026 require government agencies, state enterprises, and cloud service providers to maintain encryption, access control, and at least annual security assessments across IaaS, PaaS, and SaaS environments.  

A companion Website Security Standard, effective 16 September 2026, asks organizations serving the public to formalize risk registers, access governance, and incident response practices aligned with standards like ISO/IEC 27005. Both sit on top of Thailand's Cybersecurity Act B.E. 2562, which already empowers the NCSA to designate and directly oversee Critical Information Infrastructure. 

Detection Speed is Now a Compliance Metric 

Read together, these three frameworks are not really about paperwork. They are about how fast an organization can see a threat, understand it, and prove that it acted. Board-level cyber resilience reviews, hours-not-days incident notification windows, and mandatory continuous monitoring across cloud and interconnected systems all assume real-time threat intelligence APAC organizations rarely have in place today. 

That is precisely where most regional enterprises still fall short. The ASEAN cyber threat landscape has historically produced reactive detection — SOC teams responding to alerts generated after compromise, or intelligence arriving too late and too generic to inform an actual decision.  

Regulators in Singapore, Malaysia, and Thailand have each, independently, concluded that this model no longer meets the moment. AI-accelerated reconnaissance, faster exploit development, and an increasingly interconnected regional supply chain mean the window between initial access and material damage keeps shrinking. 

Where Cyble Vision Actually Fits?

The gap between what these regulations now require and what most enterprises currently have is specific: visibility into threats before they become incidents, and evidence that can be produced when a regulator asks for it. Cyble Vision is built around that gap rather than around it as a slogan. 

The platform monitors surface, deep, and dark web sources continuously — underground forums, ransomware leak sites, and cybercrime marketplaces — to surface exposed credentials, leaked data, and threat actor chatter referencing an organization before that activity turns into a breach.  

Cyble's attack surface management solutions keeps a running inventory of internet-facing assets, cloud services, and adjacent vendor systems, which maps directly onto Singapore's requirement to account for Interconnected Systems and Thailand's expectation that cloud configurations be reviewed on an ongoing basis.  

Brand and executive monitoring flags impersonation and targeted threats aimed at leadership, and risk scoring is used to prioritize which alerts actually warrant an incident response versus which are noise. 

None of this replaces the audits, board reporting, or licensed-provider engagements that Singapore's CCoP, Malaysia's Cyber Security Act, and Thailand's NCSA standards require — those remain organizational and legal obligations. What continuous, contextualized threat intelligence does is shorten the time between something going wrong and someone finding out, which is the exact metric each of these regulators is now measuring. 

See how fast you can detect a breach. Request a Cyble Vision demo. 

References 

•  https://www.csa.gov.sg/news-events/press-releases/cybersecurity-code-of-practice-for-critical-information-infrastructure-to-be-updated-to-address-apt-and-ai-enabled-threats/ 

• https://securiti.ai/overview-of-malaysia-cyber-securitiy-act-2024/ 

• https://sth.sh/en/compliance/ncsa-cloud-security-standard/ 

• https://www.csa.gov.sg/ 

Disclaimer: This article is intended for general informational purposes only and does not constitute legal, regulatory, or compliance advice. Regulatory requirements referenced — including Singapore's Cybersecurity Code of Practice, Malaysia's Cyber Security Act 2024, and Thailand's NCSA Cloud and Website Security Standards — are based on publicly available information as of the date of publication and may be revised, amended, or reinterpreted by the respective authorities. Organizations should consult qualified legal counsel or their compliance teams to confirm current obligations applicable to their specific operations and jurisdiction. 

The post Why APAC Enterprises Need Real-Time Threat Intelligence as Singapore, Malaysia, and Thailand Tighten Cyber Compliance in 2026 appeared first on Cyble.

Cyble has rolled out a significant upgrade to Executive Monitoring inside Cyble Vision, bringing unified findings, AI-driven scoring, and expanded alerting together in a single protection suite.

Executive monitoring has historically meant stitching together several things at once. An impersonation tool here, a dark web exposure feed there, a reputation score from somewhere else, and alerts that show up in whatever channel each vendor happened to support. Security teams protecting their executives ended up doing the integration work themselves, correlating findings across tools, and re-explaining risk to the board every quarter using numbers that didn't quite agree with each other.

That era is over.

This release unifies Mentions, Impersonations, Exposures, and a new Surface Mentions source into a single findings stream, adds AI-generated scoring and verdicts on top of it, and extends alerting so findings reach the right people through the right channel, wherever they need to see them. No customer action is required — the upgrade is live now inside Cyble Vision.

What's Upgraded

Unified Findings, Now With Surface Mentions

Security teams have long had to check multiple places to get a full picture of an executive's exposure. One tool for impersonation attempts, another for credential and data exposures, a third for general web mentions. Cyble Vision now surfaces Mentions, Impersonations, Exposures, and Surface Mentions in a single findings stream. Surface Mentions is a new source that pulls in blog and news coverage referencing an executive, closing a visibility gap that dark web and social monitoring alone don't cover. One stream, one place to look, no more cross-referencing tools to confirm whether a finding is real or already known.

Risk & Reputation Scoring

A pile of raw alerts doesn't mean much to a board. Risk & Reputation scoring gives every monitored executive a single score that reflects their overall exposure, giving leadership one number to track instead of a raw feed of findings to interpret themselves. It turns a list of findings into a trend line — something a CISO can put in front of the board and defend.

AI-Generated Verdicts and Recommendations

Every finding in Cyble Vision now arrives with an AI-generated verdict and a recommended next step, so analysts aren't starting their triage from a blank page. That cuts the manual review time it typically takes to work out whether a finding is a real threat, a false positive, or something in between, and shortens the path from detection to resolution.

Richer Executive Onboarding

False positives on executive monitoring usually come from one place: same-name matches. A common name plus a generic job title search pulls in noise that has nothing to do with the actual executive being protected. Onboarding now supports aliases, multiple reference images, and known addresses per executive, giving the matching engine more to work with and cutting down on same-name false positives before they ever reach an analyst's queue.

Unified Alert Management

Alert management now supports data residency, addressing a requirement that regularly shows up in RFPs for regulated and enterprise customers. Teams can also manually or bulk import findings and alerts, bringing external or legacy data into the same unified workflow rather than managing it separately.

Multi-Channel Alert Delivery and Access API

Findings don't help if they arrive somewhere no one's watching. Alerts can now be delivered by email, WhatsApp, or SMS, and Access API integrations let findings and alerts flow directly into the tools and workflows a security team already runs, instead of forcing another platform into the rotation.

Branded Executive PDF Report

Reporting on executive risk has typically meant assembling findings from multiple tools into a single deck by hand. Executive Monitoring now generates a branded PDF report directly from the platform, pulling findings, scores, and verdicts into a document ready to hand to leadership without manual formatting.

Where Are We Heading

Executive monitoring is moving in the same direction as third-party risk and brand protection before it – away from a collection of narrow point tools and towards a single, intelligence-led workflow. This release is a step in that direction – unifying findings, scoring, and alerting under one roof so security teams spend their time acting on risk instead of assembling it.

Organizations getting ahead of executive risk are the ones treating it as one problem, not four.

Learn more about Cyble Vision Executive Monitoring or request a demo to see it in action.

Frequently Asked Questions

1. What is Executive Monitoring in Cyble Vision?

Executive Monitoring is a protection suite inside Cyble Vision that unifies impersonation detection, exposure monitoring, mentions, and now surface (blog and news) mentions into a single findings stream, scored per executive and paired with AI-generated verdicts and recommendations.

2. Who is this for?

• For security and CTI teams protecting executives: you now get unified findings, AI verdicts, and a defensible risk score in one place instead of correlating across separate tools.
• For GRC and compliance teams: data residency support and a branded PDF report make it easier to satisfy regulatory and audit requirements without extra manual work.
• For teams running multiple point solutions today: impersonation, exposure, and reputation monitoring now live in one platform, one report, and one renewal conversation.

3. What was just launched?

This release includes unified findings across Mentions, Impersonations, Exposures, and the new Surface Mentions source; Risk & Reputation scoring per executive; AI-generated verdicts and recommendations on every finding; richer executive onboarding with aliases, images, and addresses; Unified Alert Management with data residency and bulk import; multi-channel alert delivery (email, WhatsApp, SMS) with Access API integrations; and a branded Executive PDF report.

4. How is this different from the point solutions we use today?

Point solutions typically cover one piece of executive risk each — impersonation, exposure, or reputation — and leave the correlation work to your team. Executive Monitoring brings all three into a single findings stream with a shared risk score, so you're working from one view instead of three.

5. Do we need to do anything to get these updates?

No. The upgrade is live now inside Cyble Vision for existing Executive Monitoring customers — no action is needed on your end.

6. Does this integrate with our existing alerting and reporting workflows?

Yes. Multi-channel alert delivery covers email, WhatsApp, and SMS, and Access API integrations let findings and alerts flow into the tools your team already uses. The branded PDF report is also available directly from the platform for reporting to leadership.

7. Why are false positives from same-name executives going down?

Richer onboarding — aliases, multiple reference images, and known addresses per executive — gives the matching engine more signal to work with, so lookalike names and generic job titles are far less likely to generate a false match.

8. Where can I learn more?

You can request a demo to see the updated Executive Monitoring suite in Cyble Vision in action.

Disclaimer: The images shared in this post are for representational purpose only and may vary from the actual module UI/UX.

The post Cyble Introduces Major Upgrade to its Executive Monitoring Module appeared first on Cyble.

Infostealer malware is behind a large share of today's credential compromise — and it usually doesn't start with a breach at all. When a security team hears "data breach," the instinct is to look for the moment a database was exfiltrated or a network was penetrated. But more often, the real starting point is a single endpoint infection, often on a personal device, that has nothing to do with the organization's perimeter.

By the time stolen credentials show up in a breach notification or a dark web alert, they've already passed through several distinct, mechanical stages. Understanding that pipeline — rather than waiting for the final alert — is what separates reactive security teams from ones that catch exposure early.

How Infostealer Malware Powers the Credential Theft Pipeline?

What follows is a stage-by-stage breakdown of that journey — from the moment infostealer malware first executes on a device, through the log assembly and enrichment steps that add value along the way, to the final point where credentials are packaged and sold on the open market. Each section builds directly on the one before it, showing exactly how a single infection turns into an inventoried, priced, and marketable product.

Execution and Harvesting 

The pipeline begins with infostealer malware — a lightweight piece of software designed to do one thing efficiently: grab whatever credentials, cookies, and session tokens are sitting in a browser or application on the infected machine. This is the core mechanism behind modern credential harvesting, and these tools typically arrive through cracked software installers, fake game cheats, malicious browser extensions, or phishing lures disguised as invoices or shipping notices. 

Once executed, the stealer doesn't loiter. It targets browser credential stores, autofill data, saved payment details, cryptocurrency wallet files, FTP client configurations, and any session cookies that could allow an attacker to bypass login screens entirely. Many stealers also grab system fingerprinting data — IP address, hardware ID, installed software — which becomes useful later for building convincing sessions or bypassing device-based fraud checks. 

The output of this stage is a "log": a structured folder of text files, often just a few kilobytes, containing everything the malware could pull from that one machine. These stealer logs are the raw currency of the entire pipeline that follows. 

Aggregation and Log Assembly 

A single log is not particularly valuable on its own. Its worth comes from volume. Threat actors operating stealer campaigns typically run panels — command-and-control dashboards — that collect incoming logs from hundreds or thousands of infected machines simultaneously. These logs get bundled into larger archives, sometimes labeled by infection date, campaign, or targeted region. 

This is the point where individual credential theft becomes an inventory problem for the attacker. Logs get sorted, deduplicated, and screened for anything obviously valuable — corporate VPN logins, SaaS admin panels, banking portals — versus low-value consumer accounts. 

Parsing and Enrichment 

Raw logs are messy, so a parsing step usually follows before anything is sold or shared. Automated tools and, in some cases, manual review are used to extract structured fields: username, password, URL, and associated cookies, organized into searchable formats. This is also where enrichment happens — cross-referencing a log against previously leaked datasets to add context like a person's employer, job title, or other accounts tied to the same email address. 

Enrichment matters because it changes the value proposition. A raw password paired with a login URL is interesting. That same credential paired with confirmation that it belongs to an IT administrator at a mid-sized company is something else entirely — and priced accordingly.  

It's also at this stage that enriched credentials become prime material for credential stuffing campaigns, where attackers automate login attempts across dozens of unrelated services in the hope that a password was reused. 

Marketplace Listing 

The final stage is distribution. Parsed and enriched logs are listed for sale on dark web marketplaces and forums, sometimes as full archives ("bulk logs") and sometimes broken apart and sold as individual access credentials to specific platforms — a corporate email account, a cloud console login, a remote desktop session. Listings often include partial samples as proof of authenticity, along with metadata like infection date, geography, and browser type, to help buyers judge freshness and relevance. 

This is usually the first point where an outside observer — including a security team — has a realistic chance of spotting exposure, provided they're actually looking at this layer of the ecosystem rather than waiting for a breach disclosure further downstream. 

Why the Earlier Stages Matter More Than the Alert? 

Most detection strategies are built around the last step: someone notices a listing or a breach compilation and issues an alert. But by then, the credential may have already changed hands, been tested against multiple services, or been bundled into a larger fraud operation. The earlier stages — infection, log assembly, and enrichment — are where exposure actually originates, and where it can be caught closer to the source. 

For SOC teams and identity security leads, the practical takeaway is that credential exposure isn't a single event to monitor for — it's a pipeline to monitor across. Visibility into stealer logs, marketplace chatter, and enrichment activity gives a much earlier warning than waiting for a finished, packaged breach. 

Your Credentials Are Probably Already for Sale. You Just Don't Know It Yet. 

Somewhere right now, an infostealer log sits in a marketplace listing with your company's name attached to it — and nobody on your team has seen it. That's not a scare tactic. It's the default state for most organizations, because credential exposure happens quietly, on devices you don't control, long before it ever becomes "your" incident. 

The only real question is whether you find out from a threat feed, or from a breach headline. 

See what's already exposed — before someone else finds it first. Run a free check with Cyble and get a real answer, not a guess. 

The post From Infostealer Log to Marketplace Listing: A Technical Walkthrough of the Credential Theft Pipeline appeared first on Cyble.

Qatar is racing toward a knowledge-based, fully digital economy. Smart infrastructure, cloud-first government services, a financial sector that's increasingly API-driven, and critical energy assets like QatarEnergy's LNG operations layering more connected OT/ICS systems every year. That pace of transformation makes Qatar an attractive target in the cyber realm, right now. Attackers don't need to compromise everything; they just need one high-value foothold, and Qatar's expanding digital footprint keeps handing them more doors to try.

This risk is showing up in the data as well.

The Problem: A Small, Concentrated, High-Precision Threat

Unlike sprawling, high-volume threat landscapes elsewhere, Qatar's risk profile in 2025-26 has been described as quietly high-stakes rather than loud. Attackers aren't spraying and praying — they're going after specific footholds, specific sectors, and specific vulnerabilities. That precision is arguably more dangerous than volume, because it means defenders are up against adversaries who've already done their homework on Qatari targets.

A few things stand out in the current picture:

Ransomware has consolidated around a group of dominant actors. According to Cyble's Qatar Threat Landscape Report 2025, the Qilin ransomware group was responsible for essentially all observed ransomware activity in the country during the period, including a concentrated campaign in October. But in 2026, to date, The Gentleman, Everest, Crypto24 and Payload groups shared the space. When a few groups own the entire observed ransomware footprint in a country, it signals a level of operational focus that generic, one-size-fits-all defenses aren't built to catch.

Financial services and retail are the prime targets for access brokers. The same research found confirmed instances of compromised access being sold on underground markets tied to Qatar, with BFSI and retail organizations accounting for more than half of those listings. That's initial access brokers doing reconnaissance and sale work specifically for buyers who want a way into Qatar's financial ecosystem — a pipeline that often precedes ransomware or fraud operations.

Education has become a quiet leak point. Data breaches and leak incidents were recorded, most frequently hitting the education sector, largely opportunistic actors going after personally identifiable information. Universities and training institutions tend to sit outside the security investment priorities of banks or energy firms, which makes them a softer entry point into a country's wider digital ecosystem.

Zero-days and known exploited vulnerabilities in enterprise remote-access tools spiked. Products from Microsoft, Fortinet, Ivanti, and Citrix — the tools that underpin remote access and enterprise connectivity almost everywhere in Qatar's public and private sector — saw a surge in exploitation activity. These are exactly the platforms that link head offices, branch networks, and increasingly remote or hybrid teams together, so a single unpatched edge device can become a bridge straight into the core network.

Hacktivism is low-volume but not absent. Much of it is narrative-driven information operations tied to regional geopolitical tensions rather than destructive attacks — but it's a reminder that Qatar's high international visibility (as a diplomatic hub and an LNG exporter) keeps it on ideologically motivated actors' radar too.

Beyond the Numbers, What Matters

Qatar isn't short on regulatory intent. Law No. 13 of 2016 on Personal Data Privacy Protection already requires organizations to run active breach management and compliance programs, and Qatar's National Cyber Security Agency has been steadily raising the bar — joining the global ISASecure certification program to strengthen industrial control system standards, and the country ratifying the UN Convention against Cybercrime to reinforce cross-border cooperation. The cybersecurity market itself is projected to keep growing at a solid clip through the end of the decade as organizations respond to this pressure.

But policy and market growth don't close the defense gap on their own. The data above describes a landscape where:

• A handful of ransomware operators can inflict outsized damage because they're facing fragmented, generic defenses rather than region-specific threat intelligence.
• Financially motivated actors are actively building and selling access into Qatar's banking and retail sectors before an attack ever becomes visible.
• Edge infrastructure — the very tools organizations rely on for secure remote connectivity — is itself the weak link.

The organizations best positioned to respond aren't the ones with the biggest security budgets; they're the ones with visibility into what's actually being sold, exploited, and targeted in their own region, before it turns into an incident report.

Meet Us at CYSEC, Qatar

This is exactly the conversation happening at CYSEC Qatar, the region's leading closed-door cybersecurity summit, bringing together CISOs, government cyber leaders, and IT/OT security heads to work through the threats defined above — cloud security, incident response, threat intelligence sharing, and AI-driven defense.Cyble's Mandar Patil, Feras Jbrah, Dhanish Khan, and Reshma Nair, will be on the ground at CYSEC Qatar’s – 22^nd Global Edition on 8-9th September, ready to walk through the region-specific threat intelligence behind this piece and talk about what proactive, Qatar-focused defense looks like in practice.

If you're attending, stop by and meet the team — bring your hardest questions about your own exposure, and let's talk about closing the gap before the next Qilin-style campaign finds it first.

Book your slot with our expert now!

Media Disclaimer: This blog was compiled from publicly available government advisories and open-source security reporting. It is provided for reference purposes only; readers bear full responsibility for their reliance on it.

The post Qatar’s Digital Boom Has a Blind Spot: What the 2025-26 Threat Data Is Telling Us appeared first on Cyble.

Six hours. That's the incident notification window under the UAE's Information Assurance Standard v2. Once a breach is detected, the framework requires incident notifications within 6 hours of detection, alongside quarterly compliance updates and annual maturity assessments.

Saudi Arabia's regulators aren't far behind — SAMA's cybersecurity framework and the Kingdom's PDPL both converge on a 72-hour notification standard, and the NCA's Essential Cybersecurity Controls point organizations toward a similar 72-hour reporting expectation for serious cyber incidents.

Read that again. Regulators across the GCC aren't asking enterprises to respond fast anymore — they're mandating how fast enterprises must know. And that's the part most security programs still get wrong.

The Compliance Clock Starts at Detection, Not Response 

Every regulatory framework reshaping the region's cybersecurity posture — NCA ECC, NESA/UAE IAS v2.1, SAMA CSF — shares a structural assumption: the organization already knows it's been breached. The clock for reporting, escalation, and remediation only starts ticking once detection happens. 

That assumption breaks down inside most enterprise SOCs. Detection today typically means: 

• Alerts triaged manually across siloed tools, hours or days after initial compromise 

• Threat intelligence that arrives as static reports, not real-time signal 

• Exposure discovered only after a regulator, a customer, or an attacker's leak site announces it 

Under NESA's incident management requirements, tested response procedures and a maintained incident log matter — but the underlying detection of SLA still has to be met before any of that documentation is worth anything. A perfect incident response plan is irrelevant if the breach itself goes unnoticed for a week. 

Why Reactive Detection Can't Survive These Timelines 

Reactive security was designed around a different clock — the attacker's dwell time, not the regulator's reporting window. Under IAS v2's enhanced SOC requirements, Tier 1 critical infrastructure entities now need 24/7 monitoring capability paired with defined detection and response SLAs, not just a monitoring function. That's a measurable performance bar, not a checkbox. 

For a Gulf enterprise, missing that bar isn't just a security failure — it's a compliance failure with financial, contractual, and reputational consequences layered on top. And because a single incident can trigger overlapping obligations across multiple regulators at once, one detection gap can cascade into several separate compliance breaches simultaneously. 

See how fast you can detect a breach — run a live check with Cyble Vision. 

Where AI-powered Threat Intelligence Closes the Gap 

This is the shift Cyble Vision is built for. Instead of waiting for a signature match or a manual review cycle, AI-powered threat intelligence continuously correlates external signals — leaked credentials, dark web chatter, exposed assets, attacker infrastructure — against your enterprise footprint in real time. 

That matters specifically because GCC frameworks measure speed from the moment of detection, not from the moment someone happens to notice. Closing that gap means: 

• Continuous exposure monitoring instead of periodic scans, so assets breaching policy or appearing in threat actor chatter surface immediately 

• AI-correlated alerting that cuts through noise and prioritizes what actually threatens regulated systems 

• Audit-ready detection logs that document when a threat was identified — the evidence NESA and SAMA assessors specifically ask for 

Don't wait for attackers — or a regulator — to find your blind spots first. 

What "Regulatory-Ready" Detection Actually Looks Like? 

For a CISO or compliance lead building toward NCA ECC, NESA, SAMA, or UAE IAS v2.1, the operational bar has moved from "can we respond" to "can we prove we detected in time." That means: 

1. Detection telemetry timestamped and retained for regulator review 

2. Threat intelligence mapped directly to the assets and systems in scope 

3. Alerting fast enough to fit inside a 6-to-72-hour reporting clock — not just a monthly threat report 

Cybersecurity compliance in the UAE and Saudi Arabia is no longer a documentation exercise. It's a speed test, and most enterprises are still building for the exam they used to take. 

Find Your Blind Spots Before the Regulator Does 

AI-powered threat intelligence isn't a nice-to-have layered on top of compliance anymore — for Gulf enterprises operating under NCA ECC, NESA, SAMA, and UAE IAS v2.1, it's becoming the mechanism that makes compliance achievable at all. 

See how fast you can detect a breach.  

The post AI-Driven Threat Intelligence for Gulf Enterprises: Why Detection Speed Is Now a Regulatory Requirement appeared first on Cyble.

Supply chain attacks in 2026 are no longer an edge-case risk buried in a vendor questionnaire — they are a primary breach vector that regulators, incident responders, and CISOs now treat as a first-order threat. Verizon's 2026 Data Breach Investigations Report found third-party involvement in 48% of breaches, up 60% year over year, following the 2025 edition, which already recorded a jump from 15% to 30%.  

Every vendor integration, every open-source dependency, and every managed file transfer tool expands the attack surface that an organization does not directly control. That is the core problem with supply chain security today: the weakest link is rarely the enterprise itself.  

It is the supplier three tiers removed that nobody in procurement flagged as high-risk. 

What Is a Supply Chain Attack, and Why Does It Bypass Standard Defenses?  

A supply chain attack targets the vendors, software components, and build pipelines that an organization depends on, rather than attacking the organization directly.  

Software supply chain security failures happen when a trusted update, library, or third-party platform is compromised upstream, and that compromise rides in through a channel the target already trusts and has whitelisted.  

Traditional vulnerability scanning is built to find flaws in owned infrastructure — it was never designed to flag a poisoned dependency sitting inside a vendor's codebase. 

Recent Supply Chain Attacks Prove the Blind Spot Is Structural, Not Occasional 

The pattern keeps repeating at scale. The Cybersecurity and Infrastructure Security Agency and FBI documented in advisory AA23-158A how the Cl0p ransomware group exploited a SQL injection flaw (CVE-2023-34362) in Progress Software's MOVEit Transfer platform, a widely used managed file transfer tool. Exploitation began on May 27, 2023. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on June 2, six days later, and Progress had published its own advisory on May 31. 

By January 2024, breaches or downstream exposures at more than 2,700 organizations had compromised the personal data of more than 93 million people, according to tracking by Emsisoft and KonBriefing Research. Censys counted more than 3,000 MOVEit environments exposed to the internet before the flaw was disclosed or patched.  

The same advisory covers an earlier Cl0p campaign against Fortra's GoAnywhere MFT, launched in late January 2023 against a separate zero-day, CVE-2023-0669. Cl0p claimed to have exfiltrated data affecting approximately 130 victims over the course of 10 days, a claim CISA and the FBI recorded in the advisory.  

The agencies did not identify lateral movement from GoAnywhere into victim networks, which suggests the breach stopped at the platform itself. That detail is the point, not a caveat: the attacker never needed to go any further because the platform already held the data.  

These campaigns share a structure: one vendor, one flaw, hundreds of downstream victims who had no visibility into the vendor's exposure until the breach was already public. 

Why Vendor Dependencies Create Blind Spots Scanning Alone Can't Close 

This is the operational reality procurement and vendor risk teams face: an organization can harden its own perimeter completely and still inherit a breach through a supplier's unpatched system, a compromised update mechanism, or a fourth-party dependency nobody mapped.  

Supply chain threats don't trip an internal vulnerability scanner because the vulnerable asset was never inside the scan's scope to begin with.  

By the time a breach notification arrives from a vendor, the exposure window has already closed — and the damage is already done. 

Supply Chain Attack Prevention Now Requires Continuous, External Vendor Visibility 

Governments are formalizing the response. In September 2025, CISA and the NSA, together with 19 international partners, published joint guidance establishing a shared framework for Software Bills of Materials, treating component-level transparency as a baseline security expectation rather than a nice-to-have.  

CISA, the NSA, the FBI, and international partners followed on July 29, 2026, with 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the minimum elements NTIA published in 2021.  

The revision draws on more than 90 public comments and applies to all software, including open-source components, AI systems, and software delivered as a service 

CISA has since followed with the 2026 Minimum Elements for SBOM guidance, updating the original 2021 federal standard.  

The regulatory direction is unambiguous: organizations are expected to know what's inside their vendors' software stacks —not just their own—before deployment, not after an incident. 

Monitoring the Vendor, Not Just the Perimeter 

Closing this blind spot requires continuous monitoring of vendor infrastructure, exposed credentials, dark web chatter, and third-party breach signals — the exact layer traditional vulnerability management doesn't cover.  

Cyble's Third-Party Risk Management platform continuously tracks vendor risk posture, surfacing exposure signals tied to suppliers before they cascade into a confirmed compromise, giving CISOs, vendor risk managers, and procurement security teams the lead time that reactive scanning can't provide. 

Find your blind spots before an attacker does. Request a Cyble TPRM demo! 

Conclusion 

Supply chain attacks in 2026 succeed for the same reason every time: organizations extend trust to vendors faster than they extend visibility into them. CISA's own advisory record — from GoAnywhere to MOVEit — shows that a single upstream compromise can cascade into hundreds of victims before any of them see it coming. Patching internal systems faster won't fix that. Neither will another vendor questionnaire be filed away after onboarding. 

What changes the outcome is continuous visibility into the vendors, software components, and dependencies an organization has already accepted as trusted — tracked before a breach notification forces the issue. That's the gap threat intelligence is built to close, and it's the difference between reacting to a supplier's incident and seeing it coming. 

Don't wait for a vendor to tell you they were breached. See how Cyble Third-Party Risk Management maps your vendor exposure. 

References 

• #StopRansomware: CL0P Ransomware Gang: Exploits CVE-2023-34362 MOVEit Vulnerability 

• CISA, NSA, and 19 International Partners Release Shared Vision of Software Bill of Materials for Cybersecurity Guide 

Disclaimer: This blog is for general informational purposes only and does not constitute security, legal, or compliance advice. Statistics and incidents referenced are drawn from public advisories issued by CISA, FBI, and NSA, accurate as of their publication dates. Threat conditions and guidance change frequently — consult the original advisories and your own security team before making risk or compliance decisions.

The post Supply Chain Attacks in 2026: Why Threat Intelligence Is the Only Early Warning System That Works appeared first on Cyble.

For years, cybersecurity teams have communicated risk through labels such as “High,” “Medium,” and “Low.” Those ratings can help security teams prioritize vulnerabilities, but they often leave CFOs with a more important question unanswered: What does the risk actually mean for the business financially? 

That question has become harder to ignore as the threat landscape accelerates. Cyble’s 2025 threat predictions, published as the year unfolded, provide a useful illustration. More than 80% of the threats Cyble forecast—including AI-driven ransomware and complex supply-chain attacks—materialized as anticipated.  

It was observed that dark-web discussions about using large language models for phishing, automated social engineering, and ransomware negotiation as early as six months before AI-powered ransomware became a mainstream concern. 

From Threat Signals to Financial Exposure 

Cyble’s 2025 research identified several trends that demonstrate why qualitative risk scores are no longer enough. 

Ransomware incidents increased by 52% in 2025, according to Cyble's analysis. Cyble's full-year 2025 report recorded 6,604 ransomware attacks, compared with 4,346 in 2024. December 2025 alone recorded nearly 731 attacks, the second-highest monthly total of the year, surpassed only by February. 

The FBI and CISA also issued joint warnings regarding Medusa ransomware, including the use of AI to streamline intrusion, escalate privileges, and evade detection. The EU SOCTA 2025 report similarly identified an increase in ransomware activity. Cyble also documented 57 new ransomware groups, 27 new extortion groups, and more than 350 new ransomware strains during 2025 alone. 

At the same time, ransomware affiliates proved remarkably adaptable. Cyble also documented 57 new ransomware groups, 27 new extortion groups, and more than 350 new ransomware strains during 2025 alone. 

International disruption operations targeted several ransomware ecosystems, but as RansomHub went offline in April 2025 and Black Basta became largely inactive following internal chat leaks and operational disputes, displaced affiliates migrated between operators and adopted distributed criminal models rather than withdrawing from the market. The United States remained the primary target, accounting for 55% of attacks in 2025. 

Qilin and DragonForce absorbed the bulk of those displaced affiliates, reinforcing the resilience that has made ransomware a persistently growing threat. 

Public-facing applications and zero-days remained another major entry point. The data supported its prediction that exposed applications would remain attractive targets. Incidents involving Multer for Node.js, Microsoft SharePoint, CVE-2025-20337, and CVE-2025-5777 reinforced that concern. 
 
Identity and credential compromise became the dominant initial-access vector: Unit 42 attributed 65% of intrusions to compromised credentials, stolen infostealer logs, and abused VPN access. ClickFix social-engineering lures — which manipulate users into executing malicious commands — increased 517% year over year in the first half of 2025. 

Cloud and hybrid environments also became increasingly important targets. Campaigns associated with Silk Typhoon, attacks against cloud-based identity systems, and growing software supply-chain activity demonstrated how attackers were expanding beyond traditional infrastructure. 

Supply-chain ransomware followed the same trajectory. Cyble recorded a 93% increase in supply-chain attacks, from 154 incidents in 2024 to 297 in 2025. LockBit 5.0 emphasized third-party compromise, while activity associated with Qilin, SafePay (which claimed 58 victims in May 2025 alone), and DevMan demonstrated how IT providers and technology vendors can become pathways to multiple victims. 

Critical infrastructure also faced heightened pressure amid geopolitical tensions. Hacktivist campaigns targeted energy, transportation, and government systems, while the UAE reported successfully blocking a major cyberattack against critical infrastructure, and China accused Taiwan of targeted cyber intrusions. 

Meanwhile, underground ecosystems remained resilient. Forums including XSS, Exploit, and RAMP continued to support malware development, initial-access brokerage, affiliate recruitment, and the exchange of stolen data. The HelloKitty-to-HelloGookie transition provided another example of how underground communities support ransomware operations. 

Cyble’s Cyber Risk Quantification (CRQ) addresses the gap between technical severity and business impact. The cloud-native SaaS platform combines real-time threat intelligence, asset visibility, and predictive analytics to quantify cyber risk in financial terms, calculate Return on Security Investment (RoSI), and align security decisions with enterprise value. 

See how Cyble CRQ turns cyber exposure into financial insight. Discover your financial exposure now! 

What the CFO Needs to Know 

A CFO does not necessarily need another dashboard showing hundreds of vulnerabilities. The finance function needs to understand questions such as: 

• What could this threat cost? 

• Which business assets create the greatest financial exposure? 

• What is the likelihood of a loss event? 

• Which security control reduces the most risk? 

• How much would that control cost? 

• What is the expected return on the investment? 

That is where CRQ changes the conversation. Instead of reporting that a vulnerability is “critical,” security teams can model its potential effect on operations and financial performance. 
 
Recent incidents illustrate the stakes: Marks & Spencer estimated an impact of approximately £300 million on its 2025/26 annual profit from a single ransomware incident, and the Cyber Monitoring Centre assessed the combined losses for M&S and Co-op at £270 million to £440 million, excluding any ransom payments. Meanwhile, only 28% of victims paid a ransom in 2025 — down from 62.8% in 2024 — yet the median payment increased 368%, reflecting a shift toward higher-value, targeted demands. 

Cyble CRQ provides enterprise- and asset-level risk quantification, financial risk modeling, RoSI analysis, real-time dashboards, and operational metrics including MTTD, MTTN, MTTR, FPR, and IRR. Cyble's capabilities can help reduce breach containment time by up to 23%. The platform can also integrate with Cyble CSPM, Threat Intelligence, and Asset Management through APIs and real-time feeds. 

Its AI-driven risk engine ingests security and business data, evaluates potential loss scenarios, models the effect of different controls, and continuously updates exposure as conditions change. The result is a risk picture that both the CISO and CFO can interpret. 

The Executive Risk Equation 

Financial exposure is not limited to infrastructure. Executives themselves are increasingly valuable targets because compromising a trusted leader can provide access to sensitive information, systems, and relationships. 

Spear-phishing, executive impersonation, credential theft, dark-web exposure, and social engineering can create direct financial, regulatory, and reputational consequences. A compromised CFO account, for example, could be abused to distribute fraudulent financial information, while a compromised CEO identity could be used to manipulate employees, customers, or business partners. 

Cyble’s Executive Monitoring capability extends visibility into these risks by monitoring for impersonation, leaked information, dark web exposure, and emerging threats targeting organizational leadership. 

This becomes particularly important when executives operate outside the traditional corporate perimeter through personal devices, external platforms, social media, travel environments, and other channels. A mature risk strategy, therefore, needs to connect technology risk, human risk, and business impact. 

From Security Budget to Business Investment 

Cyble Saratoga takes this approach further by combining cyber risk quantification with investment optimization, human and process risk analysis, scalable assessment models, and executive-ready dashboards. Built on Cyble’s AI-native foundation and evolving toward agentic intelligence, the platform is designed to continuously adapt to changing environments and threat conditions. 

The objective is not simply to produce a better risk score. It helps organizations determine where to invest first and why. 

For financial services organizations, that can mean quantifying ransomware, fraud, credential compromise, and operational disruption. For manufacturing and supply chains, it can mean assessing third-party exposure and potential downtime. In 2025, manufacturing accounted for 65% of all industrial ransomware activity, with 1,660 victims, making it the most heavily targeted sector of the year.  

Healthcare organizations can evaluate risks to patient data and critical systems - 423 healthcare ransomware attacks were recorded in the first nine months of 2025, with average ransom demands of USD 514,000 to USD 532,000, while government and critical-infrastructure operators can translate complex cyber exposure into measurable financial and operational consequences. 

Conclusion 

Cyber risk is no longer a static “High, Medium, or Low” assessment—it is a dynamic business exposure that can directly impact revenue, operations, reputation, and resilience. With more than 80% of Cyble’s 2025 threat predictions materializing, organizations need to move beyond severity scores and understand what cyber risk could actually cost.  

Cyble CRQ helps security and finance leaders quantify cyber exposure in financial terms, prioritize the investments that matter most, and measure how effectively each security dollar reduces risk. 

Stop telling the board your cyber risk is “High.” Tell them what it could cost. 

Turn cyber risk into financial clarity with Cyble CRQ. Request a personalized demo today. 

References: 

• Cyble’s 2025 Threat Predictions Proven True—Here’s What We Expect for 2026 

• Medusa Ransomware Surge: 60 Victims in 3 Months—Are You Next? 

The post From ‘High/Medium/Low’ to Dollars: Making Cyber Risk Legible to Your CFO  appeared first on Cyble.

Ransomware rarely appears out of nowhere. Before encryption, extortion, or data theft begins, attackers often spend time establishing access, stealing credentials, moving laterally, and identifying valuable systems. These activities occur during the ransomware pre-execution phase, when malicious activity may be difficult to distinguish from legitimate administration. 

For security teams, understanding ransomware attack vectors, ransomware initial access methods, and how ransomware evades detection is critical. Endpoint security blind spots can give attackers the time they need to prepare an attack without triggering an obvious alarm. 

Here are five areas where ransomware activity can remain hidden before detonation. 

1. Remote Access Tools: A Favorite Ransomware Attack Vector 

VPNs, RDP, and remote management tools are essential for distributed organizations, but they are also among the most important ransomware attack vectors. 

Qilin affiliates have abused tools including WinSCP, AnyDesk, and ScreenConnect to facilitate lateral movement. Attackers who obtain valid credentials can potentially use legitimate remote-access software without immediately deploying obvious malware. 

This is one reason why ransomware evasion cannot be reduced to antivirus evasion alone. Attackers can blend into normal administrative activity. 

Organizations should enforce MFA on remote-access systems, monitor unusual login behavior, and restrict remote administration privileges. 

2. Compromised Endpoints and Credential Stores 

A compromised laptop or workstation may be only the beginning. Attackers can use credential-stealing tools to obtain additional passwords and authentication material, allowing them to move toward servers, backups, and privileged accounts. 

CRIL has tracked ransomware operators using credential-harvesting techniques associated with tools such as NirSoft and Mimikatz. BYOVD, or Bring Your Own Vulnerable Driver, is another technique security teams should monitor because vulnerable drivers can help attackers bypass security controls. 

These activities represent major endpoint security blind spots when organizations monitor servers but have limited visibility across employee workstations. 

EDR coverage across every endpoint can help identify unusual processes, credential access, and other indicators during the ransomware pre-execution phase. 

3. Vendor Connections and Supply Chain Access 

Manufacturers rarely operate alone. Suppliers, contractors, logistics providers, and software vendors can all connect to corporate environments. 

Attackers may compromise a smaller vendor with weaker defenses and use that trusted relationship to reach a larger target, a technique commonly known as island hopping. 

A shared credential, remote connection, vulnerable integration, or compromised software update can become one of the most dangerous ransomware initial access methods. 

Organizations therefore need visibility beyond their own infrastructure. Vendor access should be reviewed regularly, unnecessary connections should be removed, and third-party privileges should follow least-privilege principles. 

4. Operational Technology and Industrial Systems 

Manufacturing environments face additional endpoint security blind spots because operational technology (OT) and industrial control systems (ICS) often have long lifecycles and cannot be patched as easily as conventional computers. 

Many industrial systems were designed for reliability rather than modern cybersecurity requirements. Connecting previously isolated systems to corporate networks, cloud platforms and remote-management tools has expanded their attack surface. 

A ransomware attack affecting production systems can disrupt manufacturing lines, robotics, quality controls and logistics. Attackers can also steal product designs, supplier contracts, pricing information, and other intellectual property before encryption. 

Network segmentation, vulnerability monitoring, and strict access controls can reduce the risk while allowing production environments to remain operational. 

5. Phishing and Business Email Accounts 

Phishing remains one of the most effective ransomware initial access methods, but modern campaigns are often highly targeted. 

Attackers may research procurement, finance, and supplier relationships before sending messages that closely resemble legitimate business communications. Once credentials are stolen, attackers can monitor conversations before attempting fraud or using the account to gain further access. 

This activity can remain hidden because the attacker may initially use legitimate credentials rather than obviously malicious software. 

MFA, payment verification, email monitoring, and employee awareness training can reduce exposure. Security teams should also investigate unusual authentication patterns and unexpected account behavior. 

RaaS Makes Endpoint Blind Spots More Dangerous 

Ransomware-as-a-service has lowered the barrier for criminals seeking to conduct sophisticated attacks. Cyble identified 57 new ransomware groups and 27 new extortion groups in 2025, along with more than 350 new ransomware strains. 

Between January and April 2025, global ransomware incidents increased by 86%, with Cl0P accounting for 28% of activity during that period, according to Cyble. 

Double extortion has also become common. Attackers may steal data before encryption and threaten to leak it. Some groups have escalated to triple extortion by adding DDoS attacks or directly contacting victims' customers. 

For organizations with limited security resources, this makes early detection particularly important. 

Conclusion 

Effective ransomware defense starts before encryption begins. Organizations should patch exploited vulnerabilities, enforce MFA, segment networks, and maintain tested backups while continuously monitoring endpoint security blind spots.  

Cyble Titan Endpoint Security combines behavioral detection, threat intelligence from Cyble Vision, and Blaze-AI-powered autonomous response to detect and contain threats before they escalate. See Cyble Titan in action and strengthen endpoint protection today—request a demo. 

Frequently Asked Questions (FAQs)  

1. What are endpoint security blind spots? 

Endpoint security blind spots are areas where security teams have limited visibility into devices, applications, accounts, or activities. These gaps can allow attackers to establish access and move through an environment before ransomware is detected. 

2. How does ransomware evade detection? 
 
Ransomware can evade detection by using legitimate remote-access tools, stolen credentials, fileless techniques, and vulnerable drivers. Attackers may also remain inactive during the ransomware pre-execution phase to avoid triggering security alerts. 

3. What are common ransomware attack vectors? 

Common ransomware attack vectors include phishing emails, compromised credentials, vulnerable internet-facing systems, remote-access tools, third-party vendors, and exposed operational technology environments. 

4. How can organizations reduce ransomware risks on endpoints? 

Organizations can reduce risk by deploying EDR or advanced endpoint protection, enforcing MFA, applying least-privilege access, patching vulnerabilities, segmenting networks, and continuously monitoring endpoint activity. 

5. How can Cyble Titan help prevent ransomware attacks? 

Cyble Titan combines behavioral detection, next-generation antivirus, endpoint telemetry, and Cyble Vision cyber threat intelligence. Its Blaze AI engine can analyze threats, prioritize alerts, and support automated containment and remediation to help security teams respond faster. 

Media Disclaimer: This blog was compiled from publicly available advisories and open-source security reporting. It is provided for reference purposes only; readers bear full responsibility for their reliance on it. 

The post Endpoint Blind Spots: The 5 Places Ransomware Hides Before It Detonates appeared first on Cyble.

A company can have strong firewalls, modern endpoint protection, and carefully controlled access—and still find its brand being used as a weapon against customers, employees, and partners. 

That is the new reality of digital impersonation. Attackers can register lookalike domains, clone websites, create fake executive profiles, publish fraudulent job advertisements and imitate customer-support accounts without ever breaking into the legitimate organization. 

The objective is pretty simple. Borrow the credibility that a trusted brand has already built and use it to make a scam look legitimate. For professional services, financial, legal, and consulting organizations, that risk can be particularly damaging because trust is central to the business model. 

The Numbers Show Why Speed Matters 

The scale of digital fraud makes slow brand-abuse response difficult to justify. 

The FBI's 2025 Internet Crime Report recorded 1,008,597 complaints, marking the first time the Internet Crime Complaint Center (IC3) exceeded 1 million in a year. Reported losses reached $20.877 billion, up 26% from 2024. Phishing and spoofing were among the most frequently reported complaint types. 

Business email compromise was even more costly, producing approximately $3.05 billion in reported losses from 24,768 complaints. 

The Federal Trade Commission provides another measure of the impersonation problem. Consumers reported $3.5 billion in losses to imposter scams during 2025, with nearly one in three fraud reports involving impersonation. People reported losing nearly $1 billion to business impersonators alone. 

These figures represent reported losses, not the full economic impact. Fraudulent domains and profiles can disappear quickly, victims may never report incidents, and reputational damage is difficult to quantify. 

Professional Services Have More Than a Brand to Protect 

Consulting and professional services firms often handle sensitive client information, financial models, strategic plans, legal documents and confidential communications. That makes their identities valuable to criminals. 

The legal sector provides a useful comparison. The American Bar Association's cybersecurity research has previously found that 29% of surveyed lawyers reported that their firms had experienced a security breach. 

Impersonation adds another layer because the attacker may never enter the firm's network. A counterfeit website can steal credentials. A fake executive can request a payment. A fraudulent recruiter can collect applicant information. A fake support account can redirect customers to a malicious login page. 

The brand becomes the attack surface. 

Why Traditional Takedowns Become a Whack-a-Mole Exercise 

Conventional brand protection is often reactive. Someone discovers a suspicious domain, reports it to the registrar, contacts the hosting provider or social platform, and waits. 

That process can work—but it does not scale well against automated adversaries. 

By the time one fraudulent domain is removed, another may have appeared. A fake executive account can be recreated under a slightly different name. A phishing kit can be deployed against several brands simultaneously. Fraudsters can also move between websites, social networks, advertisements, application stores and messaging platforms. 

Counting the number of takedowns therefore tells only part of the story. A more meaningful measurement is the time from discovery to verification and from verification to removal. 

The shorter that window, the fewer opportunities an attacker has to reach victims. 

What AI Changes 

Artificial intelligence has made impersonation faster, cheaper, and more convincing. 

Attackers can generate polished phishing messages, translate campaigns for different markets, create synthetic personas, clone websites and produce increasingly convincing voice or video content. The FBI has also warned about scams involving AI-generated videos and spoofed websites used to create false legitimacy. 

Europol's 2025 Internet Organised Crime Threat Assessment similarly described a cybercrime economy increasingly powered by stolen data, which can support fraud, ransomware, extortion and other criminal activity. 

That means defenders face an uncomfortable imbalance: criminals can create fraudulent content almost instantly, while organizations may still investigate abuse manually. 

Brand security consequently must become faster without becoming careless. 

The Most Common Brand-Abuse Tactics 

Security teams should watch for a broad range of impersonation signals, including: 

• Typosquatting: domains using misspellings or visually similar characters. 

• Combosquatting: brand names combined with words such as “login,” “support” or “secure.” 

• Fake social profiles: cloned executive, employee, or company accounts. 

• Account takeovers: legitimate accounts hijacked and used to exploit an existing audience. 

• Cloned websites: replicas designed to collect credentials or payment information. 

• Fake mobile applications: counterfeit apps using familiar names, icons, or branding. 

• Fraudulent marketplace listings: fake products or services presented as legitimate. 

• Malicious QR codes: QR-based redirects leading victims to phishing infrastructure. 

• AI-generated impersonation: synthetic voices, images, video, and written communications. 

• Business email compromise: messages designed to trigger payments or sensitive disclosures. 

• Fake customer-support accounts: fraudulent profiles responding to real customer complaints. 

• Malicious search advertisements: paid placements directing users toward counterfeit sites. 

• Fake recruitment campaigns: fraudulent jobs used to collect personal or financial information. 

• Fake press releases: fabricated announcements intended to mislead customers, investors or the public. 

• Dark-web brand abuse: stolen credentials, data, and brand-specific fraud resources circulating in criminal communities. 

Conclusion 

Brand impersonation is no longer just a reputation issue—it can quickly become a pathway to phishing, fraud, credential theft, and customer harm. As AI enables attackers to create convincing fake websites, domains, social profiles, and campaigns at unprecedented speed, organizations need equally fast detection and response.  

Cyble’s brand monitoring and takedown services help organizations detect impersonation, validate malicious activity, and coordinate the removal of fraudulent assets before they can cause greater damage.  

With continuous visibility and managed takedown support, Cyble helps security teams stay protected from brand threats and protect customer trust.

See Cyble’s brand monitoring and takedown capabilities in action—request a demo today. 

Frequently Asked Questions (FAQs)  

1. What is brand impersonation in cybersecurity? 

Brand impersonation occurs when attackers imitate a legitimate company, executive, employee or digital channel to deceive customers, employees or business partners. Common examples include fake websites, lookalike domains, fraudulent social profiles, counterfeit applications and phishing emails. 

2. Why is AI making brand impersonation more dangerous? 

AI allows attackers to create convincing emails, websites, social profiles, synthetic identities, voice messages and other fraudulent content much faster and at greater scale. This makes it harder for organizations to rely on manual monitoring and reactive investigations. 

3. What brand impersonation tactics should security teams monitor? 

Security teams should monitor for typosquatting and lookalike domains, fake executive profiles, cloned websites, counterfeit apps, fraudulent job postings, fake customer-support accounts, malicious advertisements, phishing campaigns, AI-generated impersonation, and brand abuse on underground platforms. 

4. Why is rapid takedown important for brand protection? 

A fraudulent website or social profile can cause harm within minutes by stealing credentials, collecting personal information, or redirecting payments. Faster verification and takedown reduce the amount of time attackers have to reach potential victims. 

5. Can smaller and mid-sized organizations also be targeted? 

Yes. Attackers are not limited to globally recognized brands. Smaller and mid-sized organizations can also be attractive targets because they may have fewer resources dedicated to continuous brand monitoring and digital risk management. 

6. How can Cyble help with brand impersonation? 

Cyble’s brand monitoring and digital risk protection capabilities help organizations identify suspicious domains, fake profiles, fraudulent websites and other forms of digital brand abuse across the online ecosystem. By bringing detection and threat intelligence together, Cyble can help security teams investigate impersonation faster and take action before fraudulent assets cause greater damage. 

References 

• FBI 2025 Internet Crime Report 

• FTC Data Show People Reported Losing $3.5 Billion to Imposter Scams in 2025 

Media Disclaimer: This blog was compiled from publicly available government advisories and open-source security reporting. It is provided for reference purposes only; readers bear full responsibility for their reliance on it. 

The post When the Attacker Wears Your Logo: Detecting and Taking Down Impersonation at AI Speed appeared first on Cyble.