https://docs.microsoft.com/archive/blogs/jonsh/feed.xml Jon Shectman and Brian Delaney on security in a big, bad world. Mon, 18 Mar 2019 13:44:59 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/jonsh/project-vast-and-azure-sentinel-a-match-made-in-the-cloud Mon, 04 Mar 2019 18:35:53 GMT https://blogs.technet.microsoft.com/jonsh/?p=985 https://azure.microsoft.com/en-us/blog/introducing-microsoft-azure-sentinel-intelligent-security-analytics-for-your-entire-enterprise/). I couldn't be more excited about this solution, and the complimentary story between Sentinel and VAST. By way of background, here's a nice summation from the PG: Azure Sentinel provides intelligent security analytics at cloud scale for your entire enterprise. Azure Sentinel makes it easy to collect security data across your entire hybrid organization from devices, to users, to apps, to servers on any cloud.  It uses the power of artificial intelligence to ensure you are identifying real threats quickly and unleashes you from the burden of traditional SIEMs by eliminating the need to spend time on setting up, maintaining, and scaling infrastructure. Since it is built on Azure, it offers nearly limitless cloud scale and speed to address your security needs. Traditional SIEMs have also proven to be expensive to own and operate, often requiring you to commit upfront and incur high cost for infrastructure maintenance and data ingestion. With Azure Sentinel there are no upfront costs, you pay for what you use. One concept included in Sentinel is that of "Dashboards." These are pre-configured data visualizations that are optimized to intelligently display a particular data stream. You can probably see where this is heading. For VAST KPIs and detections that solely depend upon log data (and not on, for example, querying Active Directory attribute data), Sentinel dashboards offer an excellent lighter-weight solution. And I'm happy to announce that Brian and I (the VAST team) supplied the Insecure Protocols dashboard with the Azure Sentinel product team. It's right there, baked into the product.  :) Rather than trying to describe it to you, I think it's best if I walk through the steps to utilize Sentinel for Insecure Protocol detection. Let's take the example of SMB1. In case this somehow isn't clear, you really need to get SMB1 out of your environment. And if you've been following along to the previous entries, you know that can be tricky without some intelligent log aggregation and thoughtful visualizations. (For more on auditing SMB1 with VAST, go here.) To start, you would turn on SMB1 auditing on your servers or a subset of servers. You would install the MMA and configure Azure Monitor (Log Analytics) to forward EventID 3000. (Note: Sentinel supports Windows Event Forwarding, meaning that we no longer have to install the Microsoft Monitoring Agent on every server we want to audit.) Once you have the data in Azure, the Insecure Protocols dashboard will display the log data to you visually. In other words, what VAST does with Power BI, Sentinel does with a built-in dashboard (and it's VAST approved  :)   ). There it is -- and you're off to go root out SMB1 across your estate. I've already been getting some questions that merit some attention here:

1. Is Sentinel replacing VAST? No. There are some advantages, and different focuses, to both. For example, the Sentinel Insecure Protocols dashboard is much lighter weight and easier to implement than VAST's Power BI-based dashboard. On the other hand, this single dashboard only represents about 25% of the KPIs and detections available in VAST at present. Sentinel is also a full-on cloud-native SIEM replacement in a way that VAST doesn't intend to be. That said, there may come a time when it makes sense for us to re-platform VAST onto Sentinel, but that time is in the future. For instance, we would need to figure out how to import Administrative User data into Sentinel before we could report on Administrative behavior.
2. Which should our org use? It depends on your goals. Insecure Protocols is but one of 26 (and counting!) dashboards that ship with Sentinel. And dashboards are but one facet of Sentinel's functionality. And as I mentioned, Insecure Protocols is only a fraction of VAST's capability as well. If you are using one and it is working for you, I would broadly suggest you continue using it, while learning about additional capabilities.
3. What about for Insecure Protocols only? If you want Insecure Protocol information with the lightest touch possible, Sentinel. If you need information about your Privileged Accounts and Insecure Protocols, VAST.
4. Is VAST going away? No.  :)

As always, please send me your questions or comments. And until then, happy auditing. Edit: For detailed instructions on setting up the Insecure Protocols Dashboard in Sentinel, please navigate here.]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-control-your-user-hygiene-and-behavior-with-project-vast-part-1 Thu, 28 Feb 2019 00:24:28 GMT https://blogs.technet.microsoft.com/jonsh/?p=875 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:

