Mapping the Mirai Botnet to MITRE ATT&CK

Turning raw findings into a threat intelligence report — and learning to map an attack in a language every SOC speaks.

"I had the findings. What I didn't have yet was a language to hand them to someone else."

In my last two posts, I found a Mirai botnet in a raw Zeek log using nothing but SQL. I had the pieces: a scanner, an internal recon host, an SSH intrusion, and command-and-control beaconing. Findings on their own are not a threat intelligence report. To turn "here's what I found" into something a SOC team could act on, I needed a shared language.

That language is MITRE ATT&CK. This post walks through how I mapped my findings to it — and I'll explain what every tag means in plain English, because I remember exactly how it looked when I first met it in my IBM Cybersecurity Fundamentals course.

What is MITRE ATT&CK, in plain language?

Imagine a giant, shared catalog of everything attackers do — every trick, every step — each with a name and an ID number. That's ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), maintained by the nonprofit MITRE and used by security teams worldwide so everyone describes attacks the same way.

It's organized in two layers:

• Tactics are the why — the attacker's goal at a given moment. "Get in." "Look around." "Phone home."

• Techniques are the how — the specific method. Each has an ID like T1046, and some have sub-techniques like T1110.001.

  
  

So when I say a behavior maps to "Discovery → T1046 Network Service Discovery," I mean: the attacker's goal was to look around (Discovery), and the method was scanning for running services (T1046). One shared sentence, understood by any analyst anywhere.

💡 Why this matters for a job hunt

ATT&CK fluency is a named requirement in most SOC and threat-intel postings. Being able to take raw findings and map them cleanly — including knowing where the edges of your evidence are — is exactly what the role asks for.

The report: TIR-2026-001

I packaged everything into a formal artifact: TIR-2026-001 (Threat Intelligence Report, number 001 — my first). A real TIR has a standard shape: executive summary, key findings, indicators of compromise, ATT&CK mapping, timeline, and recommendations. I'll walk through the ATT&CK section here, tactic by tactic.

One rule I held throughout, learned the hard way in this series: every tag has to be backed by evidence I can point to in the data. If I only suspect something, it gets labeled as suspected — not stated as fact. A mapping is only as trustworthy as the findings under it.

Tactic 1 — Reconnaissance & Discovery: the attacker looks around

Before an attacker strikes, they map the terrain: which machines are alive, what services are running, where the doors are.

T1595 — Active Scanning. In plain terms: probing systems to see what's out there. My infected host .43 sprayed 338,181 external IPs, and .50 swept the internal network with ping-style probes. Knocking on doors to see who answers.

T1046 — Network Service Discovery. Once you know a machine is alive, you check what it's running — is port 445 (file sharing) open? Port 22 (SSH)? Host .50 did exactly this across 771 internal machines, probing HTTPS, SMB, RPC, and FTP, building a map of services.

T1018 — Remote System Discovery. The "who's alive?" step — finding which systems exist at all, often with ICMP ping sweeps. .50's tens of thousands of ICMP probes fit here

Tactic 2 — Credential Access: guessing the password

Here's a distinction that tripped me up: brute-forcing a password is not "Initial Access" in ATT&CK. It's Credential Access — the goal of stealing or guessing credentials.

T1110.001 — Brute Force: Password Guessing. An external attacker, 5.45.85.158, repeatedly tried to log in over SSH — the digital equivalent of trying thousands of keys in a lock. The .001 sub-technique means "password guessing" specifically, as opposed to cracking stolen hashes offline.

💡 Why the tactic label matters

Brute force leads to getting in, but the guessing itself is about credentials. Getting this right is a small signal that you actually understand the framework rather than just pattern-matching keywords.

Tactic 3 — Initial Access: actually getting in

Once the attacker has a working credential, they walk through the door.

T1133 — External Remote Services. Using a remote-access service (like SSH) from outside to get onto the network. That's exactly what happened: SSH from the public internet into an internal host.

T1078 — Valid Accounts. Using legitimate credentials to access a system. The evidence it succeeded: 5.45.85.158 held an interactive session with host .43 lasting 3 hours and 18 minutes, moving about 4 MB of data. Not a failed login — someone inside, using a real account.

Tactic 4 — Command & Control: phoning home

Once a machine is compromised, it needs to receive orders. It "beacons" — checks in with a server the attacker controls, on a schedule.

T1071.001 — Application Layer Protocol: Web Protocols. Attackers hide check-ins inside normal-looking web traffic so it blends in. Host .60.22 beaconed to four external servers on a steady ~755-second rhythm.

⚠ An honest hedge

I tagged this as likely, not confirmed. The traffic ran on non-standard ports, and a port alone doesn't prove the protocol — confirming it's really web traffic would need a look at the packet contents. Saying "likely" here isn't hedging for its own sake; it's being precise about what the evidence actually shows.

