As a relatively new security category, many security operators and executives I’ve met have asked us, “What are Automated Security Verification (ASV) tools?” We’ve covered this quite extensively in the past, so today, instead of looking at “What is ASV?” I wanted to address “Why ASV?” question. In this article, we’ll go over some common use cases and misconceptions about how people misuse and misunderstand ASV tools on a daily basis (because it’s a lot more fun). To start a business, there is nothing to start with, as in the beginning.
Automated security audit tools are designed to provide a continuous, real-time assessment of an organization’s cybersecurity defenses. These tools are continuous and use exploitation to test protections such as EDR, NDR and WAF. They are more in-depth than vulnerability scanners because they use tactics and techniques that you would see in manual penetration tests. Vulnerability scanners will not transmit hashes or pool vulnerabilities for subsequent attacks, which is where ASVs shine. Their purpose is in the name: to “check” the defense. When issues or gaps are resolved, we must confirm that they are indeed fixed.
Why is ASV needed?
And that brings us to showing part of it, and our teacher in this is Aesop, a Greek storyteller who lived around 600 B.C. to n. He wrote a story called The Boy Who Cried Wolf, which 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 who keeps tricking the village into believing he has seen a wolf. Was it attention, fear or a terrifying vision that moved them? I don’t know. The fact is that he waves his hands in the air several times and shouts “Wolf!” when the wolf is not visible. He does this so often that the townspeople do not hear his calls, so that if the wolf is really there, the town does not believe him and the shepherd is eaten. This is a very touching story, like most Greek fairy tales.
The sysadmin who cried is fixed
In today’s cybersecurity, a false positive is the equivalent of “crying wolf.” A common problem is when threats receive an alert even though they have no chance of being exploited. But let’s revisit that story, because the only thing worse than a false positive is a false negative.
Imagine if instead of “crying wolf” when the wolf wasn’t there, the boy would have said “it’s clear” without realizing that the wolf was hiding among the sheep. This is a false negative, not alerted if there is a threat. After the boy set the traps, he was sure the threat was gone, but he didn’t confirm that the traps had actually worked to block the wolf. So the new version of Crying Wolf looked something like this:
“Ah, I thought we had a wolf. I will take care of him,” says the boy.
So the shepherd follows the instructions: he sets wolf traps, buys a security tool that kills wolves, he even places a Group Policy Object (GPO) to drive the wolf out of his field. He then goes to town proud of his work.
“I was told there was a wolf, so I took care of him,” he tells his shepherd friends over a beer at a local tavern.
Meanwhile, the reality is that a wolf is able to evade traps, walk past a misconfigured wolf kill tool, and set new application-level policies so that it doesn’t care about GPOs. He grabs a set of city domain administrator (DA) credentials, hands them over, declares himself the mayor, and then keeps the city safe from a ransomware attack. Before they know it, the town owes 2 bitcoins to some wolf or they lose their sheep and a truckload of ID information.
What the shepherd did is called a false negative. He thought there was no wolf living in a false sense of security when the threat was never neutralized. And now he’s trending on Twitter for all the wrong reasons.
Time for a real scenario!
Wolves are rarely a threat to information security, but do you know who they are? This bad actor with a backdoor, a foothold in your network, listening for credentials. All of this was made possible by their very good friends, the legacy name resolution protocol.
Name resolution poisoning attacks are a difficult bug to fix as far as remediation is concerned. If your DNS is configured incorrectly (which is surprisingly common) and you haven’t disabled the good old LLMNR, NetBIOS NS, and mDNS protocols used in man-in-the-middle attacks via GPOs, startup scripts, or your own special sauce, then you may have be a problem. And where a wolf could drink a glass of milk, your attacker will access 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’re doing this, you’re probably not), then an attacker can transmit the hash. This will allow access to a domain-joined machine without even cracking the resulting hash.
Oh!
Now your friendly village pentester finds this problem and instructs the sysadmin, also known as our shepherd, to make one of the above fixes to prevent this whole series of attacks. He fixes it to the best of his ability. They introduce Group Policy Objects, get fancy tools, do ALL the stuff. But have you seen a dead wolf? Do we KNOW the threat has been eliminated?
An attacker can get in through the assembly kit of corner cases, because there will almost always be corner cases. You’ll have a non-domain-joined Linux server, an application that ignores GPOs and passes its credentials anyway. Even worse (*shudder*), an asset discovery tool using an authenticated enumeration that trusts the network as a whole and sends DA credentials to everyone.
False alarms fixed
That’s why the Cyberbugs gave us ASV, because ASV is a lumberjack from a ruined city with a wolf ghost-like commotion. Will behave like a wolf. It will sniff the credentials, capture the hash, and pass it to the domain-joined machine so that the sysadmin can find the one offending server that isn’t domain-joined and isn’t listening to GPOs.
Let’s bring it all home. There are some things that just make sense. You don’t call a wolf dead before you see it, and you certainly don’t call something fixed until you see it. So, don’t become the “System Admin Who Screamed Fix It”.
This article was written by Joe Nye, solutions architect at Pentera.
To learn more, visit pentera.io.
