Skip to main content
ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

Security / Research

Case files

13 sourced case studies · Malware, architecture and engineering

Case indexExpand a file for its diagram and references

Android malware 4

FluBot · 2020–2022 · Source-based

FluBot: the Android banking trojan that texted its way outward

SMS lures, sideloaded app, accessibility abuse, overlay credential theft and contact-driven propagation.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Smishing link
  2. Sideloaded APK
  3. Accessibility and overlays
  4. Contact SMS propagation

Proposed defensive checks

  1. Filter fraudulent SMS lures
  2. Verify app provenance
  3. Review accessibility grants
  4. Detect abnormal SMS use

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: What happens when a dangerous permission becomes both a credential-theft path and a spreading mechanism?

Triada · 2016–2019 · Source-based

Triada: malware inside the Android system image

A preinstalled system-image backdoor changes where the mobile trust boundary begins.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Third-party firmware process
  2. Modified system image
  3. Privileged execution
  4. OEM security update

Proposed defensive checks

  1. Audit firmware suppliers
  2. Verify image signatures
  3. Check platform integrity
  4. Ship trusted security updates

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: What can an app-level detector guarantee if the system image itself is already altered?

Joker / Bread · 2017–2020 · Source-based

Joker / Bread: billing fraud hidden in Android apps

Google documented an adaptive billing-fraud family that changed techniques as Play defenses tightened.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Disguised app
  2. Dynamic/cloaked behavior
  3. Subscription abuse
  4. Play Protect response

Proposed defensive checks

  1. Review package behavior
  2. Inspect dynamic code paths
  3. Verify payment consent
  4. Monitor subscriptions

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Why is a clean-looking package or successful store review not a substitute for monitoring malicious behavior?

Toll fraud malware · 2022 · Source-based

Android toll fraud: subscriptions, OTPs and invisible consent

Premium-service subscriptions can be triggered through malicious app behavior and intercepted one-time codes.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Malicious application
  2. Network / billing path
  3. OTP interception
  4. Premium subscription

Proposed defensive checks

  1. Audit app permissions
  2. Observe billing network paths
  3. Protect one-time-code handling
  4. Reconcile unusual charges

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: How do permission grants and network-path changes affect the integrity of a billing workflow?

Worms & malware 6

WannaCry · 2017 · Source-based

WannaCry: a patchable SMB flaw becomes a global worm

The gap between MS17-010 and the May outbreak is as important as the ransomware payload.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Exposed vulnerable SMB
  2. EternalBlue exploitation
  3. Automated propagation
  4. Ransomware impact

Proposed defensive checks

  1. Apply MS17-010
  2. Reduce SMB exposure
  3. Segment lateral traffic
  4. Test offline recovery

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: How does one exposed lateral-movement protocol turn a local failure into fleet-wide impact?

NotPetya · 2017 · Source-based

NotPetya: an accounting-software update becomes destructive malware

A trusted update channel and enterprise lateral movement turned an apparently ordinary update into systemic disruption.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. M.E.Doc update path
  2. Initial compromise
  3. Lateral spread
  4. Destructive outage

Proposed defensive checks

  1. Verify software provenance
  2. Limit updater privileges
  3. Segment admin access
  4. Maintain isolated recovery

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Which control fails first when a legitimate software delivery path becomes hostile?

Mirai · 2016 · Source-based

Mirai: IoT passwords as a distributed attack surface

Default device credentials and remote management services enabled a large, centrally directed IoT botnet.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Internet-exposed IoT
  2. Default credentials
  3. Botnet enrollment
  4. DDoS traffic

Proposed defensive checks

  1. Disable unnecessary Telnet
  2. Provision unique credentials
  3. Protect firmware updates
  4. Detect outbound abuse

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: What does credential hygiene mean when thousands of unattended devices share factory defaults?

Melissa · 1999 · Source-based

Melissa: a Word macro virus meets an Outlook address book

Document-macro infection and automated email forwarding overloaded enterprise mail systems.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Word attachment
  2. Macro enabled
  3. Document infection
  4. Outlook address-book mail

Proposed defensive checks

  1. Restrict macros
  2. Screen attachments
  3. Bound automatic mail sending
  4. Monitor mail spikes

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Why can a local document execution become a network-wide availability incident?

Raspberry Robin · 2022 · Source-based

Raspberry Robin: a USB worm that fed later intrusions

LNK-based removable-media spread and staged delivery connected local infection to larger attacker ecosystems.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Infected USB
  2. LNK execution
  3. Staged persistence
  4. Follow-on intrusions

Proposed defensive checks

  1. Restrict untrusted media
  2. Log shortcut execution
  3. Track staged persistence
  4. Review follow-on activity

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: How would you distinguish initial access, persistence and later operator activity in one incident timeline?

Stuxnet · 2010 · Source-based

Stuxnet: when software crossed into industrial control

The significant boundary was not just Windows execution; it was interference with physical control logic.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Windows entry
  2. Control software discovery
  3. PLC-facing interference
  4. Physical process risk

Proposed defensive checks

  1. Isolate engineering hosts
  2. Authorize control changes
  3. Monitor controller integrity
  4. Enforce physical safety stops

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Where should an operator validate command provenance when digital commands affect physical processes?

Architecture & engineering 3

ROS 2 lifecycle · Design reference · Source-based

ROS 2: lifecycle states before a robot starts moving

Managed node states make startup and recovery observable, but the motion-control policy still needs an independent safety boundary.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Unconfigured
  2. Inactive / verified
  3. Active
  4. Error and recovery

Proposed defensive checks

  1. Configure each component
  2. Verify inputs before activation
  3. Require signed commands
  4. Fail safe and recover deliberately

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: What must be true before software is permitted to activate actuators?

AES-GCM / AEAD · Design reference · Source-based

AEAD: encryption should bind data to its context

AEAD associated data can bind an encrypted record to its tenant and schema version without hiding that context.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Select record context
  2. Encrypt with AEAD
  3. Store ciphertext + key ID
  4. Verify context on decrypt

Proposed defensive checks

  1. Canonicalize record context
  2. Keep unique nonces
  3. Bind associated data
  4. Authorize decrypt access

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Can a correctly encrypted record be copied into the wrong tenant and still decrypt?

Distributed systems · Design reference · Source-based

Architecture: retry storms are a feedback-loop failure

Retries that look harmless per client can amplify load when a dependency is already struggling.

Read analysis Primary reference
Diagram & engineering question

Reported sequence

  1. Dependency slows
  2. Clients time out
  3. Retries amplify demand
  4. Budget and jitter limit load

Proposed defensive checks

  1. Set retry ownership
  2. Enforce attempt budget
  3. Add randomized backoff
  4. Preserve idempotency keys

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Engineering question: Why should one retry budget and an idempotency contract be enforced across a call chain?

Sources & editorial standards →