Security Stuff

Build a fast, free, and effective Threat Hunting/Incident Response Console with Windows Event Forwarding and PowerBI

Jessica Payne (MSFT) — Fri, 08 Dec 2017 05:25:55 GMT

Monitoring your network and gathering massive amounts of data has become easier and easier. Many guides exist on how to gather data, and lots of companies have "enterprise grade" Security Information and Event Management products that can ingest terabytes of data. But what seems to be missing from most environments is the ability to apply context to the data they get, or a knowledge of why certain artifacts that get gathered are important. Doing Incident Response as a consultant gives you a unique perspective on monitoring, as you get to experience a wide variety of networks in varying stages of overall "health" during what is the worst possible time for owners. Things that normally can slide under the radar like slightly unhealthy patch management systems, or systems that have operational issues with monitoring agents suddenly become insurmountable problems to diagnosing and solving the security issue on the network. Another common finding is that while the company may be collecting data from servers and Domain Controllers, due to licensing costs they are not getting data from desktop endpoints, which are often times both the entry point in an intrusion and where a lot of the data access/exfiltration and lateral movement story happens. These issues are universal in companies big and small, with massive investments or minimal investments in their IT departments, and often aren't revealed until an incident occurs. This leaves the IT and Incident Response team in a position where they have to correct visibility issues when their infrastructure may not be working optimally, and rapidly be able to triage the data from potentially hundreds of thousands of endpoints while learning how to apply context to the events they are seeing. Learning from these incidents, and the requirements inherent to them (ability to deploy tools and get data rapidly, use only built in tools, has to be usable and deployable by people who probably haven't slept in a week) I developed an Incident Response dashboard that I liked so much I personally used it to "hunt" on all the engagements in the later part of my Incident Response Consultant tenure. Many of the customers liked it so much that they have kept it in their environments to use for proactive threat hunting and log analysis. Using the built in Windows Event Forwarding components of Windows, some PowerShell scripts, and PowerBI desktop, you can create a fast, free, and effective console for diagnosing problems and finding Indicators of Attack in your network. My hope is to make security investigation much more accessible to everyone by showing how to do this quickly and without a massive monetary investment. We'll go in to detail of how to deploy it and what to look for below, but here's a preview of what you get at the end to hopefully convince you to finish reading and deploy. Console with PowerBI data slicers of the collected events: Rapid ability to zoom in on selected indicators and remove other data: If you've been lucky enough to not yet have to work on a major Incident Response, I can't stress enough how valuable the ability to remove non-relevant data and quickly get to which machines require deeper level analysis is. If you're working an incident where the adversary is still live on the network and fighting the "Attacker's Time to Goal" metric, or just trying to get the issue as fully investigated as possible so you can move to an enlightened remediation effort, being able to start with a very wide net of key indicators can save days of investigation time - especially if the incident is on a globally distributed network were getting "hands on keyboards" in a remote office may be difficult. Event logs may be older technology, and the world certainly has more advanced ways to analyze a system but logs still remain the first place most investigators look on a system, and one many organizations still don't have fully under control. A great example of this is NotPetya malware outbreak. NotPetya caused massive amounts of economic damage and downtime to companies, but it also used an incredibly low tech old trick of running wevtutil cl security to clear event logs. This means that the computers that were about to go offline forever would have been sending a very strong signal in an Event ID 1102 Event Log Cleared event to any central logging that that there was something going on that needed more investigation. Even when we talk about "advanced" and "fileless" malware, there are event log traces - some of the most advanced fileless malware out there is still leaving a persistence point in the form of a new service or scheduled task which is going to leave us a log entry to investigate. Advanced attackers can bypass or tamper with logs, but that doesn't absolve you from monitoring them. Learning what to look for and making sure you have common techniques well monitored and practiced with your Red Team is like leveling up in a game or a martial arts rank - you still have to practice the fundamentals. A trend I see all too often is that attackers will just go ahead and be noisy because they know nobody is watching or that it will take long enough to start a response effort that they will have already finished their task. Using the fact Event Logs are ubiquitous and will be encountered by the attacker at every stage of their operation can potentially allow us to (along with some other hardening techniques) use the entire network as a giant sensor. The attacker will have to make a choice between leaving logs or creating a signal by removing or editing them, which can give network defenders hope in a battle that often seems stacked against them.

Setup and Configuration

This solution got named WEFFLES (Windows Event Logging Forensic Logging Enhancement Services) when I first created it and (perhaps unfortunately) the name has stuck, so we'll be using that term to refer to it in the rest of the post. WEFFLES is designed to be small and lightweight, both for speed of getting something deployed during an Incident Response and also for the sake of being sustainable in an environment going forward. It's not necessary to be familiar with the underlying technology of Windows Event Forwarding to set up the solution as it's scripted out of you, but if you would like to learn more about it before starting you can read my "Monitoring What Matters" post or watch my Microsoft Virtual Academy session on the topic. Requirements for deploying WEFFLES :

Active Directory - we need to be able to create and link a GPO that will apply to all of the machines we want in scope of monitoring. I would hope this would include desktops, servers, and domain controllers for the sake of completeness, but the flexibility to link the GPO that enables Windows Event Forwarding to a testing Organizational Unit is also a great way to start.
A server to act as the Windows Event Collector - I recommend using a dedicated server as the collector, for performance and security reasons. The server does not have to be massive in spec though, even if you have a lot of endpoints you plan to have checking in to it. The log data should not go over 10GB for even large organizations (500k endpoints is my biggest WEFFLES deployment so far) and the solution exports data to CSV files for safekeeping, which are quite small. The main performance need on a collector is memory to hold the log files. We scope the size of the event log as 1GB as it acts as a holding place only before the events get exported to CSV in this solution, but the general rule of thumb is if you wanted a larger event log you need : amount of memory required to run windows and do things like backups + specified event log size.

PowerBI Desktop - The console/data slicer itself is built using PowerBI Desktop. If you'd rather use another data slicer or the most widely used incident response tool on the planet (Microsoft Excel) the output weffles.csv file can be loaded into many different tools. There is a pre-built weffles.pbix PowerBI Desktop file in the GitHub repo that allows you to use the same data slicer console view I show in this post.

