Finally Control your User Hygiene and Behavior with Project VAST (Part 1)
Hi folks, it’s Jon back with another VAST blog – after a (ahem) longer than anticipated delay. I spent most of the last several months traveling for customers. And, while this doesn’t promise to let up anytime soon, I have two realizations to share: first, it could be much worse. Second, and more to the point, the best way for me to deal with this is to simply bang out my blog entries from the comfy (😊) confines of the absolutely sweet middle airplane seat I am presently occupying on a Sunday night (the phrase bus with wings has never felt more true). So onward and (so to speak) upward we shall go…
Today, I want to take a bit of a different approach. So far, the concept I’ve followed with each blog entry has been to tightly detail one of VAST’s tabs.
Today, I’ll necessarily take a different approach, as I want to start way back at the beginning – and with the very first problem that inspired Project VAST in the first place. This entry will be the first of a multi-part series (estimating three right now, but no promises 😊) about Project VAST and the pressing topic of Credential Hygiene. So if you’re concerned about your organization’s credential hygiene (pro tip: you should be) or if you have been wondering about the creative process here (I promise not to flatter myself), then continue on, intrepid reader.
What is Credential Hygiene (or How did you come up with VAST, anyhow? )
Gentle reader, please consider this (lightly fictionalized) conversation:
Me: We need to take some specific actions to restrict your accounts and reduce the attack surface that they present. [Goes on to describe the steps.]
Customer: OK, I’m in, let’s do it.
Me: Here’s the story [I told it literally hundreds of times]. Our first step in this project will be to understand the posture and usage of your powerful privileged accounts. We have some really robust logging and auditing that we can leverage here. Let’s begin by turning up the appropriate security auditing. Next, we’ll set up Windows Event Forwarding or, better yet, we’ll utilize your SIEM if you’re already aggregating the events there. Then we’ll analyze the aggregated events, understand what’s happening with the accounts and then we’ll take concrete steps to raise the cost of attack (steps like authentication restriction, multi-factor authentication, requiring passwords that are less weak (since no passwords should really be considered secure), and using Managed Service Accounts, to name a few.
[…] Time passes
Customer: OK, we turned up auditing for successful and failed logons, Kerberos TGT/TGS, non-Kerberos authentication traffic, and a few other things – just like you said. And now we have [a Very Large Number of]* logs to go through. I tried to do it. Now I have a headache, I need bifocals, and I’m bleeding from every pore [ok, I exaggerate]. But I’m no closer to understanding my account security posture and hygiene. How can I possibly correlate these successive events from different logs into a cohesive narrative?
Me: Um, er, you…can’t?
Curtain Call. Fade to black. Bravo. Only not bravo. Not even close. Time and again, we hadn’t achieved that much. This data problem got to the point that I could predict it, with some level of accuracy, walking into a customer site. And it wasn’t just a problem specific to accounts; it was the same virtually across the board. If you’ve read the previous entries, you know that (for example) remediating deprecated protocols faces the same kind of data problem.
Frustration ensued until one day it hit me. If everyone has a problem with their security data, the problem isn’t with everyone; the problem is with us (meaning Microsoft). Over the last 20 or so years, various PGs provided us with outstanding and granular auditing (particularly on domain controllers). But no one had ever developed the tools to actually make meaning out of all this data. What we have here, ladies and gentlemen, is a problem of big data.
OK, so What do you mean specifically by Credential Hygiene
Excellent question. Let me start with what I don’t mean; this may sound all-too-familiar to your organization. (And if it does, don’t fret; you’re not alone. Yes, you have a significant problem and yes, you can tackle it with some help. )
At a customer site about six months ago, we discovered a service account. In the Builtin/Administrators group. With a static password. From 2001. To be clear, this was not an isolated event (only one of the more extreme examples). This account almost certainly had a dictionary password, no MFA, no account restrictions, no conditional access, no credential partitioning, no monitoring of any kind, no logon restrictions, nothing. Nada, Bupkis. Zilch. Whether they realized it or not, the organization was (by definition) expecting a 20-year-old account to stand up to modern attack logic. (And to be fair, some very old attacks would almost certainly be successful against accounts like this.)
And what’s worse is that no one really knew what this account did in the environment. (Otherwise, this customer had a decent security posture and had started to restrict its accounts tied to people.) Understandably, no one wanted to touch it or restrict it in any way – they had implicitly adopted such a hands-off policy that they couldn’t even cycle the password for fear of what would break. Sound familiar? I’d wager that this story doesn’t really shock anyone (it certainly doesn’t surprise me any longer).
As if this problem wasn’t complicated enough (I alluded to this earlier), really understanding how an account is being used in the environment requires correlating data from multiple log sets (Event IDs 4624, 4625, 4768, 4769, 4776, and potentially a few others). Our default tools just aren’t up to the task.
Starting to chart a Cleaner Path with Project VAST
Remember at the start where I said we’d be utilizing multiple VAST tabs (or detections) in this series of blog entries? Well, the time has come; let’s take a look at our first tab, User Hygiene.
Let’s start by following our eyes to where they’re naturally drawn: the big pink and green box in the middle. In this visual, we are plotting user object attributes directly from AD. Specifically, the X axis plots days since an account’s last logon; the Y axis plots the days since the same account’s password has changed. Simple, huh? Yes. And also very telling. Think of this as an at-a-glance snapshot of your user hygiene posture.
Accounts (represented by user dots, the color of which mean nothing – that’s just to make them visually distinguishable) appearing in the green box (lower left) may be considered to have better user hygiene than others. That is because they have rotated their password in the last 100 days and logged on in the last 100 days. (Note: I said better hygiene – not necessarily good just yet.) These are accounts that are in use and that we can generally assume are cycling their passwords.*
You’ll notice that, in our lab, we don’t have (at present) any accounts that are terribly healthy. That is intentional, to illustrate the functionality. And if the healthier accounts are in the lower left corner, then the least healthy (or most risky) accounts are in the upper right; these accounts have neither logged on nor cycled the passwords in greater than 100 days. To channel attacker thinking, these attacks represent attack surface galore. Put a different way, they represent a potentially high Return on Investment – a low barrier to attack entry with a high reward and few (if any) detective controls.
Privileged Account Hygiene
Let’s take our inquiry a step further and (this should be familiar by now) filter to just show Administrative accounts.
You’re probably starting to notice that a positive security narrative is most certainly not beginning to emerge about our lab data here: all privileged accounts have stale passwords. And let’s focus our attention to one account in particular – the account named NestedUser. 
By clicking on the dot associated with this account, we can filter the data set to solely the attributes describing the account in question. And right away, we see that this account represents a major problem, a problem that needs immediate attention. Take a look at the bottom visual, the one rendering the log data values in text format.
Several of the values may not immediately make sense. Nonetheless, a narrative emerges. NestedUser has never logged on (represented by Microsoft epochal time), never changed its password, was created many months ago, and is sitting in an administrative group. It is a very high-value account to an attacker.
If you're like all too many organizations, you have accounts like this just waiting to be discovered and taken over. And due to the nature of the account (shared, potentially forgotten about, not tied to a human being), all of the indicators of compromise (IOC) may go un-noticed due to the very nature of the account.
To better understand the risk associated with NestedUser, let’s quickly compare it with an account in a less unhygienic (though by no means good) state – the account called briandel. (This account belongs to my VAST partner, Brian Delaney, so I find it’s always rewarding to unfairly pick on him. 😊)
By hovering over Brian’s account and then clicking on it, we can get a quick and telling sense of the scope of the problem. Here, we see that Brian’s account logged on six days ago, yet hasn’t rotated its password in 167 days. We see it’s also an Admin account and it has the Password Never Expires flag set. Though not nearly as dramatic a problem as NestedUser, briandel still represents a high-value target for attackers.
We can also notice a number of accounts somewhere between these two – accounts like bobHelpDesk, which logged on seven days ago, but hasn’t changed its password in 407 days.
From even our brief inquiry here, it's clear that there's a lot of critical work to do here.
Looking Ahead
This wraps up the time we have for our initial discussion of Credential Hygiene. Next month, we’ll transition from identifying that we have a problem to understanding a lot more about the problem. As a sneak peek, I’ll be showing you the User Auth tab.
This tab represents the first successful attempt (that I know of) to visually track how each and every account in your Forest is logging on and authenticating. We’ll do this by tracking successful and failed logons, Kerberos granting and session tickets, non-Kerberos authentications (like NTLM and wDigest) and more.
One note: You may have heard that the TechNet platform is being retired. Therefore, the Project VAST blog is moving platforms in the next month or so. Please update your bookmarks and ensure you are hitting https://aka.ms/securitypfe so you’ll be redirected to the new blog location.
I hope you’ve enjoyed this first part of the series. Stay tuned for more next month – and until then, happy auditing.
*On password rotation: you may have seen research that Microsoft published suggesting that changing passwords is actually detrimental (and not valuable) to security. You can read about it here. If you organization is ready to eliminate mandatory periodic password resets for user accounts, then you should proceed thusly. Several words of caution, however:
- Consider other compensating controls like MFA, risk-based Authentication challenges like Conditional Access policies, and so forth.
- Most customers that I work with have not yet achieved that level of maturity. In fact, most have mandatory period password resets as an InfoSec standards that the organization has decided upon; for these organizations, viewing user hygiene (and specifically password rotation non-compliance) helps them make informed decisions around not just their password policies, but also how and if to enforce them as an organization. I value your thoughts and feedback on this point especially.
Comments
- Anonymous
March 25, 2019
Does this include SPN and Managed Identities in AAD? What strategy would you recommend to list identities with their RBAC for a specific Azure service. E.g. Identities that have "contributor" rights to a subscription/resource group.