Election Influencing Podesta/DNC Email Hacks, Cyber Attacks and Russia

Folks,

There is no doubt that the recent email hacks of John Podesta and the DNC will have influenced the U.S. presidential election.

Given my background, I am often privately asked about my thoughts on the Podesta / DNC Email hacks purportedly carried out by Russia. Due to paucity of time, instead of having to respond to this so many times, I figured I'd publicly share a few thoughts.

But first I do wish to make it unequivocally clear that as (the CEO of) not just America's, but possibly the world's most relevant cyber security company today, we are professional, completely unbiased and objective, and this is only a professional opinion.

Disclaimer: My thoughts below are based on a cursory assessment of how Mr. Podesta's email was hacked. It is believed that at the time the DNC was hacked, they too may have been using Gmail, and thus may have been hacked in a similar fashion.



Simple Hacks, Huge Impact

Brass tacks, the Podesta/DNC email hack is simply a case wherein an entity that was engaging in high-value communications using a relatively low-assurance system (i.e. a free/low-cost email service) and insufficient security controls (i.e. not requiring two-factor authentication for password changes/resets) was compromised using simple social engineering involving very basic technical means by a 2nd entity, who in turn purportedly passed the compromised data to a 3rd entity that disclosed it publicly.

The 1st entity was John Podesta / the DNC, purportedly the 2nd entity was Russian hackers, and the 3rd entity was WikiLeaks.

When I say relatively, I mean that compared to (say) an in-house deployed, managed and controlled Active Directory integrated Microsoft Exchange Server based communications infrastructure that also requires 2-factor authentication (i.e. Smartcards), a free/low-cost email service is a relatively low-assurance system, especially when being used for high-value communications.

For those may not know, Mr. Podesta was using a Gmail account; he apparently received a phished email and clicked on a link.

In fairness to Mr. Podesta, apparently his assistant did ask their IT staff about the legitimacy of that phished email, and was told that it seemed legitimate and was okay to click on. In addition, at that point in time, apparently someone did ask as to whether or not two-factor authentication was enabled on his account, and if not, suggested that it be immediately enabled.

All said and done, apparently Mr. Podesta did end up clicking that link and at that very moment his account was compromised.

The rest i.e. the huge impact of the public disclosure of this sensitive data on the U.S. presidential election, is all over the news.


Now, strictly speaking, the only thing that makes this a huge deal is that in this case the compromised data happened to be vast amounts of high-value sensitive, private email conversations of one of two parties contesting an election in a specific country. The actual technical means involved in compromising security here were basic, a 2.5 on a scale of 1 to 10, 1 being very easy.

You see, usually perpetrators begin by trying to phish a target just to gain a foothold inside the organization's network perimeter. However, in a case where emails may be all they're after, and the target's already using a free/low-cost email service, merely step 1, i.e. being able to successfully phish that free/low-cost email service account will get them to mission-accomplished, because once they have compromised that email account, right then and there they have access to all of the account's emails.

Thus, using relatively easily targetable and compromisable free/low-cost email accounts likely increased their risk exposure.


From a professional cyber security standpoint, one of the most fundamental principles of security, the Principle of Adequate Protection, states that "an asset must be protected to a degree consistent with its value". In line with it, ideally entities engaging in high-value communications should be using sufficiently high-assurance systems and employing adequate security controls.   In light of this, in this case, the use of a free/low-cost email service to engage in high-value communications seems perplexing.

If you have high-value/sensitive communications to engage in, please do not use low-assurance / inadequately-secure systems to engage in them. If you must absolutely have to use a low-assurance/free email service such as Gmail for high-value/sensitive communications, at least do enable 2-factor authentication for password changes/resets to protect against phishing attacks.

At the end of the day, it matters not so much as to who compromised you, as it does that someone was able to compromise you. Once you've been compromised, the impact of that breach is purely a function of the perpetrator's motives and actions.



Speaking of Massive Cyber Attacks

Sorry for a brief digression. As a mature cyber security practioner, what I find more amusing than comical write-ups such as this and this is that the recent DoS attacks to hit the U.S. east coast were being referred to as a massive/huge cyber attack.

Don't get me wrong. Those attacks may have been massive/huge in terms of the number of websites they momentarily DOS'ed out, but if you consider the technical mechanics involved, brass tacks, its still just a (large) bunch of old-fashioned basic TCP/IP SYN flooding, using compromised IoT devices. Its fancy, but its still simple stuff with relatively low moment-in-time impact.

To put things in perspective, a massive cyber security attack would be one wherein a proficient adversary such as an advanced persistent threat could gain control over large parts of a country's power-grid, government, security and financial infrastructures. These are the kinds of cyber attacks we (know of and) worry about. In fairness, most cyber security companies aren't there yet.



Speaking of Russia

It is widely suspected that Russia carried out the DNC and Podesta email hacks. No one likely knows the facts, neither do I, so in regards to Russia, I'll share what I do know.

This so-called "hack" was so simple, that possibly even a smart freshman from anywhere in the world could have carried it out.

