Life After SOC - The Bad Guys Use Sticky Keys Too

Hello all, and welcome back to the next edition of Life After SOC - a series aimed at showing the behind-the-scenes of infosec professionals. Whether you’re trying to break in, or whether you’ve already broken in but you’re trying to get to that next level, this series is for you.

Stay tuned until the end where we feature our guest share insights of their “Life” After SOC.

P.S. Our featured guest can be ANYBODY, (yes, even you!)

---

Let’s Get a Homelab Going!

In the first edition of my series, I broke down a Sigma rule for the Sticky Keys Vulnerability.

In this post, we’ll be covering a homelab project to detect and defend against this vulnerability.

If you don’t already have a homelab configured to observe telemetry and detect & respond to threats, I highly recommend you to follow Eric Capuano’s FREE guide So You Want to Be a SOC Analyst?

In a very short time frame, you’ll have a homelab setup completely configured to detect and respond to threats, and practice adversary emulation techniques.

For this post, you only need to follow Part 1 to install a Windows Victim VM with EDR/SIEM capabilities from LimaCharlie, but here’s a quick rundown of the entire 6-part series.

• Installation and configuration of Sysmon and LimaCharlie on Windows Victim VM to capture telemetry.

• Install Sliver, an adversary emulation tool on an Ubuntu Attacking VM to generate and deploy a C2 session payload

• Interact directly with Victim VM via the Attacking VM to emulate a LSASS credential dumping attack

• Use LimaCharlie to locate evidence of the attack and then create/tune a detection rule for the LSASS attack

If you already have your homelab set up with a different SIEM platform, that’s fine because we’ll be covering a vendor-agnostic approach using Sigma.

Sigma is a generic and open detection format written in YAML that allows us to generate alerts based off of content matching in log files. Because it’s generic, we’ll be able to translate Sigma rules into any backend of your preference.

---

The Bad Guys Use Sticky Keys Too

Now, that you have your homelab environment primed and ready, let’s dive into the Sigma rule for the Sticky Keys Vulnerability.

This particular rule focused on detecting the final step of the vulnerability:

'copy /y C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe"

This is a great detection, however if you’ve ever attempted to alter System32 files, you’ll find that this vulnerability isn’t quite so easy to exploit.

For example, you’ll come across this error:

Well, that wasn’t quite what I wanted to happen. What gives?

By default, some system files in Windows are owned by the "TrustedInstaller" or the system itself, and even administrators do not have the right to modify these files.

So how do we combat this?

First we’ll have to take ownership as an Administrator:

takeown /f C:\Windows\System32\sethc.exe

But, we’re not done here. We’ve set ownership of the file as an Administrator, but the current user is who actually accesses sethc.exe.

So, as the Administrator who now owns the file, we’ll need to give the current user full access to this file:

icacls C:\Windows\System32\sethc.exe /grant %username%:F

‘icalcs’ is a command for modifying the Access Control Lists (ACLs) of files, allowing you to set specific permissions.

‘/grant %username%:F’ - We’re specifying the current user and granting them full access permissions (F)

Now, we can continue with exploiting the vulnerability:

copy /y C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe

The Sigma rule we covered earlier will catch this, but where could we build upon this rule?

Well, there’s two commands that have to be completed before the bad guys finish the exploit. - We could potentially catch them and completely mitigate the impact.

Let’s dig into this by building on top that Sigma rule to catch those prerequisite commands:

title: Persistence Via Sticky Key Backdoor
id: 1070db9a-3e5d-412e-8e7b-7183b616e1b3
status: Experimental
description: By replacing the sticky keys executable with the local admins CMD executable, an attacker is able to access a privileged windows console session without authenticating to the system.
When the sticky keys are "activated" the privileged shell is launched.
references:
    - https://www.fireeye.com/blog/threat-research/2017/03/apt29_domain_frontin.html
    - https://www.clearskysec.com/wp-content/uploads/2020/02/ClearSky-Fox-Kitten-Campaign-v1.pdf
    - https://learn.microsoft.com/en-us/archive/blogs/jonathantrull/detecting-sticky-key-backdoors
author: Sreeman, Vince
date: 2020/02/18
modified: 2024/03/02
tags:
    - attack.t1546.008
    - attack.privilege_escalation
logsource:
    product: windows
    category: process_creation
detection:
    selection1:
        CommandLine|contains|all:
            - 'copy '
            - '/y '
            - 'windows\system32\cmd.exe windows\system32\sethc.exe'
    selection2:
        CommandLine|contains|all:
            - 'takeown'
            - '/f'
            - 'Windows\System32\sethc.exe'
    selection3:
        CommandLine|contains|all:
            - 'icacls'
            - 'Windows\System32\sethc.exe'
            - '/grant'
    condition: selection1 or selection2 or selection3