All the build files are located in the WEFFLES GitHub repo, and I'll explain how to use them in the rest of the post. The first thing we need is a Group Policy object to configure Windows Event Forwarding. You will need to change the "SubscriptionManagers" Fully Qualified Domain Name setting to the FQDN of your collector server, unless of course your collector server is named wec.contoso.com. The rest of the URL is telling the clients which port to check into, and how often to do it. The Refresh=60 setting on the end of the URL is telling clients to call back to the Windows Event Collector server every 60 seconds to see if there are any changes to subscriptions. I've deployed this to large networks with that setting and not had issues, but you can feel free to scale it back to 5 minutes (360 seconds) or whatever works for your investigation to save on traffic. The "Log Access" portion of the GPO is to give the Network Service account read access to the Security Event Log. We do this so we can run WEF in a least privilege mode where nothing runs as administrator. To figure out what your Log Access setting should be, run wevtutil gl security on example machines in your domain. Copy the existing entries if you don't want to change anything, and then append (A;;0x1;;;NS) to the end. This setting replaces what is existing on the system currently, so if you have an account granted access you don't want to break, take the extra time to run the wevtutil gl security command first. (these steps are explained in great detail in my MVA session on WEF.) The next setting we need in the GPO is to start the Windows Remote Management service. There's a difference between starting this service and configuring a listener - just starting the service doesn't make port 5985 available for attackers, remember we're setting up the systems in "push" mode where they just send data to WEF, nothing is reaching in to them. We need this GPO, as the service was not automatically started on 2008R2 and Windows 7 machines. If you have a more modern environment where it's running everywhere already you may still want to use a GPO to ensure it stays that way. There are two options presented here for setting the start type of the service, one is Group Policy Preferences, the other is using the System Services setting. I've usually used Preferences in production deployments to accommodate legacy systems, but I tested the other way in my lab and it did work if you want to go that way. Once you have your GPO created and linked where you need it to be, copy the downloaded files from the WEFFLES GitHub Repo to your collector server. Execute the wefsetup.ps1 script, which will take care of everything for you - including importing the coreevents.xml subscription. WEFFLES uses the EventLogWatcher script from CodePlex to output the CSV file, and it's kicked off via ScheduledTask as system startup, so reboot the machine now. The next part takes a while to "cook" so have patience and maybe walk away for 10 minutes as the subscriptions start to work and the script starts to parse the logs. After the machine has rebooted, you can check the status of Windows Event Forwarding by opening Event Viewer and checking the "Subscriptions" area. You should see the "CoreEvents" subscription we imported, and if you right click and check runtime status you can see which machines have checked in. If you navigate to the Forwarded Events Log, you should see some of those Core Events in the log. Browse to the c:\weffles directory, and you should see a bookmarks.stream file and weffles.csv - that means everything is working! At this point you could just open weffles.csv in Excel and use the Data features there to filter and search, as a lot if IR professionals will be used to doing. I prefer copying weffles.csv to my own laptop however, and using PowerBI. If you download create a c:\weffles directory on your machine and copy the weffles.pbix from the GitHub repo and the weffles.csv from your environment to it, you should be able to open weffles.pbix (assuming you installed PowerBI Desktop) and click "Refresh" and it will pull the data from your environment into my example slicers.

What we're looking for, and why

The goal is to collect very specific and purposeful pieces of data, so we can triage them effectively. Have a well-defined goal in mind behind each piece of data you are collecting. Here are the ones I like to use to start with.

Indicators of Attack/Persistence Creation - the "Core Events" subscription

Security Event Log 1102 - Security Event Log was cleared There are some events that should always escalate to a deeper level forensic analysis, and clearing the Security Event Log is one of those. You will likely encounter some Benign Positives as you do this that are admins doing it for one reason or another, but the benefit far outweighs the annoyance. This can also be an effective way to "reeducate" individuals with administrative access who may be practicing unsafe behaviors. System Event Log 7045 - New Service creation event One of the most basic and popular ways for malware to become persistent on a system is to create a new service - even in the case of "fileless" and "in memory" malware. A very common example of this is new service creations that launch a PowerShell cradle to download code from a web server. New service creations can lead you to "possibly unwanted programs" as well, which in the case of an investigation means remote administration tools - used by the attacker. Psexec and several screen sharing tools are well documented examples of tools used by attackers just as much as authorized admins. Security Event Log 4720 - New local user created Why bring malware when you can just bring a new user? Since most networks haven't implemented lateral movement mitigations, adding a new local account on something like a SQL server means that the attacker can use access to any system on the network and RDP directly to their goal, and not utilize a trojan or malware that may be more likely to be discovered than an account named "sqladmin." Scheduled Task Operational Log 106/200 - Scheduled Task was registered or executed Just like services, the scheduled task is a very popular persistence method - but it also has the bonus capability of lateral movement as tasks can be registered remotely. You can see a lot of interesting attacker behavior in scheduled tasks, including using rundll32.exe to execute code. Why these versions of the Event IDs when there may be more verbose or newer ones? I picked the Event IDs that are most often on by default and available in the most networks, as the original goal was Incident Response. 7045s for service creation are a great example of that - there's a far more verbose and useful version of that event in Event ID 4697, however I have never seen that reliably available "in the wild." (As a good example of that, my work laptop which should be the best possible scenario has lots of 7045 events but no 4697s.) There's no Time Machine for IR yet, so we have to go with what is most likely on already without an Audit Policy change. If your environment reliably has the more verbose events available and you're not taking the solution from company to company doing IR, feel free to substitute them in as they will help you investigate. If you're a Red Team reading this, you may have noticed some of these things look like your Tools, Techniques, and Procedures - and the real attackers know that. If you have finished an operation please make sure you communicate which systems you accessed and clean up after yourself. I have investigated several cases where the initial response to my questions was "that was the red team" until we looked closer and it was in fact an attacker who had piggybacked on an artifact left by the Red Team on the machine. (Blue Teams also need to make sure they don't get used to "Red Team Tricks" and spend time deconflicting activities, as more and more attackers are emulating Penetration Tests and this can waste valuable investigation and attacker disruption time.)

Interesting Accounts

Whether you are investigating a compromise, attempting to figure out "what does that service account that has been in Domain Admins for 10 years actually do," or troubleshooting operational issues in your environment, you're likely to have already defined a list of accounts or computers that are "interesting." In an IR event, this is usually a compromised high value account (such as a Domain Admin level service account) that has been identified as behaving suspiciously, and the goal is to see what it has accessed, and what other credentials or systems it may have gained access to. Versus gathering all the logon events of every account, we can build and later modify Windows Event forwarding subscriptions with the accounts that are "in scope" for particular logon events. 4624 - Successful Logon This event is a treasure trove of information. 4624 events show you not only who logged in, but where they did it from, what process was associated with it, and what type of authentication was used. By looking at 4624 events you're going to learn a lot of things about credential exposure and unsafe admin behaviors as well as being able to track attackers. Knowing your Logon Types helps a ton here, they are a numerical value in the field that will tell you how the action occurred.

