Exposed UART → root shell → firmware extraction

§ Context

Assumed environment: physical access to a consumer / SMB IoT device. PCB has standard 3.3V UART headers exposed (the norm for consumer routers / cameras / IoT hubs).

§ Steps

1. 01
   Open the deviceInitial Access

   T1078— Valid Accounts
2. 02
   Drop into U-Boot / Linux init shellExecution

   T1059— Command and Scripting Interpreter
3. 03
   binwalk + ghidra for 0-dayDiscovery

   T1518— Software Discovery
4. 04
   Attach USB-UART at 115200Initial Access

   IOT-UART-CONSOLE— UART Debug Console
5. 05
   Find UART pins (multimeter / Bus Pirate)Initial Access

   IOT-UART-CONSOLE— UART Debug Console
6. 06
   dd /dev/mtdblock* → firmware imageCollection

   IOT-FW-EXTRACT— Firmware Extraction (binwalk / dump)

§ References

• T1078Valid Accounts
• T1059Command and Scripting Interpreter
• T1518Software Discovery

§ Frequently asked

What is the "Exposed UART → root shell → firmware extraction" attack path?

Open the IoT device, locate TX/RX/GND pads, attach a USB-UART, get an unauthenticated root prompt, dump firmware for offline analysis + 0-day hunting. It chains 6 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Open the device (T1078) — a initial access primitive. Assumed environment: physical access to a consumer / SMB IoT device.

What is the final impact of this kill-chain?

The final step lands on dd /dev/mtdblock* → firmware image (IOT-FW-EXTRACT), which falls under Collection. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques3

  AlwaysInstallElevated → SYSTEM via MSI

  Both HKCU and HKLM AlwaysInstallElevated policies set to 1 — any user-installed MSI runs as SYSTEM. Drop a malicious MSI and install it.

• Shared techniques3

  polkit pwnkit (CVE-2021-4034) → instant root

  Pre-2022 pkexec has a heap-overflow exploitable with no special permissions. Compile / drop the exploit, run as low-priv user, gain root.

• Shared techniques2

  nf_tables UAF → kernel R/W → root

  CVE-2024-1086-class nf_tables UAF reachable from a user namespace. Win the race with userfaultfd to land an attacker object in the freed slot, build a kernel R/W primitive, overwrite the current task's cred struct.

• Shared techniques2

  io_uring UAF → modprobe_path overwrite → root

  Use an io_uring UAF to land arbitrary kernel write, repoint /proc/sys/kernel/modprobe to an attacker binary, then trigger a kernel auto-modprobe — runs the binary as root.

• Shared techniques2

  Process doppelgänging → spawn signed image with attacker bytes

  Use NTFS transactional file APIs to overlay an attacker image during process creation. The final mapped process differs from the on-disk file — AV sees only the legit signed image at scan time.

• Shared techniques2

  BYOVD → kernel-level disable of EDR callbacks

  From local admin, load a signed-but-vulnerable driver. Use its kernel primitive to walk the EDR's PsSetCreateProcessNotifyRoutine entries and unlink them — EDR stops receiving events while still 'running'.