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. Continue reading “The Joy of Sandbox Mitigations”
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. 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, 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”, 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: Continue reading “TROOPERS16 Training Teaser: Dos and Don’ts of Secure Active Directory Administration”
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. Continue reading “Investigating Memory Analysis Tools – SSDT Hooking via Pointer Replacement”
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.
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.
So, what to do? The relevant mitigations, pointed out by Dell´s CTU, as event log monitoring and scanning processes on suspicious systems with the published YARA signature should be applied.
Still, let’s discuss for a second which long-term, preventative measures could come into play as well. Continue reading “Skeleton Key – a Nasty Piece of Malware. Some Remarks.”
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).
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).
However, we worked on an interesting request that focused on Skype’s security impact on end devices, mainly concerning Windows clients. Skype has many features e.g. file sharing between users, the ability to set the port on which Skype listens, or clients becoming supernodes, which in turn can be relevant for the overall security impact on network or clients. The interesting part from a corporate perspective is the ability to configure those Skype settings via GPO, for which Skype even used to provide an ADM file. However, the settings in this file were quite outdated, which made us decide to put together a file for the settings of the most recent version of Skype. Relevant resources for this are the Skype IT Administrators Guide and a corresponding TechNet article on ADMX files (Managing Group Policy ADMX Files Step-by-Step Guide).
Our Skype ADMX files can be found here for download.
Besides the concerns of Skype usage in corporate environments in general (as mentioned above, this post does not discuss those), we want to outline some of the settings that can be relevant to protect clients and network:
Disable File Transfer: Disable file transfer to achieve that any user can’t send any internal data trough Skype.
Disable Contact Import: This setting prevents any user to import contacts trough the application itself, importing contacts can be realized over Skype-Manager tool.
Disable Web Status: If you disable this setting any user can’t publish their online status.
Disable API: Prevents usage of Skype API for third party applications.
Disable Version Check: This setting prevents Skype to perform an initially version check.
Memory Only: This setting makes it possible to run Skype without storing data on the local disk.
Listen Port: Skype normally listens on a default Port, this setting restricts the port to your settings.
Disable Supernode: This setting prevents a random user to become a supernode which makes it possible for this user to intercept traffic.
Proxy Type: HTTPS or SOCKS5. This also enables the use of the proxy in general
Proxy Address: “hostname:port” e.g. “socks5.mydomain.com:5050”.
Proxy Username: “username” e.g. “socks5user”.
Proxy Password: “password” e.g. “socks5pass”.
Despite our critical opinion on Skype, we hope that the files might help the secure operation of Skype in environments where it has to be used for some reasons.
Sebastian & Matthias
PS: We tested the files in our environment and did not experience any problems. We’re happy about bug reports, however it might take time to deploy changes and we cannot provide any support/warranty on the files.
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. Continue reading “Microsoft Windows Update over IPv6 (or not?)”