Today Cyber Security plays a paramount role in global security. On this blog, the CEO of Paramount Defenses shares rare insights on issues related to Cyber Security, including Privileged Access, Organizational Cyber Security, Foundational Security, Windows Security, Active Directory Security, Insider Threats and other topics.

December 22, 2014

Sony Hack: Too Easy and Predicted by "The Paramount Brief" 5 Years Ago                    (Who's Next & Is The Whole World Sitting on a Ticking Bomb?)


By now, you must have heard about the Sony Hack. Thought I'd share a few thoughts (possibly worth a US $ Trillion) on it.

The Sony Hack has to be possibly the worst cyber security attack the world has witnessed thus far. I say thus far, because if you understand Active Directory Security, you know, that with just a little bit of effort, one can easily automate the destruction of virtually any (number of) organization(s) in the world. (To the FireEyes, TripWires, Mandiants, Kasperkys and Symantecs of the world - if you need a primer/demo, let us know.)


A few weeks ago malicious perpetrators completed compromised Sony's IT infrastructure and stole vast amounts of Sony's confidential information. They then threatened Sony to engage in a specific action, and when Sony refused, they made good on their threat by releasing part of this information in the public domain. The release of such confidential information into the public domain caused Sony significant tangible and intangible damage, the true cost of which won't be known for years.

Remarkably Easy

Based on what is known thus far, and based on what U.S officials have shared, in all likelihood, what happened here is that malicious perpetrators gained administrative access within Sony's network, and used it to obtain access to (and make a copy of) whatever they wished to obtain access to within Sony's internal network i.e. files, databases, emails, etc.

As described below, such an attack is remarkably easy to carry out. In fact, with just a little effort, today it can be carried out in the IT infrastructures of 85% of all organizations worldwide. (Should you need a demo, we'll be happy to arrange one for you.)

A word on Motive

The Sony Hack was so remarkably simple to carry out that when you think about it, you'd wonder why the hackers that carried out the attacks at Target, Home Depot, EBay, etc. did not inflict as much damage as the hackers who carried out the Sony Hack. I believe that the answer lies in one word - Motive.

In all likelihood, the motive of the hackers of the previous attacks was simply to obtain (steal) information for financial gain. In Sony's case, the motive seems to have been to proverbially take Sony hostage and force it to act in a specific manner (i.e. have them pull a movie.) It seems that certain demands may have initially been put forth and when Sony's executives didn't comply, the perpetrators started releasing the stolen information to demonstrate that threats were real. It is the release of this information in the public domain that caused substantial damage to Sony. In other words, the perpetrators succeeded in holding a $20+B company hostage and during the process inflicted colossal damage to the company.

As damaging as it was, this was a remarkably simple hack.

So, what makes this a remarkably simple and easily enactable hack to carry out?

Well, the answer is simple. It was very easy to carry out, as described below.

Before that, just one thing...

Predicted by The Paramount Brief

Five years ago, we penned "The Paramount Brief" -

The Sony Hack is the perfect example of what is described in "The Paramount Brief."

In the best interest of organizations worldwide (so as not to tip the bad guys off), we have not declassified it yet. There are some (at the highest offices in Microsoft and elsewhere) who have read it and who will tell you that we predicted the occurrence of such an attack over 5 years ago.

In light of what happened, we are inclined to declassify this brief in early 2015. Stay tuned.

What Really Seems to have Happened at Sony

What happened at Sony was remarkably simple. Like over 85% of the world's organizations, the IT infrastructure of Sony too is powered by Microsoft Windows Server platform, and at the very foundation of their cyber security was their Active Directory deployment.

You can think of Active Directory as the heart of an organization's IT infrastructure. Not only does Active Directory store and protect all of the organization's administrative accounts and their passwords, it stores and protects the user accounts of all the employees and contractors, as well as the computer accounts of all the computers that make up the IT infrastructure as well as all the security groups that are used to protect the entirety of all the IT resources in the IT infrastructure. And more.

In order to help organizations establish and manage their IT infrastructure, there exist a few default administrative groups in Active Directory. These administrative groups have unrestricted access to Active Directory and to virtually every machine (laptop, desktop, server) that is joined to the Active Directory and is thus a part of the organization's IT infrastructure. Examples of such administrative groups include the Enterprise Admins group, the Domain Admins group etc.

Every individual that is a member of one of these default administrative groups has virtually unrestricted access across the entire IT infrastructure. He/she can obtain and control access to virtually every IT resource in the organization's IT infrastructure, whether it be a file, a folder, a Share point, a server, a database, a line-of-business app etc. ... everything.

In other words, anyone with administrative access in Active Directory proverbially has God-like powers, and practically speaking, he/she any day is about 100,000 times more powerful than the organization's CEO.

Should a SINGLE account that has administrative access in Active Directory be compromised, theoretically every IT resource in the organization could be at risk of compromise, and in the worst case scenario, the entirety of the organization's IT resources could be compromised.

In other words, proverbially speaking, he/she who is able to obtain Active Directory administrative access will have the "keys to the kingdom" i.e. once you have Active Directory administrative access, you can obtain access to, copy, tamper, divulge and destroy virtually any IT resource in the IT infrastructure.

THAT is EXACTLY what seemed to have happened at Sony.

Quoting U.S. officials that were briefed on the investigation - "U.S. investigators have evidence that hackers stole the computer credentials of a system administrator to get access to Sony's computer system, allowing them broad access."

In a Microsoft Windows Server based IT infrastructure, a system administrator is layman's speak for an Active Directory administrator, because in a Microsoft Windows Server based IT infrastructure, Active Directory is the heart of the "system".

The same U.S. officials also said that "The hackers ability to gain access to the passwords of a top-level information technology employee allowed them to have "keys to the entire building,"."

In all likelihood, someone compromised the account of an Active Directory administrator and once that was done, the rest was just a matter of time... taking one's sweet time to obtain read access to and copy vast parts of organization's IT resources.

It was really as simple as that.

Not Surprising at All

In light of the fact that someone with Active Directory administrative access has God-like powers, you might find yourself asking two questions -

  1. Shouldn't organizations minimize the number of such highly privileged administrative accounts?
  2. Shouldn't organizations offer the highest protection for these highly privileged administrative accounts? 

The obvious answer to both the questions is YES.

Sadly, in reality, based on what we have seen thus far, in most organizations, not only are there an unacceptably and unbelievably large number of these highly privilege administrative accounts, but these accounts also continue to remain substantially vulnerable to compromise. In fact, in most organizations, the IT groups have no idea as to exactly who has what administrative access provisioned in their Active Directory deployments.

By the way, by what we have seen thus far, I'm referring to over 7,000 organizations from across 150 countries that have knocked at our doors thus far, and many of these organizations are some of the world's most prominent and powerful business and government organizations.

So, it is not surprising at all to us that someone was able to pull off this attack at Sony.

It helps to keep in mind that once a malicious perpetrator has Active Directory administrative access, and their primary intent is to obtain access to and copy information (files, folders, databases, mail etc.), all they're really doing is engaging in "read access" to vast amounts of information, and "read" access is almost never audited, so it would be very difficult to catch someone who has Active Directory administrative access in the act of engaging in rampant information theft.

How to Enact the Sony Hack in 4 Steps

At its core, a perpetrator seems to have obtained administrative access and used it to obtain access to (and copy) large amounts of confidential information, all done in 4 simple steps -

Step 1 - Become an Authenticated User - This step involves obtaining the credentials of any ONE of the thousands of Active Directory accounts that exist for Sony's employees, vendors and contractors. With just a little creativity (social engineering), this is fairly easy to do from the outside. It is easier still if you can officially get an account by virtue of say being a temporary contractor to Sony, not just in the U.S. but say in another country that Sony does business in/has operations in.

Step 2 - Identify Administrative Accounts - Once you're an Authenticated User, you now have READ access to vast amounts of information, including valuable information, such as the list of all administrative accounts in the organization i.e. the list of the accounts of all individuals who have administrative access in the organization's Active Directory. For instance, the list of all Enterprise Admins and Domain Admins. By the way, this is as easy as issuing the following LDAP query: (&(objectClass=user)(objectCategory=person)(admincount=1))

Step 3 - Escalate Privilege to Administrator Level - This is the defining step in which you escalate your privilege from that of a regular non-administrative account holder to that of an administrative account i.e. one of the many administrative accounts you identified in Step 2.  This is the most difficult step in the entire attack-vector. However, what is "difficult" for some, is "easy"for others, and depending on your expertise and tool-set, this can take days or minutes. (With the right tooling it only takes a few minutes.) Most amateurs use the PtH attack vector to enact this step. Unfortunately for them, as organizations establish and enforce stricter admin account use policies, this attack vector is becoming harder to use. The second vector, called Active Directory Privilege Escalation, which these amateurs don't know much about yet, still remains the easiest way to enact this step.)

Step 4 - Own The Building/Kingdom - Once you've obtained Enterprise/Domain Admin credentials, you're proverbially God within the network, because you can now obtain access to, copy, tamper, destroy and divulge virtually any IT resource that is stored on a computer that is joined to the Active Directory domain and/or protected by an Active Directory security group, (and that by the way is virtually the entire IT infrastructure.) Once you've obtained Enterprise/Domain Admin credentials, you can take your sweet time (weeks, even months) accessing and copying large amounts of information from virtually any server (file server, mail server etc.), database, laptop etc. and because all of it is read access, it is hardly every audited, so you're going to go unnoticed for a very long time.

(Strictly speaking, each time you obtain a Kerberos ticket to a separate machine, an event is logged in the audit log, but based on our experience in dealing with the 1000s of organizations that have knocked at our doors seeking assistance, less than 1% of organizations even know how many administrative personnel they really have, let alone paying attention to audit entries related to Domain Admin network logons on to various machines. Besides, for the most part, its not your identity that shows up in the audit log, but that of the account of the Enterprise/Domain Admin you compromised, and he/she could very well have a legitimate need for all these logins, making these audit log entries seem unsuspicious.)

Once you've taken your sweet time (days, weeks or months, your choice) to obtain access to virtually whatever you wanted (documents, emails, confidential data), you simply walk out, and once you're out, you're now in possession of a treasure trove of data. What you do with it, is driven by your motive.

In Sony's case, the attackers used it to coerce Sony into not releasing a movie. (It appears that in order to prove to Sony that their threats were credible, they released vast amounts of stolen information into the public domain, causing substantial tangible and intangible harm to Sony for years to come.)

It's (really) that simple.

Step 3 Above - Privilege Escalation

As you'll hopefully agree, steps 1, 2 and 4 above are pretty darn easy to enact, for anyone who knows the littlest thing about cyber security. It is step 3 that empowers a non-administrative individual to escalate his/her privilege to that of an all-powerful administrative account, that is the defining step here.

In fact, in most of the famous cyber security breaches thus far, privilege escalation has been the defining step that gave the perpetrators powerful administrative access, which could then be misused to fulfill virtually any malicious objective.

When it comes to privilege escalation in Windows / Active Directory, there are fundamentally two ways to escalate privilege - privilege escalation based on the capture and replay of hashes, and privilege escalation based on performing (a few) password resets (i.e. based on identification and exploitation of excessive permissions granted on Active Directory content such as admin accounts and groups.)

The first way i.e. privilege escalation based on the capture and replay of hashes (PtH) is well-known and commonly-used, and thankfully is steadily becoming harder to use, as organizations understand how to avoid being victimized i.e. essentially, prevent their admins from logging on to untrustworthy machines.

The second way i.e. Active Directory privilege escalation based on performing (a few) password resets, is steadily increasing as hackers become savvier about Active Directory security, and are able to identify and exploit privilege escalation paths with moderate effort. (With the right tools , this too is child's play.)

The cardinal difference between these two ways is that whereas the former absolutely requires that an administrator logs on to a machine owned by the attacker, the latter has no such requirement, and in fact can be enacted from any machine. NOW, if an administrator NEVER logs on to the computer owned by the attacker, the attacker can sit and wait and grow old and will not be successful. However, with the latter, the attacker can use any computer/account to identify and exploit these privilege escalation paths, and once identified escalate his/her privilege within minutes.

Amongst these two ways, privilege escalation based on password resets poses a far greater threat to organizations worldwide than privilege escalation based on the capture and replay of hashes, because it doesn't require the victim to logon to any specific machine, and because virtually any insider (i.e. anyone with a simple Active Directory account) could with some basic knowledge and tooling engage in it to obtain all-powerful administrative access within minutes.

Microsoft's recent acquisition of a little start-up called Aorato may be a step in the right direction towards helping organizations detect the occurrence of privilege escalation based on the capture and replay of hashes, but it still leaves organizations vulnerable to privilege escalation attacks based on (i.e. involving the identification and exploitation of excessive permissions in Active Directory that can be enacted by performing) password resets. Fortunately, our patented technology is helping organizations worldwide minimize the possibility of successful privilege escalation attacks involving password resets.

Why is Administrative Access Such a Big Deal?

Obtaining administrative access is a HUGE deal because once you have administrative access, you not only have virtually unrestricted access to just about every resource in the system, you are also a part of what is commonly referred to as the Trusted Computing Base (TCB) of the system, and once you're a part of the TCB, you can not only control the security of the entire system, you can also circumvent any additional control that might have been put in place to stop you.

In addition, in every system, default security specifications grant the administrators complete and unrestricted access. This is done so as to be able to provide the administrators the ability to control that system at all times.

For instance, in an Active Directory deployment, the default security on every domain-joined machine grants Domain Admins full control across all resource managers on that machine, as well as virtually all the privileges required to obtain access to and control the entire domain-joined machine.

So for instance, once you're a Domain Admin in an Active Directory deployment, you can obtain access to virtually every IT resource (file, folder, database, process, service etc.) on any domain-joined machine in that Active Directory forest. So, of course, by default you'd also have access to any and every server that is domain-joined, such as and not limited to Exchange Servers, File servers, Database servers, Application servers, LOB servers, PKI Servers etc., and of course all files and folders on any domain-joined client machine, e.g. the laptop or desktop of virtually every employee in the organization, including the CEO, CFO, CIO, CISO etc. In other words, you have access to virtually everything.

This is why administrative access is a HUGE deal, and this is why organizations must leave no stone unturned in minimizing the number of administrative personnel to a bare minimum. Fortunately, all mature commercial operating systems (e.g. Microsoft Windows Server) provide the means to delegate a majority of all administrative responsibilities to lesser privileged administrators, and organizations should leverage the ability to delegate administrative functions to the extent they can.

At the end of the day, once you're an administrator, you have sufficient power to be able to control the security of the entire system. When you're consider a system like the IT infrastructure of a $20B company, you could potentially (positively or negatively) impact more than $20B, if one includes the cost of intangible losses one could inflict.

Unaudited Delegated Administrative Access Grants - Low-hanging Fruit for Hackers

One often overlooked area of cyber security is that of delegated administrative access in Active Directory deployments. By delegated administrative access, I am referring to administrative access delegations that are provisioned in Active Directory deployments for the purpose of separating and/or distributing responsibilities for vital areas of IT management. Examples of such areas include account management, group management and access management.

Active Directory makes it very easy to delegate access, and thus most organizations leverage this capability to ease IT management. In most organizations, IT departments have delegated varying levels of access to numerous IT personnel, whether directly, or via group memberships. Delegation of administration is a very useful and powerful capability that if correctly used, could substantially help organizations minimize the number of highly privileged administrators in Active Directory, and thus help them reduce the risk associated with the compromise of a highly privileged Active Directory administrative account.

There is one challenge associated with delegation though which is that although it is easy to delegate access precisely, it is very difficult to assess delegated access precisely, and over time, the state of effective delegated access can change, resulting in a situation wherein many more individuals than should ideally have been delegated specific types of access end up having such access.

This results in a situation wherein many individuals end up being entitled to and having powerful, delegated unauthorized access, which can then be easily misused to compromise organizational security.

For example, a group called Privileged Account Managers could have been delegated the ability to manage administrative accounts, and thus be able to carry out sensitive tasks like being able to reset the password of all Domain Admins. Over time, someone could directly or indirectly, and intentionally or inadvertently modify the membership of this group resulting in a situation wherein more individuals than were initially assigned to this group are now able to carry out these management tasks on these privileged accounts as well.

For instance, someone could accidentally or intentionally make another group called HQ Local Admins a member of this Privileged Account Managers group, resulting in a situation wherein all members of the former group would now also have the same rights as the latter group, and thus also be able to manage the organization's privileged accounts. These changes, and their impact can sometimes be hard to detect, assess and visualize, resulting in a situation wherein many more individuals than expected end up having escalated levels of privilege which could be accidentally or intentionally misused to inflict damage. In this case, the damage could be the compromise of one of the organization's privilege Domain Admin accounts, and the impact of such a compromise could be, well... we all know what happened at Sony.

This is why delegated administrative access rights are also very important to keep an eye on, because left as is, they could potentially be the weakest link in an organization's cyber security defenses. Fortunately, today solving the delegation audit challenge too has become as easy as touching a button, so organizations can safely use delegation to minimize the number of highly privileged administrative accounts in their Active Directory.

Could This Have Been Prevented?

Cyber security is fundamentally about risk management in computer systems, and any cyber security expert worth his salt will tell that you can never mitigate a 100% of the risk; you can mitigate much of it but not all of it, and you have to manage the part you can't mitigate.

In other words, no one can say with absolute certainty that such a security incident could have been completely prevented.

What I will say, is that with adequate security measures in place, i.e. a combination of adequate security policies, procedures and controls, the likelihood of Sony witnessing a security incident of this magnitude could have been highly minimized.

Organizations around the world can learn from what happened at Sony, and enact adequate risk mitigation measures in a timely manner to minimize the likelihood of hackers being able to pull of an attack of such a devastating magnitude in their IT environments.

5 Risk Mitigation Measures Sony Could have Taken to Reduce their Exposure

Here are 5 risk mitigation measures that the Sony could have taken, and that other organizations can take today, to prevent the occurrence of a security incident of this magnitude -

1. Reduce the number of Active Directory administrative personnel to a bare minimum, by separating, distributing and delegating all non-administrative responsibilities amongst and to a large number of relatively less-privileged administrators. For more information on how to do so, please refer to Microsoft's official best-practice guide on Delegation of Administration.

2. Ensure that all administrative delegations in Active Directory adhere to the principal of least privilege. This is very important because unless this is done, perpetrators could compromise a delegated administrator's account and use it to elevate their privilege to that of a Domain Admin. For more information on how to do so, please click here.

3. Afford the highest protection to all Active Directory administrative personnel and groups. This involves protecting these accounts from all avenues of credential compromise (some of them are listed below) as well as assigning dedicated computers for each of these administrative personnel.

4. Ensure that only equally trustworthy individuals can manage these Active Directory administrative personnel and groups. For example, ensure that only equally trustworthy individuals and no delegated administrators have the ability to reset the passwords of these accounts, change critical settings on these accounts (e.g. the userAccountControl attribute), unlock these accounts should they become locked, as well as change/modify the group memberships of any administrative groups (e.g. the Domain Admins group), create and link a GPO to the OU in which the computer account of these admins is stored, as well as manage the OUs in which these user & computer accounts/groups are stored.

5. Use auditing to audit the enactment of management tasks on Active Directory administrative personnel accounts, their computer accounts and Active Directory administrative groups, as well as audit changes in security permissions on any of these objects and on the OUs in which they reside.

Also, any time an Active Directory administrative account holder find that his/her password is not working, before simply getting it reset, investigate and find out whether or not someone reset his/her password, because if someone did so, chances are that they were in the midst of engaging in Active Directory Privilege Escalation.

In addition to the above, organizations can and should certainly invest in deploying additional security controls to add additional layers of security for their IT resources. However, it must be noted and understood that no matter how many layers you deploy, you CANNOT prevent the administrator of a system from being able to circumvent/disable any such deployed control, because he/she is by definition an administrator of the system, and is thus a part of the system's Trusted Computing Base (TCB).

Further Simplified - 5 Simple Risk Reduction Steps

In case the above risk mitigation measures seem too much to enact immediately, here are 5 simple steps that organizations can take today to reduce their exposure and mitigate this risk  -
  1. Identify every single administrative account and group in your Active Directory (AD)
  2. Identify every single individual that can manage every AD admin account and group
  3. Reduce the number of individuals on these 2 lists to a bare minimum.
  4. Ensure that only the most trustworthy individuals are on these 2 lists
  5. Designate a unique specific computer for logon/use for each of these individuals
Having done so, establish a schedule (weekly, fortnightly or monthly) to audit both, the list of admin accounts and groups, as well as the list of all individuals who can manage them.

Examples of such groups include Enterprise Admins, Domain Admins etc., and examples of management tasks include who can reset their passwords, unlock these accounts, modify these groups memberships, modify permissions on these accounts and group memberships etc.

For more details and specific risk-mitigation guidance, click here.

Tip 1: Design and use a simple in-house script that shows each administrator the last time (and target computer) at (and for) which a Kerberos ticket was issued for him/her, helping him/her identify whether or not his/her account has been compromised and may currently be in simultaneous use.

Tip 2: Understand how the smart guys target Active Directory, not just how amateurs do so.

Note: As stated above, organizations should additionally implement other controls as well, but the above mentioned steps are essential because no matter what additional controls are in place, by definition, a system's administrators are part of the system's Trusted Computing Base (TCB) and can thus almost always circumvent and/or disable any additional controls that are in place.

Common Account Compromise Avenues

Here are some common ways in which someone could attempt to compromise an administrative account -
  1. Guess the user's password
  2. Brute-force the user's password
  3. Obtain access to hashes and compare hashes to infer his password
  4. Deploy key-stroke logging software on the user's computer to capture his password
  5. Social engineer the user to enter his password on a fake website, and capture that entry
  6. Social engineer the user to logon to a compromised computer and capture his hash
  7. Reset the user's password
  8. Coerce the user to giving you his password
Interestingly, of all the ways listed, the easiest way to compromise an administrator's account is to reset his password.

Here's why -

Most organizations have account lockout policies in place, making password guessing and brute-forcing difficult. Obtaining access to hashes requires physical(+system) access to a DC, which is not very easy to obtain. Deploying a keystroke logger requires you to obtain system access to the admin's computer (since you need the privilege to install a driver, and that may or may not be easy. Social engineering a user to enter his password on a fake site and/or logon to a compromised computer will require some social engineering skill. Coercing the user will most likely involve physical intimidation and thus thus require physical access to the user.

In contrast, a password reset can be performed from half way around the world in about 30 seconds, just as long as you have sufficient effective permissions to reset the user's password. With a little bit of creativity and the right tools, such permissions can usually be obtained rather quickly. (It turns out that it is very difficult to accurately assess who can reset whose passwords, so organizations are seldom able to accurately assess and thus precisely control who can reset whose passwords, as a result of which many more individuals than should be able to, can actually reset someone's password.)

Penetration Testing - Overrated

Folks, whether you turn on your Television sets or look at the media coverage of the Sony Hack online, you'll find many self-proclaimed cyber-security experts opine on the subject. You'll also find some cyber-security companies, particularly those in the penetration testing space, trying to claim that penetration-testing could have helped Sony prevent this. That's lame.

You see, a penetration test is merely a tactical security measure designed to assess an organization's security defenses at a given point in time. While the findings of a penetration test can certainly help identify specific areas for improvement, by itself it is not the "fix" itself, and it only gives you a moment in time assessment. (Besides, a cyber-security company / professional's penetration testing capabilities depend on their skill-set and tool-set, and even the world's leading penetration testing companies are novices at best when it comes to assessing the myriad of advanced ways in which a malicious insider could gain administrative access in Active Directory.)

In essence, penetration testing could at best help you identify your security worthiness at a given point in time, and given how rapidly the state of access changes in an environment, the value of a pen test is rather limited in contrast your ability to actually "fix" the problem i.e. in this case, minimize the number of highly privileged administrative personnel in your Active Directory deployment.

Colossal Impact

What happened at Sony was tantamount to a complete and system-wide compromise of an organization's IT infrastructure.

Trying to put a price on the cost of this security incident is very difficult. Suffice it to say that in the long run, it could potentially exceed the net worth of the organization, if you take into account, not just the lawsuits that they're now going to face, but more so the intangible loss i.e. the loss of trust, damage to reputation, etc. etc.

In addition, if their IP was stolen as well, it could really impact their ability to stay competitive, and because the products they develop and sell operate largely in commoditized spaces, the loss of IP could have profound implications on their business in the long run.

If this is not enough to be a wake-up call for the rest of the world, I don't know what else can drive home the point any better.

Reiterated This A Year Ago

This isn't rocket-science; it's common-sense. But perhaps, as they say, common sense is not so common. At Paramount Defenses, we saw this coming years ago, and in addition to documenting this in The Paramount Brief, I reiterated this in this blog entry last year. (The text in red italics below are quotes from that old blog post.)

"It is SO powerful that one who knows how to exploit it can use it to instantly take over virtually any Microsoft Windows Server based IT infrastructure in the world." In this case, the IT infrastructure was that of Sony's, and the perpetrators did take it over.

"With sufficient effort, it can also be used to develop an exploit that can then be packaged into a malicious payload that can automate the disruption / destruction of any Active Directory deployment of choice within hours to days." As you may know, at Sony, the hackers deployed malware to disrupt virtually all of Sony's computers.

"Once determined, this information can be easily used to perform single/multi step privilege escalations and ultimately gain varying levels of, and usually complete, administrative access...Once an attacker has gained Domain Admin access in your environment, he could do whatever he/she wants." U.S. officials that were briefed on the investigation told CNN that "U.S. investigators have evidence that hackers stole the computer credentials of a system administrator to get access to Sony's computer system, allowing them broad access"

"...once you have compromised his account, you're a minute away from owning the kingdom...The attack surface is vast, and the prize is the coveted "keys to the kingdom"." The same U.S. officials also said that "The hackers ability to gain access to the passwords of a top-level information technology employee allowed them to have "keys to the entire building,"."

I could share many more quotes from that blog entry, but out of respect for your time (and mine), I'll share just these two pertinent ones...

"So you see, virtually every IT resource in the Active Directory is a potential target. I'll say this again - technically ANYONE with a Domain User account could take HOURS/DAYS/WEEKS to determine effective access in your environment, and find privilege escalation paths, and when he has, at a time of his choice, he could make his move i.e. WITHIN MINUTES, exploit the identified privilege escalation paths to take over the entire IT infrastructure."

and, finally...

"...imagine what a foreign government can do with 1000s of personnel devoted to building something like this, especially if you consider what is at stake, and what can be had."

Well, my 10 minute timer just rang, so this will have to end right here. But, just one more thing...

Who's Next? (Every Organization is Vulnerable - The Whole World Sitting on a Ticking Bomb?)

As I mentioned above, what (most likely) happened at Sony was rather simple - hackers compromised a single administrative account, then used that access to obtain virtually unrestricted access to and steal a colossal amount of corporate data, and finally used the stolen data to wreak havoc for the organization. To rub it in, they went a mile further to develop and deploy malware that destroyed a majority's of Sony's computers.

Sadly, ONE Active Directory administrative account is all one needs to carry this out. Just ONE.

Speaking of which, since over 85% of the world operates on Active Directory, and in 99% of these IT infrastructures, not only do these organizations have absolutely no idea as to exactly how many administrative accounts and groups they have in Active Directory, they also seem to have no idea as to exactly who is delegated what access on their Active Directory administrative accounts and groups, the following song featured in the movie November Man comes to mind...

(You can click on play above, or if you prefer, view it on YouTube here.)

From the world's most powerful governments to the world's top business organizations, over 85% of the world is vulnerable today, and as hackers become sophisticated, unless organizations start to take this SERIOUSLY, anyone could be next.

Incidentally, a year ago, I ended that blog post with the following words... "Unaddressed though, it is a ticking time-bomb..."

 Who will be Next?

Best wishes,

PS: The world also got a new phrase to throw around - Cyber Vandalism.

PS2: December 11, 2015 Update - Paramount Defenses to declassify The Paramount Brief

November 13, 2014

In acquiring Israeli startup Aorato for US $ 200 M did Microsoft dodge a bullet for chump change?


It’s a very interesting world.

Microsoft, a $400B company is a name that needs no introduction. Unless you live on another planet, you know that virtually everything in the world runs on Microsoft Windows (client and server.)

On the server side, over 85% of the world’s organizations operate on Microsoft’s Windows Server platform, at the foundation of which lies a single technology – Active Directory.

Active Directory is one of the world’s most ubiquitous, entrenched and mission-critical technologies in the world – it is the bedrock of security across the whole wide world.

In fact, at work, from the moment you logon in the morning to the moment you logoff in the evening, everything you do is powered and enabled by Active Directory.  This is so because to simplify distributed security, 15 years ago Microsoft integrated its entire distributed authentication and authorization infrastructure with Active Directory.

For the most part, Active Directory is a highly robust, secure and reliable technology, designed by the some of the world’s best security engineers and architects. It had better be so, because the entire world's running on it.

(The only deficiency in Active Directory itself is the inability to help IT personnel accurately identify who is effectively delegated/provisioned what level of privileged/administrative access in Active Directory.)

For 15 years, barring and despite this deficiency, the world has been running just fine on Active Directory, and continues to do so today (, at least for now, although the Russians and the Chinese have gotten a wind of this glaring deficiency.)

This is a testament to just how secure, sound, robust and trustworthy Active Directory is as a technology.


15 years into Active Directory’s existence, a fledgling company, Aorato, shows up and proclaims to the world in its MISSION STATEMENT that –

         “At the core of its founding is the acknowledgement that Active Directory is exposed – by default and by design.

(Generally, only those who know a lot or very little about Active Directory can make such statements.)
If you want to know how much (or perhaps how little) Aorato knows about Active Directory (or knew just a few years ago), you may want to see this video. Quoting... "and then I realized that everyone has access to Active Directory"  (If you know the first thing about Active Directory, you know that a leaf doesn't move in Microsoft's ecosystem without the Active Directory being involved. You don't have to realize it while conducting a pen test.)

Turns out Aorato is in the business of developing and selling a (beta version) of a directory application firewall (DAF) that can theoretically detect suspicious activities such as PtH attacks. It has a handful of customers, few may have heard of.

What Aorato has going for it is that the second most powerful privilege escalation attack vector called Pass-the-Hash, has now been used multiple times in famous breaches, for e.g. the Target Breach.

( In case you’re wondering what the world’s most powerful privilege escalation attack vector is, its calledActive Directory Privilege Escalation” and it is based on the deficiency alluded to above. )

To its credit, perhaps in an effort to demonstrate the value of its firewall, Aorato continues to look for other attack vectors i.e. above and beyond the PtH, and finds a way to demonstrate an attack vector that was until now only theoretical. (I wouldn't expect Aorato to know much about the #1 vector mentioned above.)

Having done so, it decides to makes a little noise by proclaiming to have uncovered a CRITICAL Microsoft Active Directory Vulnerability. Apparently, Aorato also privately shows the proof-of-concept to Microsoft.

Turns out the vulnerability has nothing to do with Active Directory per-se and everything to do Microsoft’s integration of Kerberos with Active Directory. Nonetheless, journalists who don’t seem to know better, run with it.

On the other hand, hackers continue to use the second most powerful privilege escalation attack vector (Pass-the-Hash) to do damage, and in the latest case apparently, they seem to have used it at Home Depot too.

Home Depot scrambles to buy a few Macbooks for its execs, supposedly to protect them from the PtH attack vector, and a journalist runs a story titled “Home Depot reportedly drops Microsoft for Apple after data hack.”

Most people don’t read the entire story, but if you read it, all that was reported was “an IT employee bought two dozen new, secure iPhones and MacBooks for senior executives”. That’s a tactical shift-the-blame move and/or a tactical security incident response 101 move.

Nonetheless, such headlines can have the effect of making Microsoft look bad, worry its customers and create a need for Microsoft to provide some reassuring response to its global Windows Server customer base.

With Aorato, in all likelihood, Microsoft’s real worry would in all likelihood have been to prevent Aorato from releasing its proof-of-concept tool into the public domain because doing so would have worsened the situation.

The most efficient way for Microsoft to have eliminated that worry would have been to buy Aorato out, so it offered US $ 200M to Aorato, and a deal seems to have been made. $200M is the average expected cost to an organization of a major Active Directory targeted security incident, assuming it survives the incident. With over 85% of the world running on Active Directory, $200M is chump change for what Microsoft acquired i.e having prevented Aorato from releasing its proof-of-concept tool in the public domain.

If indeed Domain Admin accounts were compromised in the Target/Home Depot security incidents, then I have to say that the hackers were either really dumb, or very focused on merely getting a bunch of credit card numbers, because if they wanted, they could have shut these organizations down, within minutes. That's what I mean by "if you survive the incident".

Anyway, I digress.

What Microsoft seems to have got as a bonus now, is the ability to claim that it is indeed doing something to help its customers defend themselves from Windows-focused PtH like escalation attacks.

Not bad. For chump change, not only did Microsoft get the opportunity to show that it is doing something to help, but more importantly it dodged a bullet (prevented Aorato from putting the proof-of-concept tool in the public domain.)

All said and done, Congratulations Aorato!

As for the #1 risk to Active Directory deployments worldwide, Active Directory Privilege Escalation (the risk that would let a perpetrator completely 0wn any Active Directory deployment within minutes WITHOUT requiring anyone else to logon to any machine, let alone one 0wned by the perpetrator), we have it covered.


PS: Interestingly, Aorato has discretely and completely removed the zany claim “At the core of its founding is the acknowledgement that Active Directory is exposed – by default and by design.” from its mission statement on its website. The updated mission statement can be viewed here. If you wish to see the original, checkout Google’s cached version here.

PS2: If you liked this, you may also like my 2c on the OPM Data Breach

July 29, 2014

Claim by Israeli Cyber Security Startup Aorato "Critical Design Flaw in Microsoft Active Directory Could Allow Password Change" is Incorrect


95% of the Fortune 1000 run on Active Directory, so unless you're living on another planet, you'll want to read this.

95% of the Fortune 1000 Run on Active Directory
As former Microsoft Program Manager for Active Directory Security, and today as CEO of Paramount Defenses, the world's #1 cyber security company focused on Active Directory Security, allow me to share a few thoughts with you on what might very well be a bold yet incorrect claim.

Last week, we received a call from a journalist who wished to request our thoughts on a reported vulnerability related to Active Directory that has been widely reported as Critical design flaw in Microsoft's Active Directory could allow password change and exposed by a company called Aorato. Having never heard of this company before, we asked the journalist to email the details. The journalist then emailed us a link to Aorato's blog, which can be found here.

[Given my role at PD, I don't ordinarily have time to address such issues, but since we had a lot of organizations requesting our take on such a bold claim, I felt it necessary to shed some light on it, and am doing so via this blog entry.]

Aorato's claim that "Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim’s password without being logged" is incorrect.

With utmost respect to Aorato, I'd like to unequivocally state that, based on our assessment of their claim -

From a technical perspective, THIS IS NOT AN ACTIVE DIRECTORY VULNERABILITY at all.

Let me repeat that - technically speaking, this is NOT a vulnerability in Active Directory AT ALL. It is at best, a potentially exploitable weakness in Microsoft Corporation's implementation of Kerberos that has been known for years. Technically speaking, the only relation this has to Active Directory is that Kerberos uses Active Directory as its account database.

In my humble opinion, it may thus have been irresponsible to make such a bold yet technically incorrect claim, because doing so can result in a situation wherein thousands of organizations worldwide could panic, and incorrectly assume that their foundational Active Directory deployments are vulnerable, when in fact this is not the case.

I'm happy to demystify their claim and explain why this is not an Active Directory vulnerability (and I've done so below) but before I can do so, allow me to share a few thoughts with you.

A Little Knowledge is a Dangerous Thing

By claiming that their find is a vulnerability in Active Directory, Aorato may have demonstrated how much/little it may actually know about Active Directory Security, and as goes the old saying - a little knowledge is a dangerous thing.

I also have to admit that in my 15 year professional career, I've come across many Cyber Security companies, but I've never come across a company whose mission statement reads -

"At the core of Aorato’s founding was the acknowledgement that Active Directory is exposed – by default and by design. The consequence of which, is that the entire organization is at risk."

Now that's a first. A cyber security company at the core of which is the acknowledgement that one of the world's most robust and highly securable technologies, Microsoft's Active Directory is exposed - by default and by design.

In reality, of course, nothing could be farther from the truth. If you truly understand Active Directory security, you know that it is one of the most securable technologies in the world. It is neither exposed by default, nor in design. So such a claim only makes you wonder how much (or how little) this company might actually know about Active Directory security.

(If anything, an Active Directory deployment can be exposed to the risk of Active Directory Privilege Escalation, but that is neither by default nor by design. It is only because after years of delegating access in Active Directory, organizations do not have the means to reliably assess who is delegated what administrative access in Active Directory, and this exposure too can be reliably eliminated.)

Anyway, while browsing their website, it was a little unsettling to come across assertions/statements such as -
  • "Your Active Directory is exposed. Protect Active Directory and your organization from advanced attacks"
  • "Is your Active Directory under attack? We’re here."
  • "Windows Update to Fix Pass-the-Hash Vulnerability? Not!"

The most insightful one was on their Labs Page - "Your Knowledge Center for all Active Directory Security-Related Research"

I felt it was insightful because it only covered 4 technical topics - Pass-the-Hash, Pass-the-Ticket, Kerberos and NTLM. Microsoft has an entire 100 page+ white paper on Active Directory Security because it is an ocean of a subject, and these 4 topics at best comprise about 1% of the contents of the white paper, so to call it "Your Knowledge Center for all Active Directory Security-Related Research" seemed to provide valuable insight into how much/little they may actually know about Active Directory Security. (A better description could have been "Our Knowledge Center for Kerberos and NTLM Weaknesses Related Research.")

Perhaps they could benefit from an Active Directory Security 101 primer.

Active Directory Security 101 - A Demo of How Someone Could Actually Easily Compromise Virtually Any Active Directory Deployment in the World within Minutes

Folks, at Paramount Defenses, we actually do know a thing or two about Active Directory Security, yet out of respect for organizations worldwide, we have never demonstrated the impact of our knowledge to the world.

However, today, solely to help folks learn about the real risks to Active Directory security, and to help journalists who spin out sensational headlines without an inherent understanding of the technicals, allow us to share with you a little snippet of our knowledge - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes.

You see, if you truly understand Active Directory Security, you know that virtually any Active Directory deployment in the world can be compromised within minutes, without so much so as having to compromise a single machine, let alone having to carry out sophisticated PtH type attacks -

Active Directory Privilege Escalation
Anyone still working with techniques like Pass-the-Hash etc. is trying way too hard, for there are far easier ways to obtain administrative access in Active Directory,  so they may want to learn a thing or two about Active Directory Security.

Again, here's the link - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes

With that out of the way, here's our 2c on the vulnerability Aorato seems to have demonstrated.

The Vulnerability - A Potential Design Flaw in Microsoft's implementation of Kerberos, Not in Active Directory

If you truly understand Windows and Active Directory security, you'll most likely agree that the headline should have read - "Potential Design Flaw in Microsoft's Kerberos Implementation Could Allow Password Change" as this has everything to do with choices that Microsoft made when implementing Kerberos in Windows 2000 and nothing to do with a vulnerability in Active Directory.

Here's why...

Technically speaking, Active Directory is essentially an enterprise-grade, fault-tolerant and highly available (multi-mastered) directory service, which in addition to serving as a central directory service, can be (and is) leveraged by various components of Windows management, such as Kerberos, Group Policy, Exchange, PKI etc.

A vulnerability in Active Directory would have to do with one of the numerous components of the directory service itself, such as, but not limited to the database itsef, the Schema, its replication protocols, the LDAP protocol etc.

For instance, if someone had found a way to modify DC-to-DC replication traffic such that the data in transit could be tampered with, resulting in the inbound replication of modified tampered data at the receiving domain controller, that would constitute an Active Directory vulnerability.

The vulnerability described by Aorato has nothing to do with either of these components of Active Directory.

It only has to do with the the choice of encryption algorithms used by Microsoft's implementation of Kerberos to encrypt a Kerberos security principal's credential i.e. his/her password, the hashed version of which just happens to be stored in an attribute in Active Directory, because Microsoft's implementation of Kerberos uses Active Directory as its account database.

(For instance, consider a 3rd party application that leverages Active Directory and extends the Schema to introduce a new custom attribute that is used to store some application-specific data in Active Directory, and lets say that the manner in which that application uses the data (stored in that custom attribute) results in a potential security vulnerability. In such a situation, it would absolutely not be an Active Directory vulnerability. It would simply be a vulnerability specific to that application. In this case, that application just happens to be Microsoft's implementation of Kerberos. As far as Active Directory is concerned, there's just a blob stored in an attribute on a class of objects in it.)

Thus, it should be reasonably apparent to those of ordinary skill in the art, that this is NOT an Active Directory vulnerability. Consequently, the following claim, as made by them is factually incorrect - "As part of our ongoing research on advanced attacks, we expose a critical Active Directory flaw which enables an attacker to change the victim’s password."

For the last time, I'll say this again - this vulnerability is NOT an Active Directory flaw at all, LET ALONE alone it being a critical Active Directory flaw. With this fact out of the way, I'm happy to focus on the issue at hand.

A Potential Design Flaw in Microsoft's Implementation of Kerberos?

The issue at hand here is rather simple.

As many of you may know, there are two authentication protocols in Windows environments - Kerberos v5.0 and NTLM.

Kerberos is the default authentication protocol in Windows 2000 and beyond, and relative to NTLM, it offers various benefits such as more efficient authentication, mutual authentication, delegated authentication, simplified trust management, and of course interoperability.

I'm not about go into the details of how Kerberos and NTLM work, as you can find the details online, such as here. I'll assume that you have a decent understanding of these protocols work, so we can get to the heart of this issue.

What is commonly referred to as a "domain account" is technically a Kerberos Security Principal, and what is commonly referred to as a "domain" is technically a Kerberos realm. At the heart of Kerberos is the Key Distribution Center Service, the KDC, which happens to run on Domain Controllers (DCs) since it leverages the Active Directory as its account database.

Now, every domain account, whether it be a user account or a computer account, has a password associated with it, which is (ideally) known only to the account holder itself, and of course the KDC has access to a hashed version of the password. It is this (hashed version of the) password that is a shared secret between a Kerberos security principal and the KDC, and the KDC happens to share a unique secret with every Kerberos security principal, whether it be a user account or a computer account, and as a result, it is this set of shared secrets that enables Kerberos to facilitate secure access between two Kerberos security principals, and that is the fundamental basis upon which Kerberos works.

Now, when a user authenticates using Kerberos, he/she demonstrates knowledge of the password to the KDC during the Kerberos Authentication Service Request (KRB_AS_REQ) by encrypting pre-authentication data with the user's key, which is derived from the user's password. Since the KDC has a copy of the same user's key, it can decrypt the pre-authentication data, and authenticate the user.

As you may know, there is a fair amount of encryption involved in the inner workings of Kerberos. For instance, the authenticator requires encryption, as do tickets and session keys. In order to facilitate encryption/decryption, Kerberos allows a KDC client and the KDC to negotiate the encryption types to be used i.e. the actual encryption algorithms and checksum types to be used by a client and server to encrypt authenticators, session keys and Kerberos tickets.

For instance a client requesting a TGT from the KDC can during the KRB_AS_REQ inform the KDC about the encryption types and key lengths it can work with, and the KDC will generally pick the strictest encryption type that both the client and the KDC support, assuming it can work with the one of the requested types. (There can also be situations where in the KDC will be unable to use a specific encryption type, and in such cases, will issue an error to the client.)

Microsoft's implementation of Kerberos supports the following encryption types, (; their key lengths in parentheses)  -
  1. AES-256-CTS-HMAC-SHA1-96 (256 bit) 
  2. AES-128-CTS-HMAC-SHA1-96 (128 bit)
  3. RC4-HMAC (128 bit)
  4. RC4-HMAC-EXP (EXP stands for exportable, and is 56-bit)
  5. DES-CBC-MD5 (56-bit)
  6. DES-CBC-CRC (56-bit)
(There are also about a dozen checksum types that it supports such as CRC32, SHA1 (Unkeyed) etc.)

Anyway, the core point to note is that over the years Microsoft's implementation of Kerberos has supported multiple encryption types ranging from the weak DES-CBC-CRC to the strong AES-256. It is also worth noting that not all the encryption types have been there all along, and not all encryption types will be supported all along. For instance, AES-256 wasn't supported until recently and DES which was introduced in Windows 2000 is now off by default in Windows 7 and beyond.

The one common encryption type that has been consistently available is RC4-HMAC. It has been available since Windows 2000 and it is still supported in Windows Server 2012, although starting Windows Server 2008 R2, it can NOW be disabled on all domain controllers. (However, this requires a minimum of a Windows Server 2008 domain functional level and an environment where all Kerberos clients, application servers, and trust relationships to and from the domain must support AES. Support for AES was introduced in Windows Server 2008 and Windows Vista.)

The issue at hand has to do with the key used for RC4-HMAC. Since it was introduced way back in Windows 2000, and (apparently) because Microsoft wanted to make the upgrade from Windows NT to Windows 2000 seamless, (it appears that) a decision was made that the key to be used for RC4-HMAC would the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.

Now it turns out that the NT Password Hash is the same as the NTLM Hash, and thus what Aorato appears to be claiming is that if an attacker can gain access to a user's NTLM Hash by using appropriate tooling that can extract/copy hashes from memory, theoretically, since the attacker has the user's NTLM hash, he/she could potentially use it in an attempt to obtain a Kerberos ticket if the KDC can be made to support the RC4-HMAC as the encryption type to be used during the exchange.

Interestingly, here is where Aorato's description/claim starts to get murky, because they tangent out to claim that since "KAdmin" i.e. the module that handles password changes, essentially operates in a similar manner, theoretically, the NTLM hash could be used to request a password change operation via "KAdmin" and once the password can be changed to one of a value set by the attacker, the attacker could then additionally also obtain access to resources that require an interactive logon (i.e. the use of a clear-text password), examples of which include Remote Desktop RDP) & Outlook Web Access (OWA).

That's where their claim ends.

PtH attacks have been in use for some time now, and their exploit methodology is generally well understood by most folks. One key aspect of such PtH attacks is that password hashes can only be used for network logons, so for instance, you cannot use a password hash to obtain access to a resource that requires that you enter a clear-text password.

In light of this limitation, hypothetically it would be additionally advantageous if one could leverage a copied hash to somehow learn of the existence of a user's clear-text password. The next best thing to learning of the user's current clear-text password is to be able to change it to one of your choice, and what they're saying is that it appears that one can use the NTLM hash to carry out a password change request, thereby additionally gaining the benefit of being able to now also access resources that do require the entry of a clear-text password, examples of which include interactive logons as well as to access other services and features such as Remote Desktop.

Now, the fact that the key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) has been public knowledge for years now, and thus it is only logical that theoretically, anyone with access to the NTLM hash could potentially use it to try and use it to obtain a Kerberos ticket, and along the same lines, use KAdmin to try and enact a password change.

(Its been public knowledge because RFC 4757 states very clearly that - "The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.")

If something is theoretically possible, it is generally only a matter of time, before someone can build sufficient tooling to enact the scenario out. Aorato seems to have invested some time to demonstrate this in a proof-of-concept scenario, and although they don't provide any verifiable proof to the general public other than a claim that they have demonstrated a proof-of-concept to Microsoft, it is certainly possible to build such tooling.

For example, up until a few years ago, tooling just did not exist to carry out Pass-the-Hash based attacks. Today of course, it is commonly available to virtually the entire world.

It appears they brought this to Microsoft's attention, and in response, Microsoft simply issued a simple statement, a snippet of which follows -

"This report is about a limitation in the Kerberos Network Authentication Service (V5) standard (RFC 4120), that is well-known within the industry, whereby an attacker can authenticate as a user, or change that user’s password, if they know that user’s secret key."

In other words, according to Microsoft there's nothing novel here.

However, Aorato wishes to contend that there is indeed something novel here, because an NTLM hash can be used to perform a password change operation on the victim's account, and thereby additionally gain access to other resource types that explicitly require clear-text credentials i.e. knowledge of the password.

I will certainly give them this much - the fact that this is theoretically possible has been known for years; the fact that they seem to have put in a lot of effort to try and demonstrate it in a proof-of-concept definitely validates the theory, and yes, if based on an NTLM hash, you can obtain a Kerberos ticket, and/or change a user's password via KAdmin, there is arguably something novel about it. But this is NOT an Active Directory flaw, so  in that regard i.e. this being a "Critical Design Flaw in Active Directory", they are incorrect.

4 Realistic Barriers to Success when Using this Attack Vector

This might appear to be high-impact, but in reality, its utility is rather low, for the following reasons -

1. The attacker can only compromise those accounts that happen to logon to the machine he/she owns. If 99% of users never logon to that machine, the attacker can sit there and wait and grow old, but he'll never get anywhere, because no one logged on to his/her machine

2.  Accounts that are not in active use either because they are disabled, or because they have expired cannot be used, because even if you change the password of these accounts, unless an admin enables or unexpires them, you cannot use that account even if you know the password.

3. Accounts that are active can only be targeted for a short duration of time, because the next time around that the victim proceeds to authenticate him/herself, the password known to him/her will not work, and a call to help desk will most likely result in a password reset.

4. With minimal effort, a notification system can be put in place, such that whenever a user's password is changed, he/she instantly receives a notification. A password change not made by the user him/herself will instantly alarm the user, and allow the organization to take reactive measures.

One cardinal difference between the Pass-the-Hash attacks and an attack in which the perpetrator changes the victim's password is that the use of a hash cannot generally be easily detected, whereas a password change on a victim's account can be instantly detected.

The fact that it can be instantly detected implies that a user can instantly detect a password change not carried out by him/her, and consequently, the perpetrator can be very quickly either apprehended or his efforts can be rendered useless.

The Insufficient Auditing Claim

Aorato claims that the resulting audit entries do not have sufficient information to inform IT personnel that something "fishy" might be going on i.e. it fails to show the pertinent attack information.

It appears that the reason auditing entries fail to show pertinent attack information, is because until recently, this was simply theoretical, so it was most likely not on the list of possible scenarios, and thus log/audit support may very well not be there for such a scenario. Of course I don't speak for Microsoft anymore, but you get the drift.

In this regard, unfortunately, there is some not-so-good news for Aorato. Before I share it, I wanted to take a minute to share another thought with you. So hold this thought for a minute.

If you read the blog carefully, there is a snippet that reads -

"One of the inherent shortcomings of logs is that they are a summary of the information. During the process of summarizing some information is bound to get “lost in translation”. Therefore, building a security system and strategy to rely on logs rather than on the actual traffic means that they are built on some shaky foundations."

Now, lets stop for a minute and consider what it is Aorato actually does. If you browse their website, you'll find that they're in the business of developing and offering a "Directory Services Application Firewall" which can monitor all Active Directory related network traffic and try and help organizations detect suspicious activities such as the one involving this attack.

It thus only appears logical that it would be in their research interest to uncover additional attack vectors, the use of which, during attacks, would constitute suspicious activities that their firewall could detect, thereby potentially increasing the need for a product designed to detect such attacks.

The not-so-good news for them is that there are far easier ways for insiders to easily and completely compromise an organization's Active Directory, than having to carry out such sophisticated, expertise-reliant attacks. About a 100 times easier. And the swiftness with which they can be enacted can render virtually all security measures, including their detection by any such firewall, completely useless.

(Any organization that wishes to see a real demo in their environment can contact us. We'll be happy to demonstrate the enactment of this attack vector. In fact, its so easy that literally anyone with a domain user account can enact it today. )

But I digress.

The other not-so-good news for Aorato is that although Kerberos related auditing may not detect something fishy, with just a little bit of coding, Microsoft, or any 3rd party tool can have an alert (via email, text, voicemail etc.) issued to users that their password has changed. This is rather easy to do, and is one of the easiest ways of helping organizations combat the occurrence of such an attack.

The benefit of having end-users know that their password has changed, as opposed to having IT admins know, is that an end-user will be able to instantly identify a suspect password change, and take appropriate action, such as informing IT personnel, who could then investigate the incident.

Finally, perhaps Aorato might wish to know that anytime a user's password is changed, the PwdLastSet attribute is updated, so a malicious password change can be instantly detected.

One Important Point - 0wning a System

Folks, much has been made of hash exploitation related attacks, but one has to understand that in order to carry out such an attack, the attacker has to gain ADMINISTRATIVE control over a machine, and for someone who already has administrative control over a machine, with just a little imagination and social engineering, there are far easier ways to capture a user's clear-text password than to have to go through all this trouble.

There is nothing super heroic about being able to extract hashes from the memory of a computer when you are the Admin of that computer, because in effect, as the admin, you control the Trusted Computing Base (TCB) of that computer.

Secondly, it should again be apparent to those of ordinary skill in the art that once you control a domain-joined machine, and you spawn a process in System context on the machine, it automatically goes across the network as the domain computer account, so you already are an Authenticated User across the entire forest. I'm not about to shed light on interesting things you can do with this, but those who're smart will get the drift.

Of course if this computer account happens to be trusted for (unconstrained) delegation, well, ...

Is this Much Ado About Nothing?

As I mentioned previously, it has been a well-known fact for 8+ years now that the RC4-HMAC uses the Windows NT key (NT Password Hash), and any proficient IT security professional will agree that if its the same as the NTLM Hash, theoretically, with sufficient skill/tooling, it can be used to encrypt the pre-authentication data in a KRB_AS_REQ request and the negotiated use of RC4-HMAC as eType.

What Aorato seems to have done is demonstrated this theory in a proof-of-context, and that's worth something because it demonstrates that tooling to exploit this design flaw can be built.

Their finding may very well have led Microsoft to issue this recommendation -

In reality though, for Microsoft's customers, implementing this recommendation is not that easy. Interestingly, this recommendation from Microsoft could certainly catalyze Windows Server upgrades from Windows Server 2003 to Windows Server 2008 and beyond.

However, as I indicated above, in reality, because a password change can be instantly detected, in reality, the use of this attack-vector will almost always result in the perpetrator being caught red-handed.

Although they may have demonstrated how someone could exploit the design flaw in Microsoft's implementation of Kerberos, they unfortunately seem to have incorrectly characterized/sensationalized it as a "critical design flaw in Microsoft Active Directory."

From a quick review of their website and blogs, it appears that such a characterization may most likely have been based on their lack of in depth knowledge of Active Directory and Windows Security.

It also appears that as they work towards increasing their level of Windows and Active Directory security knowledge, they may uncover more weaknesses, some of which may be well-known and a few of which may be novel.

Here's why...

Consider a scenario wherein a beginner is introduced to a new subject. As he learns more and more about the subject, his level of expertise advances from beginner to intermediate and eventually to expert. Somewhere alone the post beginner stage, he learns something new, that to him appears to be cutting-edge, but of course to others, is something logical and well-known. Anyway, all excited about this new discovery, he builds a little proof-of-concept, and claims a huge breakthrough.

For instance, if you read Aorato's blog, a few weeks ago, they seem to have made a big deal about "a Windows authentication flaw that allows deleted/disabled accounts to access corporate data." Technically speaking, all that this refers to is that the lifetime of a TGT is 10 hours, so once you have a TGT, you're good for 10 hours, irrespective of whether the account is disabled or expires. If you read their blog, its a big deal!

If you ask others, such as most folks who've been working with Windows authentication technologies for over 14 years, since Windows 2000 came out, this is just basic knowledge. After all, its just the way Microsoft's implementation of Kerberos works.

But 14 years after Windows 2000 came out, as Aorato begins to learn more about the workings of authentication technologies in Windows, they seem to have had this profound revelation that this 10-hour TGT lifetime related issue is a Windows authentication FLAW.

Their relative newness to the subject is indicated by the following comment made in regards to that blog entry -

"We are all for responsible disclosure. However, as the quoted Microsoft's official documentation shows, they were quite aware to the consequences of their implementation choice. So there's nothing to disclose to Microsoft they did not already know. The needed responsible disclosure is for the rest of us, that were under the false impression that when we disable/delete a user account the disabled user access rights are revoked immediately."

Anyone who knows how Kerberos works in Windows knows that a TGT once issued is (by default) good for 10 hours, and by implication, that it can be used to request a service ticket during that time. The only way one can be under the "false impression that when we disable/delete a user account the disabled user access rights are revoked immediately" is if one is not (yet) decently familiar with how Kerberos works in Windows, which can happen if you're new to the subject, and find this to be a startling discovery.

My genuine well-intentioned suggestion to Aorato would be to take the time to actually understand Windows Security in-depth. In the spirit of sharing, not just for Aorato, but for anyone who wishes to be a Windows Security / Active Directory Security Expert, here's a list of some topics brain-dumped in no particular order, you might wish to read up on -

Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL seessions, Names Pipes, COM, SSL, TLS, SChannel, SAM Server, Federation, DCs, DS Repl, Trusts, SID Filtering, LDAP, DPAPI, SAML, Effective Permissions, PKI, Name Mappings, GCs, DNTs, DC Locator, ADAM, ADFS, Azure, SID History, TDOs, TLNExclusions, ANR, Cross Refs, msDsQuotas, DFS, FRS, LVR, Credman, PAC, Windows Integrated Auth, DBDump, userAccountControl, Constructed Attributes, PDC Chaining, SAML, ADAM, RODCs, Certificate Services,  Token Bloat, Password Resets, Active Directory Privilege Escalation, and about 50 other topcis that come to mind.

For starters, to help figure out just how easy it is for a user to determine whether his/her password has changed WITHOUT even having to look at an audit log, here's one thing to look at - the pwdLastSet attribute on user accounts..

The point is that Windows / Active Directory Security is an ocean of a subject, and the more you learn, the more you realize how much more there is to learn.

Wrapping it Up

Folks, the key point I wanted to make here was that purely technically speaking, this so claimed "critical design flaw" has nothing to do with "Active Directory" per se, and everything to do with someone finally being able to demonstrate that it is possible to take advantage of a potentially exploitable weakness resulting from a decision Microsoft made 15 years ago, in regards to deciding which key to use with the RC4-HMAC encryption type.

In the spirit of fairness, as I have indicated above, the ability to demonstrate how someone could exploit this design flaw, is worth something. However, in this case, the realistic opportunity to use the resulting attack vector is low because it requires a) the attacker to gain control of a machine, b) the victim to logon to that machine and c) a password change which can be instantly detected.

In comparison, when there are far easier ways to compromise virtually any domain user account without so much so as having to gain administrative control over a machine, let alone having to pass hashes, organizations have much bigger problems to solve.

Speaking of bigger problems, in reality, in a majority of the 95% of the Fortune 1000, virtually NO one has ANY idea as to EXACTLY who has what administrative powers in their Active Directory.

(When you have no idea as to exactly who has what administrative in your Active Directory, worrying about advanced attack vectors such as this one, is akin to a kingdom wherein the Defense Ministry has no idea as to exactly who has the keys to which palaces, chambers, residences and gates, but is worrying about what to do about the possibility of an outsider having entered one little hut in the kingdom possibly trying to enter another hut, when in reality, the entire populace of the kingdom, can with the right tools, instantly find out exactly who has the keys to which door across the entire kingdom, including of course to the King's chambers.)

One Final Question -

Here's a question to any company that claims to have expertise in Active Directory Security -

Q. Can you help 95% of the Fortune 1000, answer (even any 1 of) the following 5 fundamental cyber security questions? -

(Each one of these questions have everything to do with Active Directory Security.)

1. Exactly how many people can reset the password of any one of their Domain Admins, Built-in Admins, Enterprise Admins etc. to instantly take over their Active Directory, and thus potentially completely control their entire IT infrastructure?

2. Exactly how many people can reset the CEO's, CFO's, CIO's or the CISO's password to instantly login as him/her and obtain access to everything he/she has access to?

3. Exactly how many people can modify the group membership of any or every security group that they use to control access to the entirety of our organization's IT resources, to in effect gain, grant or revoke any individual of one's choice the ability to access any resource of one's choice?

4. Exactly how many people can delete mission-critical IT resources such as user accounts, computer accounts, security groups, OUs etc, in effect causing substantial and almost always irreversible damage to the organization?

5. What is the easiest path to go from being just an ordinary user account holder (e.g. a contractor working half way around the world) to being a Domain Admin / Enterprise Admin within minutes?

If you can't, please don't be too hard on yourself, because even the Dells, Hewlett-Packards, Ciscos, McAfees, EMCs, Tripwires, CAs, BAHs, Symantecs, Lockheed Martins, FireEyes, Centrifys, CyberArks and Checkpoints of the world can't.

We can (answer all of them, at the touch of a button.)

Best wishes,