That said, speaking of Russia and its purported cyber attacks on U.S entities, what should be more concerning (and we know this based on publicly available info) is that most likely, code that was likely either written in Russia or is still being supported / updated from inside Russia, may likely be running in highly privileged security contexts in various parts of the U.S. Government.

(Responsible disclosure: Strictly speaking, there's nothing to disclose here since this info has been publicly available for years, yet out of an abundance of caution, earlier this year we did bring this to the attention of several top U.S. Government officials.)

The Russians are considered to be adept at hacking, so if it was them, I'm surprised that they would resort to using such basic attack vectors (i.e. phishing a Gmail account); I suppose it must be their starting point, and it appears they got lucky at step 1 itself. Now, if their target was a specific Gmail account to begin with, then of course that is exactly where they would start.



An Important Concluding Point

I'd like to make one very simple and important point - it matters not as to who is trying to hack you, because as long as you have digital assets of value to someone, there could be (and likely already are) many entities wanting to hack you, driven by various motives; what matters is that you need to protect yourself from being hacked by anyone in the first place.

In this specific case, although any logical mind can easily see why Russia might stand to gain a lot from the outcome of the U.S. election, one could similarly reason that many other countries in the world could stand to gain much from its outcome as well. In fact, not just countries, many corporations worldwide could stand to gain or lose much based on the outcome of this election.

The point again being that it matters not as to who is trying to hack you (or why), it matters that you protect yourself from being hacked by anyone. Mature entities consider it a norm to assume that they are always operating in a hostile environment with numerous adversaries trying to hack them 365-24-7. That is the unfortunate reality of engaging in business in a digital world.

By the way, I prefer not to use the word hack, because there's a connotation of casualness to it. It would be nice to see the media use professional terms like breach, compromise, security incident etc. as they rightfully have a serious connotation.

As I conclude, I'd like to request all organizations (including of course, all media companies and all cyber security companies) worldwide to look  within and if required, consider bolstering their cyber security defenses and enhancing their security posture.

Best wishes,
Sanjay

Defending Active Directory Against CyberAttacks

Folks,

One week ago I had announced that I will be respectfully taking Microsoft to Active Directory Security School. I had also posed a Trillion $ question to Microsoft. As promised, today, in this post, I will do so. Sometimes less is more, so today I'll keep it short.

It is my privilege to share with you a presentation on Active Directory Security that I built for Microsoft and the world -

Download point - www.paramountdefenses.com/defending-active-directory-against-cyberattacks.html

Here is a snapshot of a few sections from this 90+ slide deck -

I suggest that Microsoft and organizations worldwide, go through this deck, and absorb it like a sponge absorbs water, because in this deck lies the key to organizational cyber security worldwide and the answer to the Trillion $ question I posed to Microsoft.


If you find yourself wondering "What's the big deal?", please go through the entire deck, then consider the following:

       Here are the top 3 sources of guidance from Microsoft on the paramount subject of Active Directory Security -

1. Microsoft's original 100+ page official Best Practice Guide for Securing Active Directory (Part I) and Part II

2. Microsoft's latest official Best Practices for Securing Active Directory guidance, introduced by Microsoft's CISO

3. Microsoft's latest 5+ hour series of 12+ videos on Defending Active Directory Against Cyber Attacks

       If you can find even one mention of the Trillion $ phrase "Effective Permissions" in any of the above, let me know.


We've found that due to a complete decade+ lack of guidance from Microsoft on the most important technical aspect of Active Directory Security i.e. "Effective Permissions", 99% of the 1000s of IT personnel (Domain Admins, IT Auditors, IT Managers, CISOs etc.) from 1000s of organizations that have knocked at our doors do not even know what "Effective Permissions" are !


I'll let the $ 500 Billion Microsoft, and organizations worldwide, reflect on and absorb a) this fact, b) these questions and c) this deck, for a week, then continue sharing thoughts starting Nov 01, both on this blog and at - www.paramountdefenses.com/blog/.

Best wishes,
Sanjay

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

Folks,

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 - http://technet.microsoft.com/library/9111e6f0-fb7f-4340-b87a-ab941978efe1.aspx

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,
Sanjay

An Increase in Cyber Security Attacks from the Syrian Electronic Army

Folks,

As we were getting ready to declassify the #1 Active Directory Security Risk to organizations worldwide, we received a request to consider delaying its declassification, in light of the possibility of more cyber attacks from the Syrian Electronic Army (SEA), as Washington mulls possible military action against Syria.


Who is the Syrian Electronic Army

According to Wikipedia the Syrian Electronic Army is a collection of pro-government computer hackers aligned with the Syrian President -

"The Syrian Electronic Army (SEA), also known as the Syrian Electronic Soldiers, is a collection of pro-government computer hackers aligned with Syrian President Bashar al-Assad. Using denial of service attacks, defacement, and other methods, it mainly targets political opposition groups and western websites, including news organizations and human rights groups. The Syrian Electronic Army is the first public, virtual army in the Arab world to openly launch cyber attacks on its opponents, though the precise nature of its relationship with the Syrian government is debated."

In recent months, the Syrian Electronic Army has taken credit for Web attacks on media targets that it sees as sympathetic to Syria's rebels, including prior attacks at the New York Times, along with the Washington Post, Agence France-Press, 60 Minutes, CBS News, National Public Radio, The Associated Press, Al-Jazeera English and the BBC.

Although their attacks have been thus far been simplistic (DDOS), one of the latest ones was a sophisticated spear phishing attack, they thus do seem capable of attempting sophisticated attacks, especially if they might be receiving technical assistance from the Russians, the Iranians, or others.


An Increase in Cyber Security Attacks from the Syrian Electronic Army

Quoting, Helmi Noman, a senior researcher at the Citizen Lab, Munk School of Global Affairs at the University of Toronto, who has been tracking the Syrian Electronic Army since May 2011-  "They said they are determined to escalate attacks on websites belonging to the United States, European countries and all the countries preparing a possible military action against Syria," Noman said. He also said that "This suggests that the group will try to carry out more serious attacks."

Over the last few days, the Syrian Electronic Army has increased cyber security attacks and disrupted major media websites, including that of the New York Times and earlier today, the Syrian Electronic Army hacked the website of Marines.com.

As Washington mulls possible military action in Syria, the next few few days are sensitive, and the Syrian Electronic Army could potentially try to increase cyber security attacks on the American media and other organization.


Abundance of Caution

The entity that made this request has expressed concern that the Syrian Electronic Army, or their allies, could potentially misuse such new information to develop and deploy exploits possibly aimed at attacking corporate infrastructures of major media outlets as well as military agencies and business organizations (, both that of the US, and those of its partners, notably England, France, Australia and others.)

We doubt that the Syrian Electronic Army has the technical expertise needed to use advanced attack vectors (, the simplest of which is the Pass-the-Hash attack vector,) involving intimate details of Windows Security and Active Directory Security. Their attacks thus far seem to be simplistic DDOS attacks, as well as social engineering attacks to accomplish phishing.

However, we do believe that other malicious entities out there might have the technical sophistication needed to swiftly use such advanced attack vectors. In fact, the only reason we are making this public is because we have reason to believe that at least one prominent advanced persistent threat may have already figured this out.

On the other hand, if the SEA is getting technical assistance from the Russians or the Chinese, then they could very well potentially acquire the capability to use advanced attack vectors to cause harm.

Thus, out of an abundance of caution, we decided to honor the request, and thus have postponed the declassification of this risk until September 12, 2013.  Details can be found here.

Best wishes,
Sanjay.

The Temperature Is Rising - Cyber Security Threats Abound

Folks,

If you've been following the Cyber Security space, then you know that cyber threats are increasingly becoming a serious threat to national and corporate security worldwide. Over the last few weeks, we've all seen a steady increase in cyber security attacks, and we've also seen governments move to make cyber security a national security priority, as it rightly should be.

Last week, U.S Representative Dutch Ruppersberger of Maryland, top Democrat on the House Permanent Select Committee on Intelligence, said on CNN’s State of the Union program - “We have attacks right now. Wall Street has been attacked. We have the capability of other countries, including Iran, for destructive attacks, to knock out our grid system, to attack some of our banks. We have got to stop this.”

A few months ago, I had alluded to the fact that the Perfect Storm may be brewing for organizations worldwide. I believe that a perfect cyber security storm is ahead of us, and it may be around the corner.

 

Based on what we're seeing, we believe that the temperature is rising, and that in months to come, the number and severity of cyber attacks on organizations is unfortunately only going to increase.

Based on what we're seeing, I also continue to believe that inspite of the rhetoric, most organizations worldwide, including numerous government organizations hardly have a clue as to some of the world's most serious cyber security risks today. (For now, the seem busy trying to figure out how to prevent themselves from kiddish DDOS attacks, which frankly, are merely an annoyance.)

There's no dearth of rhetoric when it comes to Cyber Security. There is only the dearth of the enactment of well-thought out, prioritized risk mitigation measures aimed at ensuring that organizations are adequately defendable from not just kiddish DDOS attacks to their front doors, but also adequately defendable from advanced cyber threats that could very well be launched from on the inside, once malicious perpetrators have found a way to deliver a well-crafted payload to the inside.

In essense, what is needed is that organizations understand just how paramount the importance of cyber security is, and that they swiftly enact measures aimed at ensuring that their digital assets are adequately and comprehensively protect from risks. A high-priority, well-funded, organization wide cyber security risk assessment and mitigation initiative

At Paramount Defenses, we're helping organizations obtain a deeper understanding of some of the most critical of such advanced threats that have the potential to cause swift, irreversible, wide-spread damage to the very foundation of their cyber security defenses.

We wish all organizations well, and we hope that understand the gravity of the situation, because the temperature is certainly rising, and the perfect storm may unfortunately be around the corner.

Best wishes,
Sanjay