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.
At the first glance, restricting the debug privilege to a very restricted, legitimate users group (which requires revoking this privilege from the Administrators group that do have the privilege in Windows operating systems by default) seems to be a valid mitigation option. This option can be deployed (and maintained) in enterprise environments in a reasonable way via Group Policy (GPO) and it will prevent the execution of the malware (as published by Dell) so far. But: looking a bit deeper, this mitigation might be circumvented easily by an attacker, executing psexec with the “-i” and “-s” parameters or potentially by slightly modifying the code of the malware. The same will most probably apply to mitigations like logon restrictions for well-known Security Identifiers (SIDs) – a valid mitigation for the credential theft and credential reuse attack vector (but not for the patched LSASS process).
As in the lately and vastly discussed Active Directory credential theft scenarios (privilege escalation via Mimikatz or Windows Credential Editor (WCE)), the most decisive and pre-emptive mitigating control is: Take special care of where you ‘leave’ the ‘footprint’ of high privileged credentials, such as the credentials from members of the Domain Admin, Enterprise Admin, Schema Admin and Administrators group on DCs. In other words:
- Implement administrative tiers (which should be – of course – part of your AD security concept – you have one (?) 😉 that fit your organizational needs.
- Split service accounts according to your administrative tiers (if you have, for example a backup service account running on each Windows server, you will need one backup service account for each administrative tier).
- Use well-defined systems from where highly privileged administrators do their daily administrative work (this might be a jump server or a Privileged Account Workstation (PAW – in the Microsoft terminology).
- Use a small number of administrative accounts (of course, you already knew and followed this one, right? ;-).
- Use two-factor authentication for highly privileged accounts (which will protect you in the case of the Skeleton Key malware, but maybe not in the case of stolen credential reuse).
- Do some additional Active Directory authentication hardening as proposed in the already quite well-known (but still worth reading) paper “Mitigating Pass-the-Hash and Other Credential Theft, version 2” (http://www.microsoft.com/en-us/download/details.aspx?id=36036 ).
- Perform strict security logging and monitoring.
- Have sufficient administrative personnel – ideally not outsourced – to implement the steps 1. – 7. It´s surely _not_ an easy task in case of large AD environments with hundreds of DCs and thousands of servers… still, considering the impact of an AD compromise, reflecting on these measures’ Return on Security Investment (ROSI) could be helpful. (This ENISA link https://www.enisa.europa.eu/activities/cert/other-work/introduction-to-return-on-security-investment might serve as a starting point).
Please note: The first control is the most important – and unfortunately most painful – one and … it is an organizational control! All other controls are direct consequences of the first control (like 2. and 3.) or they are meant to accompany the administrative tier model.
If you want to deepen this and other topics related to Microsoft security, visit our one day training “Hardening Microsoft Environments” on March 17th (https://www.troopers.de/events/troopers15/321_hardening_microsoft_environments/) at Troopers 2015!
If you want to learn more about forensic analysis in case of AD/Domain Controller compromise, attending our two day training “Incident Analysis” (https://www.troopers.de/events/troopers15/301_incident_analysis/ ) on March 16th. and 17.th. might be a good idea, too.
Have a great day,
Friedwart Kuhn.