Life After SOC - The Beginning

Hello world

Hi all, and welcome to my new blog series, Life After SOC - A series about overcoming the challenges infosec professionals face after making it into the field.

My name’s Vince, and I’m currently a Detection Engineer for a small MDR firm, Nano Cyber Solutions.

Title sounds cool, huh? Things weren’t always so glamorous.

After 3 years of self-studying various courses and countless hours practicing in homelabs, the grueling grind finally paid off in early 2023 when I landed an internship with Nano as a SOC Analyst.

That was the biggest challenge that I’ve faced in this career thus far. And not for reasons you’re probably thinking.

Analyzing alerts in controlled environments is fun, and exciting! You know what you’re looking for, or at least the general idea of it.

To those of you in the field, you know how incredibly boring the real work is. You don’t come across real incidents regularly like you would in practice. Most of the time it’s boring work.

Well then, how would you learn new skills and improve preexisting ones if the work is mostly static? Here’s where this series comes into play.

I'd like to bring you along on my journey of how I approach continuous learning post- break in, and how I keep my skills sharp.

This series will cater to all in the infosec space. Whether you're trying to break in, or you've been in the field for some time, I hope you'll learn something new as I explore new technologies and tools.

---

I'll start with a passion of mine: Detection Engineering

What is DE?

I’d define Detection Engineering as proactively creating defenses against potential adversaries. It could also be looked at retroactively, say as a way to fill a gap that you learned you had after an incident response engagement.

An awesome way to view the proactive approach was brought up by Olaf Hartong during a Defender Fridays episode. I'll paraphrase here: "Look at the top threat actors targeting your customer's environment. View the techniques they like to use, and write detections against them."

Going along this line of thinking, let's jump into a threat intel report from Mandiant on a threat actor, APT41:

There's a lot to unpack here, but reading through the full report shows that APT41 is primarily financially motivated, and we’ll also see that they have been known the use the Windows Sticky Keys vulnerability to maintain persistence and to elevate privileges.

I'm sure most of you reading have ran into the Sticky Keys popup at some point in your life. If you're not familiar, Sticky Keys will show up when a Windows user presses the shift button 5 times in quick succession. Doing this will launch an accessibility menu (sethc.exe) to allow a user the option to execute keyboard shortcuts easier, or an option to disable this feature entirely.

The attack in this instance is to change the executable that's launched for the Sticky Keys accessibility menu to a Command Prompt. And the crazy part is, this shortcut can activate even before the user logs in, as well as persisting through reboots. Talk about an invaluable persistence technique!

Next up we’ll be doing an overview of a a pre-existing Sigma rule that covers the detection for this attack.
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. If you’ve never seen a Sigma rule before, don’t worry - I’ll break down the meat and potatoes of the rule in an easily digestible manner:

title: Persistence Via Sticky Key Backdoor
id: 1070db9a-3e5d-412e-8e7b-7183b616e1b3
status: test
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 privilleged 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
date: 2020/02/18
modified: 2023/03/07
tags:
    - attack.t1546.008
    - attack.privilege_escalation
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        CommandLine|contains|all:
            - 'copy '
            - '/y '
            - 'C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe'
    condition: selection
falsepositives:
    - Unlikely
level: critical

If you’re new to rule-building , this may look a bit intimidating. Like I said, we’ll be focusing on the actual detection logic of the rule. So, here’s a snippet of the rule focusing on what’s called a Search Identifier:

CommandLine|contains|all:

            - 'copy '

            - '/y '

            - 'C:\windows\system32\cmd.exe C:\windows\system32\sethc.exe'

As you can see, we're trying to catch something similar to:

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

If you’re unfamiliar with this command, I’ve listed a more detailed breakdown below:

'copy' - This is used to copy files from one location to another. In this context, to replace the Sticky Keys executable, sethc.exe, with the command prompt executable, cmd.exe

'/y' - this switch is used to force cmd.exe to overwrite sethc.exe without prompting for confirmation

'File Path' - again, we're simply specifying the path to ‘copy’ or overwrite sethc.exe with cmd.exe

Now that you understand how attackers exploit this vulnerability with Sticky Keys, let’s breakdown the entire detection logic:

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

falsepositives:
    - Unlikely

level: critical

‘detection:’ - this is where the detection logic begins. Everything before that was either metadata related to the attack, or specifying the log source.

‘selection:’ - here we’re specifying where the search identifiers begin. The search identifier in this case is:

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

‘condition:’ - Now that we’ve established the detection logic, we’ll need to implement a condition for the alert to fire. In this case, the condition statement in this particular example isn't verbose as it indirectly references the search identifier, which already contains an "all" statement. - CommandLine|contains|all

‘falsepositves’ - This is where you’d put the false positives, if there were any. This field contains information to help the responding analyst figure out if this rule fired on legitimate malicious behavior, or if the alert generated on non-malicious behavior.

In this specific example, there aren’t any false positives, due to the likelihood of sethc.exe being overwritten with cmd.exe being a very intentional, and most often, a malicious behavior.

‘level:’ - As you might have guessed, this is the severity rating for this rule. In this case it’s ‘critical’, which is the highest or most severe rating for a detection rule.

There you have it! If you’re already in the field, I hope you’ve learned something new. If you’re trying to break in, hopefully you now understand a little bit about rule tuning. It’ll give you something interesting to bring up in an interview!

Which brings me to my final point:

It’s great to learn about this stuff, but to really solidify your knowledge, we need practice! In the next part of this series, I'll post a walk-through of how we can emulate this persistence technique in a lab environment, and then write a detection against it.

I hoped you’ve enjoyed the first post of my new series, and if this post brought any value to you or you have any criticisms, please feel free to reach out to me on LinkedIn.

Stay safe and have a wonderful day!