He is a security researcher in Google’s Project Zero. He has been involved with computer hardware and software security for over 10 years looking at a range of different platforms and applications. With a great interest in logical vulnerabilities he has numerous disclosures in a wide range of products from web browsers to virtual machine breakouts as well as being a Pwn2Own and Microsoft Mitigation Bypass bounty winner. He has spoken at a number of security conferences including Black Hat USA, CanSecWest, Bluehat, HITB, and Infiltrate.
In the last few years, attack techniques which fall in the categories of “Credential Theft” or “Credential Reuse” have grown into one of the biggest threats to Microsoft Windows environments. Microsoft has stated more than one time, that nearly almost all of their customers that run Active Directory have experienced “Pass-the-Hash” (PtH) attacks recently.[1] Once an attacker gains an initial foothold on a single system in the environment it takes often less than 48 hours until the entire Active Directory infrastructure is compromised. To defend against this kind of attacks, a well-planned approach is required as part of a comprehensive security architecture and operations program. As breach has to be assumed[2], this includes a preventative mitigating control strategy, where technical and organizational controls are implemented, as well as preparations against insider attacks. This is mainly achieved by partitioning the credential flow in order to firstly limit their exposure and secondly limit their usefulness if an attacker was able to get them. Although we spoke last year at Troopers 15 about “How to Efficiently Protect Active Directory from Credential Theft & Large Scale Compromise”[3], we would like to summarize exemplary later in this post Active Directory pentest findings that we classified in four categories in order to better understand what goes typically wrong and thus has to be addressed. For a better understanding of the overall security goals, we classified the findings as to belonging as a security best practice violation of the following categories:
In this blogpost we will briefly explain a well known Syscall hooking technique (a more detailed explanation can be gathered from e.g. http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/) used by multiple malware samples (like the laqma trojan) and right after discuss how some memory analysis tools have trouble in the analysis and/or reporting of these.
Before we go further, I just shortly wanted to say, that this post is not intended to be a bashing of any tool. We have the greatest respect for all the effort and work which has been and most probably will be done in the future.
This year’s Black Hat US saw a number of quite interesting talks in the context of Windows or Active Directory Security. For those of you too lazy to search for themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to Vegas due to heavy project load) I’ve compiled a little list of those.
Paul Stone & Alex Chapman: WSUSPect – Compromising the Windows Enterprise via Windows Update
Slides here.
Whitepaper here. (Attention: on the BH website there’s an older this. the above link leads to the latest one).
Server operating systems with an OS, for which vendor support has ended, come with many risks that have to be considered and addressed. The primary goal should be always to decommission or migrate the majority of end-of-life (EoL) servers to OS versions, supported by the vendor. Here it should be noted that a migration to an up-to-date OS should be preferably done before your organization enters the end of life of that software 😉
Just recently, Dell SecureWorks Counter Threat Unit(TM) (CTU) researchers published details (see http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/ ) on a especially nasty piece of malware that bypasses authentication on Active Directory (AD) systems which implement single-factor (password only) authentication. Once deployed the malware stays quite noiseless in the Domain Controller´s (DC) RAM, and the DC´s replication issues caused by it weren´t interpreted – in this case – during months as a hint for system compromise. Probably the malware´s modification on the LSASS process reduced the DC´s ability to perform DC-to-DC authentication, but this is only speculation and not where we would like to go today.
After we recently released the “Linux IPv6 Hardening Guide” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the ipv6hackers mailing list).
Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It can be found here.
Once more we’d like to emphasize that the approach described is only suited for very specific environments with high security requirements and an associated ratio of “generous operational resources”. From our perspective this guide is intended mostly to serve as a source of inspiration (“what could be done”) and for documentation purposes (“how to do it”). Everything described should be carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an organization where the Windows guys (completely legitimately) came up with a stance of “before we fully accept and ratify the strategy and policy just discussed, we’d like to get feedback from Microsoft, if we still have full support once we follow this path”.
In the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
regularly we get requests from customers where the idea of using Skype as a VoIP solution in their corporate environment is brought up. There are a lot of eavesdropping and more conceptual concerns (e.g. refer to this or this, and of course the legendary “Silver Needle in the Skype” paper from Black Hat EU 2006), but those won’t be covered in this post (just to say this: at ERNW the use of Skype is strictly prohibited at by policy).
I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column.