Ransomware Payments Under Scrutiny: What Sustained Red Teams Measure

Here's a question most security teams get wrong: how long would your red team actually survive on your network before someone notices? Not a scheduled pentest with a defined start and stop. Not a tabletop exercise where everyone plays nice. A real, sustained operation that hunts for weeks, hides in the noise, and keeps moving. That's what sustained red teaming is about, and it changes the metrics you should care about.

This article breaks down how to measure attack persistence without blowing the budget or turning the engagement into a circus. We'll look at the numbers that matter, the ones that lie, and a worked example that shows why dwell time means more than a finding count.

Why One-Off Pentests Miss the Real Threat

A five-day pentest is a snapshot. You get a crisp list of findings, a score, and a handshake. Then the report lands in a folder and the folder gathers dust. That feels like security. It isn't. The illusion persists because the test mimics a burglar who jimmies one lock, photographs the hallway, and leaves. Real adversaries don't photograph the hallway. They move in.

Consider what a single assessment actually captures: a narrow window of time, a defined scope, and a tester who must report back by Friday afternoon. Pressure bends behavior. Testers shortcut, skip persistence, and chase quick wins. The result? A wishlist of vulnerabilities—not a picture of how an operator would chain them over weeks. The catch is that dwell time, not initial access, drives most of the damage. And dwell time is precisely what the weekend test can't see.

What a persistent attacker looks like

Persistent attackers think in phases. They establish a foothold, then test credentials, then pivot laterally, then embed themselves in backup systems. Each step is small. Each step is reversible. A red team operating over thirty days behaves the same way—except the defenders also get to respond, patch, and hunt. That back-and-forth is the real simulation. One-shot tests skip the back-and-forth entirely. They hand you a before-and-after photo, not the film reel.

I have seen organizations fail spectacularly at the week mark. Not because the initial exploit was clever, but because the blue team never noticed the secondary beacon. A persistent adversary counts on that. They exploit the gap between detection and response, stretching it until the cost of eviction exceeds the value of the data they've already copied.

The math is brutal. The longer an attacker stays, the more systems they touch, the more credentials they harvest, the more exfiltration channels they open. Cost compounds. A breach resolved in three days might cost a fraction of one that lingers for three months. Sustained red team operations measure that decay—how quickly defenders close the window. That's the metric that matters, and no pentest report will ever show it to you.

'A pentest tells you where the door is open. A sustained campaign tells you why nobody closed it.'

— contractor, after a 40-day engagement

The odd part is—most buyers don't ask for the right thing. They request a report, a remediation plan, a compliance checkbox. Sustained operations deliver something messier: a timeline of defender fatigue, a log of missed alerts, a dossier of repeated mistakes. That's harder to present to a board. It's also the only version that reflects reality.

So the pitch isn't about more testing. It's about different testing—operations that mirror the adversary's patience, not the consultant's calendar. If you're paying for a snapshot, you'll get a snapshot. The threat is a movie.

Persistence Metrics, Explained Without Fluff

Dwell time is the ugly number nobody wants to talk about. It measures how long an adversary sits inside your network before you notice. The clock starts at the first unauthorized action—not the first alert, not the login that looked weird—and stops when your team actually confirms the intrusion. Time-to-detect is the second hand on that same clock. It counts the gap between initial compromise and the moment someone says “we’re breached.” Most teams conflate the two. They shouldn’t. You can detect a foothold in an hour, but if the attacker established persistence three weeks earlier, your dwell time is still twenty-one days.

The catch is that dwell time punishes you twice. Long dwell means more stolen data, more lateral movement, more chances to plant backdoors. But it also skews every other metric you track. Shorten detection time without cleaning out the existing footholds, and you’re just measuring your own blind spots.

I have seen red team reports where the dwell time looked fantastic—under 48 hours—because the team only measured from the moment their C2 beacon first called home. Wrong order. The real breach started when they phished a credentials cache from a forgotten file share three weeks earlier. That’s the number that matters.

“Dwell time is the quiet room you never sweep. The longer you ignore it, the more it fills with things you didn’t put there.”

