Speaker: Sonia Seddiki (Dev turned DevOps turned security enthusiast, passionate about CTFs and reverse engineering)
Context
Though WannaCry is an old incident (2017), the speaker used it to explore core cybersecurity techniques, reverse engineering, and malware analysis — Those skills surprinsgly are highly relevant today for developers as debugging is really close to reverse engineering
Background
-
The speaker transitioned from development to DevOps out of necessity, and gradually into cybersecurity through a love of debugging and CTFs.
-
She drew a parallel between reverse engineering malware and debugging tricky production issues — it’s fundamentally about dissecting systems you didn’t write and figuring out how they break.
Story of WannaCry
-
WannaCry was a ransomware attack that exploited the EternalBlue vulnerability — a Windows SMB exploit originally discovered and hoarded by the NSA, then leaked by a group called The Shadow Brokers.
-
It infected hundreds of thousands of systems globally in May 2017 before a researcher accidentally activated a killswitch by registering a hardcoded domain name the malware checked for.
Technical Dive
The speaker walked through the reverse engineering process using:
-
Ghidra (NSA’s open-source reverse engineering tool)
-
Memory forensics
-
Malware behavior analysis
Key steps covered:
-
Analyzing the .exe sample
-
Tracing its use of Windows Crypto API for encryption routines
-
How to locate the private encryption key in memory on an infected system — crucial for potential file recovery in ransomware scenarios
Takeaways
-
Reverse engineering and debugging are closely related skills — both require curiosity, system-level thinking, and the ability to reason about unknown or opaque systems.
-
Even old incidents like WannaCry remain valuable case studies for understanding how malware propagates, how vulnerabilities get exploited, and how defenders can respond.
-
Memory forensics and API call tracing remain powerful tools when dealing with active incidents or suspicious binaries.