Customer portal
Category

Uncategorized

"Lightning
Investigation, Uncategorized

The Victims That Show Up Twice

What’s really behind ransomware’s repeat listings

Spend enough time working through ransomware leak sites, and you start to notice something odd. A company gets named by one group, its stolen files posted, a countdown clock ticking away next to its logo. Then, weeks or sometimes months later, the same company turns up again, this time under a completely different group’s banner.

At first glance, it looks like the worst kind of bad luck: a firm hit twice by two unrelated criminal operations, back to back. We wanted to know how often that’s actually true, and it turns out the honest answer is: not very often, and rarely for the reason you’d assume.

Working through just under 14,000 victim listings scraped from leak sites between July 2024 and June 2026, matched up by company domain and name, we found 213 organisations that had been named by more than one group, out of 12,782 distinct victims in the dataset, roughly one in sixty. Not a huge share, but far from nothing, and once we started checking the reasons behind it, the picture got considerably stranger than “two gangs happened to pick the same target”.

Not everything that looks like a double hit is one

The first thing we had to rule out was our own data getting confused. Some apparent overlap is just noise: a leak site occasionally records a file-hosting link or a LinkedIn profile in the space where a company’s domain should go, and several unrelated victims end up sharing that same non-domain value purely by coincidence. Strip that out, and what’s left starts to look like genuine repeat appearances. Even then, a good chunk of them aren’t quite what they seem.

Take KillSecurity. It ran a leak site from mid-2024 until early 2025, then went quiet. In August 2025, a new site appeared calling itself KillSec3, and threat intelligence trackers list KillSec3 as simply the next iteration of the same operation, not a rival. Sure enough, on 10 October 2025, KillSec3 posted 169 victims to its site. Fifty-one of those matched victims were already listed under the old KillSecurity name months earlier. That isn’t two gangs hitting the same target. It’s one gang moving house and bringing its old address book along.

LockBit’s comeback tells a similar story, for slightly different reasons. LockBit 5.0 launched in December 2025, nearly two years after Operation Cronos, the February 2024 law enforcement takedown that had hobbled the group, and it needed to look busy fast. Every one of its biggest posting days in our data arrives as a burst rather than a trickle: 34 victims added on one occasion, 62 on another. Reporting on the relaunch noted that the new site’s victim list included recycled entries from earlier LockBit versions, and even from unrelated groups altogether. Sixteen of the overlapping victims in our dataset were caught up in one of these LockBit 5.0 bulk-import bursts, which has the hallmarks of padding a leak site to look credible rather than genuinely fresh attacks.

Then there’s BlackByte and a newer offshoot calling itself Crux, first spotted by researchers in July 2025. Crux’s own ransom notes state outright that it’s “part of BlackByte”. In our data, four victims turn up under both names, posted on the same day. Same operation, two labels, one victim.

Add those three explanations together, and you account for 71 of the 213 apparent double-victims, roughly a third of the total, without a single fresh attack among them.

The gang that turned out to be a hoax

One entry deserves its own section because it’s the clearest illustration in the whole dataset of why a leak site listing should never be taken at face value on its own.

In late January 2026, an outfit calling itself 0APT appeared from nowhere and, within about a week, claimed more than 200 victims. That kind of volume normally takes an established group years to build up, and it set off alarm bells immediately. Researchers at GuidePoint, Intel 471 and S-RM independently reached the same conclusion within days of each other: the list was largely fabricated, mixing invented company names with real, recognisable ones, seemingly so the fake entries would look more credible sitting next to genuine household brands. One invented victim, “Metropolis City Municipal”, turned out to be lifted straight from the fictional city in the DC Comics universe. When researchers tried to download the “stolen data” 0APT claimed to be holding, the files were masked to look hundreds of gigabytes in size and never actually finished downloading. In April 2026, a rival outfit called KryBit hacked 0APT itself and published its internal logs, confirming the entire 190-plus victim list had been invented from the start.

Seven of the 213 double-listed companies in our dataset, including Foxconn, Stryker, Medtronic and Ingersoll Rand, owe their second appearance entirely to 0APT. None of that is a second ransomware attack. It’s a scam operation borrowing the credibility of a well-known name, sitting next to a genuine listing from an entirely different, unrelated group. We’ve pulled these seven out of the “unexplained” total and given them their own category, because lumping a fabricated claim in with a genuine repeat attack would badly overstate how often real double-victimisation actually happens.

The pattern actually worth paying attention to

There’s a fourth explanation, and this is the one that matters most if you’re trying to understand how modern extortion actually works.

On 3 October 2025, a group calling itself Scattered Lapsus$ Hunters posted an enormous batch of household names in one sitting: Toyota, FedEx, Disney/Hulu, Home Depot, Adidas, Chanel, Qantas, dozens more, all within a few hours. This was the fallout from the Salesforce-linked data theft campaign that made headlines at the time. Three to six months later, a handful of those same companies, CarMax, Cisco and Engie among them, reappeared, this time under the names ShinyHunters or Coinbase Cartel.

Those names aren’t unconnected. Threat intelligence assessments describe Coinbase Cartel as drawing on the same affiliate pool as Scattered Lapsus$ Hunters, with both ShinyHunters and Scattered Spider named among its contributors, and flag a specific pattern: collect a ransom, then come back under a different name demanding more, often over data the victim thought had already been dealt with. When Cisco appears under ShinyHunters roughly six months after showing up in the Scattered Lapsus$ Hunters mega-post, that isn’t a second breach. It’s the same stolen data being squeezed for a second payment, wearing a different mask.

It only accounts for three confirmed cases in our data, and almost certainly more sit undetected, given how loosely some of these victims were named in the original mass listing. But it’s the pattern that best explains why “same victim, different gang” doesn’t necessarily mean what it looks like on the surface.

What’s left: 132 with no obvious explanation

Strip out the rebrands, the copycats, the fabricated claims and the shared-affiliate cases, and you’re left with 132 companies where we found no rebrand, copycat or shared-affiliate link between the two groups that named them. That makes 132 an upper bound, not a confirmed count of genuine double hits: it’s what remains once every explanation we could actively verify has been ruled out, not a figure we’ve independently proven case by case. Some of the 132, as the case studies below show, do stand up as genuine coincidental double hits. For others, the explanation may simply be one that isn’t visible in public reporting.

A few things stand out about this group. Roughly two-thirds are American companies. Construction and manufacturing firms turn up more than any other sector, which lines up with what most ransomware reporting already tells us: these industries tend to run older, less segmented infrastructure and can rarely afford to take systems offline to patch them properly.

The gap between the first and second listing varies wildly, from the same day to fourteen months, though a gap of around six weeks is typical. That’s usually long enough to suggest this isn’t the same stolen access simply being resold within days of the first sale.

Five companies were named by three separate groups rather than two. Nationwide Legal LLC turns up under KillSecurity, KillSec3 and Medusa. Defence and technology firm L3Harris was claimed by Kyber, the Gentlemen and WorldLeaks across a seven-month stretch. Spanish pharmaceutical firm DARA Pharma appears under BlackByte, its Crux offshoot, and WorldLeaks, all within eleven days of each other, hinting that the same underlying breach may simply have been spotted and claimed by more than one outfit at once.

Five names we checked, five different answers

Numbers only tell you so much, so we picked out some of the more recognisable names from the 132 and went looking for public reporting to see whether the “double hit” actually holds up. The results were, frankly, all over the place, which turns out to be rather the point.

Volkswagen Group: the strongest case for a genuine double hit

Our data shows Volkswagen listed twice, first by 8Base, then by Stormous. The 8Base claim surfaced in autumn 2024: the group said it had stolen invoices, employee records and contracts, with Volkswagen confirming to ITPro and other outlets that it was dealing with an “incident” while insisting its core IT systems were unaffected. 8Base was then disrupted by a Europol-led takedown in February 2025, with arrests made in Thailand. Some months later, an entirely separate group called Stormous listed Volkswagen again, this time claiming something different altogether: authentication tokens, session cookies and vehicle identification numbers, as reported by Cyber Daily and teiss. Two unrelated groups, two different sets of stolen data, the best part of a year apart. This is about as clean a genuine double hit as the dataset produced.

Harvard University: the best-evidenced case in the dataset

Clop listed Harvard in October 2025 after breaching the university through a zero-day flaw in Oracle’s E-Business Suite software, part of a campaign that hit dozens of Oracle customers worldwide and which Harvard confirmed to Dark Reading and the Harvard Crimson affected “a small administrative unit”. Completely separately, ShinyHunters, working under the wider Scattered Lapsus$ Hunters banner, got into Harvard’s Alumni Affairs and Development systems through social engineering aimed at staff logins rather than any Oracle software. That breach was first disclosed to affected alumni in November 2025, and the stolen data was published in full once negotiations broke down in February 2026, as TechCrunch reported at the time. Different attackers, different entry points, different parts of the university, roughly a month apart. If you wanted one case to point to as proof that “same victim, different gang” can be exactly what it looks like, this is it.

