Research submission
/Eternal.ain’t.always.forever:445/ Dissecting Malware Leveraging NSA Exploits was a research proposal submitted to ShmooCon as Submission 318. I participated in the submission and acted as a secondary contact in the December 2018 correspondence.
The proposal was not accepted for that conference. This record documents the research submission, rather than a delivered ShmooCon presentation or a published proceedings paper. The surviving status correspondence does not establish the full author list or each contributor’s technical responsibilities.
The question behind the title
The title connects malware analysis with NSA-associated exploitation techniques. Its reference to port 445 suggests an SMB focus. That is an interpretation of the title; the available submission record does not identify the exact samples, exploit variants, experiments, or findings.
The useful defensive question is how to connect an exposed service with the behavior of a suspicious program. A reachable port, an applicable vulnerability, and successful code execution are separate observations. Treating them as interchangeable can turn an interesting lead into an unsupported incident claim.
- Service exposure
Identify the listening service and which network paths can reach it.
- Vulnerability applicability
Check the actual software, configuration, and relevant security updates.
- Execution evidence
Correlate network activity with host events and the suspicious process.
- Payload behavior
Establish what the program did, separately from how it obtained execution.
Historical technical context
Microsoft’s MS17-010 bulletin, published in March 2017, addresses Windows SMB vulnerabilities, including flaws that could allow remote code execution through specially crafted messages to an SMBv1 server. It provides a historical reference for the attack surface suggested by the proposal title. It does not establish which vulnerability or malware sample this proposal analyzed.
A defensive investigation should record the service version and exposure before relating traffic to a vulnerability. It should then connect any suspected exploitation to endpoint evidence. Finally, it should characterize the resulting program’s actions: persistence, propagation, file changes, or other observed effects. Each conclusion needs the artifacts that support it.
Questions that make a dissection reproducible
| Question | Evidence to preserve |
|---|---|
| What artifact was analyzed? | A stable sample identifier, format, architecture, and collection context. |
| Was the service applicable to the suspected flaw? | Software, configuration, and update state. |
| Did the event lead to execution? | A time-aligned relationship between network and host records. |
| What happened afterward? | Process, file, registry, and connection evidence attributable to the program. |
These are explanatory questions for readers, not additional results attributed to the 2018 submission. The archive retains the documented proposal while leaving unverified experimental details open.
For a fully reproducible public example of recovering behavior, see the benign binary-frame walkthrough. For historical propagation analysis, see Mess on Mesh Connections.