The Backup Wrap-Up

Phishing-resistant MFA could have stopped a Chinese state-sponsored threat actor from spending over a year inside North American academic and medical research networks — and we're going to tell you exactly how it happened and what you need to do about it.
A group called UNC5608, tracked by Google's Threat Intelligence Group (GTIG), exploited a vulnerability unique to REDCap — a research data platform that allows multiple software versions to run simultaneously. They got in via stolen admin credentials, planted custom malware called Infinite.red directly into REDCap's upgrade process, harvested credentials for over a year, then used those credentials to log into Google Workspace as a domain admin and create fake compliance rules to silently forward sensitive research emails — military strategy, geostrategic policy, advanced tech, specific pathogens — straight to Gmail accounts they controlled. And nobody noticed for a very long time.
Prasanna and I break down the full attack chain, then walk through every prevention layer that could have stopped it: inventory management, patching, password hygiene, SSO, phishing-resistant MFA, passkeys, DBSC, context-aware access, compliance rule monitoring, credential separation across security domains, and logging. We also get into what backups can and can't do for you in a long-dwell-time attack like this — and why infrastructure-as-code and truly immutable golden images matter more than you might think.
If you're running any kind of research platform, academic institution, or medical network — or honestly any organization that uses Google Workspace — this one's for you.
Chapters:
00:00 — Intro: The attack that phishing-resistant MFA could have stopped
01:03 — Show intro & woodworking banter
03:26 — What is a living-off-the-land attack?
04:02 — Who is UNC5608 and who did they target?
05:08 — How REDCap's multi-version design was exploited
06:11 — Infinite.red malware and credential harvesting
09:01 — Google Workspace infiltration via fake compliance rules
10:18 — The keywords they were stealing: pathogens, military strategy, and more
11:50 — What could the victims have done differently?
12:42 — Inventory management, patching, and legacy version removal
14:00 — Why you can't trust application-level authentication alone — use SSO
15:18 — Phishing-resistant MFA and why it matters
16:00 — Passkeys, FIDO, and why there are zero known attacks against them
17:57 — Device-bound session credentials (DBSC) and context-aware access
19:38 — Monitor your compliance rules — have a compliance rule for the compliance rule
20:40 — Credential separation across security domains
23:00 — Get some logging — XDR, SIEM, and catching exfiltration in progress
24:00 — What can backups actually do in a long-dwell-time attack?
27:00 — Infrastructure-as-code and the right cyber recovery approach
28:58 — Protecting your golden images with immutable storage
31:59 — Wrap-up

California election fraud claims are flooding social media — and most of them fall apart under basic scrutiny. In this follow-up episode, longtime San Diego County poll worker W. Curtis Preston tackles the wave of viral fraud allegations head-on, with sources so you can check his work yourself.
Topics covered: the LA mayoral race "statistically impossible" surge for Nithya Raman, the AP reporting error that got blamed on fraud, claims that Spencer Pratt voters were having ballots rejected for signatures, the "gym membership card" voter ID myth, the Skid Row "paid to vote" controversy, and yes — the one claim that turned out to be true (a woman who actually did register her dog to vote).
If you've seen these claims and wondered whether there's anything to them, this episode walks through the actual data, the actual law, and the actual outcomes — no spin, just the facts from someone counting the votes.
Here are some sources:
Los Angeles 2026 Mayor primary results:
https://results.lavote.gov/#year=2026&election=4338
Donald Trump got 27% of City of LA vote in 2024:
https://xtown.la/2024/12/16/a-city-country-divide-more-than-70-percent-of-los-angeles-voters-picked-kamala-harris-for-president/
There were 12,700 rejected ballots in all of LA county:
https://perma.cc/E5Y9-NURQ
Orange County woman registered her dog:
https://www.foxla.com/news/costa-mesa-woman-dog-voter-fraud-sentencing
Heritage Foundation Voter Fraud Database:
https://electionfraud.heritage.org/search

