How Mirai Actually Infects a Device

root · February 18, 2026, 8:39am

Mirai Botnet Series — Part 2 of 6

Part	Title	Status
1	From Zero to Botnet: What Is a Botnet and Why Should You Care?
2 — You are here	How Mirai Actually Infects a Device
3	I Opened Mirai’s Source Code — Here Is What I Found
4	I Read Mirai’s Scanner Code — Here Is How It Infects Millions
5	I Read the Brain of Mirai — How the C2 Server Actually Works
6	Mirai’s Weapons — How 600,000 Cameras Brought Down the Internet

View the Full Series Index

← Previous: Part 1: From Zero to Botnet | Next → Part 3: I Opened Mirai’s Source Code

(Told by someone who was confused about it too)

Blog 2 of 6 in the Mirai Botnet Series

When I started looking into how Mirai infects devices, I had one burning question nobody seemed to answer clearly:

Who is actually doing what?

Like is it the camera that installs the malware? Is it the C2 server? Who is running what?

I was confused. So let me explain it the way I wish someone had explained it to me.

Quick Recap From Blog 1

In Blog 1 we learned:

Mirai is a botnet that turns IoT devices into attack slaves
It finds victims by scanning random public IP addresses
It logs in using default credentials like admin/admin
Infected devices report to a C2 server and wait for attack orders

But HOW does the infection actually happen step by step?

That is what this blog is about.

Part 1 — The Knock (SYN Scanning)

Before Mirai can infect anything, it needs to find vulnerable devices.

It does this using something called a SYN scan.

To understand this, you need to know how two computers normally start talking. It is called the TCP three-way handshake:

Three steps. Only after all three does communication begin.

Normal scanning completes all three steps for every single IP address. Slow. One at a time.

Mirai does something smarter:

Normal scan:
IP 1: SYN → wait → SYN-ACK → ACK → "noted" → next
IP 2: SYN → wait → SYN-ACK → ACK → "noted" → next
(painfully slow, one at a time)

Mirai SYN scan:
Send SYN to IP 1, 2, 3, 4, 5... all at once
Collect whoever sends SYN-ACK back
Never complete the handshake
(thousands happening simultaneously)

Think of it like throwing rocks at 1000 windows simultaneously. See which lights turn on. Only visit those houses.

SYN-ACK response = port 23 is open = Telnet is running = potential victim.

Mirai generates random IP addresses and fires SYN packets at them non-stop. Millions of IPs per second. When something responds, it gets added to the target list.

Part 2 — The Login Conversation

Found a device with Telnet open. Now what?

Mirai tries to log in using a list of 63 default username and password combinations. But this is not as simple as:

try admin/admin → wrong → try next

It is a staged conversation. Like calling a bank’s automated phone system you have to wait for each prompt before you can respond:

Stage 1 — Connecting to device
Stage 2 — Handling Telnet negotiation
Stage 3 — Waiting for username prompt
Stage 4 — Sending username, waiting for password prompt
Stage 5 — Sending password, waiting for response
Stage 6 — Waiting for shell prompt to confirm login worked

You cannot skip stages. You go through them in order.

And Mirai has hundreds of these conversations happening simultaneously. So it tracks the exact stage of every single connection:

Connection 1:   waiting for username prompt
Connection 2:   just sent password, waiting for response
Connection 3:   still connecting
Connection 247: waiting for shell prompt

Without tracking stages, Mirai would get confused. Sending a password when the device is asking for a username. Sending a username when the device already gave a shell. Everything would break.

Tracking the stage = knowing exactly what to say next.

This is one of the things that makes Mirai’s scanner efficient. Not just speed. Precision.

Part 3 — “Found One!” (The Report Server)

Login succeeded. Mirai is in.

Now here is the part that confused me the most when I first read about this.

The bot that found the victim does NOT install the malware.

Let me say that again because I had to read it three times before it clicked.

The infected camera that scanned the internet and cracked the login does not install anything. It just reports what it found.

Think of it like a bounty hunting operation:

Scout    = finds targets, reports their location
HQ       = receives reports, coordinates the team
Operative = actually does the job

In Mirai’s architecture:

Bot (scanner)    = finds victim, cracks login, reports credentials
Report Server    = receives the report
Loader           = actually installs the malware on the victim

So the real flow looks like this:

Vietnam camera (already infected bot)
        │
        │ scans internet, finds router in Brazil
        │ cracks login: admin/admin
        │
        ▼