1. Consider other compensating controls like MFA, risk-based Authentication challenges like Conditional Access policies, and so forth.
2. 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.

]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-deploy-and-audit-laps-with-project-vast-part-2-of-2 Tue, 06 Nov 2018 17:38:20 GMT https://blogs.technet.microsoft.com/jonsh/?p=695 auditing LAPS. We’ll discuss why you should audit LAPS, look at some of the difficulties with effectively auditing LAPS, and closely examine how VAST can help empower your organization. Why You Need LAPS Auditing (Hint: Because it allows you to use LAPS) Here’s a scenario: A company, call it TailSpin Toys, has been carefully following the Security Privileged Access roadmap (https://aka.ms/privsec) for some time now. They’ve made good progress, carefully deploying LAPS, partitioning their credentials according to the tiered model, and implementing Privileged Access Workstations (PAWs). In this new administrative model, highly privileged accounts (for Tier 0) become Domain Controller Admin accounts (rather than Domain Admin-style accounts). TailSpin Toys’ server administrators are thoughtfully segregated according to task, necessity, and role. And Tier 2, or Workstation Admins, are still…well…they’re still Workstation Admins. Helpdesk and deskside support techs authenticate to workstations using accounts with broad entitlements throughout the enterprise; these accounts often enjoy administrative access to wide swaths of machines in particular regions, or (in extreme cases) to machines across the entire enterprise. See the problem? LAPS has dramatically reduced the attack surface of the built-in Administrator account on workstations. Privileged Access Workstations and credential partitioning has reduced the risk of credential seepage onto assume compromised machines that sit on the Interwebs. However (you knew it was coming, right?  😊), TailSpin Toys has inadvertently left behind a major attack vector. As an attacker, I can no longer go after the built-in Admin account, but I can win wide latitude for lateral account movement by simply stealing a helpdesk or deskside Admin (Tier 2) account. This is particularly easy to do, as Tier 2 admins typically don’t operate on PAWs, meaning their machines (and by extension, their credentials) are accessible to remote attackers. So an attacker potentially only has to compromise one (or a handful) of machines in order to win access to every machine that the Tier 2 administrators have access to. So what exactly constitutes an easy, low-cost, low-disruption solution to this quandary? Embracing the use of LAPS-managed local admin accounts in place of domain-based ones for support calls, of course. This effectively solves the problem described, but presents a new challenge of its own. If Bob and Alice both have access to the store of LAPS passwords (granted by ACLs in AD), how can an organization practice trust but verify of who has done what with the local accounts? Now consider that many organizations wish to grant arbitrary access to an entire helpdesk organization (which could be dozens of people). You see the challenge? Lucky for us, LAPS writes a nice audit trail each and every time a password is retrieved from AD. Unlucky for us, it can be challenging to use effectively. The Challenge(s) of LAPS Auditing To be fully transparent, this section should really be called “the three challenge(s) of LAPS auditing.” To understand each of these challenges, let’s first examine how exactly LAPS implements (or more accurately leverages) auditing in AD. Assuming that auditing and System Access Control Lists (SACLs) are appropriately configured, each time an attribute value is read, AD writes a 4662 Event: An operation was performed on an object. To be more specific, it writes multiple 4662 events. Herein lies our first challenge. In my lab, I performed a simple LAPS lookup with an account called DA-SA1 and successfully retrieved the LAPS password. Then I popped over to the Event Viewer to have a look at the audit trail. Right away, I discovered a problem you might have suspected all along: 4662 is a very chatty Event ID. Right away, there’s a lot to sift through. In this case, I have the advantage of knowing the general time for the retrieval I wish to audit. Because this was a test, I know that I performed the retrieval during the 3:00 PM hour. Narrowing the audit log, I see five 4662s in the log during that time: Our second challenge is that AD writes multiple 4662s for each LAPS retrieval. How can we tell which is the one we care about? Well, scrolling through the entries, I can play the game which of these is not like the others? And we have a winner. Four of the 4662 entries are for the expected Read Property access. And one is for Control Access. Recall that MSMCSADMPWD is protected by its status as a confidential attribute. And recall that confidential attributes require not just Read access, but also Control access to retrieve. We’re making progress – and there’s just one final hurdle to clear. When I’m working with organizations that have implemented LAPS, we almost always see applications, products or accounts making inefficient LDAP queries. An inefficient query is where an entity pulls back all of the attributes for an object or set of objects and then parses them in memory or in its own data store. As the name suggests, it’s inefficient and can also be very taxing on the LDAP server (in this case, AD). It’s bad practice, but it’s also very widespread. In this type of reality, the third challenge becomes clear. How do I know that the 4662 Control access is actually for MSMCSADMPWD? We know because the log tells us so long as we know where to look. Directly underneath the Access Mask (0x100 for Control Access), we see a listing of Properties. These are objectGUIDs for the confidential attributes that have been accessed. One of these signifies our MSMCSADMPWD attribute. But which one? I need to do some detective work. For this, we’ll use PowerShell to dump out the objectGUID for the MSMCSADMPWD attribute. Note that this is unique for each Forest. So I know that this objectGUID (starting with 1dab and ending with ef26 is what we’re after. And we see it in the 4662 Control log: We have successfully audited my example LAPS password retrieval. Scaling the Solution Unless you are the rare IT professional with time on his or her hands(!), it’s not realistic to go through this process to meaningfully audit each and every LAPS password retrieval. And unless your organization is willing to introduce shared passwords without audit-ability (which it should absolutely not do), we need to make this process repeatable. Data aggregation tools like Log Analytics (now part of Azure Monitor) can help us get started. Because I know the AccessMask I need (0x100 for Control) and the objectGUID (which I retrieved earlier – the one that started with “1dab”), I could certainly craft a query off of those parameters: This will go a long way toward making LAPS truly auditable. Yet, I’m still in the business of sifting through a lot of log files. It’s do-able, just not very efficient. In Project VAST, we take this a step further – and control all of the queries and filtering in the background. Let’s have a look at the LAPS Audit tab. Starting in the upper left-hand spot, we can view all of the accounts that have retrieved passwords in this data set (briandel, JJWatt and TomBrady). Clicking on one of them filters the dataset like so: From the data at the bottom, a story begins to emerge. We see that account briandel was used to retrieve the password for the computer JONSH386VM. This is important for verification purposes: was there a change or problem ticket opened? Does this account belong to a person whose role it is to access this type of machine? Was the account owner of briandel at work during these hours? Is this typical behavior for this account? We can see the data and begin to make important decisions at a glance. Further, we can start to baseline the expected behavior for each account. I see this account was used to perform a total of 168 password retrievals. This is a deceptively important insight. Over time, an organization can and should baseline account behaviors. If briandel is used for retrievals in the ballpark of 170 times a week, then that should be what we come to expect. We can measure derivation and take appropriate action. If we notice that briandel has gone from around 170 retrievals down to only a few, we’ll need to ensure the account is being used appropriately and that another, more privileged one is not being used in its place. If it goes from around 170 to 270 or 1700, we know we may have an early indicator of compromise: the account may be being used to raid the AD store of LAPS passwords. By visualizing data in the way we do with Project VAST, we can also utilize it in a more typical forensic fashion. Let’s say that we are concerned that something potentially injurious was done on a machine; maybe data was exfiltrated or configuration changes were made. We can filter by computer name and date/time. Let’s say that the event in question happened at 2:30AM on October 31. By filtering to the computer in question and simply sorting the logs by retrieval time and date, I can see what happened: I see that user JJWatt retrieved the password at 2:15AM; the owner of the account (indeed anyone with access to its credentials) must be part of my investigation. By carefully filtering, sorting, and querying the 4662 data coming from AD, we can turn a potential liability into an easily audited solution. That wraps it up for LAPS auditing and Project VAST. Stay tuned next month when we’ll discuss another security capability of visualizing security Big Data with Project VAST. I invite you to follow me on Twitter @securitypfe. And until then, happy auditing. - Jon]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-deploy-and-audit-laps-with-project-vast-part-1-of-2 Wed, 03 Oct 2018 13:58:45 GMT https://blogs.technet.microsoft.com/jonsh/?p=575 Quick Review: Lateral Account Movement Lateral account movement, or the action of an attacker “pivoting” between computers, is a well-understood part of the known attack playbook. At simplified attack might go something like this: An attacker compromises a first “patient zero” machine with a drive by, an exploit, or likely some form of social engineering like a phishing attack. At this point and with virtually no effort or cost, the attacker has already bypassed perimeter-based security. With little effort, he or she can steal credentials out of memory or out of the Security Accounts Manager (SAM) database using free tools such as Mimikatz, pwdump7 or the like. You might be surprised to learn that one of the credentials attackers are looking to steal is your local administrator. That’s right – the one in the local workstation or server’s SAM database. Your surprise might come from the fact that the local administrator only grants access to the machine – in this case, the machine that he or she already owns. Except that it doesn’t.  😊  Not if your organization has created the same local administrator password for all or even for large groups of the machines in your organization. In this scenario, the attacker simply re-uses the stolen credential to pivot between machines; put differently, the attacker may now move throughout the environment, often with total impunity. At this point in the known playbook, the attacker has breached the perimeter security, stolen credentials, and is able to move freely throughout the environment. If the computers that contain the matching local admin password contain trade secrets, personal information, or other sensitive material, the attacker may simply steal it, destroy it, or perform some similar nefarious activity. At the same time, the attacker looks for escalation possibilities – namely, privileged credentials in the environment – to steal and with which to escalate entitlements. There are multiple opportunities in the kill chain during the (oversimplified) attack that I’ve described so far. As I mentioned, installing and carefully using LAPS is one of the most effective mitigation techniques for dramatically slowing down the attacker’s lateral movement. What is LAPS? LAPS is a free, supported tool from Microsoft which “provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset” (source: LAPS download page here). In simple terms, LAPS creates unique, random passwords and automatically changes them on a schedule that you specify (between one and 365 days; pro tip: don’t choose 365 days  😊). Installation steps and prerequisites are all documented in the LAPS Operations Guide, available on the download site:

1. Install and register a client-side extension (cse) dll on each computer to be managed
2. Extend the schema for two new attributes and a class change
3. Set Active Directory (AD) permissions
4. Configure and activate LAPS via Group Policy (GPO)

That’s pretty much it. The cse code calls a .NET randomizer, creates a new password in memory, commits it to the directory, and writes it back to the SAM database. Password changes occur when one of the two attributes on the computer object – the one that holds the expiration date – value expires and a GPO refresh occurs. LAPS-managed passwords viewed in AD Users and Computers (ADUC) and also in PowerShell. Note that msmcsadmpwd is a confidential attribute; only authentication principals that you delegate can view it. By implementing and configuring LAPS thoughtfully and carefully, organizations can insert a mitigation into the attack chain. Namely, by enforcing a non-matching local administrator account password, organizations can slow down the lateral account movement. Put enough roadblocks in front of an attacker, and you might be able to create an attacker’s dilemma, in which the advanced persistent threat (APT) has to choose whether or not to continue attacking your organization. In schematic terms, it might look something like this: LAPS is very effective at what it does (and it only does what it is very effective at). It is so effective, in fact, that implementing LAPS comprises two of the very first actions on the Securing Privilege Access (SPA) roadmap, our prescriptive, public guidance for securing identities. Okay, I’m convinced – what’s the problem? Well there’s not necessarily a problem, per se. On the other hand, I’ve seen organizations really struggle in three areas:

1. Comprehensive roll-out to workstations and servers. LAPS doesn’t really provide a built-in method of reporting which machines are and are not under password management. I have worked with many organizations who have previously implemented LAPS partially, on only their workstations and not their servers, vice-versa, or who believe LAPS is managing the password for many more local admin accounts than it actually is. Certainly not all organizations struggle with successful rollout. But if there’s one gotcha off the bat, it’s that LAPS requires one (and only one) initial implementation (the cse dll) on each machine. This can get a bit complex and time consuming, especially for larger organizations or organizations without a robust software management solution. Additionally, decision makers often (and should!) ask what they are spending their security budget on, when it comes to any tool implementation – and LAPS is no exception. Decision makers from the CISO down increasingly need to understand their organization’s big data in order to make informed decisions and to gauge the impact of their intentional spending.
2. Delegating permissions to the accounts (and only the accounts) that they truly want to be able to view the passwords in AD. Recently, I worked with a company that saw a *lot* of LAPS password retrievals in its audit log through VAST. Upon investigation, we discovered that authenticated users had been accidentally granted the ability to view LAPS passwords. This undoubtedly made them less secure than they were before. Which leads me to the third area in which organizations struggle with LAPS.
3. Auditing usage of the shared password. Remember when I said LAPS does what it does very well? That’s still true. But auditing usage of managed passwords has never been its strong suit. VAST goes a long way toward solving the problem of making the LAPS audit trail really usable for these shared accounts. I will discus LAPS auditing next month, in the second part of this blog series.

Enter Project VAST VAST actually contains two LAPS tabs: LAPS Deploy and LAPS Audit. Let’s examine LAPS Deploy. By querying the non-confidential attribute msmcsadmpwdexpirationtime, VAST can display the current state of an organization’s LAPS deployment down to the machine. Using VAST, we can also view the current deployment by operating system, by workstation or server, by groups of machines that do or do not have LAPS deployed, and we can provide specific progress reports for each of these categories. I typically like to start with a high-level overview of the data without filtering this tab just yet. In the lower right-hand corner, we have two needles representing progress. Overall LAPS Deployment % is a visual representation of the percentage of machines under LAPS management. In my lab, it’s 50% of all machines. LAPS Password Freshness represents the number of machines, of those 50% under management, whose local admin passwords are fresh (that is, are not past their expiration date). These machines measure 100%. At this point, a narrative begins to make itself clear: half the machines are managed in my lab. Of those half, all of them are being managed as we desire. The solution is working well, but it is not, or not yet, fully deployed. We can drill deeper. Setting isServerOS to True filters to only servers. This “organization” (my lab) has not yet begun its deployment to any servers. Clicking isSeverOS to False, we get a report of our LAPS rollout progress on workstations only. Filtering in this way typically makes sense for several reasons. First, different teams almost always manage LAPS deployments to different types of computers (workstations and servers). Also, many organizations struggle with LAPS and different workstation operating systems. Many successfully add the cse dll to their images and then the GPO to the organizational unit (OU) for new machines, but struggle with their existing workstations. This can often manifest as a Windows 10 and Windows 7 problem, respectively. I’ve seen the opposite scenario as well. Finally, as I said earlier, any single machine in question may be checked, by simply using the ComputerName filter.   Using VAST in this way, both engineers and decision makers can understand their LAPS deployment in ways that they simply couldn’t (or struggled to) previously. By aggregating a large amount of data and rendering it truly actionable, VAST can display exactly where an organization is succeeding and where it is struggling with its LAPS deployment. That wraps it up for LAPS deployment and Project VAST. Stay tuned next month when we’ll discuss VAST and LAPS auditing. I invite you to follow me on Twitter @securitypfe. And until then, happy auditing.]]> https://docs.microsoft.com/archive/blogs/jonsh/project-vast-now-available-via-premier Thu, 06 Sep 2018 17:01:55 GMT https://blogs.technet.microsoft.com/jonsh/?p=565

The pilot phase has completed -- and thanks to all of our pilot organizations

Premier organizations may now book a VAST engagement by engaging their Technical Account Manager directly