— paraphrased from a SOC lead who lost a quarter to a stealthy foothold

Coverage Decay

Coverage decay sounds like marketing jargon, but it’s brutally practical. Run a red team campaign on day one, and your detection tools catch, say, 80% of the team’s techniques. Run the same campaign thirty days later—without changing the tools—and that number drifts downward. Event log retention windows expire. Monitoring rules get tuned to silence false positives. Analysts rotate shifts and lose context. That drift is coverage decay, and it’s usually steeper than anyone expects. I have seen detection rates fall from 80% to 55% in under six weeks on an otherwise healthy network. The tools didn’t fail. The environment just shifted beneath them.

What usually breaks first are the low-frequency detections—the odd PowerShell invocation, the unusual service creation, the login from a new geography. Those get tuned out because they generate noise. Alert fatigue is the solvent that dissolves coverage. The red team’s job is to find which controls decayed and show you the exact week they stopped working. That feedback loop is worth more than any single vulnerability scan.

Repeated Detection and Alert Fatigue

Here’s the trap: a red team that gets detected on day one often keeps trying the same technique. If your SOC blocks it, the team swaps tools and tries again. Each attempt generates a ticket. If your analysts handle it correctly, you get a clean kill chain. But three weeks into a sustained campaign, the same technique gets a “seen this before” shrug. That’s alert fatigue quantified—repeated detection doesn’t mean repeated response. It means your team stopped treating the second, third, and fourth hits as real. The metric to track is not “detections” but “detection-to-action ratio.” How many alerts actually produced a response that removed the foothold?

The trade-off is brutal. Push your team to respond aggressively to every repeat, and you burn them out on false positives. Let repeats slide, and you hand the adversary a free pass. Sustained red teams measure this ratio every week, not in a final report. That’s the only way to see fatigue before it costs you a real incident. We fixed this by setting a hard rule: any technique that triggered the same alert three times within five days gets an automatic deep-dive, no matter how harmless it looks.

Under the Hood: How These Metrics Are Actually Calculated

Every persistence metric starts with a simple question: what did the adversary touch, and when? The answer lives in three places — endpoint logs, authentication servers, and the occasional firewall stream nobody owns. Pulling from all three sounds obvious. In practice, most shops only have one source stitched together properly. The other two sit half-configured, with retention windows that expire before the red team finishes its first week.

Sysmon and Windows Event Logs give you the process creation and network connection data. But they spew noise — thousands of events per host per hour. Filtering that down to "interesting" requires a detection rule set that actually matches the adversary's known toolkit. That's the rub. Your rules were written for last year's TTPs, not the current campaign. We fixed this once by pulling raw logs into a local SIEM and writing custom queries on day one, before the operation even started. Wrong order? Sure. But it showed the team what the data looked like before we asked it to answer anything.

Authentication logs are cleaner but narrower. They tell you about logons, not what happened after. Combine them with process telemetry and you get a partial picture. The missing piece is often the endpoint that wasn't instrumented — a Linux server here, a network appliance there. Adversaries find those gaps fast.

Setting baselines and thresholds

You can't measure persistence without knowing what normal looks like. That means building a baseline from at least two weeks of quiet traffic. Not one week — two. A single week misses the monthly patch cycle, the backup jobs that run every third Tuesday, and the night shift employee who logs in at 2 AM like clockwork.

The threshold question is trickier. How many failed logons count as suspicious? How many scheduled tasks created in an hour is too many? There's no universal number. The pragmatic approach is to pick a baseline multiple — say, five times the median daily count — and then watch what happens. The catch is that a quiet environment with near-zero activity will flag almost any addition. A busy domain with constant admin changes will swallow a persistent foothold whole. Both are dangerous, just differently.

Thresholds also decay. The adversary's behavior changes over 30 days, and your static threshold becomes less useful by week three. Recalculate it weekly. Rebaselining is boring, but it keeps the metric honest.

The role of manual review

Automation gets you 80 percent of the way. The last 20 percent is a human staring at a timeline and saying, "that doesn't belong." No algorithm catches a scheduled task that masquerades as a Windows Update job if the naming convention matches exactly. A human who's seen the actual update schedule will spot it in seconds.