Logon Type 2 : Interactive, aka a full session often a hands on keyboard kind, except it can also mean RunAs.
Logon Type 3: Network logon, like file shares
Logon Type 4: Batch or Scheduled Task logon (this not only leaves credentials in memory, but on disk in the LSA secrets)
Logon Type 5: Service logon (this not only leaves credentials in memory, but on disk in the LSA secrets)
Logon Type 7: Unlocking the system
Logon Type 8: Cleartext logon, which means something like Plaintext Auth to an IIS server or it can mean CredSSP logons - meaning the Cleartext is local to the machine, not over the network. Investigate the package type and the source for this one to figure out what it really means.
Logon Type 10: Remote Desktop logon - if you see a service account doing RDP logons you either have an attacker, or some admins that need threat landscape education.

4625 - Unsuccessful Logon Failed logons are not normally something I track as related to attacker behavior (in the day and age of Mimikatz, we just assume they have the credentials they want versus brute forcing them) and is more something to gather in preparation for remediation activities - what machines have failed logons when that mystery account in Domain Admins finally has it removed. There are some exceptions to this rule however, like the Qakbot malware that gets discussed a bit later in the post. 4648 - Logon was Attempted with Explicit Credentials This event is why I cite that you must get logs from workstations as well as servers - if a 4648 Logon with Explicit Credentials is performed it gets logged on the originating machine. Meaning that if an attacker runs maliciousscript.cmd with a RunAs against a Domain Controller you would likely just see a network logon from the account on the DC - something that blends in far too easily. This will also allow you to see things like mapped drives with admin credentials, which is a popular way of exploring and exfiltrating data among attackers. Once you define who is "interesting" for your investigation, you can edit the InterestingAccounts.xml subscription to add their account names to it and then import it with wecutil cs "InterestingAccounts.xml" Now that we have our data, we can start to "hunt" in the environment.

Investigation

Here are some examples of things I would look for in an investigation. By clicking the radio button next to the 1102 event, I can filter out the machines that have had their Security Event logs cleared. I would want to flag these for deeper analysis. Here I am filtering by Logon Type 5, "Log on as a Service." This Is a service running as Bob's domain admin account, which is a bad sign from a credential exposure perspective but also because we already knew Bob's account was compromised. This is a good example of an Extremely Shady machine. It has a PowerShell cradle as a persistence mechanism, and two not-really-legit ups services on it. Incident Response is always a bit more art than science, and practice makes perfect. You'll probably make some assumptions in the beginning that might lead to false positives and make you feel silly, but don't worry, and don't lose your enthusiasm. Use the console to understand how your environment works, and make it a regular activity versus just an IR activity. Data is power, and you can help operations teams as well as security teams with this.

Flexibility: add what you need, when you need it.

Let's say you're having an outbreak of Qakbot, a malware which can cause mass lockouts on your network as it steals and brute forces credentials and performs lateral movement over WMI. You'll have scheduled task and service creations to show you the persistence points, but ultimately you're going to need to track down which accounts are being locked out and from where to solve the mystery. We can add a new subscription for account lockouts, and have it propagate to the entire domain and get us information in a matter of minutes - just from importing a new subscription. We're using an account lockout as an example here, but the steps apply to almost all Event IDs - meaning you can add what you care about tracking, depending on the circumstances you're trying to diagnose. We start with an event log entry for a lockout - I just generated this one by doing Run as a Different User and failing logons for Bob, so you don't have to be having an active malware outbreak to have an event log entry to practice from. We need to pull data from a few fields to get our subscriptions to work. The easy pieces of data to gather are which Event Log the message you're looking for lives in, and which Event ID. We 're going to need to pull out EventID 4740 from the Security log via Windows Event Forwarding Subscription - this one is easy, so feel free to make it via the GUI if you want, but we're going to get more flexibility and the ability to pull existing events if we write it manually. This is what the subscription looks like when made manually. You can see the relevant parts - which log it came from, what EventID, and that we want the existing events as well as new one. (Don't worry the .xml is in the GitHub, you don't have to type it from the screenshot.) We can save that to our working directory, and then import it via wecutil cs "InterestingAccounts.xml" After a few minutes, if everything goes correctly you'll start to see 4740 Account Lockout events in Forwarded Events . Our next step is to get them into our weffles.csv file so we can see them in the PowerBI Console. To do that, we're going to need to investigate the XML view to decide what parts of the Event Record we want to add to our CSV, so click on the Details tab and then the XML view radio button. Lockouts will be fairly straightforward, as they share Event Data with events we're already collecting, but here you can see the "guts" of how Event Viewer knows what to display for you. (My goal in walking you through this manually is to teach you how the underlying technology works, but if you're in a hurry or have a very complicated event Kurt Falde has written a script to automate some of the subscription creation for you.) The relevant parts from an investigation standpoint art the TargetUserName (who was being locked out) and SubjectUserName (who performed the locking out.) Sidenote: see how the Subject User is a computer? That's because in AD Computers are people too, or at least Users. The "Domain Users" group contains computer objects as well as User objects, which is an interesting thing to know from a security perspective. An interview question I like to ask is "what is the difference between Domain Users, Authenticated Users, and Everyone groups?" We need edit the wefflesreporting.ps1 script, and then first place we need to go is the $EventLogQuery line - since you've seen Xpath filters it should be clear what this is, but this is where we are cherry picking the Event IDs from the Forwarded Events Log we'd like to have in the CSV. We need to tack the 4740 EventID on the end of that. After that, scroll down a bit and you can see a large block of $EventObj | Add-Member lines. These are where the relevant parts of Event Logs get selected as areas we are able to add as text to our event log entries in the CSV file. Since the TargetUserName and SubjectUserName are needed for other events we are already collection, we can see they are already available for us. We need to add a new entry for the 4740 events to the script so they show up in the CSV, so scroll down to the area where we're adding new $EventRecordXml items to our CSV. You'll see a lot of them here in my original file, so you can feel free to cut and paste (I'm not judging) just be careful to only have $EventRecordXml items that actually exist in the EventID you are looking for to avoid errors. (And also avoid cut and paste errors that wind up with you having 17 ElseIf statements and other errors like I did before.) So now we have the item in the script, which is being run by our scheduled task. Since the scheduled task runs at System Startup, we need to get it to reload to recognize that we made the change. You can either go old school and just reboot the machine, or from an elevated PowerShell prompt run Stop-ScheduledTask -TaskName "WEF Parsing Task" followed by Start-ScheduledTask -TaskName "WEF Parsing Task" to restart the task. After that, give it a few minutes to catch up with adding the new events, and you should be able to open up the weffles.csv file and see the new Event IDs in it. And if we refresh the data in PowerBI, we can now rapidly get to which accounts are being locked out on which machines - which in the scenario of a Qakbot infection, is an important thing to do quickly. The process is really simple and useful for many different scenarios. Maybe you have a particular application with an error code that matters to you, or maybe you want to enhance the WEFFLES logging to include things like Event ID 400 for PowerShell downgrade attacks to detect things like the PS>Attack Tool. The idea is that you have the power of Windows Event Forwarding applying to massive amounts of endpoints, with the ability to rapidly deploy new detections, and the great data slicer that is PowerBI to make hunting through the stacks of data easier. If you need some more ideas of things you might want to monitor, check out my Monitoring What Matters and Tracking Lateral Movement posts. Acknowledgements:

