Just when you thought the ‘Sticky Key’ backdoor has gone out of fashion, you detect a threat actor still leveraging this old, yet effective technique to escalate privileges and maintain persistence on a machine they’ve targeted. Today we’ll examine a computer’s Digital Guardian (DG) logs that left behind a trail of nastiness in an effort to maintain persistence. But first, a little history lesson. The Sticky Key function is a well-known Windows feature that helps handicapped users. It allows the user to press a modifier key, such as Shift, Ctrl, Alt, or the Windows key, and have it remain active until another key is pressed. Of course anything with good intentions, often will get abused by someone to wreak havoc. Affected operating systems: pretty much all Windows!
The Attack
It was a Tuesday morning. Upon arrival to work I was greeted with several alerts almost instantly after my second sip of steaming hot coffee. These alerts caused a fast and furious dash to our consoles to review the logged events. The first alert was for the following:
ATAC – [Lateral Movement] – Interactive Scheduled AT Command (New User)
I’m not going to be ‘judgy’ here, but creating a user account “adm” with a password of “B@ckd00r” seems like an extremely hacker adolescent thing to do. I mean yes, the password is fairly strong with the use of upper and lower case characters, a symbol, and numbers. And yes, this would most likely adhere to a somewhat lax corporate policy, but REALLY? Right away I knew this was something nefarious and I immediately jumped to our next alert:
ATAC – [Lateral Movement] – Interactive Scheduled AT Command (Ping)
Well, well, checking for internet connectivity are we? This is commonly a sign of actors ensuring the box they’ve targeted has access to the world wide web of command and control and distributed botnets. It would, of course, be useless to drop malware on a machine that doesn’t even have the ability to ping Google’s DNS servers. Moving along, we see another alert associated with persistence:
ATAC – [Persistence] – Sticky Key Backdoor
This command is adding a registry entry where cmd.exe is set as a debugger to the sethc.exe process. This ultimately provides the ability for an attacker to press the Shift key five times from the logon screen and bada-bing, a command prompt is spawned with the added prize of a shell running as LOCAL_SYSTEM privileges. No need to authenticate and the attackers have effectively bypassed any Windows event-based logging being generated by the OS.
Below is a condensed view of the events that transpired during the initial phases of this attack. If I were a betting man, the HoK (Hands on Keyboard) behind this endeavor was a trainee or a member of the ‘D’ team and definitely not the ‘A’ team. They fumbled through commands and took a fairly decent amount of time to finally achieve their opening objective, however in good fashion we were able to thwart these pesky intruders and send them back to whatever province they reside in. (And yes, we know what province they reside in!)
Mitigation
Unfortunately there is no real effective solution for mitigating this type of an attack. Sure, you could turn off Sticky Keys via a registry entry; however, that only slows down an adversary by adding an additional step for them to turn it back on. Detection is really the best option in this scenario and can be achieved by configuring a security solution like a host-based IPS (HIPS) to alert on registry modifications or file replacements commonly observed by this vulnerability. Additionally, the ATAC (Advanced Threat and Analysis Center) here at Digital Guardian offers (through our MSP program) real-time alerting on these events with the DG Agent installed. We also have the ability to block this activity from even occurring in the first place, if the customer is so inclined.