“Metrics are only as good as the person who questions them. A number that never gets challenged is just a guess with a timestamp.”

— Senior red team operator, speaking at a tabletop exercise

Manual review is also where you catch data quality issues. Logs that stopped flowing at 3 AM. A timezone mismatch between the web server and the domain controller. A collector that died and restarted silently. The metric calculation will happily include those gaps and produce a result that looks plausible but is wrong. That's the pitfall nobody puts in the slide deck.

What usually breaks first is the correlation step. Joining process IDs across two log sources requires a time window and a host identifier. If one source uses UTC and the other local time, your join silently drops half the events. We caught this by spot-checking a single known event — a scheduled task firing at midnight — and tracing it through both pipelines. It took two hours to fix. Two hours that saved a week of garbage metrics.

The manual pass also answers the why. Metrics tell you that persistence increased on day nine. They don't tell you if the adversary just installed a new backdoor or if the defenders finally patched the old one, causing the adversary to pivot. Only a person looking at the actual events can distinguish those. The number is a symptom; the review is the diagnosis.

Budget for that review time in the campaign plan. Ten minutes per day per analyst is enough for a 30-day operation. Less than that, and you're trusting the math without checking the inputs. More than that, and you're probably over-analyzing noise instead of acting on signal.

A 30-Day Campaign: A Worked Example

We ran a 30-day campaign against a mid-sized logistics firm that had just paid a ransom demand. The client wanted to know if their recovery actually held. I pitched a simple engagement: drop a persistent agent, stay quiet, and see how long before someone noticed. The target had about 400 endpoints, a half-hearted EDR rollout, and patching that ran on a weekly schedule nobody enforced. Nothing exotic.

The operator planted the beacon inside a mocked-up invoice macro that arrived as an email attachment. Realistic enough for the demo environment, and the landing zone was standard—a contractor’s laptop that had been parked on the VPN for six weeks straight. From day one, the dashboards looked golden. Dwell time sat at zero, because the beacon only phoned home every four hours. That silence was a lie. The clock was already ticking.

Tracking dwell time day by day

Day three, we started lateral movement. One credential theft, one SMB share, and we were on a domain controller with a service account nobody had rotated in two years. Dwell time still read zero. Our own telemetry pipeline only counted active sessions, so the metric had a blind spot—any time between beacons vanished from the calculation. We knew this, but the client’s dashboard didn’t. It showed a clean sheet.

By day nine, we had touched sixteen machines, installed two persistence mechanisms, and tripped zero alerts. The EDR logs showed the file writes, but the alert thresholds were buried under false positives from routine patching. The catch is, if you measure dwell time as “first discovery minus initial infection,” you miss the whole middle. The real story is what the attacker does with that quiet window.

Day fourteen brought our first scare. A system admin ran a manual scan on a file server we had touched. The scan flagged a binary we left there—not because it was malicious, but because it had a weird signature. The client’s security team dismissed it as a false positive and moved on. That moment taught me more than any KPI. The metric that matters is not dwell time but the time-to-acknowledgement of an anomaly. Most teams don’t track that at all.

What the dashboards hide

Here’s where the numbers mislead. Our final report showed a mean dwell time of 22 days, which sounded comfortable. The median was 17 days. But the distribution was bimodal—one cluster around 9 days for the file server touches, another around 29 days for a second persistence mechanism we installed late in the game. Averaging these flattens the risk. The 29-day lurk is what would have gone unnoticed for months in a real attack.

The dashboards also hid the cost of detection. We spent roughly 40 hours of operator time to stay stealthy. The client’s SOC, once engaged, took 11 hours to fully contain a simulated payload we triggered on day 26. That containment time is a better predictor of ransom negotiation leverage than any dwell metric. Yet nobody reports it.

“A 20-day dwell time with a 12-hour containment is safer than a 5-day dwell with a 48-hour containment.”

— Incident response lead, reviewing our after-action deck

Not every penetration checklist earns its ink.

