Network Security Monitoring Remains Relevant
Cylance blogged today about a Redirect to SMB problem found in many Windows applications. Unfortunately, it facilitates credential theft. Steve Ragan wrote a good story discussing the problem. Note this issue does not rely on malware, at least not directly. It's a problem with Microsoft's Server Message Block protocol, with deep historical roots.
(Mitigating Service Account Credential Theft on Windows [pdf] is a good paper on mitigation techniques for a variety of SMB problems.)
Rather than discussing the technical problem, I wanted to make a different point. After reading about this technique, you probably want to know when an intruder uses it against you, so you can see it and preferably stop it.
However, you should be wondering if an intruder has already used it against you.
If you are practicing network security monitoring (described most recently in my newest book), then you should already be collecting network-based evidence of this attack.
Whenever you see a discussion of a new attack vector, you will likely think "how do I stop it, or at least see it?"
Don't forget to think about ways to determine if an attacker has already used it against you. Chances are that certain classes of intruders have been exercising it for days, weeks, months, or perhaps years before it surfaced in the media.
PS: This post may remind you of my late 2013 post Linux Covert Channel Explains Why NSM Matters.
Tweet
(Mitigating Service Account Credential Theft on Windows [pdf] is a good paper on mitigation techniques for a variety of SMB problems.)
Rather than discussing the technical problem, I wanted to make a different point. After reading about this technique, you probably want to know when an intruder uses it against you, so you can see it and preferably stop it.
However, you should be wondering if an intruder has already used it against you.
If you are practicing network security monitoring (described most recently in my newest book), then you should already be collecting network-based evidence of this attack.
- You could check session data and infer that outbound traffic on using traditional SMB ports like 139 or 445 TCP are likely evidence of attack.
- You could review transaction data for artifacts of SMB traffic, looking for requests and replies.
- Best of all, you could review full content data directly for SMB traffic, and see exactly what happened.
Whenever you see a discussion of a new attack vector, you will likely think "how do I stop it, or at least see it?"
Don't forget to think about ways to determine if an attacker has already used it against you. Chances are that certain classes of intruders have been exercising it for days, weeks, months, or perhaps years before it surfaced in the media.
PS: This post may remind you of my late 2013 post Linux Covert Channel Explains Why NSM Matters.
Tweet
Comments
The paper made some great suggestions on log/SIEM integration into these classic Microsoft forest issues. Thank you for the link!