I talk about Event ID 1102 a lot. So much that when the Bad Rabbit malware that was very similar to NotPetya happened, my mum emailed me simply "Event ID 1102" So if you learn nothing else from this blog, my mum wants you to monitor 1102 Events.
Kurt Falde for helping me find the right tools for my crazy idea
Sean Metcalf, Valentine Reid, Devon Kerr, Lee Holmes, Carlos Perez, Jacob Soo, and Swift On Security for testing/reviewing my code
The companies I have visited who gladly tested my code in production but would probably prefer to remain nameless. :)
Greg Linares for reviewing the very first draft of this all the way back in 2016 and encouraging me that it was a good idea

When the manual is not enough - runas /netonly, Unexpected Credential Exposure and the Need for Reality Based Holistic Threat Models

Jessica Payne (MSFT) — Mon, 04 Apr 2016 16:14:23 GMT

One of the things I always advocate for IT Professionals/Defenders is that versus letting Penetration Testers and Real Attackers figure out the holes in their systems, is a serious contemplation of how you would bypass your own defenses. Your adversaries are more than willing to spend time learning the apps and defenses you have in place and who knows better how those defenses work than those that built them? This post is less about a particular bypass or technology (as all sets of controls will have workarounds) and more about thinking like an attacker. Try to bypass your own systems - before someone else succeeds. This exercise proved especially fruitful at a recent super smart and awesome customer, as within minutes of putting Privileged Admin Workstations and Credential Theft Mitigation GPOs in place in their domain, the Domain Admins found a way to bypass the mitigations and do Domain Admin work from their regular workstations and the internal Red Team found that this bypass left High Value Credentials behind for easy harvesting. What happened? Well, it all revolves around the runas /netonly command and the Logon Type 9. Let's do a run through of how this looks. This is my lab, and spoiler alert, we know credentials are getting exposed here so let's start off by mimicking real attacker behavior - capturing credentials in a persistent manner. This could be done via an implant, or Mimikatz, keylogging, or LSA Keychaining but in this instance I'm going to use Windows Credential Editor. Here you can see that at startup/initial logon by Bob, we just have credentials for Bob's account and that of Bob's computer (cleverly also named Bob.) Bob is our Tier 0/Domain Admin. Let's pretend Bob is new to the job, and while he's been given a PAW, nobody has shown him any scary videos or trained him on how and why to use it yet. Bob also is the only Domain Admin available on the weekend at 1AM when a Priority 1 ticket comes in for an account to be removed from the Domain Admins. We can see from a gpresult /h output on Bob's regular workstation, all the Pass the Hash mitigation GPOs are in place : Bob knows he also can't RDP to the Domain Controller since Windows Firewall rules are in place preventing access over TCP 3389 from anything other than the Privileged Admin Workstations. Bob's got A Very Important Security Task to do however, and therefore he tries a trick that always worked at his old job, which is Run as a Different User - Bob holds down the shift key on his keyboard and right clicks on cmd.exe, intending to run it as his Domain Admin account to launch Active Directory Users and Computers. But alas for Bob - this is denied by the Deny Log on Locally GPO setting - a Run as a Different user is a full interactive logon after all, and should rightly be prevented for Domain Admins on lower trust systems such as workstations. We can also see what that looks like in the Event Log, and it might be something you want to monitor as it might indicate either untrained admin or malicious activity. Bob however is very clever and not one to be deterred - after all he's got a Priority 1 ticket to remove an account from the Domain Admins, which is a Very Important Security Task! So Bob tries something he found in a search engine - which is to use the /netonly switch on Run As. This is a different type of Logon, Logon Type 9, and Bob thinks this might work on his laptop. Bob crafts the following command : runas /netonly /user:contoso\bob-da "mmc.exe c:\windows\system32\dsa.msc" and enters his Domain Admin Password (already exposing himself to any Keylogging malware on the system.) Not only does Bob get his Active Directory Users and Computers MMC without having to use his Privileged Admin Workstation in spite of all of those lockdowns, his credentials are left behind in memory. Well, Bob gets his ticket closed - but this is very bad. Because Bob is an efficient admin who wants to do things quickly, he's likely to never open his Privileged Admin Workstation, which means that in spite of all of the great work Bob's company has gone to they are still only a few steps away from total domain compromise. This particular set of circumstances described in this did require Bob to be an admin on his workstation to run the commands with UAC Elevation - which is another great reason to fight the usually tough political fight of removing local administrator rights from IT staff - but the principle could work with other apps without elevation. Imagine if instead of Paint that was an Identity Management System front end GUI - that might make it a bit more realistic to imagine a use for Bob using his Domain Admin account to launch it. : ) So what can be done to stop this? The easy option would be to create an Applocker Rule to Prevent RunAs from being executed (since it's actually an executable.) I'd recommend applying it to a group of "People with Tier 0 Access" (as well as targeting to other privileged accounts like server admins) that way help desk and other support staff can still elevate/runas local admin accounts as needed. This has the desired effect of stopping the runas /netonly behavior : But it's still moot if you let Bob keep Local Administrator access - because if you stop the Application Identity Service, Applocker Rules no longer work. Bob might just be determined enough to do that, or an attacker who has Bob's access might be. The harder option is Authentication Silos. These should, in theory, prevent the logon from occurring on the lower level workstation and block the auth - however myself and a coworker haven't been able to make them block the logon reliably yet. While this story might appear to be about a particular admin behavior that could be solved by some "staffing decisions" it's really a bigger concept. Any security control you put in is simply a Turing Test. If there is a Human Adversary on the other end, chances are high they will find a bypass. Don't delegate the discovery of flaws in your systems to adversaries - create realistic threat models. Don't just assume admins are going to follow the rules, as the adversaries trying to get into your network certainly aren't. I hope this relatively simple real world example will help you to think outside the box and beyond manuals and guidance on other systems in your environment. -Jessica @jepayneMSFT