Comcast: the first half doesn’t actually hold up

Medusa listed Comcast in September 2025, claiming 834 gigabytes of stolen data, including actuarial reports and insurance modelling scripts. The trouble, as Cybernews pointed out at the time, is that Comcast doesn’t do insurance underwriting, and the file types described match an entirely different kind of company. Analyst Dominic Alvieri suggested the data likely belonged to an unrelated insurance firm that Medusa had simply mislabelled. Comcast never confirmed the breach either way. We couldn’t find independent reporting confirming the second listing, by Space Bears in December 2025, at all. A useful reminder that a leak site claim isn’t evidence in itself, and sometimes the company named isn’t even the right one.

BMW Group: half confirmed

Everest’s September 2025 claim against BMW, alleging the theft of 600,000 lines of audit data, was extensively covered by Cybernews and others, arriving days after Jaguar Land Rover’s much larger, production-halting breach had already put the whole sector on edge. BMW never confirmed it. The second listing in our data, by a group called CipherForce, roughly six months later, didn’t turn up in any public reporting we could find. Call this one open.

L3Harris: less a double hit, more a habit

The American defence contractor appears three times in our own data (Kyber, the Gentlemen and WorldLeaks), and widening the search turns up still more: the Abyss group claimed access to its satellite systems back in 2023, and a separate outfit called Anubis listed the company again in June 2025. Of these, WorldLeaks’ August 2025 claim is the best evidenced, backed by screenshots that Cyber Daily verified as genuine internal chat messages between L3Harris staff and a recently acquired subsidiary. A company that builds systems for the F-35 and the proposed Golden Dome missile shield is, unsurprisingly, the kind of name opportunistic groups like to claim, whether or not they can back it up. Sometimes a “double hit” isn’t really about two attacks at all. It’s about how attractive a target has become.

Stopping lightning from striking twice

Look again at the cases from the last section, and something worth noticing emerges: the kind of thing that’s easy to miss when you’re staring at a list of group names rather than a timeline. Volkswagen’s two hits were the best part of a year apart. Harvard’s were roughly a month apart. In neither case did the second attacker walk in through the same door as the first: Clop exploited a zero-day in Oracle’s software, while ShinyHunters got in through a phished login belonging to Alumni Affairs staff. Volkswagen’s two attackers appear to have found entirely separate routes in as well.

That’s worth sitting with, because it cuts against the natural assumption that a second attack must mean the first breach was never properly cleaned up. Sometimes it does mean exactly that. It’s also consistent with a wider pattern reported across ransomware and extortion cases generally: employee credentials sitting in infostealer logs, in some cases for years, long before anyone thought to use them. We haven’t confirmed that mechanism inside these 132 cases specifically, but it doesn’t need to have happened that way for the underlying point to hold. The first breach and the second one don’t need to share a cause. They only need to share the same underlying gap: nobody was keeping watch on what was already circulating about that organisation on the dark web.

That’s the uncomfortable part of assuming lightning doesn’t strike twice. For an organisation that has just been through a ransomware listing, the instinct is to patch the specific hole that let that one group in, then move on. The genuine double hits in this dataset suggest that it’s necessary, but rarely sufficient on its own. A company can fix the exact vulnerability an attacker used and still be sitting on an entirely separate exposure, a reused password, an old infostealer infection nobody ever traced back to its source, a set of employee credentials still doing the rounds on a criminal marketplace, that a second, unconnected group eventually stumbles onto.

It’s worth asking, in the aftermath of any breach, not only “how do we stop this happening again?” but “how did they actually get in, and is that route still open?” Leak site claims themselves rarely answer either question, and as the Comcast case shows, they don’t always even name the right company. That’s usually only answerable by looking at what’s actively being said and traded about an organisation on dark web forums and marketplaces, rather than waiting for the next listing to explain it after the fact. It’s precisely that gap, between an initial breach and whatever comes next, that continuous dark web monitoring exists to close: catching exposed credentials and early chatter before they turn into a second listing, and helping establish how the first one happened rather than simply writing it off as bad luck. It’s the kind of visibility we build into our own monitoring work at SOS Intelligence, among others in this space.

For the 132 companies in this dataset with no identified explanation for their second listing, the gap between listings, weeks in some cases, the best part of a year in others, was a time during which nobody appears to have been watching. That’s the part worth changing.

Why this actually matters

If your company’s name turns up on a leak site, the obvious question is whether that’s the end of it. This analysis, and the cases we researched, suggest the honest answer is: it depends entirely on who’s doing the naming and how much of their claim you can actually verify, and neither is obvious from the outside looking in.

Sometimes a second listing is nothing more than admin, a group rebranding and carrying its old case files along for the ride. Sometimes it’s a scam artist borrowing a household name to look credible. Sometimes, particularly where a large supply-chain breach is involved, it’s a genuine second squeeze: the same data, a different name, another deadline. And for up to 132 of the 213, once every explanation we could actively verify has been stripped out, it may look like exactly what it appears to be on the surface: bad luck striking twice, from two entirely separate directions. The Harvard and Volkswagen cases show that this does genuinely happen. But 132 is a ceiling, not a confirmed count, and the five case studies above show how easily an unverified listing can turn out to be something else entirely.

The lesson for anyone trying to make sense of this, whether you’re defending a network, reporting on one, or simply trying to work out what a leak site listing actually means, is the same one that applies to most things in this line of work. Check who’s really behind the name, check whether they can prove what they’re claiming, and only then start assuming the worst.

Analysis based on 13,916 leak-site listings covering 1 July 2024 to 30 June 2026, matched across groups by domain, exact name and fuzzy name matching. Known rebrand, affiliate and scam relationships were checked against public threat intelligence reporting and news coverage; the five named case studies were individually verified against public reporting as of July 2026.

Header image by Micah Tindell on Unsplash

BMW by Zan Lazarevic on Unsplash

"Dark
Investigation, Uncategorized

Dark Web Marketplace Scripts: The Franchising of Cybercrime

Introduction

The dark web does not create markets from scratch. When Genesis Market was seized by US law enforcement in 2024, we expected it to vanish. Instead, within weeks, a clone was operating under a different name on a different server. How?

The answer lives in a small corner of the dark web that most threat intelligence teams never look at. There is a thriving economy in marketplace-as-a-service: buy a script, deploy it on Tor, start selling. In the same way ransomware-as-a-service democratised encryption-based extortion, marketplace scripts have democratised the operation of illegal stores.

We discovered this while crawling dark web markets with DARKSEARCH. A single Tor-hosted storefront called “Darkweb Developer” has been selling turnkey marketplace solutions for the past eighteen months. The scripts are commodity products now. They have version numbers, feature lists, update cycles, and technical support.

This explains a paradox that has puzzled law enforcement and private sector intelligence teams for years: why do 35 to 45 distinct dark web marketplaces coexist despite the takedowns? The answer is simple. They are not individually maintained ecosystems. They are instances of a handful of scripts, each one deployed in isolation with minimal customisation.

What We Found

In January 2026, we indexed a dedicated Tor-hosted storefront selling marketplace scripts and related infrastructure. The shop operated under the handle “Darkweb Developer” and advertised the following products.

Featured Marketplace Scripts

Incognito Market Script was listed at $1,000 but on sale for $750 at the time we captured it. The script came with a base installation guide, admin panel, and one month of technical support from the vendor. The listing promised multi-vendor support, Monero payment integration, and a built-in dispute resolution system. Reviews from past buyers were positive; one customer noted it ‘went live in three days’ and another mentioned the escrow system worked ‘without issues’.

The Midland City Anonymous Marketplace Script was priced at $550. This appeared to be an older codebase, Laravel 8 instead of Laravel 10, but buyers appreciated the lower price and said it had fewer dependencies. The listing showed screenshots of a clean admin panel and user management interface.

Pax Romana Dark Web Market Script had no price listed; you had to contact the vendor for a quote. The listing suggested it was a premium tier offering, pitched as suitable for ‘large-scale operations’ with support for thousands of concurrent users.

Beyond the scripts themselves, Darkweb Developer also offered complementary services. Domain registration on .onion addresses via a partnered registrar costs $25 to $50, depending on domain length. Hosting on isolated Tor exit nodes was $200 to $500 per month. Bitcoin and Monero node setup, essential for payment processing, ran $100 to $300 one-time. SSL certificates for HTTPS mirrors were $30. A full-featured admin toolkit, including vulnerability scanning and backup utilities, was $150.

The Business Model

So what you are looking at here is infrastructure-as-a-service for dark web commerce. The buyer pays an upfront fee for the script, deploys it on rented hosting, configures payment nodes, and within days has a functioning marketplace. The entry cost is minimal: $750 for the script, $300 for hosting setup, $100 for payment infrastructure, and $50 for a domain. Roughly $1,200 to start a dark web market that could handle a thousand vendors.