California election counting has confused — and frankly ticked off — a lot of people, and I get it. I'm W. Curtis Preston, I've worked every California election since the 2016 presidential primary, and I've managed the polls at multiple elections here in San Diego County. This episode, I'm going solo to explain exactly what's going on, why it takes so long, what the "red mirage" actually is, and why none of it is fraud. Sorry to disappoint some of you.
If you've ever had a family member call you asking "what the hell is going on over there?" — this one's for you. I walk through the specific changes California made to election law, how our system compares to Florida's, why human nature is a big part of the problem, and what the chain of custody for every single ballot actually looks like from the inside. This isn't punditry. This is someone who has stood at those poll books, sealed those ballot cartons, and escorted those ballots to the DART team.
Chapters:
0:00 – Introduction: What the hell is going on in California?
1:23 – Who I am and why I can speak to this
2:12 – How California election law changed six years ago
4:43 – The mail ballot window: postmark by 8 PM, received within 7 days
5:09 – Vote centers vs. the old precinct model
7:39 – California vs. Florida: why the laws produce such different results
9:09 – Why California voters wait until the last minute
14:12 – The red mirage explained: it's not fraud, it's math
15:31 – Signature verification: 80,000–100,000 per day in San Diego alone
16:35 – How computers count ballots — and the 1% manual audit that checks them
19:11 – Chain of custody: two people, sealed cartons, tracked numbers
20:17 – Debunking the "law enforcement can't observe" myth
21:24 – Dead people voting? Let's talk about what's actually happening
22:47 – Wrap-up

Basic cyber hygiene — patch management, password management, and MFA — is responsible for stopping roughly 90% of the ransomware attacks that could hit your organization. This episode is the overview: what those three things are, why they matter, and what happens when you skip them.
WannaCry infected over 200,000 systems worldwide. A patch existed. People just hadn't applied it. Rackspace lost an entire business line — not because the attack was sophisticated, but because a workaround gave them false confidence and they delayed a critical patch. These aren't edge cases. They're the rule.
Dr. Mike Saylor (Black Swan Cybersecurity) and Prasanna Malaiyandi join me to walk through the three pillars of basic cyber hygiene. We cover patch management first — and before you can even patch, you have to know what you have. Inventory is the starting point. Then we get into passwords: why reusing them is a numbers game the bad guys always win, and why a password manager isn't optional anymore. Finally, MFA — what it is, which forms are actually worth using, and why "remember this device" is quietly defeating the whole point.
This is an overview episode. We're going deeper on each pillar in three follow-up episodes. But if you're not doing these three things today, stop reading this and go do them. There's no point talking about EDR, XDR, or any other three-letter security product if you haven't nailed the basics first. It's like researching a Roth IRA when you don't have a savings account.
Chapters:
0:00 Intro
0:59 Welcome & Introductions
4:20 WannaCry: The Patch That Would Have Saved 200,000 Systems
7:33 Rackspace: When a Workaround Isn't Enough
12:12 Defining Basic Cyber Hygiene
14:53 Why These Three Things Stop 90% of Ransomware
17:54 Pillar 1: Patch Management
23:55 Pillar 2: Password Management
31:55 Pillar 3: MFA & Passkeys
37:34 Wrap-Up & What's Next

Claude deletes a company — and the internet immediately blamed the AI. But this story is really about backup design, credential management, and least privilege. An AI coding agent running Claude via Cursor deleted PocketOS's entire production database and all its backups in nine seconds. One bad design decision at a time, a startup built itself a disaster waiting to happen. Claude just happened to be the thing that set it off.
Here's what you need to understand: the AI violated the principles it was given, and that's on Claude. But Claude never should have had access to do what it did. Credentials were sitting in a plain text YAML file. The production database and its backups lived on the same volume. No least privilege. No expiration on elevated permissions. And almost certainly, no backup recovery test — ever.
In this episode, Curtis and Prasanna break down what actually went wrong with PocketOS, what Railway did to help recover the data, and what you need to do to make sure this never happens to you. Topics covered include backup isolation, the 3-2-1 rule, secrets management tools like AWS Secrets Manager and HashiCorp Vault, least privilege access, permission expiration, and credential scanning tools like TruffleHog.
Chapters:
0:00 — Intro: Meet the villain
1:50 — Welcome and introducing "the French friend"
3:48 — What Claude actually did to PocketOS
7:20 — This is a backup story, not an AI story
9:27 — The recovery: Railway, a weekend of chaos, and a lucky Twitter post
12:31 — Your data is your responsibility — not your vendor's
17:48 — Rule #1: Never store backups inside production
20:37 — The real problem: credential management
23:38 — Secrets management tools explained
25:21 — Least privilege and why permissions need expiration dates
34:59 — Finding exposed credentials with TruffleHog
37:24 — Summary and takeaways