Local Administrator Password Solution (LAPS) Implementation Hints and Security Nerd Commentary (including mini threat model)

Jessica Payne (MSFT) — Mon, 28 Dec 2015 20:39:01 GMT

I did a guest post over on the Ask PFE Platforms blog about the Local Administrator Password Solution (LAPS) this week. You can check it out here :

http://blogs.technet.com/b/askpfeplat/archive/2015/12/28/local-administrator-password-solution-laps-implementation-hints-and-security-nerd-commentary-including-mini-threat-model.aspx

-Jessica @jepayneMSFT

Tracking Lateral Movement Part One - Special Groups and Specific Service Accounts

Jessica Payne (MSFT) — Thu, 26 Nov 2015 19:44:00 GMT

Lateral Movement - the moving of an attacker from one compromised host throughout your domain until they find what they are looking for - is something we see many just about all attackers doing during compromise. I've talked a lot about the attacker behavior and how to stop it - strong protective controls can serve as powerful detective controls. The problem for most of our customers is that they lack the visibility/documentation to comfortably put Lateral Movement preventions in place without breaking everything. Even before we put the protective controls in place we can put some of the detective controls in place - which will give us greater insight into what is currently happening in the environment so we can get the protective controls in faster. One very powerful detective control I mentioned in my Ignite Australia session on monitoring : Special Groups. Special Groups were introduced in Windows 2008/Vista as a way to track when particular accounts log onto a system. Which is pretty awesome from a security/Lateral Account Movement perspective. Especially since you get to define just what group is a special group! For Lateral Account Movement and credential hygiene, we want to know if administrative accounts or highly privileged (Tier 0 in MSFT speak) accounts logon to systems, especially systems in the workstation or member server tiers. When you enable Special Groups, you get a unique Event ID (4964) in the Security log that you can send to Windows Event Forwarding (which naturally you have in your environment now because of my blog post or the in depth Microsoft Virtual Academy session . :) ) Getting Event ID 4964 to show up does require some configuration, which is best done via Group Policy Preferences. First, we need to make sure the audit policies applied to our machines are in fact auditing for Special Logon. Configure your GPO so Computer Configuration\Windows Settings\Security Settings\Advanced Audit Configuration\Account Management\Audit Special Logon is set to log Success and Failure (we do want failure here, it's very useful once we get those protective controls in place.) Next we need to determine who is a Special Group in the organization. For the purposes of tracking Bad Guy Behaviors as well as preparing for Lateral Account Movement lockdowns I'd really like at least the following things considered "Special Groups."

Local Account : S-1-5-113 - this will help track the local accounts people may be using on your network so you can put the Lateral Movement blocks for Local Account in later without breaking things, as well as track Bad Guy Behavior.
Domain Admins : S-1-5-21domain-512 - we need to know if there are any workflows that are currently in place in an organization that would lead to credential exposure before putting protective controls in place, and also alerts on Bad Guy Behavior.
Enterprise Admins : S-1-5-21root domain-519 - same as Domain Admins, just Enterprise wide. Even if you only have one domain, monitor this.
Special Group: I recommend creating a group specifically for things you want to track with Special Logon later, and adding it to the registry policy now. You could nest the other groups into it as well, but you might want those specifically defined. You can use this group to add Service Accounts to for instance, then if one is used across workstations, you know you have a problem.

I'd also like to see Built In Administrators : S-1-5-32-544 - we want to know when someone is logging on with admin privileges in general from a forensic stand point often. But this may be just far too noisy in some environments for the first pass. Give it a try if you can. We're using Special Group not just to track Bad Guy Behavior, but potentially dangerous administrator behaviors that will be blocked by Lateral Movement mitigations. One of the workflows to worry about is Domain Admins using "Run as a Different User" on their normal workstations. Many people now have secondary admin accounts (which is great!) but use RunAs when they are doing admin activities - such as running Active Directory Users and Computers from the same computer they are logged on and surfing the web/checking email. This behavior may seem safe, but a RunAs is a full interactive logon that leaves credentials behind in memory. (This is why we stress the need for a hardware separation between regular and administrative credentials so much in the Pass the Hash Whitepapers.) We need to now assemble our SIDs. Even for Domain/Enterprise Admins you can get the SID of from attribute editor, under the objectSID attribute. You can also use the power of https://support.microsoft.com/en-us/kb/243330 to know the Domain Admins SID is always S-1-5-21domain-512 and fill in the "domain" part based on another group in your domain, or you could logon on to a Domain Controller as a Domain Admin and run whoami /groups. If you pipe it out to a text file as shown, you can get the SID from there (useful trick for other stuff too.) So now that we have our SIDs, either make a new GPO or edit one that applies where you need it (which, is pretty much everywhere. Except maybe Tier 0/Domain Controllers to reduce initial noise.) Navigate to Computer Configuration\Preferences\Windows Settings\Registry\ and create a New Registry Item. You'll want to fill it in like the screenshot below, with the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit\SpecialGroups set to a REG_SZ (string) value that contains your SIDs of interest separated by ; (semi colons.) Public Service Announcement : whenever you're making a Group Policy Preference like a registry key, make sure to check the box on the Common tab for "Remove this item when it is no longer applied." This will make sure when you unlink the GPO the setting is cleaned up, otherwise you can sometimes get weird tattoos on your registry of settings you unlinked ages ago. Once you're done, the GPO should look something like this. So now, when Bob the Domain Admin does the dangerous behavior of Shift+ Right Click +Run as Different User on his Bob the Regular User workstation we get a very descriptive alert telling us what Bob did and what group it was that triggered the alert. Now that we have an Event ID, we can make a Subscription for this in Windows Event Forwarding. I already covered the basics of WEF in another post, so if you haven't read that go back to get the basics. Our 4964 subscription can be quite simple : Now you have way more insight into what is happening on your network - both in preparation for Lateral Movement lockdowns and to keep track of Bad Guy Behaviors. Another barrier to getting Lateral Account Movement lockdowns in place or removing Service Accounts from high privileged groups like Domain Admins is often the accounts are in those groups for legacy reasons, and have been for years. When nobody knows why the account is there, or what might break it can make even the very real and very easy to exploit threat of a Service Account in the Domain Admins difficult to mitigate for some customers. This is another case where Windows Event Forwarding can come to the rescue! Creating a WEF subscription for "Where all did Service Account X log in" is very easy to do. I recommend making these subscriptions one or two accounts at a time, to make it easier to narrow down what it's doing, and I recommend making sure the subscription is targeted to both Domain Computers and Domain Controllers for visibility into any local/NTLM logons that might not hit the Domain Controllers. I've covered the basics of Windows Event Forwarding in both an Ignite Session on Channel 9 and a previous blog post so we'll skip to just the Xpath filter you'll need to track down a specific account : Replace Interesting Account name with the user names you're interested in. EventID 4624 will get you all of the logon types, service/batch/interactive so should go a long way to tracking down what is going on, but 4625 will track failed logons for you - which help not just with potential security issues but with troubleshooting after you reduce privileges/credential exposure. Event ID 4648 is for explicit credential logon, which is used by bad guys doing lateral movement and sysadmins doing things like runas/mapping drives, so it's definitely an Event ID you'll want. :) Getting these monitors enabled in your domain will not only go a long way to helping you lock down and monitor Lateral Account Movement, they'll also be a huge help if you ever need an Incident Response. Good luck and happy logging! -Jessica @jepayneMSFT