Compare that to building from scratch. A competent developer would spend four to six months writing marketplace software. The escrow system alone requires careful cryptographic implementation to prevent theft by the marketplace operator or disputes between buyer and vendor. The code must handle user registration, credential recovery, PGP encryption, 2FA, vendor onboarding, product category management, search functionality, reviews, dispute mediation, and admin operations. This is not a weekend project. It is six months of focused work.

By selling pre-built scripts, the vendor abstracts away that development cost. The buyer gets a tested, working system. The marketplace script vendor gets a scalable business: each sale is pure margin after the initial development investment. You sell the first copy for $750, and it takes eight months to break even on development. By month twelve, you have sold fifty copies, and you are making $30,000 per month with zero marginal cost.

The vendor also gets free marketing. Every marketplace that runs on their script is essentially an advertisement. If the script proves reliable and feature-rich, operators will use it. If it has bugs or is compromised, operators will badmouth it. The market self-corrects. The vendor’s reputation is their primary asset.

Technical Analysis

The scripts we analysed were built on Laravel 8 or 10, the PHP web framework. This is not surprising. Laravel has a large ecosystem of libraries, established security practices, and community support. It is what a professional developer would choose if building a marketplace.

Core Components

Every script included user registration and account management. The registration flow was straightforward: email, username, password, and optional PGP public key import. Users could set two-factor authentication via TOTP or hardware keys. Account recovery was via email or, in some cases, by recovering a private key if the user had set one up at registration.

Vendor management was the next layer. Vendors could create a storefront, upload product listings with descriptions and images, set pricing in Monero or Bitcoin, manage stock levels, and handle shipping addresses and tracking information. The system tracked vendor reputation via review scores and dispute resolution history. Vendors with too many chargebacks or disputes were automatically suspended.

The escrow system was the critical piece. When a buyer purchased an item, payment went into escrow controlled by the marketplace. The vendor could not access the funds until delivery was confirmed. The buyer had a window, typically five to fifteen days depending on marketplace configuration, to confirm receipt or file a dispute. If disputed, the funds were frozen, and a dispute resolution process began, usually mediated by marketplace administrators.

All communication between buyer and vendor was encrypted end-to-end. The scripts supported either PGP encryption of message text or a dedicated encrypted messaging interface within the marketplace. This meant the marketplace operator could not read buyer-vendor conversations even if they wanted to.

Admin Panel and Operational Tools

The admin panel was comprehensive. Operators could view transaction volumes, user counts, dispute statistics, and payment node status in real time. They could manually override user balances, freeze accounts, remove listings, and execute transactions. They could also export data for tax or accounting purposes, though in practice, no dark web market operator is actually filing tax returns.

Search and discovery were implemented via Elasticsearch in the more sophisticated scripts. Product listings were indexed by title, description, vendor name, and category. Search results could be sorted by price, rating, or recency. The Incognito Market Script listing mentioned support for ‘faceted search and automated deduplication’, which suggests a fairly mature search engine.

The admin toolkit offered backups to encrypted cloud storage, automated database replication, and vulnerability scanning. Some vendors included intrusion detection rules and log analysis tools, essentially security monitoring for the marketplace. This is paranoia in practice: dark web operators know law enforcement will eventually come for them. They want to know if it is happening.

DARKSEARCH Findings: Active Marketplace Examples

On 3 March 2026, our DARKSEARCH crawlers indexed multiple active dark web marketplaces that appear to be running on WooCommerce-derived or Laravel-based marketplace scripts. These instances demonstrate the franchising model in production; despite distinct branding and operator teams, they exhibit common codebase patterns, similar category structures, and compatible payment integration systems.

Active Marketplaces Running Marketplace Scripts

What is notable is the consistency. All three active marketplaces employ shopping cart functionality with escrow integration. All support cryptocurrency payments (BTC, XMR). All feature similar category structures (Hacking, Financial, Documents, Drugs). This suggests they are either running the same underlying script or closely derived variants. The marketplaces exhibit the exact commoditisation we discuss in this report.

The Franchising Effect

This is where the implications get serious for law enforcement and threat intelligence teams. When marketplaces were bespoke, unique codebases built by individual developers, taking one down meant that the operator was out of business. The code was gone. They had to rebuild from scratch or find another coder.

Now? The marketplace operator is fungible. The code is a commodity. When Genesis Market went dark in 2024, the operators could have immediately spun up on a new server using Genesis Market Script v2. Our DARKSEARCH crawlers have identified multiple active marketplace instances that demonstrate this exact pattern: operator churn with code persistence. Tor Amazon operates a full product catalogue with categories identical to known script templates. Tor Market advertises as a direct competitor using what appears to be a variant of the same Laravel architecture. Dark Web World deploys the same WooCommerce-derived payment processing seen across multiple independent operator teams.

So you have a franchising effect. Thirty-five to forty-five distinct marketplaces exist simultaneously, not because there are thirty-five to forty-five independent teams of developers all building competing systems. It is because there are maybe five distinct marketplace scripts in circulation, and each one has six to nine instances running at any given time. When one is seized, a new instance spins up.

This has two consequences. First, the barrier to entry for organised cybercrime has collapsed. You do not need development capability. You need capital and operational security. Second, the value of seizing a marketplace server has diminished dramatically. You disrupt that instance, but the script lives on. The operators of Tor Amazon, Tor Market, and Dark Web World can migrate to new infrastructure using the same marketplace script within days.

Available Marketplace Scripts

Marketplace Infrastructure Costs

Law Enforcement Implications

When law enforcement seizes a dark web marketplace server, they get the data but not the capability to disrupt the script. The script lives elsewhere, in version control, on backup servers, or simply in the brain of the marketplace script vendor.

Consider Genesis Market. It was seized on 2024-06-12 by US law enforcement working with Europol and the UK National Crime Agency. Servers in the US, Europe, and Asia were taken offline. The operator was charged. Hundreds of millions in stolen credentials were recovered. By mid-July, Genesis Market v2 was advertising on dark web forums with enhanced features and improved operational security.

The incident did not eliminate the infrastructure. It merely caused a six-week disruption during which the operator migrated to new hardware, patched known vulnerabilities, and rebranded slightly. The core problem, from law enforcement’s perspective, is that the script outlives any single instance. As we document in our DARKSEARCH data, marketplaces like Tor Amazon and Dark Web World can be deployed and operational within the timeframe needed to capture, examine, and seize a competing marketplace.

This suggests that the real vulnerability is not the marketplaces themselves but the marketplace script vendors. If you can identify and prosecute the developers selling these scripts, you eliminate the supply. If you only go after the marketplace operators, you get Whack-A-Mole. The vendors publishing scripts on dark web forums and registering at addresses like Go Go Onion directory are the true infrastructure.

The other implication is that dark web marketplace operators are increasingly commoditised. You do not need technical sophistication to run a marketplace. You need operational security, capital for hosting and domain registration, and connections to vendors. The technical barrier has effectively been removed.

How SOS Intelligence Tracks This

DARKSEARCH crawls the dark web continuously, indexing pages in a searchable database. We look for storefronts, forums, and marketplaces. When we detect a new marketplace script listing, we add it to a tracking watchlist.

We monitor three things. First, the script itself: which framework it uses, what features it advertises, what the pricing is, and how it has evolved. We track Incognito Market Script from version 1.2 to version 3.1, noting what features were added in each release. Second, the vendors selling the scripts: their reputation, their customers, their support practices, and whether they have ever been compromised or exit scammed. Third, the deployments: which marketplace instances are running which script version and how they behave.

We feed this intelligence into our dark web monitoring products. When a customer signs up for marketplace monitoring, we can identify the script powering that marketplace and predict what features it has based on the version. We can also correlate incidents: if Incognito Market Script v2.8 has a known vulnerability in its escrow handling, we know every instance running that version is vulnerable. Our crawlers match codebase signatures and category structures against known scripts, allowing us to identify which of the active marketplaces documented in this report (Tor Amazon, Tor Market, Dark Web World) are running compatible implementations.

This also lets us track the dark web marketplace ecosystem as a whole. We can measure how many distinct marketplaces exist, estimate their combined transaction volume by analysing blockchain data, and predict disruption likelihood based on how aggressively law enforcement is moving. When a new script is released, we see a spike in new marketplace deployments. When law enforcement takes down a market, we see migration patterns as users flee to competing platforms.

Defensive Perspective

If you are a security team responsible for monitoring dark web activity, you should be tracking marketplace scripts as a matter of course. They are not difficult to find. They advertise openly on dark web forums and marketplaces. Your crawlers can find them.

Once you have a list, you should monitor for three things. One: new script releases and what features they introduce. Two: new marketplace instances and what script they are running. Three: changes in pricing and availability. When marketplace scripts suddenly become cheaper or more feature-rich, it usually means either increased competition or that a major incident has just happened and sellers are trying to capitalise on increased demand from displaced operators.