falsepositives:
    - Unlikely
level: critical

So, what’s changed?

Previous detection logic:

detection:
    selection:
        CommandLine|contains|all:
            - 'copy '
            - '/y '
            - 'C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe'
    condition: selection

New logic:

detection:
    selection1:
        CommandLine|contains|all:
            - 'copy '
            - '/y '
            - 'windows\system32\cmd.exe windows\system32\sethc.exe'
    selection2:
        CommandLine|contains|all:
            - 'takeown'
            - '/f'
            - 'Windows\System32\sethc.exe'
    selection3:
        CommandLine|contains|all:
            - 'icacls'
            - 'Windows\System32\sethc.exe'
            - '/grant'

    condition: selection1 or selection2 or selection3

As you can see, we’re detecting all 3 pieces of the puzzle:

takeown /f C:\Windows\System32\sethc.exe
icacls C:\Windows\System32\sethc.exe /grant %username%:F
copy /y C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe

If you’re unfamiliar with Sigma rule building, you may have asked why we didn’t write it this way:

detection:
    selection1:
	CommandLine|contains|all:
            - 'copy '
            - '/y '
            - 'windows\system32\cmd.exe windows\system32\sethc.exe'
            - 'takeown'
            - '/f'
            - 'Windows\System32\sethc.exe'
            - 'icacls'
            - 'Windows\System32\sethc.exe'
            - '/grant'
    condition: selection1

If the rule was written this way this means that for the alert to fire, the command line MUST contain a variation of ALL of those strings in a single line, like so:

takeown /f C:\Windows\System32\sethc.exe && icacls C:\Windows\System32\sethc.exe /grant %username%:F && copy /y C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe

While it’s likely that an attacker may execute all of the commands at once, our alert would fail if they executed them one at a time.

So, our Sigma rule is successfully written, now let’s translate it into LimaCharlie to actively detect and respond to this event.

---

I Don’t Want the Bad Guys to Use Sticky Keys

If you’ve made it this far, you’re awesome! You’ve strengthened your understanding of rule creation, now let’s dive into my EDR solution of choice, LimaCharlie and translate our Sigma rule!

Here’s what I came up with:

#Detect

event: NEW_PROCESS
op: and
rules:
  - op: is windows
  - op: or
    rules:
      - op: and  # Detect 'takeown' command variations
        rules:
          - op: contains
            path: event/COMMAND_LINE
            value: "takeown"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/f"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\Windows\\System32\\sethc.exe"
            case sensitive: false
      - op: and  # Detect 'icacls' command variations
        rules:
          - op: contains
            path: event/COMMAND_LINE
            value: "icacls"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\Windows\\System32\\sethc.exe"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/grant"
            case sensitive: false
      - op: and  # Detect 'copy' command variations
        rules:
          - op: contains
            path: event/COMMAND_LINE
            value: "copy"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/y"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\windows\\system32\\cmd.exe"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\windows\\system32\\sethc.exe"
            case sensitive: false

#Respond

- action: report
  name: Sticky Keys Exploit
  priority: 1 
- action: isolate network

If you’re unfamiliar with LimaCharlie rule syntax, let me break down the Detection and Response one piece at a time:

So, starting from the top, we’re looking for a new process, in this case cmd.exe. I will also simplify the detection logic by separating each rule condition.

event: NEW_PROCESS (cmd.exe)
op: and
rules1:
  - op: is windows
  - op: or
    rules:

Now that we know we’re looking for a NEW_PROCESS event (cmd.exe), for the detection to alert us, we’re using ‘operation: and’ to specify that both event: NEW_PROCESS and rules1 must be true.

In this next snippet, rules1 is simply stating that both operations must be true.

op1: the log source must be Windows AND

op2: any condition in Rules2 must be true.

rules1:
  - op1: is windows (log source must be Windows)
  - op2: or (Any of the conditions in rules2 must be true)
    rules2:

As we’ve established, for rules1 to be true, any of the conditions in rules2 has to be true.

Now, in order for rules2 to be true, any of the three conditions must be true.

Condition1 is looking for:

takeown /f C:\Windows\System32\sethc.exe

   rules2:
      - op: and  # Detect 'takeown' command variations
        condition1: 
          - op: contains
            path: event/COMMAND_LINE
            value: "takeown"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/f"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\Windows\\System32\\sethc.exe"
            case sensitive: false

Condition 1:

All this wall of text is saying that the command line should contain the values “takeown”, “/f”, and “C:\Windows\System32\sethc.exe” in any order, and be case insensitive.

You may be asking yourself, why couldn’t we simplify it? This command can only be executed one way. You can’t put the ‘/f’ flag AFTER the file path. What’s with all of the extra fluff?

 - op: and  # Detect 'takeown' 
        condition1:
          - op: contains
            path: event/COMMAND_LINE
            value: "takeown /f C:\\Windows\\System32\\sethc.exe"
            case sensitive: false