Monitoring what matters - Windows Event Forwarding for everyone (even if you already have a SIEM.)

Jessica Payne (MSFT) — Mon, 23 Nov 2015 19:56:00 GMT

Last week at Ignite Australia I presented a session (available here ) on something I don't think gets talked about enough - Windows Event Forwarding, or WEF. (Edit: I've also since done an depth Microsoft Virtual Academy session on Event Forwarding too!).

Often when we engage for an Incident Response, we find the customer :

Has no centralized logging
Are not monitoring endpoints/member servers (often just DCs)
Spam logs with extra data
Are not logging key events
Logs roll too quickly
Those with centralized logging still missing data, takes too long for IT admins to get reports

In Internet speak :

WEF's been part of the operating system for a while now, but not many people take advantage of it. Many people appear to not even be aware of it, as evidenced by this highly scientific poll.

WEF is not only free and built-in, it has some nice features when configured appropriately :

Works nicely as a compliment to SCOM or SIEM products.
Can dramatically increase your overall visibility in the environment. Frequently desktops aren't part of the centralized monitoring due to licensing costs - WEF can be setup (for free) to collect the key events from the desktops and then be forwarding on to the SIEM.
Configured via GPO (easy!)
Uses Windows Remote Management (Kerberos) to prevent man in the middle
Can (and should be) targeted to specific events
Native evtx (xml) log format
“Push” log mode – less attack surface than adding a monitoring agent or account to a widely privileged group
IT admins control their own logging destiny - AD guys looking to track down a certain service account don't have to wait on the security team.

Setting WEF up is really easy too. Prerequisites are essentially a server and a GPO. To collect security events, we'll also need to grant the local Network Service principal rights to read that log. This is just the Network Service on the machine itself, so it's not a wide privilege throughout the domain. The WinRM service will also need to be started on all the clients in the domain - just started though, not configured. This is key, as just starting the WinRM service doesn't leave it in a listening state, versus a quick config of the service would make it listening.

Recommendations for the collector server would be to use 2012R2, although you can even do this on Windows 7 if you have licensing restraints. The log files will be pretty small if you're just collecting targeted/critical events, so you likely won't need much above and beyond your typical VM drive size but you may want to bump up the memory in the box a bit to avoid race conditions.

On your collector server, fire up an administrative command prompt (you do have UAC enabled, right? 🙂 ) and type in winrm qc. You'll then be asked two important questions - do you want the WinRM service to start automatically and do you want to poke a hole in the firewall for WinRM. I'd recommend controlling the firewall with a GPO as well, but go ahead and answer yes to both of these.

When that created the WinRM listener, it also created a Service Principal Name for Kerberos authentication to the service. If something goes flakey with WEF, this is usually where it happens. If the SPNs aren't right, Kerberos authentication can't happen which makes Event Forwarding not work. You may also have noticed the listener is on HTTP ://* - WinRM is at its core HTTP, so while the SPN is WSMAN for WinRM, if you try to install WEF on a server that already has an HTTP SPN Windows Event Forwarding will fail as if it's a duplicate SPN. If you're curious, you can check your SPNs out via attribute editor.