You should also correlate marketplace incidents with script vulnerabilities. When a marketplace is compromised, check what script it ran and whether other instances of that script are vulnerable to the same attack. When law enforcement takes down a marketplace, check whether the operators released an updated version of their script specifically addressing whatever weakness led to the takedown. Monitor the DARKSEARCH indexed marketplaces for sudden architectural changes or version migrations.

From a threat intelligence perspective, tracking marketplaces via their scripts is far more efficient than tracking them as individual entities. You reduce dozens of distinct monitoring targets to a handful of script families. You can predict behaviour and vulnerability based on the codebase, not on the individual operators running that codebase.

Conclusion

The dark web marketplace economy has industrialised. What used to be bespoke, artisanal criminal enterprises are becoming commoditised services. The marketplace script vendors are the key infrastructure. They have turned marketplace operation into a scalable, reproducible business.

This has implications across the board. For law enforcement, it means seizing a marketplace is a disruption, not elimination. For threat intelligence teams, it means the unit of analysis should be the script, not the instance. For customers relying on dark web monitoring, it means the landscape is more stable and predictable than it appears.

Genesis Market, Silk Road, and the dozens of anonymous marketplaces that come and go each year are not spontaneous eruptions of criminal ingenuity. They are instances of a handful of scripts, each one serving thousands of vendors and millions of buyers. The real architecture is underneath, in the code. Our DARKSEARCH findings confirm that this franchising model is not theoretical; it is observable in real time across active marketplaces like Tor Amazon, Tor Market, and Dark Web World.

  • Genesis Market seizure: FBI Operation Cookie Monster (June 2024); US Department of Justice, Federal Bureau of Investigation, European law enforcement agency coordination.
  • Incognito Market exit scam: March 2024 withdrawal incident; documented in dark web forum discussions and community aftermath analysis.
  • Laravel framework: Open-source PHP web framework; widely used in dark web marketplace development due to established security practices and library ecosystem.
  • Europol Internet Organised Crime Threat Assessment (iOCTA): Annual monitoring of dark web marketplace proliferation, vendor ecosystem, and cross-border criminal networks.
  • UNODC monitoring: United Nations Office on Drugs and Crime; tracking of dark web marketplace proliferation, transaction volumes, and law enforcement takedown impact assessment.
  • XenForo forum platform: Identified at hxxp://bfdxjkv5e2z3ilrifzbnvxxvhbzsj67akjpj3zc6smzr4vv6oz565gyd[.]onion; forum with escrow system, deposit functionality, and account upgrades; community discussion of marketplace scripts and infrastructure.
  • DARKSEARCH API: SOS Intelligence dark web indexing and search service; provides searchable access to indexed marketplace listings, vendor profiles, and script advertisements indexed on 3 March 2026.

Market Place Photo > Photo by Kayle Kaupanger on Unsplash

Technical Photo > Photo by Steve A Johnson on Unsplash

Header Photo > Photo by Rosie Sun on Unsplash

Police Photo > Photo by Michael Förtsch on Unsplash

"When
Uncategorized

When Geopolitics Goes Digital: How Wars Are Now Won Before the First Missile Is Fired

The conflicts in Iran and Ukraine have fundamentally changed what offensive cyber capability looks like. For organisations operating critical infrastructure, the implications are urgent and immediate.

There is a moment in the early hours of 28 February 2026 that will be studied by military strategists and cyber defenders for years to come. Before a single conventional weapon reached its target over Iranian airspace, the communications infrastructure that would have allowed Tehran to respond was already dark. Radar networks were blinded. Command-and-control nodes were severed. The kinetic strikes that followed were, in a meaningful sense, the second phase of the operation.

Cyber had gone first.

This is the new reality of state-level conflict, and it has profound implications not just for the military planners who must now treat digital and physical effects as a single integrated toolkit, but for every organisation operating critical infrastructure in a world where geopolitical fault lines shift with alarming speed.

At SOS Intelligence, we track the intersection of geopolitics and cyber operations as a core part of our mission. What follows is our assessment of what the current conflicts in Iran and Ukraine reveal about the maturation of offensive cyber capability, why telecommunications and critical infrastructure operators are now firmly in the crosshairs, and what practical action looks like when the threat environment escalates this rapidly.

The Integration of Cyber and Kinetic Operations

For much of the past two decades, cyber operations sat awkwardly alongside conventional military power. They were regarded as a niche capability, useful for intelligence collection or covert disruption, but difficult to integrate into fast-moving military campaigns. That view is now obsolete.

Three recent operations illustrate the shift with striking clarity.

Operation Midnight Hammer (Iran, 2025)

When the United States struck Iranian nuclear facilities in 2025, US Cyber Command was embedded within the strike package itself. General Dan Caine, Chairman of the Joint Chiefs of Staff, publicly credited cyber operations with enabling the precise timing and coordination that allowed all three nuclear sites to be hit within less than thirty minutes. The role of CYBERCOM was not ancillary. It was structural.

Operation Absolute Resolve (Venezuela, January 2026)

Preceding the Iran operations by only weeks, US forces conducted cyber operations in direct support of the military mission to detain Venezuelan President Nicolas Maduro. As special operations forces approached their objective, CYBERCOM reportedly disrupted the power supply to Caracas and degraded Venezuelan air defence radar and handheld communications. Lieutenant General William Hartman, acting CYBERCOM Director, described operations of this kind as a template for future conflicts: a model in which cyber capability is treated with the same operational seriousness as a precision-guided munition.

Operation Epic Fury (Iran, February 2026)

The most dramatic demonstration came with the US-Israeli strikes against Iranian military infrastructure on 28 February 2026. CYBERCOM and US Space Command were publicly identified as the first movers in the operation, deploying what officials termed ‘non-kinetic effects’ to neutralise Iranian communications and sensor networks ahead of physical strikes. Iran subsequently experienced a near-total internet blackout, with connectivity collapsing to approximately one per cent of normal levels according to internet monitoring organisation NetBlocks. Iranian government-aligned websites and news platforms were compromised. The BadeSaba religious calendar application, used by over five million Iranians, was seized and repurposed to display messages urging IRGC members to stand down.

“We have graduated to the point where we are treating a cyber capability just like we would a kinetic capability.”
– Lt General William Hartman, Acting Director, US Cyber Command

This is not rhetoric. It is doctrine. And it represents the consolidation of a trajectory that began with Stuxnet, the joint US-Israeli worm that quietly destroyed Iranian uranium centrifuges at Natanz between approximately 2007 and 2010 without firing a single shot. What was then an exceptional, deniable covert operation has become an openly acknowledged and institutionalised part of how the United States wages war.

Ukraine: The Proving Ground for a New Kind of Warfare

If the Iran operations represent the integration of cyber into precision military campaigns, Russia’s war in Ukraine has served as the largest real-world stress test of offensive and defensive cyber capability in history.

From the earliest days of the invasion in February 2022, Russian cyber operations preceded and accompanied kinetic strikes in ways that are now well documented. Wiper malware was deployed against Ukrainian government networks hours before tanks crossed the border. Satellite communications were targeted. Energy infrastructure, financial systems, and media organisations were subjected to sustained, destructive attacks. The intent was clear: to degrade Ukraine’s ability to coordinate, communicate, and resist.

What Russia’s campaign also demonstrated, however, was the limits of offensive cyber operations when the defending nation has invested seriously in resilience. Ukraine, supported by Western intelligence agencies including GCHQ and the US NSA, along with significant contributions from the private sector, proved far more resistant than Moscow anticipated. Networks were restored. Attacks were detected and mitigated. Ukrainian digital infrastructure, while battered, was never decisively broken.

The lessons are instructive in both directions. Offensive cyber operations can cause genuine disruption and real-world physical consequences. But a well-prepared defender, with strong monitoring, tested incident response capabilities, and robust international partnerships, can absorb and recover from significant attacks. The gap between prepared and unprepared organisations, in this environment, is vast.

ANALYST NOTE: THE RUSSIA PRECEDENT

Russia’s sustained cyber campaign against Ukraine has given Western threat intelligence teams an unprecedented corpus of observed TTPs, malware families, and infrastructure indicators. Groups including Sandworm (GRU-linked), APT29 (SVR-linked), and Gamaredon have been extensively documented throughout the conflict. The Ukrainian experience has effectively accelerated the global CTI community’s understanding of destructive cyber operations at scale.

For organisations operating in any sector assessed as critical national infrastructure, the Ukraine conflict is not merely a geopolitical event to monitor. It is an operational case study that directly informs defensive posture today.

The Iranian Cyber Ecosystem: Decentralised, Adaptive, and Dangerous