We are in the process of lowering customer wait-times by training local resources around the globe. At present, we have a good jump on capacity in EMEA, with the Americas and the Asia-Pacific regions to follow

We are now offering this as a five-day standard engagement; four-days onsite and one day with the PFE remote

For additional information on the Project VAST Premier Engagement, please go here. And if your organization is not yet a Premier customer, please go here for information on becoming one. That's it for now. I'll return shortly with a technical blog about another one of VAST's capabilities. Until then, happy auditing.  ]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-remove-smb1-with-project-vast Wed, 08 Aug 2018 22:08:53 GMT https://blogs.technet.microsoft.com/jonsh/?p=465 Quick Review: What is SMB For our project, we don’t need to spend too much time on how SMB works. Ned Pyle, an owner of SMB at Microsoft, has written extensively on the subject (start here). Note that Microsoft has implemented three versions of SMB over the years; SMB2 and SMB3 are much more secure than SMB1. The good news is that supported operating systems will use SMB2/3 by default. The bad news is that your out-of-support computers (you definitely don’t have any of those, right?  😊), such as Windows XP and Server 2003, support only SMB1. And as is the case with so many other deprecated protocols, your overall security posture may very well be being set by these outdated computers and applications. This is not a good situation. (To be clear, there is no way to use SMB1 securely – at least not at the protocol level. To be very clear, if you are running out-of-support Operating Systems in your production environment, then SMB1 support is but one of the many security pratfalls you face.) The other places that SMB1 may be coming from are outdated (or not updated) printers and multi-function devices. If you have devices on your network that require SMB1, then it’s time to have a heart-to-heart with the vendor or the team requiring their use. Ned and team publish a clearinghouse of SMB1 products here. Digging a bit deeper – what’s the specific problem with SMB1? If you’re convinced and just want to learn how to remove SMB1 without wrecking your environment, skip to the next section. But if you’d like to learn a bit more, read on. The security built into SMB2 and SMB3 is primarily around protecting against security downgrade attacks (Pre-authentication Integrity, Secure Dialect Negotiation) and attacker-in-the-middle attacks (Encryption, Insecure guest auth blocking). SMB1 simply doesn’t know about or contain any of these protections. Worse yet, if you have SMB1 enabled on your file servers or (worse, worse yet) your domain controllers, then an attacker-in-the-middle can simply block SMB2/3 and force a downgrade attack. The net effect here will be that your computer(s) will gracefully and happily flip over to SMB1, thereby exposing the exchange’s data. As if this all weren’t scary enough, the world experienced several massive ransomware attacks with SMB1 components last year. Petya/WannaCrypt and their variants marked a sea change in their use of rapid destruction combined with credential theft.** From the Microsoft Secure blog: [Petya] ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with Mimikatz and comes in 32-bit and 64-bit variants. Because users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other machines.⁺ In addition to impersonation via stolen credentials, Petya/WannaCrypt also leveraged an EternalBlue exploit to utilize the ticking timebomb of SMB1 to worm through the environment. One piece of good news is that MS17-010 solved this specific exploit. But we will almost certainly see other SMB1 exploits in the future. Okay, I’m convinced – what to do about SMB1? Unless you’re in the rare position of knowing exactly the sources of your SMB1 traffic, we need to start with auditing. Beginning in Windows 10 and Server 2016, and back-ported via an update to Server 2012 R2 and Windows 8.1, Microsoft made SMB1 auditing available. To enable SMB1 server-side auditing, you’ll run the following PowerShell command: Set-SmbServerConfiguration –AuditSmb1Access $true To set auditing on a group of servers or across a large swath of your environment, export a list using PowerShell or LDIF. And then run something like this: $computers = Get-Content "c:\SMB_computers.txt" foreach ($computer in $computers) {Invoke-Command -ComputerName $computer -ScriptBlock {set-smbserverconfiguration -auditsmb1Access $true -Force}} (In this example, SMB_computers.txt is the list of your exported computers or server to targets.) This will set auditing for the Applications and Services Logs\Microsoft\SMBServer\Audit hive. Specifically, Windows will write a simple EventID 3000 for each and every time that a client attempts to access the server using SMB1. As shown below, you will log the IP address or hostname of the client. You will then need to don your best Sherlock Holmes cap and figure out what is using SMB1 on the client. Finding out is typically not very hard. As with other protocols, this logging presents several immediate problems. Natively, you will have to hop between servers to check the event logs. Depending upon the amount of SMB1 traffic you are seeing, you may be able to employ technologies like Windows Event Forwarding (WEF) to aggregate the log data. However, there’s a high probability that you will need more than just aggregation to deal with the sheer number of log events that you’ll be generating. And that’s where Project VAST comes in. Enter Project VAST As we’ve discussed in previous blog entries, we need to deal with this data in two ways. First, we clearly need to aggregate it and then we need to make the SMB1 big data set consumable and truly actionable. We’ll start, as we always do in Project VAST, with Azure Log Analytics. Once we have EventID 3000 aggregated in Azure, we can create Kusto queries to view the data and control the output. Notice a couple of things here. First, Azure Log Analytics combined with the Kusto query language makes this data highly extensible. With a single line, we can pull the ClientAddress attribute out of the common ParameterXml attribute. Second, notice on the right-hand side, this query returned almost 7,500 records in just seven days of data. Even with some creative Azure Log Analytics queries, we may need to employ another step to render our data truly actionable. After all, recall that a central guiding principle of Project VAST is to provide the ability to make well-informed, data-centric decisions about security budgets. A Closer Look Let’s take a look at Project VAST’s new SMB1 tab. Recall that here we are exporting the Kusto query out of Azure Log Analytics and importing it into Power BI. This configuration allows Power BI to query Azure Log Analytics directly with no need for intermediary data sources. The SMB1 tab in Project VAST allows us to visualize the EventID 3000 data and filter the display in a number of ways. Let’s start examining this tab in the box in the upper left. The box entitled SMB1 Traffic Flow (Top 5) is a visual representation of the top five largest SMB1 flows in the data set. In other words, this box shows us where to start. Notice that we have four IP addresses and a loopback address responsible for this SMB1 traffic. Because we enabled logging for SMB1 (and not 2 or 3), all of this traffic is part of our problem. We want this data addressed so that SMB1 can be removed, with haste, from our organization’s infrastructure. Clicking on any one of these data flows will filter the other panes on the screen to only reflect that data flow filter. For example, clicking on the largest of the IP addresses, 192.168.2.57, would filter the data set to only reflect the flow from this IP address against Server2.Contoso.com (the server it is hitting). We could also filter by ClientAddress or SMB Server in the boxes directly to the right. Or, below those boxes, we could also filter on the SMBv1 traffic flow by Destination. In fact, this is where I tend to start with customers. Without even filtering this sample data set, we see that Server1.Contoso.com is by far the largest offender for fulfilling SMB1 data requests. Let’s click on it and display only the SMB1 data going against this Server, Server1. Clicking on it greys out the other SMB1 flows in the data set. SMB1 flows hitting Server1 are now the only ones in scope. This is reflected in the box we looked at originally -- the one that represented SMB1 client-server traffic flows: At this point, we have a specific, actionable set of SMB1 client computers to investigate and remediate; in other words, we have now actionable data. Our investigation here would quickly lead us to the clients making SMB1 calls against Server1 and then against other servers. It is likely that either the clients or something running on them are responsible for requiring the use of SMB1. It is also possible that the server itself is demanding SMB1 usage through misconfiguration (I’ve seen that several times). This is all the more reason to remove SMB1 from the environment, and then to disallow its use globally. If you have read my previous blog entries on Project VAST, the process should be becoming familiar to you. We have now surfaced a major vulnerability with SMB1 and can now take action to mitigate it. This is a central story to any modern and thoughtful security journey. Once we’re satisfied we’ve mitigated SMB1 traffic, then by all means we will disable it in the environment. That wraps it up for Project VAST and SMB1 auditing for now. Good luck, let us know how we can help and, as always, happy auditing. *If I get my hands on the article, I will post a link. **Thanks to my friend and colleague Mark Simos for this insight. ⁺https://cloudblogs.microsoft.com/microsoftsecure/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-remove-ntlmv1-with-project-vast Wed, 27 Jun 2018 13:51:20 GMT https://blogs.technet.microsoft.com/jonsh/?p=335 Quick Review: What is NTLM Once upon a time, before Active Directory (AD), before Windows 2000, before Microsoft’s implementation of Kerberos, there was NTLM (okay, I’ll stop with the reminiscing 😊 ). NTLM stands for NT Lan Manager, a suite of Microsoft protocols used for authentication and integrity. You may know NTLM as a challenge-response protocol. By today’s standards, an NTLM challenge-response is really pretty simple: -          Client sends user name to resource server in plain text -          Resource server generates a nonce or random number, and sends it to the client -          Client encrypts the nonce with the hash of the user’s password (which it has claimed into memory at logon) and returns it to the server -          The server proxies the username, the challenge it sent to the client, and client response to the challenge, to the DC (or other authoritative server) for confirmation -          The DC/authority retrieves the hash from its local Security Accounts manager (SAM) database and uses it to encrypt the challenge it received from the server -          The DC/authority compares the new challenge it created against the one from the client; identical challenges result in Authorization to the resource server (Ref: MSDN at https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx) Notice anything here? NTLM was particularly innovative and effective, in its heyday, because it never transmitted the user’s password or its hash across the network, where it could be easily stolen. Why is NTLM still in use if we have Kerberos? Good question. Though NTLM has been largely replaced by Kerberos in AD (and several other protocols for Internet-based authentication), NTLM is still in widespread use because it fills in some gaps where Kerberos is not possible. Kerberos relies upon a trusted-third-party scenario; in AD, this third-party is the Key Distribution Center (KDC) portion of a DC. But suppose you have an old application that can’t support Kerberos, or that you have a member server that lives outside of your AD forest, or that you need to call a resource in a manner unsupported by a Service Principal Name (SPN), such as an IP address. In these scenarios, you need something else and that something else is generally NTLM. OK, so what’s the problem? Well done – you’re asking all the right questions.  😊  The problem is multi-faceted. First, NTLMv1 hashing (or the mathematical value used to represent its password) is based upon the Data Encryption Standard (DES) symmetric-key encryption algorithm. DES was considered secure when it was invented and when NTLMv1 used it. But given today’s graphical processing units and freely-available password cracking tools, DES is easily broken. As easy as NTLM is to crack, that’s not its biggest weakness. Its biggest weakness is its vulnerability to credential theft attacks such as Pass the Hash (PtH). While there are many similar attacks, the underlying strategy is generally the same: steal a “secret” (such as an NTLM hash) from an end-point where it has been cached in memory (recall the third step of challenge-response), and use it to access resources to which one would otherwise not be granted access. (To be clear, PtH is not a Windows-specific attack.) A thorough discussion of PtH and credential theft is not really my focus here. (For a thorough discussion, check out my friend Mark Simos’s excellent video and work at https://aka.ms/pth.) For now, think of PtH as akin to using a fake ID. The account whose context is being used is still the account of record; but in its context, an attacker has stolen another “ID” (or hash) and used it to grant itself access to a resource that is prohibited (or to which the original account has not been authorized). In the physical world, maybe this “resource” is a bar or six-pack of beer; in AD terms, it’s generally a computing resource or data set. By using free tools (the same tools used by attackers), one can easily see the problem. Take a look at these commands executed with Windows Credential Editor (WCE). In a nutshell, we have just attacked NTLM by stealing very powerful credentials from memory and re-using them. This attack required no knowledge of NTLM, Kerberos or AD. And, in the example above, the attacker was able to achieve domain dominance. What to do about NTLM? We haven’t talked about NTLM versions yet. Prior to the ascendancy of AD and Kerberos, Microsoft released two (or more precisely three) revisions to the NLTM standard:

• NT Lan Manager
• NTLMv1
• NTLMv2

All three have been long deprecated; it’s safe to say that NT Lan Manager (“LanMan” for short) offers no real protection, NTLMv1 offers limited protection, and NTLMv2 – being the latest revision – is the better of the three. In terms of resistance to cracking, LanMan and NTLMv1 cannot be used securely (short of encrypting the transport with something like IPSec); only NTLMv2 may be considered secure from this standpoint. To be clear, all three are vulnerable to credential theft attacks like PtH. (To be very clear, Kerberos is vulnerable to similar attacks like Pass the Ticket.) That said, there are three compelling reasons for removing NTLMv1 from your environment, even if you leave NTLMv2 for backward compatibility (and you will probably need to, at least for awhile). First, it is far less complex for an attacker to anticipate the challenge length in NTLMv1, as it is always a 16-byte random number. NTLMv2, on the other hand, uses a challenge of variable length. Second, for challenge encryption, recall that NTLMv1 uses DES encryption, whereas NTLMv2 uses the stronger HMAC-MD5. As of now, it’s not feasible to brute-force HMAC-MD5. (Quantum computing will change everything, but that’s a different story.) Third, even if you’re somehow not concerned about the security vulnerabilities inherent in NTLMv1, you’ll have to remove it to use Windows 10 Credential Guard (and you should absolutely use Credential Guard). Because NTLMv1 is so much less secure, the only protocols that Credential Guard supports are Kerberos and NTLMv2. You’ll have to address the sources of NTLMv1 before using Credential Guard; else it won’t end well when you disallow NTLMv1. NTLM versions are easily configurable via Group Policy (GPO) at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level with six different options ranging from 0 (least secure) to five (most). A rule of thumb that I encourage customers to embrace is to start auditing with level three. Level three sets NTLMv2 as the default, but allows for fallback to the older protocol version. Eventually, we’ll want to get to level five, but we’re not ready yet. We need to audit, and that’s where VAST comes in. The Challenge (so to speak) At least three native methods of logging NTLM traffic exist. For our project and because we need to explicitly log the version, we’ll focus on Event ID 4624, An account was successfully logged on. The good news is that this is a very high-value, verbose event. It clearly tells us the account, originating Workstation name and its IP address (to be exact, this is the workstation name and IP of the computer that last chained the NTLM request). Critically for us here, 4624 also shows us the Package Name, which in this case is NTLMv1. So we can construct a pretty good story out of this data: The built-in Administrator account authenticated using NTLMv1 to the local machine from computer Workstation1, which has IP 192.168.2.61. Inspecting this event is efficient enough, but look closely. In my lab (as in most environments), I have thousands of events to comb through – in this case over 28,000 of them on this single machine. This is partly because 4624 tracks all successful logons – not just those using NTLM. Once again – what we have here is a problem of big data. Enter Project VAST We need to deal with this data in two ways. First, we clearly need to aggregate it. Windows Event Forwarding and SIEMs do this well enough. But in my experience, aggregation is simply not enough. After all, combing through this amount of data, even after aggregation, is not always very realistic; too few organizations are successful using aggregation alone. This brings me to the second necessary factor here: we need to make the big data set consumable and truly actionable. We’ll start, as we always do in Project VAST, with Azure Log Analytics. Once we have the data aggregated in Azure, we can create Kusto queries to view the data and control the output. In AD, we weren’t able to easily filter natively to only NTLM authentications; recall that 4624 is a successful logon, regardless of protocol. In Azure Log Analytics, we can easily query on the AuthenicationPackageName field, as we’ve done here. Still, in just 24 hours, we have 209 NTLM logons to sift through. Overall that’s better but we haven’t rendered the data really actionable yet. After all, we want folks to make well-informed, data-centric decisions about their security budget. A Closer Look Let’s take a look at Project VAST’s NTLM tab. Recall that here we are exporting the Kusto query out of Azure Log Analytics and importing it into Power BI. This configuration allows Power BI to query Azure Log Analytics directly with no need for intermediary data sources. The NTLM tab in Project VAST allows us to visualize the 4624 data and filter the display in a number of ways. Start by focusing your attention to the NTLM Version filter that I’ve marked above with the red arrow. Because 4624 includes the Package Name attribute, we can filter to either V1 or V2. For the reasons we’ve discussed earlier in this article, Brian and I have made the decision to default VAST filtering on this page to NTLMv1 only. This will help you focus on the less secure authentication traffic patterns. Directly above the filter NTLM Version is a filter titled isAdmin. Because Project VAST both queries your AD for members of built-in groups (like Domain Admin and Server Operators, for example) and also allows you to specify Administrative accounts, we can filter only admin accounts, non-admin accounts or (as we’ve done here), not filter on either. This view is therefore displaying the NTLMv1 authentication traffic for both admin and non-admin accounts. This is a good place to start. Below the filter for NTLM Version, have a look at NTLM Auth by Account (Top 5). As in tabs we’ve discussed previously, the yellow bars represent NTLM traffic from non-Admin accounts; the red, for Admin. If you’ve read the previous entries, this look and feel should be becoming familiar. In the upper left-hand corner, we have represented the flow of data of the top five NTLM authentications. In my lab, there are only two due to the size, 192.168.2.57 and -56, each sending authentications against DCs 1 and 2. Now that we have an idea of the most significant culprits and authentication flows, let’s drill down to some truly actionable data. By clicking on one of the accounts in NTLM Auth by Account, we can examine data that solely pertains to that account and the other filters that we have applied. Let’s click on svc7. On display now is only the data pertaining to svc7’s NTLMv1 authentication flows within our data set. We can easily see the host IP, the authenticating DCs, timestamp information, and some raw data. We now have the understanding that we need in order to take action – starting with determining the process running on 192.168.2.56 responsible for NTLMv1 traffic. Next we’ll work with application owners, vendors, or infrastructure teams to change the traffic over to NTLMv2 or Kerberos. In other words, we will have surfaced a vulnerability and then mitigated it – making for a nice story of progress as well as return on investment along our security roadmap. And like all journeys, our work with NTLMv1 won’t last indefinitely. Once we’re satisfied that we’ve mitigated all of our NTLMv1 traffic (e.g. the NTLM tab in Project VAST, filtered to V1, is blank), then it’s time to change our GPO setting to five. All new NTLM traffic will have to use NTLMv2, since the DCs won’t accept any of the other five levels of negotiation. That wraps it up for Project VAST and NTLM auditing for now. Good luck, let us know how we can help and, as always, happy auditing.]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-remove-insecure-ldap-and-protect-your-credentials-with-project-vast Fri, 11 May 2018 19:56:20 GMT https://blogs.technet.microsoft.com/jonsh/?p=255 credential theft and reuse. And today I’d like to dive deeper into one such widespread vulnerability: Lightweight Directory Access Protocol (LDAP) security misconfiguration. We need to talk about it, and you need to do something about it. And Project VAST can help. Hey there, it’s Jon again, with this month’s installment about Project VAST (the Visual Auditing Security Tool). Quick Review: What is LDAP LDAP (an X.500 derivative) is a protocol for data exchange between clients and data stores like Active Directory (AD). Clients bind (or authenticate) against a Domain Controller (DC), run a query to ask for a certain data set, and then receive the data set back from the DC. An example of this exchange might be something like this: Client1 binds against DC1 and asks for the multivalued attribute value member for an object with the displayName of zookeeper. In lay terms, the application, person, or script running the query just asked for the name of all members of an organization’s group zookeepers in the directory. (AD uses LDAP for all sorts of internal calls as well.) Simple enough, right? Well, not so fast. What’s the problem? The problem is with how the client asks for the data. Specifically, in how it binds to the DC. Unless you’ve configured the DC to require signing, many clients are returning unsigned traffic, which is susceptible to replay or attacker-in-the-middle attacks. This may result in nefarious activity, such as modified packets, in which a server or even a person makes decisions based on forged data. Let’s have a look at a simple network cap below. See anything? Yup, we’ve exposed potentially sensitive data to an attacker, or anyone else with a sniffer. Let’s look a bit deeper and examine the binds themselves. They’re similarly not secure. Turning back to our simple network cap, we can see the credentials being asserted in the simple LDAP bind. (For clarity, this is not an AD problem. It’s a problem of LDAP and specifically of LDAP implementations.) Even more concerning, many organizations are exposing their highly-privileged authentication principals' credentials – such as the ones for those that belong to the Domain Admins group. With a simple network cap, an attacker can capture these credentials and achieve an escalation path or even a domain dominance type scenario. Don’t despair – yes, you are probably vulnerable and yes, you have work to do. But with some help from Project VAST, you can mitigate this scenario. What to do about insecure LDAP? Well, the first order of business is to verify that you indeed do have this vulnerability. We’ll do this by checking first for the existence of Event 2887 in the Directory Service log. If you find this event (and you probably will), it means you have had, in the last 24 hours, a client attempt to bind with either a SASL (non-signed) bind or a simple bind over a clear-text connection. At the same time, the existence of 2887 tells us that the directory service is not currently configured to reject such binds. In other words, we have verified the vulnerability exists in the directory. An example of an Event ID 2887   At this point, we know we have an insecure LDAP configuration and we have clients leveraging it insecurely. But we haven’t yet discovered the source – we don’t know where to take action on the client side. (We could simply start requiring LDAP signing on the DCs, but that would cause the DCs to reject these binds. That would probably not end well.  😊 ) For this, we’ll need to configure some auditing in order to gain a bit more information in the form of Event ID 2889 In order to capture this event, we need to make a registry change on each of our DCs. We’ll target HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" with a DWORD value of “2.” If you have more than a handful of DCs, you’ll probably want to use Group Policy Preferences to set this registry value on each of your DCs. (This can be a very verbose log. You may need to increase the size limit of your log, and certainly turn it off when you’re finished.) For our project, 2889 is a high-value event, in that it tells us some pretty granular information about the sources of insecure LDAP: The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a cleartext (non-SSL/TLS-encrypted) LDAP connection. Event 2889   By closely examining this example event 2889, we can see that account svc4 has actually performed an unsigned SASL or clear-text bind from IP address 192.168.2.67. Also, pay attention to the value called Binding Type. The value of 1 in the example tells us that svc4 performed a simple bind; a value of 0 would indicate an unsigned SASL bind. The Challenge Do you see the challenge here? In order to enforce signing on our DCs, we need to first remediate insecure binds (or else we’ll break the applications that rely on them). Look closely at the picture above. This log file represents one bind out of 6,771 during a 13-day period from one DC in my lab. You could use Windows Event Forwarding or a SIEM to aggregate the log files. If you are able to accomplish mitigation of insecure LDAP using these technologies, then you should use them. (You should also share how you were able to accomplish this.) In my experience, aggregation simply isn’t enough. Assuming for a second that the DC above is representative and that my organization has 10 DCs, I have something in the neighborhood of 60,000 logs to sift through. That’s simply not realistic on its own. What we have here is a problem of big data. Enter Project VAST This is one of the charters for Project VAST: to make big data sets in the form of audit logs actionable and realistically usable for security mitigation activities. As I discussed in a previous blog entry, we’ll use the relatively new technologies of Azure Log Analytics and Power BI to get a handle on our data here. Using the Microsoft Monitoring Agent (MMA) and some Azure configuration, we’ll pump all of our 2889 events into Azure Log Analytics. Once the data has arrived (typically a delay of a few minutes), we can view and begin controlling the output with a Kusto query in Azure. That’s better, but it’s not really truly actionable yet. After all, this data set of seven days and two domain controllers contains 9,258 event records. The real goal here is to leverage the rich visualizations that we’ve come to know and love in Power BI in order to represent the data in a truly actionable format. This allows us to make logical decisions about how we present the data. More importantly, it allows data consumers to make rational, data-centric decisions and to act upon their data. A Closer Look Now that we’ve covered the vulnerability and the problem in taking action, let’s have a closer look at Project VAST’s Insecure LDAP tab. The first thing to notice here is the general look and feel. In the coming months and blog entries, I hope that this interface will become familiar to you. Let’s start in the upper left-hand corner and move through the tab clockwise. (As in the past, a few details have been obfuscated to protect the innocent. 😊) In the upper left, you’ll see the data flow. This visualizer is mapping the flow of client to DC data. Here, we see a large amount of insecure LDAP traffic coming from two clients and against two DCs. (Recall that the data source here is 2889; in a normal production environment, the data flow may be more complex, so we’re limiting the view to the Top 5 clients.) Right off the bat, we’ve got a few IPs with which to begin our detective work. To the right of the data flow are some slicers: source IP and destination DC. These will be useful once we’ve decided upon the specific LDAP workflows that we need to research. To the right of Destination DC is a critical filter called isAdmin. This is just what it sounds like. Because VAST does a limited set of queries against AD, we can determine what accounts constitute Administrative accounts; we can (and should) pay special attention to these high-value, high-risk accounts. This brings us to Insecure LDAP by Account. This is actually where we tend to start our research with customers. The first thing you’ll notice is that some data bars are red and others are yellow. This is because red bars delineate that these are Administrative accounts. (By Administrative accounts, we mean that these accounts have an adminCount value of 1; they are or have been members of a group protected by AdminSDHolder.) By clicking on one (let’s say svc1 in the example above), we can filter all other traffic out and focus solely on this account’s insecure LDAP traffic. By doing this, we’re taking a problem that might seem overwhelming and tackling it in bite-size chunks. This allows us to really dig down into the data to understand where it’s coming from – if necessary, we can look to a raw(er) view of the data (lower right-hand corner) and also delve into the date and time stamps from the 2889s with our final slicer in the lower left-hand corner. Once we have discovered the source of our insecure LDAP traffic, we’ll work with application owners, developers, and vendors to move to signed and/or encrypted LDAP. Ideally, we’ll also work with decision-makers in our environment to set a date for insecure LDAP to be turned off. We’ll do this so that once the project is complete and we see no more LDAP binds (e.g. we’ve established a KPI of zero insecure LDAP binds), we can disable insecure LDAP on the DCs. That way, new LDAP calls that appear in the environment won’t be able to use insecure or unsigned implementations. A small point of clarity After my last blog post, a few folks asked some questions around Project VAST. Specifically, folks wanted to know how they could implement Project VAST in their environment. At present, the only way to implement Project VAST is through Microsoft Premier services, as Project VAST is a Premier Field Engineer (PFE)-designed service. If you’re interested, please contact your TAM or Account Team. (If your organization is not yet a Microsoft Premier customer, please click here.) In the future, the project may become open source or may even integrate into one of our Azure Security products. Stay tuned! Until then, happy auditing.   *For a broader discussion of credential theft mitigation, please browse the Securing Privileged Access (SPA) roadmap at https://aka.ms/privsec.]]> https://docs.microsoft.com/archive/blogs/jonsh/finally-remove-your-security-blockers-introducing-project-vast Wed, 28 Mar 2018 14:27:27 GMT https://blogs.technet.microsoft.com/jonsh/?p=225 yes to either (or both) of the questions above, then the Visual Auditing Security Tool (VAST) can help. VAST provides a repeatable, scalable solution to quickly and cost-effectively help mitigate security blockers by visually representing specific infrastructure log and audit events. It also provides specific, actionable KPI-based metrics to measure your organization’s effectiveness in mitigating the risk of devastating credential theft. Many organizations aggregate log data into query-able aggregation stores such as SIEMs. Even so, experience shows that combing through log files in an effort to correlate security events is typically a time-consuming activity from which you can draw limited conclusions and take limited action. VAST takes a different approach. VAST leverages powerful, relatively new Microsoft technologies – chiefly Azure Log Analytics and Power BI – to present your organization with a rich, visual representation of its security data in a single-pane-of-glass interface. VAST can work along-side your existing solutions – and it adds a dimension to your data that most enterprise SIEMs presently don’t: interactive data visualization. Over the coming months, Brian and I – Project VAST’s creators as well as the team behind the SecurityPFE blog – will be sharing the capabilities of this new security product. The format will be pretty simple: once a month, we’ll feature a detailed discussion of one of Project VAST’s capabilities – what it can detect, what it can measure, and how it can help your organization achieve more on its security journey. In this inaugural blog entry, we’ll introduce Project VAST and share a bit about what it can help you to accomplish. We’ll also provide some information about how your organization can partner with Microsoft Services to implement VAST in your environment. How can Project VAST Help? Project VAST grows directly out of our experiences working with security-conscious customers. Virtually all customers we work with struggle in various ways with activities like removing deprecated protocols, securing LDAP traffic, controlling their service accounts, enforcing compliant use of their Privileged Access Workstations (PAWs), safeguarding their privileged accounts, and understanding authentication patterns within their infrastructure. By not just aggregating big data such as log sets, but also by providing a rich, visual interface, Project VAST makes it easy to accomplish these activities – and a whole lot more. How does Project VAST Work? First, we work with you to capture the relevant event data into your Domain Controller logs – mainly Security and Directory Service. Then, using the Microsoft Monitoring Agent (MMA), we capture the log information and aggregate it into Azure Log Analytics. Using the relatively new Kusto query language, we can pinpoint exactly the data which is relevant for each of VAST’s detections or KPIs. Finally, we pull the data into Microsoft Power BI, where we can render security data in a rich, visual interface – empowering your organization to make intelligent, data-based decisions. But as the consumer of Project VAST, you don’t really have to mess with any of the back-end technology once it’s set up. You will chiefly be consuming the data directly out of Power BI, so let’s have a look at the VAST interface. The Project VAST Interface (Courtesy of Power BI  😊) Above is a screen shot of Project VAST (a few details have been hidden or changed to protect the innocent). The first thing to notice is the series of tabs along the bottom. We call each of these a separate “detection” or “KPI” – essentially each represents a vulnerability being measured. When we set up Project VAST with customers, we stress a particular mindset. We encourage our customers to think about security not as something they can “get right,” but more as a continual journey. And this journey, as reflected in the interface of VAST, entails surfacing vulnerabilities and then taking concrete, specific, achievable steps to solve them. You might think of each tab, therefore, as representing a step on your organization’s ongoing security journey: User and Computer Hygiene, LAPS Deployment and Auditing, Insecure LDAP, Deprecated Protocols, Account Theft and Misuse, Privileged Group Hygiene, Authentication Posture, and more. To view information about a detection or KIP, simply click on the tab at the bottom. In the example above (and we’ll talk a lot more about this in subsequent posts), I have clicked on the NTLM tab and am therefore able to view information about the organization’s NTLM usage. (Note: NTLM is a deprecated protocol consisting of several versions, chiefly V1 and V2. Click here for more details.) Let’s have a look at the measurements that are available in this particular tab. Starting clockwise from the upper left:

1. A traffic flow representing the client-server flow of NTLM traffic
2. A filter boxes for client and then server
3. A filter to view authentication traffic from administrative accounts only
4. A filter for NTLM version (filtered to V1 in the example)
5. Top 5 NTLM accounts by authentications
6. A table displaying the data set
7. And finally, a chart allowing for display and filtering by authentication time

One goal across many detection tabs is to help end the stalemate facing so many organizations: organizations know they have to turn off unsafe protocols like NTLM v1, but don’t know what they’ll break if they do. Here we show the exact sources of the traffic, so they can be addressed – and ultimately  the authentication type can be turned off at the root level. Where can I go to learn more about VAST? Brian and I recorded a Microsoft Taste of Premier about VAST. Check it out here. How do I sign up? If you’re a Microsoft Premier customer, then we’d be delighted to work with you. Contact your Technical Account Manager (TAM) or account team. If your organization is not yet a Premier customer, then click here for information on how to become one. A Few FAQs We’ve been asked several questions from multiple folks. Here are a few of the common ones Q: Where do we have to install Microsoft Monitoring Agents? A: On all of your domain controllers; nowhere else Q: Can VAST co-exist with other SIEM products? What about integration? A: Yes! VAST is a separate tool from SIEM products. Future enhancements may include SIEM integration. Q: How can we get started with VAST? Can we get a demo? A: Contact your Technical Account Manager (TAM) or account team. At present, a limited number of demo slots are available. Q: What are the costs for using Azure Log Analytics in VAST? A: In short, it depends. That said, we have designed VAST to be very affordable for organizations of many different sizes. Factors that will influence Azure consumption costs are licensing type, organization size, number of domain controllers, and the amount of activity in your environment. Azure Security & Compliance pricing is available here. Q: Is there a size limit for using VAST? A: No, we have designed VAST to scale to organizations of many different sizes. Q: I have an idea for an additional detection or KPI. Could I get it added? A: At present, the best avenue is to talk with your TAM; he or she can pass your idea along. In the future, there may be a web-based feedback tool, such as UserVoice, available for VAST. Q: Does VAST integrate with Microsoft Advanced Threat Analytics (ATA)? A: Yes! VAST will query and display both health and suspicious activity (SA) events from ATA in its dashboard. That wraps up the inaugural edition of the SecurityPFE blog and our VAST overview. Keep an eye out each month for detailed information about each of Project VAST’s detection capabilities. Until then, happy auditing. 4/25/18 - Edit: Added the link to the Taste of Premier video.]]>