Lion Cipher Lab

Characterize a banking trojan's web-injects: targeted banks and browser manipulation

Why it matters

Banking web-injects are, per Recorded Future, a top cyber threat to the financial sector — and they are the reason a padlock in the address bar is not a promise your session is safe. When a banking trojan owns the browser, TLS still encrypts the wire perfectly; the theft happens inside the browser, after the page is decrypted and before it's drawn, where the lock icon can't see it. An analyst who can take a captured web-inject config and read it cold — which banks are targeted, what the injects add to the login page, where the stolen data is sent — turns a single infected laptop into…

What you'll learn

Steps in this lab

  1. The scenario, and the one idea that makes it all make sense
  2. Artifact 1 — the decoded web-inject config, and the target list inside it
  3. Artifact 2 — how the inject rewrites the live page (and why the extra fields matter)
  4. Artifact 3 — the browser-hook evidence: the man-in-the-browser mechanism
  5. WHY man-in-the-browser defeats TLS — the part people get wrong
  6. Artifact 4 — the network traffic: config pull and credential exfil
  7. Map it to MITRE ATT&CK — naming the behavior
  8. The third rule — when the config is enough, why TLS won't save you, and how a pro finishes

Open the full interactive lab →