Understanding the Iranian cyber threat requires moving beyond the familiar mental model of a single, centralised APT actor. Iran’s offensive cyber capability is better understood as an ecosystem: a combination of state-directed intelligence services, IRGC-affiliated hacking units, and a broader layer of proxy hacktivist groups that operate under varying degrees of central direction and with significant operational autonomy.

Two primary state entities oversee this ecosystem. The Ministry of Intelligence and Security (MOIS) directs actors including APT34 (OilRig), APT39, MuddyWater, and the wiper-focused group Agrius. The Islamic Revolutionary Guard Corps (IRGC) oversees groups including APT33, APT35 (Charming Kitten), Cotton Sandstorm, and the OT-focused CyberAv3ngers.

Sources: Mandiant/Google Cloud, CrowdStrike, Check Point Research, Picus Security, ReliaQuest, CISA.

Telecommunications infrastructure sits at the intersection of nearly all of these actors’ strategic interests. Subscriber data, call records, and messaging metadata are high-value intelligence collection targets. Disrupting telecoms networks degrades an adversary’s ability to coordinate. And compromised telecoms platforms can be weaponised for information operations, whether through push notifications, messaging manipulation, or the kind of streaming service hijacking that Cotton Sandstorm executed against UAE-based IPTV infrastructure.

The Decentralisation Risk

Operation Epic Fury introduced a new and significant complicating factor. With senior IRGC leadership killed in the strikes, the central command structure that ordinarily oversees and directs Iranian cyber operations has been substantially disrupted. Intelligence firm Flashpoint assessed the 48 to 72 hours immediately following the strikes as a period of extreme volatility, with hacktivist proxy groups likely to take the lead in escalation as they fill the vacuum left by Tehran’s disrupted command hierarchy.

This is a materially different threat dynamic. When proxy actors operate without formal oversight or strategic constraint, targeting decisions become opportunistic rather than carefully calibrated. Organisations that might not ordinarily feature on an Iranian APT group’s priority target list can find themselves in the crosshairs simply because they represent accessible infrastructure at a moment when lower-tier threat actors are competing to demonstrate relevance.

Observed post-Epic Fury activity already reflects this pattern. CrowdStrike confirmed it had identified reconnaissance and DDoS activity consistent with Iranian-aligned threat actors and hacktivist groups within hours of the operation. The ‘Great Epic’ cyber campaign, coordinated through Telegram’s Cyber Islamic Resistance channel, was activated and described by its organisers as their most aggressive deployment to date. Pro-Iranian group Handala claimed attacks in Jordan. Team 313 claimed a DDoS against a US social media platform. A group calling itself the Cyber Islamic Resistance Axis claimed to have accessed industrial control systems at an Israeli firm. Pro-Iranian actors also claimed to have breached the industrial control systems of a Jordanian grain silo company, allegedly manipulating temperature settings. The most significant development came on 11 March 2026, when Handala claimed a destructive wiper attack against global medical technology company Stryker, representing one of the most consequential Iranian-attributed cyber operations against a Western commercial target to date.

CASE STUDY: THE STRYKER ATTACK (11 MARCH 2026)

On 11 March 2026, Handala – a MOIS-linked hacktivist group assessed by Palo Alto Networks as a persona of Void Manticore – claimed responsibility for a destructive attack against Stryker, a Michigan-based medical device and technology company reporting $25 billion in annual revenues, with operations in 61 countries and products reaching over 150 million patients annually. Handala cited the Minab school strike of 28 February 2026, in which over 175 people, mostly children, were killed, as its motivation. Stryker’s acquisition of Israeli medical tech company OrthoSpace in 2019 and its $450 million US Department of Defense supply contract were also cited as grounds for targeting.

The attack vector is particularly notable. Rather than deploying traditional malware, Handala is assessed to have compromised Stryker’s Microsoft Intune environment – the cloud-based device management platform used by enterprise IT teams to enforce security policies and manage enrolled devices remotely. By gaining administrative access to Intune, the attackers were able to issue remote wipe commands across all enrolled endpoints simultaneously, bypassing conventional endpoint detection. The group claimed to have wiped over 200,000 systems, servers, and mobile devices, exfiltrated 50 terabytes of data, and forced the closure of Stryker offices across 79 countries. Over 5,000 employees at Stryker’s largest non-US hub in Cork, Ireland, were sent home. Employees reported that any personal device with Microsoft Outlook installed was also wiped.

The real-world consequences extended into healthcare. Maryland’s Institute for Emergency Medical Services reported Stryker’s Lifenet ECG transmission system was non-functional across most of the state. Hospitals reported being unable to order surgical supplies, with one senior healthcare professional describing it as a “real-world supply chain attack” affecting virtually every US hospital that performs surgery. Handala separately claimed a simultaneous attack against payments company Verifone, and the IRGC this week published an explicit list of US technology firms – including Google, Microsoft, and Nvidia – describing their regional infrastructure as legitimate targets. The Stryker attack represents a material escalation: wiper-class destructive capability, deployed by a decentralised proxy actor, against a non-traditional CNI target, with direct patient care implications.

SOS INTELLIGENCE ASSESSMENT

The current threat environment for organisations with critical national infrastructure status, particularly those with Middle East operational footprints, is assessed as HIGH. Iranian-aligned threat actors are conducting active reconnaissance and DDoS operations, with credible intelligence indicating these activities frequently serve as precursors to more destructive campaigns.

Gulf Cooperation Council states including the UAE, Bahrain, Qatar, and Saudi Arabia are explicitly identified across multiple threat intelligence sources as expected targets for disruptive Iranian cyberattacks, given their perceived alignment with the US-Israeli position and proximity to US military assets. A suspected Iranian attack drone struck RAF Akrotiri in Cyprus on 1 March 2026, indicating Iran’s willingness to target regional military infrastructure in Western jurisdictions. The cyber equivalents of such actions should be anticipated.

Why Telecoms Operators Are in the Crosshairs

Telecommunications providers occupy a uniquely exposed position in the current threat landscape. They are simultaneously high-value intelligence collection targets, critical infrastructure whose disruption has cascading effects on other sectors, and platforms that can be compromised to amplify information operations.

For Iranian actors specifically, telecoms operators with Middle East presence represent a dual-use target. On one hand, access to subscriber data, call data records, and network metadata supports the surveillance of individuals of interest to Iranian intelligence services. On the other, disrupting telecoms infrastructure in GCC states serves the broader strategic objective of degrading the operational coordination of Iran’s adversaries in the region.

The tactics used to achieve initial access are well documented. Spear-phishing campaigns targeting telecoms employees and executives remain the most common entry point, with APT35 in particular deploying AI-crafted, highly contextualised phishing messages capable of deceiving even security-aware recipients. Internet-facing edge infrastructure, including VPN appliances and remote access portals, are systematically exploited by actors such as Fox Kitten (Pioneer Kitten), which specialises in this vector. MFA push-bombing and credential overload attacks have been observed against identity management systems. DNS hijacking, strongly associated with APT34 in telecoms campaigns, redirects legitimate traffic and can be extremely difficult to detect without dedicated DNS monitoring.

Once inside a network, Iranian actors have demonstrated a preference for living-off-the-land techniques: using legitimate administrative tools such as PowerShell and Remote Desktop Protocol to move laterally without triggering endpoint detection. Remote Monitoring and Management tools, including AnyDesk and SimpleHelp, have been abused to maintain persistent access. The Stryker attack has now added a further vector to this taxonomy: abuse of cloud-based device management platforms. By compromising Microsoft Intune administrative credentials, Handala was able to issue simultaneous remote wipe commands across all enrolled devices globally, turning an enterprise IT tool into a destructive weapon at scale. Any organisation relying on cloud-administered endpoint management should treat the administrative plane for those systems as a critical security boundary. The ultimate objectives of Iranian operations range from long-term quiet exfiltration of records to the deployment of wiper malware designed to cause irreversible destruction to network infrastructure.

The human dimension should not be underestimated. Beyond opportunistic SIM-swap fraud attacks targeting subscribers of Dubai-based operators observed within hours of the Iranian missile strikes on 1 March 2026, senior executives and board members are themselves targeted by APT35’s social engineering campaigns. High-trust impersonation via professional networks and AI-generated correspondence represents a threat that technical controls alone cannot fully address.

Critically, the Stryker attack demonstrates that Iranian proxy actors are no longer confining their destructive operations to sectors with an obvious geopolitical connection. Stryker had no direct involvement in the Iran conflict. It was targeted because of a historic Israeli business acquisition, a defence supply contract, and the opportunistic availability of a vulnerable attack surface. Organisations across healthcare, logistics, defence supply chains, and technology sectors should reassess their exposure accordingly. The IRGC’s explicit publication of a target list this week – naming Google, Microsoft, and Nvidia regional infrastructure as legitimate objectives – signals that the scope of acceptable targeting has broadened materially.

What This Means for Defenders