What usually breaks first is the assumptions baked into the metric. You can calculate dwell time precisely, but the definition of “initial access” shifts. Was it the invoice macro, or the time we reused the same credential on a second host? Most tools call it the first touch—but that undercounts repeat offenders. I have seen engagements where the real entry point was a forgotten test server, not the phishing email everyone assumed.

Not every penetration checklist earns its ink.

If you’re running your own sustained red team, fix one thing: track the time between each action and its corresponding detection signal, not just the whole campaign. Slice by asset class, by persistence type, by time of day. Then prepare to defend the dashboard to a CFO who wants a single number. You’ll likely end up with three numbers: median dwell, worst-case dwell, and half-life of a silent beacon. That last one is the one I watch. If a beacon stops calling for 48 hours, is it dead, or just waiting? Wrong answer, and you’ve lost the campaign.

Edge Cases: When the Metrics Stop Making Sense

Imagine an attacker grabs one password. Not a domain admin, just a service account with access to three file shares. The metric says persistence held for eleven days. But then the red team discovers the same password sits in a vault used by forty employees. Every logon from those users — legitimate or not — now looks like enemy movement. We saw this in a recent simulation: the attacker’s presence became indistinguishable from a night-shift operator who always worked late. The dwell-time number inflated to twenty days, and nobody could tell us whether the spike meant the bad guys were still inside or just a tired contractor.

The catch is that shared credentials wreck the foundational assumption of attribution. You can't measure persistence if you can't tell who is who. Most red teams respond by flipping to anomaly scoring — count logons, flag new source hosts, watch for off-hours access. That works, until one user logs in from a VPN at 2 AM because their child was sick. False alarm. The metric stops being a signal and turns into noise. I have watched analysts burn two days chasing a ghost that was just a misplaced token.

Worse, the persistence metric misleads when attackers intentionally reuse known credentials to blend in. They borrow the janitor’s account, move a file, log out. The system records another “normal” authentication. Your dwell-time clock resets, but nobody inside that network actually got compromised in a meaningful way. Wrong answer, right numbers. That's the trap.

Insider Threats That Look Normal

Then there is the insider who doesn't need to hack anything. A sales manager copies a customer list before quitting. Her access logs show regular hours, her machine has corporate AV, she never touches PowerShell. The persistence metric says zero — no implant, no lateral movement, no persistence. But the data walked out the door. The metric is technically correct and operationally useless.

Standard red team tools measure attacker footholds, not human betrayal. Nobody can fix this by adding more telemetry. We once ran a scenario where a disgruntled admin reset his own password, deleted the audit logs, and gave his old badge to a friend. That looked exactly like routine account maintenance. No metric broke. The only thing that caught it was a manager noticing he had not shown up for two weeks — a human check that no KPI will ever replace.

Metrics quantify what tools detect, not what actually happened. The gap between those two is where the real stories hide.

— Senior incident responder, on why they still interview staff after every engagement

That said, you can tighten the edge-case handling by adding a simple rule: treat any account with elevated privileges as permanently suspicious, regardless of activity. It costs extra review time, but it catches the insider who just copies files. The trade-off is alert fatigue — analysts start ignoring the daily flag on the same three admins. Wrong, again. The fix is to pair the rule with a secondary check on data volume, not just authentication patterns.

Fileless Attacks and Memory-Only Implants

Fileless attacks break the last assumption you have: that persistence means an artifact on disk. A memory-only implant runs in PowerShell’s runspace, lives for exactly one session, and vanishes on reboot. The dwell-time metric says it was present for forty minutes. The real story is that the attacker used those forty minutes to launch six other processes, one of which wrote a scheduled task that survives. The initial implant was ephemeral, but the follow-on persistence was not.

Most teams botch this by measuring the wrong layer.

The persistence metric should track the operation’s endurance, not the implant’s. A memory-only tool that establishes a stable beacon via a scheduled task is persistent — even though the original file never existed. I have seen red teams report “no persistence” because they only looked at files on disk, missing a system that would reconnect every hour for months. How do you reconcile that? You track the beacon’s reachability, not its storage medium.

The odd part is that fileless attacks often make the metric too high. A temporary PowerShell process that gets killed and restarted ten times a day generates ten separate persistence events. The real count is one campaign. The metric fragments into noise. We fixed this in our own workflows by asking a single question: “Could the attacker still execute commands if the machine rebooted?” If yes, it's persistent. Everything else is just forensics.

Your next action should be to add that reboot test to every detection rule you own. Run it against your own thresholds, not the vendor default. And when a metric disagrees with what your analyst sees on the screen, trust the analyst — the number is probably measuring the wrong thing.

Limits of the Approach: What Metrics Can't Tell You

Any metric worth tracking can be gamed. I have watched blue teams inflate their detection scores by simply whitelisting a red team’s known IP range. False positives vanish overnight. The dashboard turns green. And everyone pretends the problem is solved.

The catch is that sustained red teams can game the numbers too. We control our own noise. If persistence metrics reward stealth, we can slide in with a single scheduled task and call it a day. That measures nothing except our restraint. The real question is whether the metric still means something when someone is actively trying to fool it.

Most teams skip this: define what the metric is not measuring before you trust it. A dwell-time score of zero days might mean you caught the intrusion fast. Or it might mean the attacker split their foothold into fifty tiny pieces, and you only found one. Same number, opposite story.

“A metric is a flashlight, not a map. It shows you where to look, never what is actually there.”

— paraphrased from two separate incident responders, different years, same frustration

Baseline drift and organizational change

Persistence metrics assume the environment stays still. It never does. Reorganizations shuffle server ownership. New cloud accounts appear weekly. Someone’s “critical asset” list gets archived during a merger, and suddenly your baseline is measuring a ghost.

What usually breaks first is the time-to-detect calculation. You calibrate it against last quarter’s traffic patterns. Then the company rolls out a new VPN client, shifts half its workloads to a different region, and every detection threshold silently moves. The metric says “steady.” The reality is that your baseline drifted three weeks ago and nobody logged the change.

Field note: penetration plans crack at handoff.

That sounds fine until a real adversary exploits the gap. We fixed this in one engagement by pinning the baseline to a specific date and flagging any deviation automatically. Then the flag itself became noise, so we pinned it to a different date. The honest answer: you're always chasing a moving target, and the metric lags the truth by days or weeks.

Field note: penetration plans crack at handoff.

The danger of dashboard confidence

The worst failure mode is not bad data. It's good-looking data that makes people stop asking questions. A green “persistence health” score feels like closure. It's not. It's a snapshot of one slice of time, taken with tools that can see only what they were built to detect.

I have seen leadership cancel an active red team rotation because the dashboard showed three straight months of “improving” dwell times. Then the next real incident took eleven days to find. The metric was fine. The confidence it created was not.

Statistical noise compounds this. A fifteen-day dwell time might be a real win or just a quiet month for the attacker’s scheduling. Two incidents out of twenty will randomly spike or drop for no operational reason. If you treat every fluctuation as signal, you will chase shadows. If you ignore every fluctuation, you will miss the one that matters.

So what do you actually do with these numbers? Use them as a smell test, not a verdict. Pair each metric with a raw-log review. Question why a number changed before celebrating why it improved. And when the dashboard looks perfect, that's the day to go hunting for what it can't see.

Red Team Metrics FAQ

Budget questions always come first, and the honest answer is uncomfortable: it depends on what you're trying to learn. A two-week campaign with one operator and a borrowed laptop costs maybe $15,000 in internal time. A 90-day engagement with two operators, custom tooling, and cloud infrastructure pushes toward six figures. Neither is wrong, but they answer different questions. The cheap one tests your detection coverage. The expensive one tests whether your organization can survive a patient adversary who adapts. I have seen teams burn $80,000 on a fancy engagement and then ignore the single finding that mattered. The catch is that budget should follow the decision you need to make, not the other way around.

Set a range, not a fixed number. Start with $25,000–$40,000 for a 30-day campaign if you have decent logging and a mature SOC. That buys you enough time to see persistence attempts that would be missed in a week. If you have no idea where your crown jewels live, spend less first — maybe $10,000 — on a scoping exercise. The odd part is that most breaches are not exotic. They exploit a stale VPN credential or a misconfigured service account. Your red team budget should reflect that reality: more time on the boring stuff, less on zero-day theatrics.

