As a relatively new security category, many security operators and executives I’ve met have asked us “What are these Automated Security Validation (ASV) tools?” We’ve covered that pretty extensively in the past, so today, instead of covering the “What is ASV?” I wanted to address the “Why ASV?” question. In this article, we’ll cover some common use cases and misconceptions of how people misuse and misunderstand ASV tools daily (because that’s a lot more fun). To kick things off, there’s no place to start like the beginning.
Automated security validation tools are designed to provide continuous, real-time assessment of an organization’s cybersecurity defenses. These tools are continuous and use exploitation to validate defenses like EDR, NDR, and WAFs. They’re more in-depth than vulnerability scanners because they use tactics and techniques that you’ll see in manual penetration tests. Vulnerability scanners won’t relay hashes or combine vulnerabilities to further attacks, which is where ASVs shine. Their purpose is in the name: to “validate” defenses. When issues or gaps are addressed, we need to validate that they really are fixed.
Why is ASV needed?
And that brings us to the showing part of this, and our teacher for this is Aesop, the Greek storyteller who lived around 600 BC. He wrote a story called The Boy Who Cried Wolf that I know you’ve heard before, but I’ll share it again in case you need a refresher:
The fable tells the story of a shepherd boy who keeps fooling the village into believing that he’s seen a wolf. Whether he was motivated by attention, fear, or terrible eyesight? I don’t know. The point is that he repeatedly waves his hands in the air and cries “Wolf!” when there’s no wolf in sight. He does this so often that he desensitizes the townspeople to his calls so that when there really is a wolf, the town doesn’t believe him, and the shepherd boy gets eaten. It’s a very heartwarming story, like most Greek tales.
The Sys Admin Who Cried Remediated
In modern cybersecurity, the false positive is the equivalent of “crying wolf.”. A common practice issue, where threats get alerted despite not having any chance of being exploited. But let’s rescope this story because the only thing worse than a false positive, is a false negative.
Imagine, if instead of “crying wolf” when there was no wolf, the boy said “all’s clear,” never realizing the wolf was hiding among the sheep This is a false negative, not getting alerted when a threat is prevalent. Once the boy had set up the traps, he was convinced that there was no longer a threat, but he didn’t validate that the traps actually worked to block the wolf. So the rescoped version of Crying Wolf went something like this:
“Ah, I figured we had a wolf lurking around. I’ll take care of it,” says the boy.
So the shepherd follows the instructions: He sets up wolf traps, buys a wolf-killing security tool, he even puts in a Group Policy Object (GPO) to get that wolf out of his field. Then he goes to the town proud of his work.
“They told me there was a wolf, so I took care of it,” he tells his shepherd friends while having a beer at the local tavern.
Meanwhile, the reality is that the wolf is able to dodge the traps, saunter past the misconfigured wolf-killing tool, and set new policies at the application level so he doesn’t care about the GPO. He captures a set of the town’s Domain Admin (DA) credentials, relays them, declares himself mayor, and then holds the town to a ransomware attack. Before they know it, the town owes 2 Bitcoin to some wolf, or else they’ll lose their sheep and a truckload of PII.
What the shepherd boy did is called a false negative. He thought there was no wolf, living in a false sense of security when the threat was never truly neutralized. And he’s now trending on Twitter for all the wrong reasons.
Real-life scenario time!
Wolves are rarely a threat to information security, but do you know who is? That bad actor with a backdoor, a foothold in your network, listening for credentials. All of it is made possible through their very good friends, legacy name resolution protocols.
Name resolution poisoning attacks are a tough bug to squash as far as remediation goes. If your DNS is configured improperly (which is surprisingly common) and you haven’t disabled good ol’ LLMNR, NetBIOS NS, and mDNS protocols used in man-in-the-middle attacks via GPO, start-up scripts, or your own special sauce, then you might be in some trouble. And where the wolf might have helped himself to a glass of milk—your attacker will be helping himself to sensitive data.
If an attacker sniffs credentials and you don’t have SMB signing enabled and required on all your domain-joined machines (if you’re wondering if you do, then you probably don’t) then that attacker may relay the hash. This will gain access to the domain-joined machine without even cracking the captured hash.
Yikes!
Now your friendly village pentester finds this issue and tells the sys admin, AKA our shepherd, to do one of the aforementioned fixes to prevent this whole string of attacks. He remediates this to the best of their ability. They put in the GPOs, they get the fancy tools, they do ALL the things. But has the dead wolf been seen? Do we KNOW the threat has been fixed?
Through a montage-worthy set of corner cases, the attacker can still get in, because there will almost always be corner cases. You’ll have a Linux server that isn’t domain-joined, an application that ignores GPO and broadcasts its credentials anyway. Worse still (*shivers*), an asset discovery tool using authenticated enumeration that trusts the network at large and sends DA credentials to everyone.
False Alarms Rectified
That’s why the cyber gods gave us ASV, because ASV is the ripped-town lumberjack with a side hustle as a wolf phantom. It’ll behave like a wolf. It’ll sniff the credentials, catch the hash, and relay it to the domain-joined machine so the sys-admin can find the one pesky server that’s not domain-joined and doesn’t listen to the GPO.
Let’s bring it all home. There are some things that just make sense. You wouldn’t call a wolf dead before you’ve seen it, and without a doubt, you wouldn’t call something remediated before you actually validated it. So, don’t become ‘The Sys Admin Who Cried Remediated’.
This article was written by Joe Nay, Solutions Architect at Pentera.
To learn more, visit pentera.io.