Once WinRM is setup (and hopefully after you've set the firewall via GPO) you can enable Event Forwarding. Open up Event Viewer on the Collector and navigate to the area called "Subscriptions" that you've probably never clicked on before. 🙂 If you haven't clicked on it before, you'll get prompted with this question:

We do need/want the Windows Event Collector to start up automatically with the computer, so go ahead and click yes on that.

And that's it, you've configured a Windows Event Collector! The next trick is to get things report to it.

The best way to do that is via GPO. First things first, we'll need to give the local Network Service principal rights to read the security log. To make sure we don't break anything, run the following command on a server/workstation in your environment:

wevtutil gl security

That will spit out the information about the Security Event Log, as shown below. The weird "O:BAG:SYD:" line is where the permissions on the log are stored. Copy out that line from the O through the last parenthesis and stick it into Notepad. If yours doesn't have (A;;0x1;;;NS) on the end like mine does, append that in Notepad.

Copy the whole O:BAG:SYD line from Notepad, as we'll need it in the GPO. Create a new GPO in your domain to point the systems you want to monitor at the collector server - the same GPO can be used for both member systems and Domain Controllers in your environment, unless you want to point them at different collectors for delegation reasons.

You'll need to configure two settings :

Computer>Policies>Admin Templates>Windows Components>Event Forwarding>Configure target subscription manager

This will need to be populated with the address of your collector server in this format :

Server=http://fqdnofsubscriptionserver:5985/wsman/SubscriptionManager/WEC,Refresh=60

The refresh interval on the end indicates how often clients should check in to see if new subscriptions are there for them. 60 seconds might be a bit aggressive in production, but it helps out a lot when you're setting things up and testing.

Computer>Policies>Admin Templates>Windows Components>Event Log Service>Security> Configure log access

This is where you'll need to paste your O:BAG:SYD line from Notepad. Remember this is an authoritative setting, so if you had permissions set some other way on a system in your environment this would replace them.

When you're done, your GPO should look like this:

Now any system that has this GPO will know to check into the web service running on the Windows Event Collector to see if there are any subscriptions for it. Computers only send events when they get a subscription telling them to do so.

So what should you monitor?

You absolutely could configure WEF to collect all the security logs in your domain - and maybe if you don't have any other centralized logging in your domain you should do this for forensic reasons - but the real value of WEF is targeted alerts, filtering out what really matters. This is also where WEF is a great compliment to a SIEM you already have in your environment - let the SIEM do the heavy lifting of collecting every single event and use WEF for targeted visibility, and use WEF to get important security events from workstations/member servers in your environment you may not have covered by the SIEM. The SIEM can then collect them from the WEF server, still providing you with the "single pane of glass" view.

The five basic things I think everyone should start with for monitoring in their domain (if they aren't already) are :

Security Event Logs being cleared
High value groups like Domain Admins being Changed
Local administrator groups being changed
Local users being created or deleted on member systems
New Services being installed, particularly on Domain Controllers (as this is often an indicator of malware or lateral movement behavior.)

Configuring subscriptions can be done via the GUI (easy mode) or via XPath filters (lots more flexibility.) The settings for the subscriptions do matter though, as this is where you configure the logs to be in "push" mode versus "pull."

Let's configure the Security Event log cleared alert via the GUI:

Right click on Subscriptions, then select Create Subscription. We'll need to give the subscription a name and pick "Source Computer Initiated" as that's what makes it "push."

Select Computer Groups next, as this will define which computers send us the events we're interested in. Since we want to know whenever anyone anywhere clears a security log, we're going to use the two built-in/auto populating groups in AD, "Domain Controllers" and "Domain Computers."

Next we click Select Events to define what we're monitoring. This alert is pretty straight forward, we're looking for Event ID 1102 in the Security log, so we can do it all via the GUI. 🙂

If we click on the XML tab we can see what the XPath filter we just created looks like.

Click okay on that and then click Advanced on the main page. We want to set the subscription to Minimize Latency, to make sure we get events as soon as possible and also to help it catch up if we miss any.

You can troubleshoot that things have actually checked in by checking the Source Computers column on the main Subscriptions page :

You can also check the Event Forwarding Plugin Operational log under Applications and Services on the client to make sure everything is happy. This is where you'll see descriptive errors if something has gone awry with Kerberos or Firewalls.

Click okay and you've got a subscription. Find a low-value test VM, clear the Security log and see if you get an alert. 🙂

Configure those 5 events with cut and paste for two commands? Yes you can!

Thanks to Australian PFE Russell Tomkins, you can do just that. Below are two XML files that contain the appropriate subscriptions for Domain Computers and Domain Controllers. The subscriptions here are maybe a bit wider than you want in your production domain to start with, as it's collecting services installing on workstations too, but give it a go. We'll want that data if we ever have to do an IR for you.

To import the XML files, save them to a directory on the server and then run the following commands from the same directory on your Windows Event Collector.

wecutil cs DomainComputers.xml

wecutil cs DomainControllers.xml

DomainComputers.xml

Domain Computer Events SourceInitiated Important Domain Controller Events True http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog MinLatency ]]> true http RenderedText ForwardedEvents O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;DD)

DomainControllers.xml

Domain Controller Events SourceInitiated Important Domain Controller Events True http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog MinLatency ]]> True http RenderedText ForwardedEvents O:NSG:NSD:(A;;GA;;;DD)

If you have more than one domain, you'll need to specify the SIDs of Domain Computers/Domain Controllers in the line as well as the DC (Domain Computers) and DD (Domain Controlls) SDDLs that are in there.

Hope this helps. Be sure to check out my post on tracking Special Groups with WEF and look forward to more things you can do with WEF in future blog posts! Happy Logging!

-Jessica @jepayneMSFT

What should I know about security? The massive list of links post.

Jessica Payne (MSFT) — Fri, 20 Nov 2015 14:22:00 GMT

I maintain a list of links I call "security stuff every Microsoft customer should know" that I send to every customer I visit. The list ranges from basic things to more in depth security knowledge, and is now available even if I haven't visited you. :) You might want to bookmark this page, as it will get updated periodically.

My links on security I send to every customer : Best Practices for Securing Active Directory https://technet.microsoft.com/en-us/library/dn487446.aspx This whitepaper also contains a large quantity of monitoring guidance including which optional logs to turn on. I highly recommend at least skimming through this whole whitepaper. Pass the Hash Whitepapers http://microsoft.com/pth (this URL also hosts ongoing content and discussions on the topic of Pass the Hash – there are two whitepapers here, I recommend reading both. ) Channel9 Presentation of SLAM and Lateral Movement : https://aka.ms/toppopslam POP-EMET Presentation : https://channel9.msdn.com/Blogs/Taste-of-Premier/Taste-of-Premier-Protect-Your-Enterprise-with-the-Enhanced-Mitigation-Experience-Toolkit LAPS Video : https://channel9.msdn.com/Blogs/Taste-of-Premier/Taste-of-Premier-How-to-tackle-Local-Admin-Password-Problems-in-the-Enterprise-with-LAPS Download LAPS : https://aka.ms/laps The Hierarchy of Cyber Needs - Basics like credential hygiene, patching, and least privilege often solve more problems than advanced solutions. https://blogs.technet.microsoft.com/captain/2016/01/05/cyberneeds/ JIT-JEA (just in time just enough admin – this is the future) : https://channel9.msdn.com/events/Ignite/2015/BRK2470 AGPM : https://channel9.msdn.com/events/TechEd/NorthAmerica/2011/WCL308 Advanced Threat Analytics : https://channel9.msdn.com/events/Ignite/2015/BRK3870 Ransomware Talks: Less technical/more managerial concerns version https://channel9.msdn.com/Blogs/Taste-of-Premier/DigitalSpringCleaning (this one also discusses Cyber extortion and destructive attacks) More technical version https://channel9.msdn.com/Blogs/Taste-of-Premier/Ransomware101 MMPC Blogs on Ransomware, including Samas which is a targeted attack: https://blogs.technet.microsoft.com/mmpc/2016/03/17/no-mas-samas-whats-in-this-ransomwares-modus-operandi/ https://blogs.technet.microsoft.com/mmpc/2016/02/24/locky-malware-lucky-to-avoid-it/ Windows Event Forwarding and monitoring what matters (centralized logging for free!) https://aka.ms/wef http://blogs.technet.com/b/jepayne/archive/2015/11/24/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem.aspx http://blogs.technet.com/b/jepayne/archive/2015/11/27/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts.aspx http://blogs.technet.com/b/kfalde/archive/2015/11/18/laps-audit-reporting-via-wef-posh-and-powerbi.aspx Blackbelt security from TechEd 2014 https://channel9.msdn.com/events/TechEd/Europe/2014/WIN-B318 LUA Buglight - are your users running as admin because an application supposedly needs it? Don't let one app ruin your whole security posture, Aaron's got an app for that: https://blogs.msdn.microsoft.com/aaron_margosis/2015/06/30/lua-buglight-2-3-with-support-for-windows-8-1-and-windows-10/ KB2871997 Overview of the backported security features from 8.1/2012 to 7/2008R2. These features are critical for stopping lateral movement, especially the "Local Account" principal. (Highly recommend following the SRD blog in general, as it is one of the best sources from Microsoft) : http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx How Cybersecurity investigations actually work - how real attacks happen, a little on what the Incident Response process looks like and a lot on what you could be doing to stop attackers https://channel9.msdn.com/Events/Ignite/Australia-2015/WIN433 *the attack I show in this was based on this : http://carnal0wnage.attackresearch.com/2013/10/dumping-domains-worth-of-passwords-with.html I'm not linking this to show you how to hack - that's not why I am here, but to show you people who do want to attack you can find clever ways quite easily. You should learn how these work so you can defend against them. Information on the JASBug/GPO patch - this bug would allow you to trick a Windows workstation into getting group policy from the internet. It was patched however there are steps that need to be configured post-patch to defend against it : https://www.jasadvisors.com/additonal-jasbug-security-exploit-info/ https://www.jasadvisors.com/about-jas/jasbug-security-vulnerability-fact-sheet/ Blackhat talk on Golden Ticket and other attacks (which can be prevented by the controls we discussed) https://www.youtube.com/watch?v=-IMrNGPZTl0 (PtH mitigations make all of this moot.) SRD posts on some of the critical security issues in the last couple years : https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-ms15-014-hardening-group-policy/ http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx Places in AD attackers can use for persistence: https://adsecurity.org/?p=1929 Kerberoasting, a technique for stealing credentials even if the account has not logged onto the box: https://adsecurity.org/?p=2293 Discussions on Powershell persistence and logging - this is a very popular technique now and most 2008R2/Win7 customers don't have sufficient logging or preventions : https://blog.gdatasoftware.com/blog/article/poweliks-the-persistent-malware-without-a-file.html https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html https://adsecurity.org/?p=2604 http://www.exploit-monday.com/2015/11/investigating-subversive-powershell.html - Powershell profiles can be a sneaky and difficult to detect way to maintain persistence on a network. Make sure you know all the locations if you're researching them. (Which Matt has kindly written about here. :) )