Report Server (on attacker's infrastructure)
        │
        │ "Got one! IP: x.x.x.x, creds: admin/admin"
        │
        ▼
Loader (also on attacker's infrastructure)
        │
        │ connects directly to Brazil router
        │ logs in using admin/admin
        │ uploads and executes the malware
        │
        ▼
Brazil router is now infected
Connects to C2, becomes a new bot
Starts scanning for more victims

Three separate programs. All running on the attacker’s server:

ATTACKER'S SERVER:
├── C2 Server      (sends attack orders to all bots)
├── Report Server  (receives "found victim" reports from bots)
└── Loader         (installs malware on newly found victims)

The C2 server is only involved after infection is complete. The Loader does the actual dirty work of installing.

Part 4 — But Which Malware File?

Here is where it gets clever.

Mirai targets cameras, routers, and DVRs from all over the world. Different devices have different CPU architectures:

Camera from China:    ARM processor
Router from Brazil:   MIPS processor
DVR from Germany:     x86 processor

Code compiled for one CPU will not run on a different CPU. It is like trying to run an Android app on an iPhone. Same idea, completely incompatible.

So Mirai pre-compiles eight different versions of itself:

mirai.arm
mirai.mips
mirai.mpsl
mirai.x86
mirai.sh4
mirai.ppc
mirai.spc
mirai.m68k

But how does the Loader know which version to send to which device?

It runs one simple command on the victim after logging in:

cat /bin/echo

That is it. One command.

Every Linux device has a file called /bin/echo. And every Linux binary file starts with something called an ELF header a small block of bytes that describes the file, including what CPU architecture it was compiled for.

The output looks like garbage to human eyes, but the important part is right at the beginning:

ELF > p - @ ( ▯ @ 8 @ @ @ ...

See that “ELF” at the start? A few bytes in, there is a field called e_machine that literally identifies the CPU this binary was compiled for.

/bin/echo on ARM device:
  ELF header → e_machine = ARM → Loader sends mirai.arm

/bin/echo on MIPS device:
  ELF header → e_machine = MIPS → Loader sends mirai.mips

/bin/echo on x86 device:
  ELF header → e_machine = x86 → Loader sends mirai.x86

The device reveals its own CPU architecture without knowing it.

No special scanning tools needed. No OS detection needed. Just read a file that already exists on every single Linux device. Elegant and simple.

Part 5 — The Disappearing Act

Malware is uploaded. Malware runs.

Now Mirai does something immediately after execution.

It deletes itself from disk.

Malware uploaded to /tmp/
        │
        ▼
Malware executes
        │
        ▼
Malware deletes its own file from disk
        │
        ▼
Malware still running — in RAM, not on disk

If an investigator checks the filesystem: nothing there.

If antivirus scans the disk: nothing there.

If the device owner looks for suspicious files: nothing there.

Invisible. Clean. No evidence on disk.

But here is the catch.

RAM is wiped on every reboot. So if the device restarts, the malware disappears completely.

Sounds like a problem for the attacker, right?

It is not. Because:

Device reboots.
Malware is gone from RAM.
But...
Default credentials are still the same.
Telnet port 23 is still open.
The vulnerability was never fixed.

Within minutes:
Another bot scans it.
Finds port 23 open.
Cracks admin/admin again.
Reinfects it.

The vulnerability was never patched. Just the malware was temporarily removed. The attacker does not care the device will be reinfected automatically by the botnet itself.

Part 6 — The Complete Infection Flow

Let us put everything together from start to finish:

PHASE 1 — FIND
Already infected bot sends SYN packets
to millions of random IP addresses.
Collects every device that responds with SYN-ACK.
(Telnet port 23 is open on that device)

        │
        ▼

PHASE 2 — CRACK
For each device found:
Bot goes through staged Telnet login conversation.
Tracks exact conversation state.
Tries 63 default credential combinations.
If one works → login succeeded.

        │
        ▼

PHASE 3 — REPORT
Login succeeded.
Bot sends report to Report Server:
IP address + working username + working password.

        │
        ▼

PHASE 4 — DELIVER
Loader receives the report.
Logs into victim device using provided credentials.
Runs "cat /bin/echo" to detect CPU architecture.
Reads ELF header, identifies architecture.
Uploads correct malware binary.
Executes it.

        │
        ▼

PHASE 5 — VANISH
Malware deletes itself from disk immediately.
Invisible to forensics and antivirus.
Still running in RAM.

        │
        ▼

PHASE 6 — REGISTER
New bot connects to C2 server.
C2 adds it to the list.
New bot starts scanning for more victims.
Cycle repeats from Phase 1.

What I Found Confusing (And Now Don’t)

The biggest confusion I had was who runs what. So let me end with this clean picture:

ATTACKER'S SERVER runs:
├── Report Server  (receives victim reports from bots)
├── Loader         (installs malware on victims)
└── C2             (commands all infected bots)

INFECTED BOTS run:
├── Scanner        (finds new vulnerable devices)
└── Attack module  (executes DDoS when C2 orders it)

UNINFECTED DEVICES (not yet victims):
├── Telnet port 23 open
├── Default credentials unchanged
└── Just waiting to become the next bot

Three separate worlds. Three separate roles. One coordinated infection machine.

What We Learned

SYN scan      =  send millions of SYN packets, collect who responds
Telnet        =  port 23, remote login, how Mirai gets in
Staged login  =  tracking conversation state across thousands of connections
63 creds      =  the default username/password list hardcoded into Mirai
Report Server =  receives "found victim" reports from infected bots
Loader        =  the program that actually installs malware on victims
ELF header    =  first bytes of every Linux binary, reveals CPU architecture
Delete itself =  malware removes disk evidence immediately after running

In Blog 3, we crack open the actual Mirai source code. We look at the scanner line by line the IP generation logic, the connection state machine, the credential list, and the exact function that reads the ELF header to pick the right binary.

Time to get technical.

Resources

Previous: Blog 1 — What Is a Botnet
Next: Blog 3 — Infection Code Deep Dive: Reading Mirai’s Source