
Goal is to triage well known attacks and learn how security teams quickly respond.
For this lab, the goal was to triage another well-known real-world vulnerability, this time EternalBlue, the SMBv1 flaw that was famously exploited by the WannaCry ransomware outbreak.
I went to the National Vulnerability Database and looked up the CVE:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
I searched for CVE-2017-0144 and opened the result page.
After reading through the description, I answered a few basic questions to understand what's actually at risk:
I found the CVSS score and vector string listed on the page:

I went through the vector string piece by piece to see what each part actually meant:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
This one requires a small amount of privilege to exploit (unlike ProxyLogon, which needed none), but it still doesn't need any user interaction, and a successful attack still fully compromises confidentiality, integrity, and availability. That combination is a big part of why EternalBlue was so dangerous once it was paired with a self-spreading worm like WannaCry.
I checked the Weakness Enumeration section on the NVD page for this CVE, but no CWE was listed for it.
I considered whether I'd treat this as higher or lower risk under two different scenarios.
Scenario 1: The vulnerable software is live and reachable. Higher risk. This vulnerability lets an attacker remotely access the server, run code, and access files.
Scenario 2: The vulnerable software is installed on a machine that's powered off and not reachable. Lower risk. With no power or network connection, there's no way for an attacker to actually reach the server to exploit the vulnerability in the first place.
Comparing this to the ProxyLogon triage, it's a good example of how two critical vulnerabilities can still differ in the details, EternalBlue needs low privileges where ProxyLogon needed none, but both still land in the "treat as high risk" category once you look at how much damage a successful exploit could do. Just like before, actual risk still comes down to context: the same vulnerability is far less dangerous on a machine that's offline and unreachable.