While this version can be effective, this only looks for the command exactly the way it is. Meaning, an attacker can easily evade this detection by adding an additional space between words such as:

takeown /f C:\Windows\System32\sethc.exe
takeown   /f  C:\Windows\System32\sethc.exe

The next two conditions, are very similar and look to see if the command line executed “icacls C:\Windows\System32\sethc.exe /grant” in any order:

      - op: and  # Detect 'icacls' command variations
        condition2:
          - op: contains
            path: event/COMMAND_LINE
            value: "icacls"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\Windows\\System32\\sethc.exe"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/grant"
            case sensitive: false

Again, this rule, or condition is specifying that the command line value contains “icacls”, AND “C:\Windows\System32\sethc.exe” AND “/grant” regardless of where they’re placed in the command line relative to one another.

Condition3:

“copy /y C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe”

      - op: and  # Detect 'copy' command variations
        condition3:
          - op: contains
            path: event/COMMAND_LINE
            value: "copy"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "/y"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\windows\\system32\\cmd.exe"
            case sensitive: false
          - op: contains
            path: event/COMMAND_LINE
            value: "C:\\windows\\system32\\sethc.exe"
            case sensitive: false

We’ve covered the Detection part, now how about the Response?

- action: report
  name: Sticky Keys Exploit
  priority: 1 
- action: isolate network

We’re configuring the rule to alert us when it detects any of the 3 commands being ran in our environment, and to prioritize this alert as critical. These commands should not be ran in a production environment.

“action: isolate network”

Since this is a persistence and privilege escalation tactic, we’re going to go ahead and cut off the attackers and force the VM to only be able to communicate with LimaCharlie, even across reboots. This allows us to perform an investigation and respond to the threat.

That’s it! We’ve successfully built a Sigma rule to detect the Sticky Keys Vulnerability, and we translated it into LimaCharlie where we were able to implement mitigation against this technique.

---

So, what’s with the “LIFE” After SOC?

I’ll upload a video walk-through of this technique soon, but first, keeping in theme with the ‘Life’ aspect, let’s introduce this week’s Life After SOC guest, Jennifer Funk.

Jennifer currently holds the position Manager II Cyber Defence & Ops US with Ahold Delhaize, a leading global retailer with over 380,000 associates and 7,000 stores across 11 countries.

Bringing with her extensive 10+ year history in IT and a background in running a marketing agency as well as being a Military Police in the US Army, she shares some insights into her Life After SOC:

Prior to breaking in you ran a marketing business, how did that influence your current CTI position? -

"While running a marketing business, I was able to work with clients intimately in their web space and analytics. I think learning to draw data on numbers and assess information to draw conclusions were all viable skills when transferring into cybersecurity and specifically the CTI space." 

From being an Army MP, how transferable were your investigative skills to infosec?

"I think a lot of military experience, military police or not is transferable to cyber security. You are taught about working across a great breadth of cultures and personality types to reach a common goal. In my case yes, I learned about investigations, report writing, and thinking clearly in chaos, all which have served me well in cybersecurity."

What are some of the most important skills you've learned since being in the field? Any major takeaways you learned from a memorable investigation or IR engagement?

"A big takeaway from working in the cybersecurity space is there is no lack of learning and it is impossible to know everything. The best skills someone can bring to the table outside of the basics for the job requirement are a thrust for knowledge,  aptitude to learn, and ability to collaborate with others and listen subjectively. "

How do you think you'll leverage these experiences and your knowledge to further your career in infosec? What's the short term/long term goal? 

"This is an interesting question. I have learned a lot about information security since working in the cybersecurity field. I think it also changes so often that there is still much learning to be done. I’d like to continue to build my personal brand, not only to scratch the itch of creativity that I am often plagued with, but also support those interested in the field. Long term I would like to curate a positive community and comfortable space to have real candid conversations around cybersecurity. "

And finally, with what you know now, would you have done anything differently leading up to now? What skills did you wish you spent longer mastering before getting in? Or something you wished you learned in your first month or two, rather than now.

“I don't think I would have done anything differently. I spent the first almost full year before getting my first role gaining certs, reading cyber news, immersing myself in the community, and talking to professionals. I was careful not to jump in too quickly, and knew it would take time before the role I would be able to land would reflect my personal goals.

To those that say "there are no entry level roles in cybersecurity" I could combat that with saying "there are not effortless roles". It will take work, but is absolutely possible."

Love the responses, Jennifer, and I wish you the best of luck with your YouTube channel!

If you’d like to collaborate and feature your “Life” After SOC, feel free to reach out to me on LinkedIn, and we’ll work together to help the infosec community!

Stay safe and have a wonderful day!