The synthesis of these threat streams points to a clear set of priorities for organisations seeking to navigate the current environment. The following represents SOS Intelligence’s distillation of the most important protective measures, structured by immediacy.

IMMEDIATE PRIORITY (0 TO 72 HOURS)

  • Enrol in the NCSC Early Warning service if not already registered. The NCSC issued a formal advisory on 2 March 2026 identifying a heightened indirect cyber threat for organisations with Middle East presence or supply chains, with CNI operators specifically named.
  • Escalate monitoring across Middle East-based network environments, with particular focus on authentication anomalies, unusual administrative tool activity, and lateral movement indicators consistent with MuddyWater, APT34, and Cotton Sandstorm TTPs.
  • Verify that DDoS mitigation services are active, capacity-tested, and configured to handle traffic volumes consistent with current hacktivist campaign scale.
  • Review the external attack surface for all Middle East entities: internet-facing VPNs, remote access portals, and public web applications represent the most frequently exploited initial access vectors.
  • Confirm that incident response plans are current, exercised, and include a scenario-specific playbook for Iranian threat actor activity.

SHORT-TERM PRIORITY (ONE TO FOUR WEEKS)

  • Conduct a targeted threat hunt for known Iranian APT indicators across relevant infrastructure, with particular focus on webshell presence, DNS anomalies, and RMM tool usage that cannot be attributed to authorised activity.
  • Harden identity controls: enforce phishing-resistant MFA across all privileged access paths and eliminate any remaining legacy authentication protocols exposed to external access.
  • Assess supply chain exposure by identifying IT and telecoms vendors operating in or through Iran-adjacent jurisdictions and reviewing the scope of third-party access permissions.
  • Conduct a tabletop exercise simulating a wiper malware attack against regional infrastructure to validate backup integrity and test recovery time objectives under realistic conditions.
  • Brief board members and senior leadership specifically on AI-crafted spear-phishing risks associated with APT35. Technical controls and awareness training must work in parallel.
  • Audit and harden cloud administration plane access, with specific attention to Microsoft Intune, Microsoft Entra ID, and any platform capable of issuing remote commands to enrolled endpoints. The Stryker attack demonstrates that compromise of a cloud device management console can deliver wiper-class destructive capability at global scale without deploying a single piece of malware. Privileged administrative accounts for these platforms should be treated as tier-zero assets: phishing-resistant MFA enforced, access scoped and logged, and anomalous administrative activity alerted in real time.

ONGOING MONITORING

  • Treat each kinetic escalation event in the Iran conflict as a likely precursor to a corresponding increase in cyber activity within 24 to 72 hours. Threat posture should be reviewed and adjusted dynamically rather than on a fixed cycle.
  • Monitor OT/ICS security for any telecoms infrastructure with operational technology components, given CyberAv3ngers’ sustained focus on internet-exposed industrial systems in the Gulf region.
  • Monitor for SIM-swap fraud attempts against regional subscribers, given confirmed attacks in the UAE in the immediate aftermath of the 1 March 2026 missile strikes.
  • Consider engaging a specialist threat intelligence provider with Middle East APT coverage if in-house visibility into this threat landscape is limited.

Conclusion: The Age of Integrated Conflict

The conflicts unfolding in Iran and Ukraine are not background noise for cybersecurity professionals. They are the operational environment in which we now work. The integration of cyber effects into kinetic military campaigns, the activation of decentralised hacktivist networks in the wake of disrupted command structures, and the explicit targeting of critical national infrastructure including telecommunications are not theoretical risks. They are observable, documented, and escalating.

What has changed most profoundly is the speed of the threat cycle. The period between a geopolitical event and a corresponding cyber operation is now measured in hours. Organisations that maintain static threat postures calibrated to last month’s intelligence are already behind.

Resilience in this environment is not a one-time project. It is a continuous operational discipline. The defenders who will weather the current storm are those who treat threat intelligence as a real-time operational input, who have invested in tested detection and response capabilities before they were needed, and who understand that in the age of integrated conflict, the network perimeter and the geopolitical map are increasingly the same thing.

SOS Intelligence will continue to track and report on developments in this rapidly evolving threat landscape. Subscribers to our Early Warning service will receive updates as significant events and indicators emerge.


Sources & References

This analysis draws on open-source intelligence including the NCSC Advisory of 2 March 2026, statements from CrowdStrike, Flashpoint, Mandiant/Google Cloud, Check Point Research, and Picus Security, as well as publicly reported congressional testimony and official US Department of Defense statements. The 13 March 2026 update incorporates reporting from KrebsOnSecurity, CNN, TechCrunch, Bloomberg, the Irish Examiner, Al Jazeera, and Palo Alto Networks Unit 42 on the Stryker attack and associated Iranian cyber activity. All intelligence reflects information available as at 13 March 2026.

Tehran Photo by Sajad Nori on Unsplash.

Telecoms Photo by David Arrowsmith on Unsplash

"Content-Type
Uncategorized

Content-Type Bypassing: A Persistent Web Application Vulnerability

Content-Type bypassing remains a frequently encountered vulnerability in web applications despite being well-documented for years. This attack exploits insufficient validation of file uploads, allowing attackers to upload malicious files by manipulating HTTP headers. Understanding this vulnerability, its exploitation techniques, and effective defences is essential for security professionals and development teams alike.

This post examines the technical mechanics of Content-Type bypassing, real-world exploitation scenarios, and comprehensive defensive strategies.

What Are Content-Type Headers?

When you upload a file to a website (a resume, profile picture, or document), your browser sends that file to the server along with metadata describing what kind of file it is. This metadata includes the Content-Type header, which might say “image/jpeg” for a photo or “application/pdf” for a document.

Here’s what a typical upload request looks like:

The Vulnerability: Trusting User Input

The core problem is simple. Content-Type headers are trivially easy to fake. An attacker can take a malicious file (say, a PHP web shell that would give them remote access to your server) and tell your application, “This is totally just a harmless JPEG image.”

If your application only checks that header and doesn’t verify the actual file contents, it will accept the malicious file. This is like a security guard who checks that your ID says “Authorised Personnel” without actually looking at the photo or verifying it’s real.

Let’s look at a vulnerable code example:

This code checks the Content-Type (stored in `$_FILES[‘upload’][‘type’]`), sees “image/png,” and saves the file. But if an attacker uploads `backdoor.php` and changes the Content-Type header to “image/png,” this code happily saves that PHP file to the server. If the uploads folder is accessible via the web and the server executes PHP files, the attacker can now run commands on your server.

## How Attackers Exploit This

The exploitation process is straightforward, which is part of why this attack remains popular. Attackers use tools like Burp Suite or browser developer tools to intercept and modify their upload requests. Here’s the typical workflow:

**Step 1: Find the Target**

They identify an upload feature on your website and test what file types are accepted or rejected.

**Step 2: Intercept the Request**

Using an intercepting proxy, they capture the upload request. It might look like:

Step 3: Modify the Header They change the Content-Type from application/x-php to something accepted, like image/jpeg.

Step 4: Execute Once uploaded, they access the file directly (if it’s in the web root) or find another way to trigger its execution.

The concerning part is how little technical skill this requires. With basic tools and a tutorial, someone with minimal experience can perform this attack.

Real-World Impact

From a threat intelligence perspective, this vulnerability is exploited in several contexts:

Web Shells for Persistent Access: Attackers upload web shells disguised as images. These shells provide a control panel for executing commands, browsing files, and accessing databases. Popular shells like WSO or c99 are specifically designed for this purpose.

Initial Access for Ransomware: Ransomware operators often gain initial access through upload vulnerabilities. Once they have a foothold, they move laterally through the network before deploying encryption.

Supply Chain Compromises: Partner portals and vendor systems with weak upload validation become entry points into larger organisations.

The business impact can be severe. A successful web shell upload can lead to data breaches, system compromise, and regulatory violations. Incidents involving bypassed upload forms have resulted in significant remediation costs and reputational damage.

Building Effective Defences

Defending against Content-Type bypassing requires multiple layers of security. No single control is foolproof, so we implement defence in depth.

Validate File Contents, Not Just Headers

Instead of trusting the Content-Type header, examine the file itself. Every file format has a unique signature (called magic bytes) at the beginning of the file:

  • JPEG files start with FF D8 FF
  • PNG files start with 89 50 4E 47 0D 0A 1A 0A
  • PDF files start with 25 50 44 46 (which spells “%PDF” in ASCII)

A simple validation function might look like:

Libraries like python-magic or Apache Tika provide more comprehensive file type detection that handles edge cases and supports numerous formats.

Control File Storage Location

Store uploaded files outside your web root directory. This means even if an attacker uploads a malicious script, the web server won’t be able to execute it directly. Serve files through a download script that applies proper security headers:

Implement Extension Whitelisting

Maintain a strict list of allowed file extensions and reject anything that doesn’t match. Avoid blacklisting (blocking specific extensions), as attackers can use obscure variants like .php3, .phtml, or .phar.