Powershell best practices with some awesome people, Lee Holmes and James Forshaw : https://channel9.msdn.com/events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2013-Sessions/PowerShell-Best-Practices https://channel9.msdn.com/events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2013-Sessions/PowerShell-Code-Integrity UEFI and SecureBoot attacks: https://channel9.msdn.com/events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2014-Sesions/BlueHat-Security-Briefing-Fall-2014-Summary-of-Attacks-against-BIOS-and-Secure-Boot-Yuriy-Bulygin

adsecurity.org - Sean's whole blog is amazing and you should read the whole thing if you are security Windows. :) Derivative Local Admin Discovery - if you don't have host firewalls on in your network, any authenticated user can discover the memberships of Local Admin Groups in your environment. This is a real world attacker behavior, and here's a write up and a tool by a pen tester on it : https://wald0.com/?p=14 Pretty good writeup of some webshell behavior to maintain persistence on a network: http://blog.crowdstrike.com/mo-shells-mo-problems-web-server-log-analysis/ Microsoft Security Intelligence Report, published quarterly: https://microsoft.com/sir Threatpost discussions of various attacks that can be used: http://threatpost.com/tracking-malware-that-uses-dns-for-exfiltration/111147 http://threatpost.com/patched-windows-kernel-mode-driver-flaw-exploitable-with-one-bit-change/111020 http://threatpost.com/chinese-hackers-compromised-forbes-com-using-ie-flash-zero-days/110996 This one is really important, because this targeted malware being deployed simply by visiting a website. This is why defense in depth/desktop hardening/credential hygiene/EMET are so key. “Admin Free” Active Directory blog posts (anything Laura writes is gold) : http://blogs.technet.com/b/lrobins/archive/2011/06/23/quot-admin-free-quot-active-directory-and-windows-part-1-understanding-privileged-groups-in-ad.aspx http://blogs.technet.com/b/lrobins/archive/2011/06/23/quot-admin-free-quot-active-directory-part-2-protected-accounts-and-groups-in-active-directory.aspx Purging Legacy Authentication Protocols : http://blogs.technet.com/b/askds/archive/2012/02/02/purging-old-nt-security-protocols.aspx Building custom X-Path filters : http://blogs.technet.com/b/kfalde/archive/2014/03/25/xpath-event-log-filtering.aspx Spotting the Adversary with Windows Event Forwarding from our dear friends at the NSA, which is a good write-up of basic monitoring (including gathering crash dumps, as they can indicate compromise in many instances) : http://www.nsa.gov/ia/_files/app/Spotting_the_Adversary_with_Windows_Event_Log_Monitoring.pdf OCTAVE framework for threat modeling : http://www.cert.org/resilience/products-services/octave/ http://www.sei.cmu.edu/reports/99tr017.pdf (this is the older version but still applicable!) TechEd presentation on memory analysis which contains details on Pass the Hash and Golden Ticket : https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B350#fbid= TechEd presentation on EMET to prevent zero days and other exploits (EMET is free!): https://channel9.msdn.com/events/TechEd/Europe/2014/CDP-B348 Way more indepth overview of EMET : https://channel9.msdn.com/events/TechEd/NewZealand/2014/PCIT417 Redirecting the default place computers joined to your domain go (remember Computers is a “Container” and can’t get policy such as randomized passwords and firewall.) : http://support.microsoft.com/kb/324949 Reducing the number of computers someone can join to the domain so any person with credentials can’t add random Macs to the domain : http://support.microsoft.com/kb/243327 Using Powershell to get local group membership like Admins : http://blogs.technet.com/b/heyscriptingguy/archive/2012/12/15/weekend-scripter-use-powershell-to-find-local-administrators-on-a-computer.aspx Blocking out of date ActiveX on the internet. If you have out of date Java or Flash for a mission critical application and can't do EMET ASR, please please please deploy this GPO. Otherwise every time you hit a website with a malicious exploit kit embedded in it, you are pretty much guaranteed to get malware like Ransomware. http://technet.microsoft.com/en-us/library/dn761713.aspx

Have a suspicious IP in your logs? Don't ping it or nslookup! This can tip off the attacker. Try searching for it in these tools instead: https://isc.sans.edu/tools/whereis.html virustotal.com/ Well Known Security Identifiers in Windows - one day you will be reading an event log in an emergency and you will need this :) https://support.microsoft.com/en-us/kb/243330

Hope these help! -Jessica @jepayneMSFT