Earlier this year Dell’s SecureWorks published an analysis of a malware they named “Skeleton Key”. This malware bypasses authentication for Active Directory users who have single-factor (password only) authentication. The “Skeleton Key” attack as documented by the SecureWorks CTU relies on several critical parts, listed in reverse order of use by the threat actor:
1.) The Skelky Trojan resident in memory on a domain controller (or similar malware from the Winnti family).
2.) psexec from the Windows Sysinternals toolkit, to launch the Trojan as the LocalSystem account.
3.) Access to the Active Directory Domain Controller
4.) Access to the network
While other vendors have excellent write-ups detailing how this attack works, we’ll spend some time discussing some available defensive strategies.
Stopping the Trojan
The piece of this Advanced Persistent Threat attack that gives rise to its name is the ability to use any password to authenticate as any user on the network, an authentication “Skeleton Key”. This is obtained via the Trojan running resident in memory on one or more Domain Controllers in the victim’s environment. Several AV vendors, including our PowerBroker Endpoint Protection have signatures to block the known versions of this Trojan. However, these products need to be configured to scan the entire memory, not just files on disk, since the attack documented by Dell used only memory-resident code, so as not to leave a trace for offline forensics. For PowerBroker Endpoint Protection, the option is here:
(This screen is under: BeyondInsight -> Configure -> Protection Policies -> Policy Name -> Edit Policy -> Rule Name -> Manage)
The downside to AV signatures is that many Trojans, worms, and viruses, including this one, are polymorphic and can change to avoid AV signatures. Because of this, using AV to stop the Trojan from running should not be the only defensive measure employed by concerned administrators.
Stopping the Trojan from Being Launched
In both the Dell and Symantec write-ups, the malware described is decidedly a Trojan, not a worm. This means that it needs to be manually launched by an actor, either the threat actor, or an unwitting administrator. In the Dell writeup, this launcher was Microsoft’s psexec utility. If you’re unfamiliar with the use of psexec, we strongly recommend you read the Microsoft Technet article in order to understand this powerful systems administration tool. (APT actors will often re-use standard systems administration tools, to avoid installing custom toolkits on many of the systems in their target environments, and to help avoid detection by systems administrators.) Psexec has a unique feature of allowing software to be launched as “LocalSystem” – the same account the kernel and system drivers are often running as. This makes the trojan harder for many defensive tools to remove from the system.
BeyondTrust’s PowerBroker for Windows software can be used to prevent not just this tool, but many tools of this sort from being run. PowerBroker for Windows on a server can require administrators to provide a reason for every activity they run, but it can also prevent known dangerous tools, even if they have a good purpose, such as psexec. An example PowerBroker for Windows rule to block psexec entirely could look like the following:
Even though psexec.exe is signed by Microsoft, and we may have a rule allowing all Microsoft signed software to run, we can still block this particular tool, no matter where it exists on the server’s hard drive.
Blocking Access to the Active Directory Domain Controller
Once an APT attacker is inside the network, they are going to often use standard systems administration tools for lateral movement through the network. In the case of the Skeleton Key attack, files were copied to the domain controllers using the standard \servernameadmin$ share and stolen credentials. While some security systems consider the admin$ share to be a vulnerability in and of itself, it’s also necessary for many centralized administration systems.
A vulnerability scanner like Retina Network Security Scanner can identify servers that have overly-open administrator groups (only the local Administrators group can access the Admin$ share), as seen below.
By using least-privilege delegation of rights and removing users from the built-in Administrators group (made easier by running products like PowerBroker for Windows to limit only pre-allowed software) can help prevent the psexec command remotely running on remote systems as well.
Preventing Initial Access to the Network
The starting point for many long-running attacks such as Skeleton Key is a vulnerable entry point to the network. While ensuring least-privilege across the network is a necessary security step, discovering and remediating vulnerabilities that attackers use for entry is just as important. Whether the entry point is a spear-fishing email with a malformed PDF or self-running Word macro (such as a recent CryptoRansom variant used), finding the vulnerable endpoints and removing those vulnerabilities combined with least-privilege access and escalation will reduce the area that attackers can exploit to enter your network in the first place.
(This screen is under: BeyondInsight -> Configure -> Protection Policies -> Policy Name -> Edit Policy -> Rule Name -> Manage)
The downside to AV signatures is that many Trojans, worms, and viruses, including this one, are polymorphic and can change to avoid AV signatures. Because of this, using AV to stop the Trojan from running should not be the only defensive measure employed by concerned administrators.
Stopping the Trojan from Being Launched
In both the Dell and Symantec write-ups, the malware described is decidedly a Trojan, not a worm. This means that it needs to be manually launched by an actor, either the threat actor, or an unwitting administrator. In the Dell writeup, this launcher was Microsoft’s psexec utility. If you’re unfamiliar with the use of psexec, we strongly recommend you read the Microsoft Technet article in order to understand this powerful systems administration tool. (APT actors will often re-use standard systems administration tools, to avoid installing custom toolkits on many of the systems in their target environments, and to help avoid detection by systems administrators.) Psexec has a unique feature of allowing software to be launched as “LocalSystem” – the same account the kernel and system drivers are often running as. This makes the trojan harder for many defensive tools to remove from the system.
BeyondTrust’s PowerBroker for Windows software can be used to prevent not just this tool, but many tools of this sort from being run. PowerBroker for Windows on a server can require administrators to provide a reason for every activity they run, but it can also prevent known dangerous tools, even if they have a good purpose, such as psexec. An example PowerBroker for Windows rule to block psexec entirely could look like the following:
Even though psexec.exe is signed by Microsoft, and we may have a rule allowing all Microsoft signed software to run, we can still block this particular tool, no matter where it exists on the server’s hard drive.
Blocking Access to the Active Directory Domain Controller
Once an APT attacker is inside the network, they are going to often use standard systems administration tools for lateral movement through the network. In the case of the Skeleton Key attack, files were copied to the domain controllers using the standard \servernameadmin$ share and stolen credentials. While some security systems consider the admin$ share to be a vulnerability in and of itself, it’s also necessary for many centralized administration systems.
A vulnerability scanner like Retina Network Security Scanner can identify servers that have overly-open administrator groups (only the local Administrators group can access the Admin$ share), as seen below.
By using least-privilege delegation of rights and removing users from the built-in Administrators group (made easier by running products like PowerBroker for Windows to limit only pre-allowed software) can help prevent the psexec command remotely running on remote systems as well.
Preventing Initial Access to the Network
The starting point for many long-running attacks such as Skeleton Key is a vulnerable entry point to the network. While ensuring least-privilege across the network is a necessary security step, discovering and remediating vulnerabilities that attackers use for entry is just as important. Whether the entry point is a spear-fishing email with a malformed PDF or self-running Word macro (such as a recent CryptoRansom variant used), finding the vulnerable endpoints and removing those vulnerabilities combined with least-privilege access and escalation will reduce the area that attackers can exploit to enter your network in the first place.