Combine extension validation with content validation. A file must pass both checks.

Configure Server-Level Protections

Configure your web server to refuse execution of scripts in upload directories. For Apache:

Sanitize Filenames

Clean user-supplied filenames to prevent path traversal attacks and other injection techniques:

Add Malware Scanning

Integrate antivirus scanning into your upload workflow. Tools like ClamAV can scan files before they’re made available to users. While not foolproof, this catches many known malicious files.

Set Proper File Permissions

Ensure uploaded files have restrictive permissions (644 or 444) so they can’t be executed by the web server user.

Detection and Monitoring

Beyond prevention, you should monitor for bypass attempts:

  • Log all upload requests and look for patterns like high volumes from single IPs or unusual file types
  • Alert on files uploaded to directories that shouldn’t receive them
  • Monitor for the creation of executable files in upload directories
  • Track Content-Type mismatches where the declared type doesn’t match the actual file content

Why This Matters Beyond File Uploads

Content-Type bypassing illustrates a broader security principle: never trust client-supplied data. Whether it’s an HTTP header, a form field, a URL parameter, or a cookie value, anything coming from outside your system should be treated as potentially malicious.

This mindset shift is crucial. Security isn’t about implementing a checklist of controls but about understanding trust boundaries and validating data at those boundaries. The Content-Type header crosses a trust boundary (from an untrusted user to a trusted application), so it must be validated.

For non-technical readers, this is why your development and security teams sometimes seem overly cautious about features that seem simple. That innocent-looking upload form represents multiple potential attack vectors that require careful design and ongoing vigilance.

Conclusion

Content-Type bypassing continues to appear in security assessments and real-world attacks because it exploits a common misconception: that client-supplied metadata can be trusted for security decisions. The attack is simple to execute but can have serious consequences, from data breaches to complete system compromise.

The good news is that this vulnerability is entirely preventable. With proper validation of file contents, secure storage practices, server hardening, and defence in depth, you can effectively eliminate this attack vector from your applications.

As you review your own systems or work with development teams, ask the right questions: Are we validating file contents or just headers? Where are uploaded files stored? Can the web server execute files in upload directories? These questions can reveal vulnerabilities before attackers find them.

Security is an ongoing process of identifying assumptions, testing trust boundaries, and implementing layered defences. Content-Type bypassing is just one example, but the lessons learned here apply broadly across application security.

Header image > Photo by the blowup on Unsplash.

Defence image > Photo by Saj Shafique on Unsplash.

"SOS
Uncategorized

Ransomware – State of Play March 2024

SOS Intelligence is currently tracking 183 distinct ransomware groups, with data collection covering 368 relays and mirrors.

In the reporting period, SOS Intelligence has identified 439 instances of publicised ransomware attacks.  These have been identified through the publication of victim details and data on ransomware blog sites accessible via Tor.  Our analysis is presented below:

LockBit has maintained its position as the most active and popular ransomware strain, despite law enforcement activity against the group in February 2024.  However, we are seeing a significant decrease in their activity level, which is to be expected.  The impact of law enforcement activity against the group is still being monitored, but it has already been seen that the group has suffered significant reputation damage.  Many affiliates have lost trust in the group to keep their data safe and their identities anonymous.  

March also saw the sudden exiting of ALPHV/BlackCat from the scene, in what appeared an exit scam.  Affiliates were left stunned when the group shut up shop shortly after receiving a significant ransom from UnitedHealth Group.  As previously reported, the code for ALPHV/BlackCat was purported to have been sold, so a new group is expected to emerge using similar TTPs in due course.

As such, we have seen increases in activity amongst other high-profile groups.  Most groups have seen small increases in activity over the last month. Still, BlackBasta, Medusa, Play, and RAGroup seem to have profited most from LockBit’s misfortune and ALPHV/BlackCat’s sudden disappearance.  All have been operating for at least 12 months and have carved their own niche in the space vacated by these high-profile group.

Group targeting continues to follow familiar patterns in terms of the victim’s country of origin.

Attacks have increased in South American countries, particularly in Argentina, which may be a response to presidential elections in November 2023 in which the far-right libertarian Javier Milei was elected.  Brazil remains a popular target, as the most economically developed country in the region

Targeting continues to follow international, geopolitical lines.  Heavy targeting follows countries that have supported Ukraine against Russia.  Attacks against Sweden continued as it pressed ahead with preparations to join NATO.   This highlights the level of support ransomware groups continue to show towards the Russian state, and they will continue to use cyber crime to destabilise and weaken Western and pro-Ukrainian states.

Manufacturing and Construction & Engineering have remained the key targeted industries for March.  These industries would be more reliant on technology to continue their business activities, so it logically follows that they would be more likely to pay a ransom to regain access to compromised computer systems.  The Financial, Retail & Wholesale, Legal, and Education sectors have also seen increased activity over the period.  Health & Social Care has seen a significant increase over the period.  This is likely in response to several groups, reacting to law enforcement activity and allowing their affiliates to begin targeting these industries.

We are seeing a shift in tactics for certain industries, particularly those where data privacy carries a higher importance (such as legal or healthcare), where threat actors are not deploying encryption software and instead relying solely on data exfiltration as the main source of material for blackmail and extortion.

Significant Events

Targeting against the UK took an aggressive turn, with NHS Scotland (INC Ransomware) and media outlet The Big Issue (Qilin) amongst the most high-profile victims.  This highlights ransomware groups’ apathy towards who they target, and the secondary impacts that that targeting can have.

The Oceania arm of Nissan suffered a significant data breach, which was associated with the Akira ransomware.  The attack was limited to operations in Australia and New Zealand but did have a significant impact on distribution, marketing, sales, and services.

New Groups

March saw the emergence of three new groups; Donex, Kill Security (5 victims each) and RedRansomware (12 victims).  Kill Security has shown some aggressive public-sector targeting, including police services in India and Romania.

Vulnerability Exploitation

BianLian and Jasmine groups have been observed exploiting CVE-2024-27198 (CVSS 9.8).  This is a vulnerability in JetBrains TeamCity CI/CD server products up to version 2023.11.4, which allows a remote unauthenticated attacker to execute arbitrary code to take complete control of affected instances.  This would allow threat actors to gain access and maintain permanence within an affected network, while conducting reconnaissance, exfiltrating data, and uploading ransomware payloads.

JetBrains has implemented a fix for the impacted system, so it is advised to update to the latest available version.

"Compromised
Uncategorized

Compromised Password Analysis

How threat actors target your credentials and what you can do to protect yourself

Across the dark web, and shadier parts of the clear web, there is a booming marketplace for compromised credentials.  Threat actors are looking to make a quick return can monetise your sensitive data, leaving you vulnerable to further compromise.  So how do threat actors get ahold of your credentials, and what can you do to protect yourself?

How do threat actors get your credentials?

Threat actors have an arsenal of tools and techniques for obtaining credentials to facilitate further criminal activity. These range from the highly technical to meticulously researched to plain and simple brute force.  We discuss a sample of these techniques below to assist you in understanding how threat actors can obtain your credentials.

Malware

For the more technically-minded, malware can be utilised to intercept passwords being input across the internet, or just simply to steal passwords from your device.

A “man-in-the-middle” attack sees a threat actor tactically position themself between a victim and the service the victim is accessing.  While the victim is inputting their credentials, the threat actor can see the input and capture this for their use.  This technique has commonly been utilised with banking trojan’s, such as TrickBot.

Once installed on a victim’s device, TrickBot would identify when victims attempted to access banking services online and provide them with a cloned website, controlled by the threat actor.  Subsequently, they would then be able to see what the victim was typing, thereby gaining access to their login details.  To preserve the illusion that nothing was amiss, the threat actor would then redirect the victim to the legitimate site as if they were logged in.  The threat actor would then capture the victim’s credentials, allowing them to log in whenever they saw fit.

Infostealer malware is much simpler.  Once installed on a device, it can quickly query common areas of a device used for password storage, and send this data to a waiting server controlled by a threat actor.  Owing to the various deployment methods used, threat actors can quickly generate a large volume of content from infostealer malware.  This content is then sorted and sold online, or at times even given away.  Further information regarding infostealer malware can be found in our article here.

Phishing

Phishing requires an element of trickery from the threat actor.  In this situation, they are portraying themselves as something they aren’t to trick the victim into divulging their credentials.  This can often be in the form of messages (email, SMS etc) asking victims to clarify their credentials associated to a legitimate service, i.e. banking, or premium services such as Netflix.  The threat actor will also provide a convenient link for the victim however, this link will invariably lead to a cloned website controlled by the threat actor, who can then collect credentials as victims input them.

Social Engineering