T1571 — Non-Standard Port. Instead of the usual web ports (443, 80), the beacons went to ports 4431 and 8343 — numbers chosen to look almost legitimate (4431 echoes 443). A deliberate blend-in tactic, confirmed in the data.

T1008 — Fallback Channels. Attackers build in backups so losing one C2 server doesn't cut them off. My beacon traffic split almost evenly across four servers and two ports — textbook redundancy.

Tactic 5 — Impact: the endgame

T1498 / T1499 — Network Denial of Service. This is what Mirai is for: conscripting devices into a botnet that floods targets with traffic until they crash.

⚠ Objective, not observed

I tagged this as the objective, not an observed behavior. My data shows the recruitment and the C2 — it does not show an actual DDoS being launched. Naming the goal is useful context; claiming I saw it would be a lie the data can't back.

The full ATT&CK mapping

Here's the complete mapping from TIR-2026-001, with a confidence tag on each: confirmed (observed in data), likely (inferred), or objective (the threat's goal, not observed).

Tactic	Technique	ID	Confidence
Reconnaissance	Active Scanning	T1595	Confirmed
Discovery	Network Service Discovery	T1046	Confirmed
Discovery	Remote System Discovery	T1018	Confirmed
Credential Access	Brute Force: Password Guessing	T1110.001	Confirmed
Initial Access	External Remote Services	T1133	Confirmed
Initial Access	Valid Accounts	T1078	Confirmed
Command & Control	App Layer Protocol: Web Protocols	T1071.001	Likely
Command & Control	Non-Standard Port	T1571	Confirmed
Command & Control	Fallback Channels	T1008	Confirmed
Impact	Network Denial of Service	T1498/T1499	Objective

Mapped against MITRE ATT&CK Enterprise v19.1.

The whole picture — with a twist

Laid out as an attack chain, the tactics tell a story: the attacker looked around (Recon/Discovery), guessed a password (Credential Access), got in (Initial Access), set up remote control (C2), all toward an eventual DDoS (Impact).

My timeline analysis revealed a twist — and it's why a report is more than a list of tags. The recon and C2 were already running about 28 hours before the SSH intrusion I could see. The intrusion explains one host; it doesn't explain the others, which were compromised earlier. So the neat left-to-right chain is real for .43, but the network was already infected before the attacker in my logs showed up. A good report says that plainly instead of forcing the evidence into a tidy sequence.

A workflow for verifying ATT&CK mappings

ATT&CK gets updated regularly — techniques get renamed, renumbered, split, or retired between versions. So before I trust any mapping, mine or anyone else's, I run a simple checklist. I built this after realizing my own draft was mapped against an older version than the current one:

1. Verify the ATT&CK version you're mapping against (e.g. v19.1) — and state it explicitly.

2. Check each technique ID exists in that version.

3. Confirm any referenced sub-techniques still exist (e.g. T1110.001).

4. Verify the technique name hasn't changed since the version you learned it in.

5. Make sure the tactic(s) are still accurate — this is where I caught that brute force sits under Credential Access, not Initial Access.

6. Update your documentation so every artifact — report, blog, repo — references the same ATT&CK version.

   
   

It takes ten minutes on attack.mitre.org, and it's the difference between "ATT&CK-fluent" and "mapped against a version that's two releases stale." For a report someone might act on, that check isn't optional.

What I learned building my first TIR

A tag is a claim, and claims need evidence. The temptation is to map aggressively — more tags looks more impressive. But every tag a reader can't trace back to the data is a crack in the report. I labeled two mappings "likely" and one "objective" precisely because the evidence didn't fully support "confirmed." That restraint is the report's support, not its weakness.

Precision is the skill. Knowing that brute force is Credential Access, or that a non-standard port doesn't confirm a protocol — those small distinctions separate someone who's memorized ATT&CK IDs from someone who can actually use them.

The framework turns findings into communication. My SQL queries found the botnet. ATT&CK is what lets me hand those findings to a SOC team, a hiring manager, or a future me, and have them understood immediately.

🔗 ISC2 CC Domain Connections

This work reinforces Domain 4 (Network Security — scanning, unauthorized access, C2) and Domain 5 (Security Operations — incident identification, indicators of compromise, and structured reporting). Threat intelligence and IOC-driven reporting sit at the heart of SOC operations.

→See the full report & the code

The complete TIR-2026-001 — executive summary, IOCs, full ATT&CK mapping, timeline, and recommendations — plus every query behind these findings, reproducible against the public dataset, on GitHub.

Start from the beginning: What I Found in a Zeek Dataset and Detecting C2 Beaconing with SQL. Mapped against MITRE ATT&CK Enterprise v19.1.