"10 hours" and "around two weeks" are not the same kind of number

mars70s — Sun, 20 Sep 2026 16:44:27 +0000

In September 2026, Palo Alto Networks Unit 42 published a case involving
an AI-assisted intrusion into an enterprise network. The article includes
figures like "less than 10 hours," "more than 50 MITRE ATT&CK techniques,"
and "around two weeks" for what a human operator would normally need.

It's tempting to divide those numbers and conclude "AI made this 30x faster."
I don't think the source material supports that.

Two different kinds of numbers

"Less than 10 hours" is a reported duration of activity.

"Around two weeks" is Unit 42's comparative assessment of what a human
operator would typically require for impact of that scale.

The public article doesn't include a same-conditions human-only comparison,
team size, skill composition, tools used, or a detailed calculation method.
So "AI turned two weeks into 10 hours" isn't a measured speedup ratio —
it's two different types of numbers sitting next to each other.

The article changed after publication

I checked the Wayback Machine capture from the publication date against
the current version. Two things changed:

"as part of a ransomware attack" → "as part of a ransom attack" (the page's own update history later clarifies this was an intrusion, not a ransomware attack)
"public API endpoint" → "publicly accessible web service"

The second change isn't explained in the page's own changelog. I can't
establish when it happened or why — so I don't speculate. I just note
that the wording changed.

What's actually confirmed about AI use

Two separate evidence paths exist:

The threat actor's own account (told to Unit 42 during negotiations) that they used frontier AI models and attack-specific agentic frameworks
Technical indicators Unit 42 observed independently — parallel LLM calls, structured Markdown passed between agents, custom scripts

Both matter. Neither, alone or together, establishes that AI autonomously
ran every stage of the intrusion. Unit 42's own Figure 1 shows a human
actor setting objectives and making key decisions while agents execute —
closer to human-directed / agent-executed than fully autonomous.

A hypothesis worth testing: parallelization, not just speed

Here's where I'll go beyond what Unit 42 states. The public material
can't tell us how many times faster any single task became. But it does
describe multiple agents, parallel LLM calls, and state handed off across
sessions — which suggests a different question:

Maybe the effect of AI-assisted intrusion isn't mainly per-task speedup.
Maybe it's lower coordination cost and handoff latency when running
multiple workstreams in parallel.

If that's right, the interesting metrics aren't total elapsed time —
they're things like: how many agents/sessions ran concurrently, how much
independent tasks overlapped in time, how long from observation to next
action, what share of time went to human-approval waits.

This hypothesis also has a clear failure mode: if a detailed timeline
showed activity was mostly sequential, with few concurrent agents and
long approval waits, the parallelization story falls apart.

Full writeup

I go through the source comparison, the evidence paths, and the
full list of what remains unknown in more detail here:

https://osiix.com/en/library/unit42-ai-assisted-intrusion.html

This article independently reviews public material and does not
indicate any approval, supervision, or affiliation by Palo Alto
Networks or Unit 42.

Restorable Backup Safe Cyber Recovery

mars70s — Sat, 19 Sep 2026 13:58:41 +0000

You have multiple generations of backups. The newest one restores fine.
Ransomware was detected today. But you don't actually know when the
intrusion started.

The natural instinct: restore the latest backup. But "restorable" and
"safe to adopt as your recovery point" are not the same claim.

This is one chapter from a self-study book I've been writing on Backup /
Recovery / Archive design. Here's the short version.

Latest ≠ Correct

A backup taken after compromise may already contain:

encrypted data
corrupted state
some other form of unsafe state

This doesn't mean "newer is dangerous." It means newness alone doesn't
prove correctness.

False signals of "clean"

The chapter lists reasons people wrongly declare a backup safe — none of
which, alone, proves it:

it restored successfully
it was protected as immutable
the hash matched
antivirus scan passed
it predates the detection time

Each is a useful signal. None is proof on its own.

Two checkpoints, not one

NIST's guidance on cyber recovery separates verification into two stages:
checking the recovery asset before you use it, and checking the restored
system before you put it back into production. One check is not enough.

The discipline that matters most

"Don't turn 'unknown' into 'safe.'"

When the intrusion start time is uncertain — which it often is — that
uncertainty doesn't disappear just because you'd like to move forward.
The chapter treats "we don't know" as an honest state, not a failure to
be papered over.

Full chapter: https://osiix.com/en/library/backup-recovery-archive-fundamentals/chapter-11.html
Book index: https://osiix.com/en/library/backup-recovery-archive-fundamentals/

DEV Community: mars70s