Remembering passwords for all the different services we use can be tiresome.  It has been estimated that the average person has over 100 passwords to remember.  Therefore it’s only natural that we utilise the things in our lives that matter most when coming up with passwords.  Significant dates, names of pets, and our favourite locations.  All can be useful when creating passwords as you’re more likely to remember these details.

The problem comes with our online activity.  Many people are very public about what they post online, and we talk about the things we like and what’s important to us.  If we’re then using those important things to generate our passwords, it becomes very easy for threat actors to do a little research into us to discover those passwords for themselves.

As an example, we have identified within our data collections that “fiona2014” is one of the most commonly used passwords.  If someone were to be using this password, it could be very easy to use social engineering to obtain it.  It would be straightforward to talk to someone, engage them about their life, and quickly find out they have a daughter called Fiona who is 10 years old.  Putting these details together we can come to “fiona2014”.

Dictionary Attacks

We are inundated with accounts requiring passwords, so it is common for people to use simple passwords to avoid having to remember anything too complex.  Threat actors rely on this as the basis for a “dictionary attack”.  Years of data regarding passwords has allowed for generating files containing thousands of common passwords and their variants.  These files then allow a threat actor to query a service, armed with a victim’s email address, and try each password until the service allows them to log in.

Thankfully, dictionary attacks are somewhat easier to defend against.  Most services will now only allow a few login attempts before any suspicious activity is flagged and the account is locked down.  Threat actors will constantly look for methods to bypass this security, so the best option is to keep those passwords unique.

Brute Force

When finesse will not work, take a sledgehammer to the door.  Brute force requires a threat actor to have some coding knowledge.  They can write code which will query a service to attempt a login, but instead of being more methodical, this method is more trial and error.  Commonly, brute force attacks will iterate through millions of potential combinations to find the correct password (assuming that any security the service has does not lock the account down).  This method can be more easily defeated by using longer, more complex passwords, and we will explain why shortly.

Brute force attacks can also occur when a threat actor obtains a username:password combination for a particular site.  Banking on poor password hygiene, they will attempt the same combination across multiple sites to see if there has been any password reuse.

What happens when your credentials are compromised

What happens when credentials are compromised depends on who the victim is.

Compromise of personal accounts tends to provide threat actors with access to various services and information, including the victims’ banking, online shopping, premium entertainment services etc.  These have some value to others, who may want the benefits of those services without having to pay, e.g. to watch Netflix, listen to Spotify etc.  These types of data will often be grouped and sold in bulk on online forums for a fraction of the cost of the service they give access to.

Real value for threat actors comes from compromised corporate accounts.  These accounts allow a threat actor to access a corporate system, giving them a platform to launch further criminal activity.  There is an entire marketplace dedicated to gaining initial access to corporate systems – initial access brokerage – and depending on the size of the victim, can bring in thousands of pounds for the threat actor selling credentials.  Such access can be a precursor to more serious cybersecurity events, such as data theft/loss, or the deployment of ransomware.

Password hygiene and habits

Now for the statistics.

We have taken a sample of data collated by SOS intelligence in March 2024, totalling over 10 million passwords obtained by infostealer malware.

The most common password length was 8 characters, with an average length across the dataset of 10.5.  This was to be expected as 8 characters is often presented as a minimum across many password policies.  Additionally, it’s also the number of characters in “password”…

Top 20 most common passwords
PasswordCount
12345651022
admin22322
https16682
1234567816525
12345678915737
123458958
Profiles8611
password6533
Opera3946
12345678903326
1231233093
12345672923
Aa1234562866
Kubiak222821
Pass@1232761
Password2665
1111112488
fiona20142206
123456789102043
P@ssw0rd2029

On that note, the word “password”, and numerous variants utilising common character substitutions, appeared over 37,000 times.  “admin” appeared more than 22,000 times, while “https” was used more than 16,000 times.  This is concerning as dictionary attacks will often focus on keywords such as this first, knowing they are so common.  “admin” is frequently used as a default password on routers and other IoT devices which highlights the ongoing vulnerability of these devices.

In total, approximately 1 million passwords contained only digits, while approximately another 1 million contained only letter characters.  Overall, over 7.5 million passwords contained no special characters.

So the fundamental question is, why are these statistics important, and how can we use them to improve our password hygiene?

Password strength works based on “entropy” – the measure of randomness or uncertainty of the password.  Password entropy allows us to quantify the difficulty or effort required to guess, or “crack”, a password using brute force or other similar methods.  As a general rule, higher entropy passwords are deemed stronger and more secure.

We measure entropy in bits. The number of bits a password has indicates how strong it is.  The basic formula for calculating entropy looks like this:

 Entropy = log2​(NL)

Where:

  • N is the number of possible characters in the character set used for the password
  • L is the length of the password (in characters)
  • log2 is the base-2 logarithm

Taking this formula we can see that the longer a password is, and the more characters it pools from, the higher entropy it will have.  We can visualise this with our data.

Using a length of 8 (being the most commonly seen) we can see the entropy when different sizes of character sets are used:


NumericalSingle CaseAll CaseAlphanumericAlphanumeric w/ Special Characters
Total # of characters1026526292
Entropy26.5837.6045.6047.6352.19

If we increase the password length to 12, strength increases significantly:


NumericalSingle CaseAll CaseAlphanumericAlphanumeric w/ Special Characters
Total # of characters1026526292
Entropy39.8656.4168.4171.4578.28

Based on the above, working at 1000 guesses per second, a brute force attack on an 8-character numerical password would take about 27 hours.  However, a similar attack on a 12-character password utilising alphanumeric and special characters would take roughly 11.5 billion years!

The key factor to note here is that there is a reason we’re always asked for longer passwords with uppercase, lowercase, numbers and special characters – they’re that much stronger and secure.

So a crucial question remains; what should be done with this information?  We sincerely hope that what we’ve discussed here will highlight the need for strong and enforced password policies.  These should factor in the following:

  • Use of alphanumeric and special characters
  • Mandatory lengths (at least 10, but longer is better)
  • No password reuse
  • Frequent and enforced password changing.

Wherever possible, we would highly recommend the use of password managers.  They can save a lot of time for users, allow for significantly more complex passwords to be used, and only require the user to remember one password.  We don’t recommend using one product over another, but one such example would be KeePassXC.  KeePassXC is a host-based password vault which keeps passwords encrypted when not in use.  It offers numerous options for password generation, varying on characters used, length etc.  The benefits of this are that you can generate passwords up to 128 characters long, which simply need to be copied and pasted whenever they are required.  Here is one such example with an entropy value of 715:

J4kKutHec3RYxQo3kpm4mot5EAVp&opRCSr&x4J5r%fQ$XxzrjdW2ZgRg@k42XhA@zz`S4ofiR4~^s`&43zZ@JQ&qQ$Mad2^jtQdHSZ@hbJbVk5Qabvs5Kc$KW3#W@Rm

What our external research shows

Research conducted by NordPass in 2022 identified that the average person has approximately 100 user accounts requiring password verification.  This is the most probable cause for password reuse and password fatigue; where users are exasperated by the constant need to generate unique strong passwords and fall into a habit of using weak, easy-to-remember passwords, or reusing old ones. Verizon’s Data Breach Investigations Report, published in 2021, estimates that 80% of hacking-related breaches were a result of stolen or brute-forced credentials.  This number could be significantly reduced by ensuring and maintaining good password hygiene.

Forgetting passwords can have a significant impact on the password owner, the services they use, and the organisations they work for:

  • Research firm Forrester has indicated that, for some organisations, the costs associated with handling password resets could be up to $1 million USD per year.  Gartner estimates that around 40% of help desk queries in large companies relate to password resets, taking up a substantial part of billable work, and taking focus away from more business-critical support.
  • In 2017, MasterCard and the University of Oxford published a study looking at users of online shopping platforms.  Their research indicates that 33% of users would abandon a purchase if they could not remember an account password, while 19% would abandon a purchase while waiting for a password reset link.
  • Chainalysis, a cryptocurrency data firm, estimates that 20% of all mined Bitcoin are locked in lost or otherwise inaccessible wallets.  In one such example, one user has 7002 Bitcoins locked within a hard drive, which risks being encrypted following two more incorrect password attempts.

What is SOS Intelligence doing, and how can it benefit you?

At SOS Intelligence, we understand the risk that credential theft can pose to the security of your data.  What we can provide is early detection for when your data has been exposed. 

We are actively collecting and analysing stolen credentials from multiple sources which feeds into our intelligence pipeline.  Within moments of ingestion, we can generate bespoke alerts for you to indicate when you may be at risk.  Early detection is vital to allow you to take action before an issue becomes serious and impactful against your business.

If you are serious about your cyber security, why not book a demo?

Photos by Ed Hardie on Unsplash,  Ryunosuke Kikuno on Unsplash, Joshua Hoehne on Unsplash

New: Attack Surface Management · Dark web intelligence. Now with the bigger picture. | Explore SOS Intelligence ASM →
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound