The Attacks You Can’t See Are the Ones That Hurt the Most

Over the past several years, I’ve worked closely with fraud and risk teams across some of the most sophisticated platforms on the internet: companies with multiple user cohorts, high-frequency financial flows, enforced login requirements, and an overwhelming variety of fraud and abuse vectors.

They all had slightly different use cases, but the same underlying problem kept surfacing. Their tools were built to respond to known threats, not to detect the ones hiding in plain sight.

What we kept encountering – and what ultimately led to the creation of Spec ID – was a persistent gap in visibility. Fraud was happening upstream, before login, across multiple sessions, in environments where traditional signals break down. And it wasn’t just going undetected. It was effectively invisible.

What looked like harmless anomalies were actually coordinated attacks. But the signals were too fragmented, too distributed, and too easily dismissed. They were like shards of a larger story that was nearly impossible, and thus unfathomable, to piece together.

Fraud Doesn’t Show Up All at Once

When you operate a platform that facilitates high-value or high-volume transactions between buyers and sellers, it’s not just known patterns you’re fighting, it’s also the infrastructure that’s constantly mutating.

You’ll see a password reset from a suspicious device. Then a login attempt from another location. Later, a new account that behaves just like the last one you flagged, but it’s coming from a clean IP and an untouched browser fingerprint. None of these events, on their own, are enough to raise a hand. But together, they tell a very different story.

The problem is, most fraud tools can’t connect or contextualize these activities. This is especially true for tools that need successful logins to expose key user flows.

Fraud that happens before credential submission – credential stuffing attempts, bot-led probing, card testing attacks, account reconnaissance – rarely generates clean signals. And because most tools rely on JavaScript, device fingerprinting, or post-authentication behavior, that upstream activity falls through the cracks.

Fraud isn’t failing to signal. The system just isn’t set up to listen.

A Coordinated Attack

In one of our customer environments, we saw what this looks like at scale.

We observed a single attacker responsible for more than 470,000 authentication attempts over the course of just a few days. Signatures in our platform immediately revealed a high level of sessions marked ATO. Had our customer seen or felt it themselves, it might have looked like scattered, low-risk login failures from unrelated users.

But through Spec ID, the picture became clear.

This single attacker was using:

• Over 471,000 unique email addresses (largely disposable or synthetic)
• Nearly 45,000 unique IP addresses, rotated aggressively via proxy services
• 5,500 ISPs, likely from commercial providers to botnet
• Traffic distributed across 205 countries, deliberately fragmented to evade geo-based heuristics

Imagine, with this sort of fragmentation, how would you stop this attack?

The attacker was rotating IPs every few minutes; sometimes with every attempt.

What IPs would you block? You can’t just block a user agent or an entire region or country, because you’ll definitely be blocking legitimate customers too.

That’s the challenge.

But because of our unprecedented visibility and novel approach to behavioral mapping, Spec ID allowed us to link all of the activity back to one persistent identity, built not from cookies or device fingerprints, but from network signals.

And not only that, our customer’s users, like most platforms of its kind, have a normal and natural user experience, which also allows us to identify deviations from how it should be used: loading pages or not using hundreds of IPs, for example.

We didn’t need the attacker to log in. We didn’t need JavaScript to trigger. We didn’t need them to reuse a device or reveal a pattern. We just needed to observe how they moved and how that behavior mirrored or differed from what we’d seen before.

By doing that, we identified the attack early, funneled it into a honeypot, and monitored its progression without disrupting legitimate users. The customer didn’t have to take action. The fraud was neutralized before it could escalate.

Why Traditional Tools Can’t See This

The issue isn’t that legacy systems don’t try to detect fraud. It’s that they weren’t built for attackers who deliberately fragment their activity across sessions, devices, and user states.

Most fraud tools rely on one or more of the following assumptions:

• That JavaScript will execute, allowing for device fingerprinting
• That IP addresses or user agents will remain stable
• That attackers will trigger login success or downstream behavior that can be scored
• That each signal comes with enough context to be evaluated independently

But in modern attack scenarios, those assumptions break down fast.

You might see a credential stuffing probe that never loads the login page. Or an attacker rotating IPs, skipping web views entirely and calling your APIs directly. These interactions don’t trigger JavaScript. They don’t produce a usable fingerprint. They never generate a login success.

Fraud often shows up in brief, disconnected interactions: a bot probing an endpoint with a credential set that never loads a full login page, or an attacker spoofing browser headers to avoid persistent detection. These interactions bypass frontend protections and leave no surface-level signal behind.

To make matters worse, many detection platforms are priced and architected in ways that reinforce these blind spots. When a system charges based on login decisions or successful authentications, there’s little financial incentive to inspect the activity that precedes them. If there’s no login, it’s treated as if there’s no risk. If a session ends before credentials are submitted, it’s ignored entirely. If a bot isn’t loud enough to trigger a captcha, it slips through unnoticed.

As a result, these platforms only begin to engage once it’s already too late, and in many cases, they never engage at all. What fraud teams are left with is a scattering of disconnected events: a failed password reset, an unremarkable registration, a strange browser configuration. None of it offers a complete picture. None of it feels actionable.

But in our work with these teams, we’ve seen again and again that those incomplete, seemingly unrelated shards of data are not meaningless. They’re early signals of something much larger. They’re part of a distributed campaign built to stay below the radar.

How Spec ID Works

Spec ID is a passive, server-side identifier built entirely from network and behavior-based heuristics. It doesn’t require JavaScript, cookies, or device storage. It’s invisible to the attacker, but incredibly effective at identifying patterns they didn’t intend to reveal.

It looks at things like:

• The order and structure of HTTP headers
• Temporal cadence and flow of requests
• Navigation and endpoint traversal across sessions
• Infrastructure reuse patterns, even when obfuscated

Each signal, on its own, is just another shard. But when you observe them over time, and know how to link them back to prior behavior, they form a durable identifier that can persist across sessions, browsers, proxies, and devices.

We’ve engineered Spec ID to perform this stitching in real time, without requiring login state or frontend execution. And once the identifier is created, you can watch the actor move across your environment — test, fail, escalate — all from a single, unified perspective.

From Fragmented to Connected

For fraud teams tasked with protecting complex, high-risk user experiences, the shift that happens with Spec ID is immediate and tangible.

Instead of reacting to confirmed losses after the fact, teams can start identifying the earliest signs of fraud campaigns as they begin to take shape. Authentication failures and policy probes no longer have to be treated as isolated events; with the full context of behavior and infrastructure, those signals become connected, meaningful, and actionable.

Your team can investigate patterns that unfold across time, channels, and endpoints. They can move beyond pattern matching and start understanding the intent behind every interaction, significantly reducing false positives along the way. This visibility eliminates the constant tension between blocking too aggressively and reviewing too conservatively. It gives fraud teams the confidence to act with precision.

With Spec ID, fraud teams can shift their focus to what really matters: strengthening their defenses, scaling smarter, and staying ahead of adversaries who rely on staying unseen.

The Real Shift

Spec ID doesn’t just give you more data, although that’s part of it. It also gives you clarity and continuity.

This isn’t something we theorized in a whiteboard session. We built it alongside the teams who were already seeing signs of fraud they couldn’t explain and had exhausted every other fraud and bot solution trying to figure it out.

Once they saw the full picture, they never wanted to go back.

See it in Action

Download the Spec ID white paper to learn more about how it works.

--

Get Started with Spec

Getting started with Spec is simple and fast. We designed integration to eliminate common barriers and accelerate time to value:

• No major re-instrumentation required: Sessions automatically start when users land on your site or app.
• Lightweight integration: API calls are linked to sessions in real-time through simple configuration.
• Spec ID activates immediately: Returning users are fingerprinted and connected across sessions as soon as integration is live.
• Full support and onboarding: Our team guides your integration process, ensuring fast time-to-value.

You don’t need to rebuild your fraud stack to start seeing full customer journey visibility. Learn more.