How often should I run one?

Quarterly is the default answer, but the real answer is “whenever your environment changes significantly.” A full sustained campaign every three months is overkill for most mid-size companies. You will burn out your defenders and your operators. Instead, run a short 2–3 day detection-focused exercise monthly, then a deeper sustained campaign twice a year. That rhythm catches drift. New cloud deployments, merges, or a sudden shift to remote work — those are the moments when your security posture decays fastest.

Most teams skip this: schedule the follow-up before the first campaign ends. If you wait until the report is written, you will lose the momentum and the context. I have seen red teams finish a campaign, deliver a great report, and then the company reorganizes three weeks later — new endpoints, new SaaS tools, old gaps back. The interval matters less than the trigger. Define what change in your environment warrants a new campaign, and treat that as your schedule.

Which single metric predicts real-world impact best?

Time-to-persistence, measured as the hours from initial access until the operator establishes a foothold that survives a reboot or credential rotation. That one number correlates with real attack outcomes more reliably than mean time to detect or number of alerts fired. Why? Because it captures two things at once: how well your detection picks up the intrusion, and how quickly your response team actually acts on the signal. A short time-to-persistence means your defenders are either blind or slow. Either way, the adversary controls the timeline.

That said, don't fixate on it alone. A low time-to-persistence can look great while your email gateway lets every phishing link through. The metric only makes sense when paired with a baseline: initial access vector, difficulty, and whether the operator had to use a known vulnerability or a novel one. One concrete example: we ran a campaign where the operator got persistence in four hours via a forgotten test admin account. The detection metrics looked fine — all alerts fired, none were noisy. But nobody triaged them for six hours. That gap was the real finding, and no single score would have surfaced it without the context of the alert queue backlog.

“A metric without a decision attached is just a number you can ignore. Ask what you would change if it moved 20%.”

— red team lead, mid-size SaaS firm

Choose your metric based on what you can act on. If you can't fix the alert queue, tracking time-to-persistence is theatre. If you can, it becomes your best early-warning gauge.

Takeaways: A Short List of KPIs That Matter

Five metrics earn their place. Median time-to-detection, not average—one outlier will lie to you. Time-to-containment, measured from first alert, not from when someone finally reads the ticket. Persistence breadth, meaning how many distinct footholds survived past day three. Recurrence count, because attackers who get kicked out once often walk back in through the same open door. And dwell time per credential set, which tells you if your password reset actually mattered.

Boards want risk, not log counts. Draw a single timeline with three bands: red for undetected, amber for contained-but-present, green for clean. Put the median detection time as a number at the top. Then add one bullet: "Would a $5M payment change this picture?" That question frames the whole conversation. The odd part is—boards understand dwell time instantly when you frame it as rent. "The attacker lived in your network for 19 days. That's 19 days of free rent."

What usually breaks first is the confidence interval. You ran one 30-day campaign, so you have one sample. Present it as a baseline, not a benchmark. Good phrasing: "We saw X, which suggests Y—but we need two more cycles before we trust the number." No invented precision. That credibility gap closes when you show the raw jam: screen recordings, alert timestamps, the Slack thread where nobody responded for six hours.

Drop the percentage of phishing simulations clicked. Drop total alerts generated. Drop "detection rate" without a denominator. Those numbers reward noise.

"If the KPI doesn't force an uncomfortable conversation, it's just decoration."

— red team lead, after a third failed tabletop exercise

Instead, track one metric you hate: cleanup completeness. Count every implant, every dropped file, every modified registry key. Then check your defenders' closure rate on those artifacts. We fixed this by making the red team score themselves on leaving zero artifacts behind. Painful. Honest. That number surfaces more real gaps than any dwell-time chart ever will.

Present outliers as events, not noise. A single 45-minute detection on day 12 beats a uniform 15-minute average across all days—one tells you about a busy weekend shift, the other tells you nothing. Write the exception in the report. Next quarter, you will have two data points. Then three. That's how sustained programs earn their keep.