Hero Ben Brundage - Are Tiny Networked Devices in Your Home Part of a BotNet?

WSJ resource : https://www.wsj.com/tech/personal-tech/residential-proxy-network-cybersecurity-botnets-03856c7f

https://spur.us/context/me (from the podcast show notes)

If he hadn't taken time off studying for his finals, the internet might have died - so says the WSJ :)

Bigger than Stuxnet, but KimWolf was no match for Benjamin Brundage of Seattle

Back to the point : if you're making money off your network, but sharing bandwidth, be warned. Who does that anyway? Are ghetto people that smart? Maybe word gets around

How You Can Defeat Ransomware After the Hack

A practical guide to whether preserved clean and encrypted file pairs can help researchers recover decryption capability after a ransomware attack.

Problem Statement

Is it possible to deliberately preserve a small set of files, along with backups of their original versions, so that if a ransomware attack occurs, security researchers could compare the pre-encryption and post-encryption versions and potentially recover the decryption key or otherwise build a decryptor?

If so:

1. Is there a canonical or especially useful set of file types that should be preserved for this purpose?
2. What characteristics make certain files more valuable than others in a known-plaintext or before/after comparison attack?
3. Under what conditions can this approach actually work, and why does it fail against many modern ransomware families?
4. What is the most practical defender-oriented checklist of files and related artifacts to archive now, so that if a future decryptor becomes possible, the chances of successful recovery are maximized?

Defender-Oriented Checklist

The goal is not to assume you will be able to break the ransomware. The goal is to preserve the kinds of artifacts that are most useful if the ransomware later turns out to have made a cryptographic mistake, or if a public decryptor becomes available.

Highest-Value File Types

• PNG files
• PDF files
• DOCX / XLSX / PPTX files
• ZIP files
• One append-heavy database file, such as SQLite
• One or two small text or config files whose original contents are known exactly
• One standard image or template file used repeatedly in the environment

For Each Preserved File, Ideally Keep

• The clean/original copy
• The encrypted version, if an attack occurs
• The original path and filename
• The encrypted filename and any added extension
• Before/after file sizes
• Timestamps
• A SHA-256 hash of the clean file
• A SHA-256 hash of the encrypted file

Incident Artifacts to Preserve

• The ransom note
• At least one sample encrypted file
• The ransomware-added extension, if any
• Any notes about when the attack happened and which systems were affected
• If safely captured by professionals, a copy of the malware binary or launcher

A Practical Minimum Archive Kit

• 1 PNG
• 1 PDF
• 1 DOCX
• 1 XLSX
• 1 ZIP
• 1 append-heavy database file
• 1 small known text/config file
• 1 common template or reference image
• 1 ransom note, if attacked
• Encrypted counterparts of the above, if available

The most useful pair is often the exact same file before and after encryption: same filename, same original location, and a clean version from backup.

Can Preserved Before/After Files Help Recover a Ransomware Key?

Sometimes, yes — but there is no universal canonical set of files that guarantees recovery.

When ransomware researchers succeed by comparing a clean file to its encrypted version, the real reason is usually not merely the existence of a before/after pair. What they are typically exploiting is a cryptographic or implementation mistake in the ransomware.

Examples of mistakes that can make recovery possible include:

• Reused keystream
• Reused nonce or IV
• Weak XOR-style encryption
• Deterministic partial encryption
• Broken key generation
• Improper key reuse across files

If the ransomware uses sound modern cryptography correctly — for example, a fresh per-file symmetric key or nonce, with those keys then protected using the attacker’s public key — then having both the original and encrypted versions of the same file usually does not let you recover the decryption key.

That is why this approach is best understood as an opportunistic recovery aid, not a primary defense strategy.

What Kinds of Files Are Most Useful?

The best files for this kind of analysis are those with highly predictable structure or exactly known content.

These are especially valuable:

• PNG files, because they have a well-defined signature and chunk structure
• PDF files, because they start with recognizable headers and have regular internal structure
• ZIP files
• Office files such as DOCX, XLSX, and PPTX, because they are ZIP-based containers internally
• Small template-based text or config files whose contents are known exactly
• Append-heavy database files, where an older copy and a newer encrypted copy may differ mostly by appended data

The strongest possible sample is not just a “good file type,” but a file whose original bytes are known exactly. A standard company logo, a stock image used everywhere, a blank template, an exported form, or a known installer can all be more useful than a random user-created document.

What Makes This Approach Work?

This approach works only under fairly specific conditions. The biggest enabler is usually a real flaw in the ransomware.

The conditions that can make recovery feasible include:

1. The same key material or keystream is reused across files.
   In that case, one known plaintext/ciphertext pair may reveal information useful for decrypting others.
2. Encryption is partial, patterned, or deterministic.
   Some ransomware encrypts only parts of each file for speed, which can leave useful structure visible.
3. The file format reveals a lot about the plaintext.
   Fixed headers, signatures, and internal structure increase the amount of known plaintext.
4. Multiple files of the same type are available.
   A large set of samples can reveal patterns that a single pair cannot.
5. The clean and encrypted copies are truly corresponding versions of the same file.
   Exact pairing matters. Random clean files of the same type are much less valuable than the real before/after pair.

The decisive factor is almost always whether the ransomware made a mistake. The file set only helps researchers exploit that mistake.

Why This Often Fails Against Modern Ransomware

Many modern ransomware families cannot be defeated this way.

If the ransomware uses correct modern cryptography with:

• fresh per-file keys,
• fresh nonces/IVs,
• proper authenticated encryption, and
• attacker-held asymmetric key wrapping,

then known plaintext is usually not enough to recover the decryption key.

In other words:

There is no magic file set that defeats correctly implemented ransomware.

That is why preserving helpful files is worthwhile as a secondary recovery aid, but attacker-inaccessible backups remain the real defense.

What Is the Real Defensive Strategy?

The practical takeaway is straightforward:

• Preserve helpful file pairs and incident artifacts because they may help researchers later.
• Do not assume cryptanalysis will work.
• Maintain offline, immutable, or otherwise attacker-inaccessible backups.

The preserved-file approach is best viewed as:

A way to improve your odds in the rare cases where the ransomware is flawed — not a substitute for proper backups.

Yes, you can prepare a useful set of files and artifacts that may help future decryptor efforts. But what makes recovery possible is usually a weakness in the ransomware, not the mere existence of those files.

Why? A friend told me about "The Ransomware Hunting Team" by Renee Dudley and Daniel Golden. Said it's not something she'll be recommending to anyone because of how unnecessarily long it is, there were some useful tidbits.

If you're unlucky enough, these are the old folks in the world who can help you out:

https://www.bleepingcomputer.com

Michael Gillespie : https://www.youtube.com/@Demonslay335

Bottom line - if you have an old computer, install nothing that you don't download from a Fortune 50 company :)

Search

Search this blog

Why?

Because the Read aloud thing wasn't showing up on the mobile version, I went into settings and told it to use the Custom for the mobile settings. But now, when I go to View Web Version (on mobile) it no longer shows me the search box. So, on mobile, there is no way to search.