Hello again! I'm back with part 2 of Building Robust Detection Capabilities. Last time, we dove into the awesomeness of the SigmaHQ detection repository, covering what Sigma HQ detections are, their usage, and formatting. Now, let’s get practical and explore how to craft these detections using logs from your environment. Content warning: This post will dive deep into the nerdiness of detection engineering, packed with details you might find useful.
Well let’s start with a log that exists in your environment that can be fed into a SEIM of your choosing with some minor work. There are several uses for Sigma detections but I want to focus on one that is pretty general, has multiple use cases, and is near and dear to how Recon likes to use detections. We will be making a basic detection for a user being added to a Domain Administrator group. You ask though “why would i want to know this?”. Well, several reasons: to catch bad guys, to catch good guys, and maybe because you are just curious. For a very basic understanding from a senior SOC analyst who thoroughly appreciates the rockstar Security Devops Team. We run sysmon and LC to ship logs from endpoints to our log collection and SEIM platform see cool example picture below.
Behold we have our very generic log entry nicely formatted so we can use this as our starting point. What you will be looking at below is a simple organic windows event 4728 (click here if you want some additional information about windows logs related to user activity) which looks at when A member was added to a security-enabled global group. This is a log generated by windows by default.
Default windows view:
An account was successfully logged on.
A member was added to a security-enabled global group.
Subject:
Security ID: ACME\Administrator Account Name: Administrator Account Domain: ACME Logon ID: 0x27a79
Member:
Security ID: ACME\gkhan Account Name: cn=Ghenghis Khan,CN=Users,DC=acme,DC=local
Group:
Security ID: S-1-5-21-3108364787-189202583-342365621-1108 Group Name: Historical Figures Group Domain: Domain Admins
Additional Information:
Privileges: -
Expiration time:
Our enhanced awesome sysmon/Lima Charlie view with a slight bit more context and format
"event":{
"EVENT":{
"EventData":{
"MemberName":"cn=Ghenghis Khan,CN=Users,DC=acme,DC=local"
"MemberSid":"S-1-5-21-1609578530-38470043-1846952604-20411"
"PrivilegeList":"-"
"SubjectDomainName":"ACME"
"SubjectLogonId":"0x27a79"
"SubjectUserName":"gkhan"
"SubjectUserSid":"S-1-5-21-3108364787-189202583-342365621-1108"
"TargetDomainName":"ACME"
"TargetSid":"S-1-5-21-3108364787-189202583-342365621-1108"
"TargetUserName":"Domain Admins"
}
"System":{
"Channel":"Security"
"Computer":"Khenti-MTN-MON"
"Correlation":""
"EventID":"4728"
"EventRecordID":"519639466"
"Execution":{
"ProcessID":"816"
"ThreadID":"3044"
}
"Keywords":"0x8020000000000000"
"Level":"0"
"Opcode":"0"
"Provider":{
"Guid":"{54849625-5478-4994-a5ba-3e3b0328c30d}"
"Name":"Microsoft-Windows-Security-Auditing"
}
"Security":""
"Task":"13826"
"TimeCreated":{
"SystemTime":"1162-05-31T19:23:46.9642788Z"
}
"Version":"0"
"_event_id":"4728"
}
}
}
Ok I have translated machine language from the sparky rock that thinks. What do I do with this and how do I write a detection for someone being added to the Domain administrator group given our example logs above. Well let's look at how we can take this telemetry and snag a few pieces for our detection.
Alright now that we have our main ingredients let's go ahead and start completing this dish. We are aware of what specific event we want to look at and the specific group we want to monitor. Let's build our question we want to ask. Essentially it boils down to picking our log source which would be the windows security logs , the specific security events of 4728, and our specific group of domain admins. Which query wise would look eventid: “4728” AND TargetUserName: “Domain admins”.
If we look below I have a fully functioning rule to look at what should be a rare occurrence in your environment. The key fields to pay attention to would be our selection, selection group and condition. Everything above that is more for reference and tracking. Selection is our first field we want to look at, Selection group is our secondary field we want to look at and our condition says to take these 2 values and look for them.
title: User Added to Domain Administrators
id: 721c01f9-1725-4c8d-a35a-73fb62aaa754
description: This rule triggers on user accounts that are added to the domain Administrators group, which could be legitimate activity or a sign of privilege escalation activity
status: stable
author: Watson Brown
date: 2022/12/09
modified: 2022/12/09
tags:
- attack.privilege_escalation
- attack.t1078
- attack.persistence
- attack.t1098
logsource:
product: windows
service: security
detection:
selection:
Eventid: 4728
selection_group:
TargetUserName: 'Domain Admins'
condition: selection and selection_group
falsepositives:
- Legitimate administrative activity
level: medium
** side note: If you want to look at those fields and filter something out, you can easily add a filter and add it in between your conditions and your selection say for instance i want to exclude anyone added that has a “DA.username”. The below filter is not necessary but is a good example of how to filter out what could be legitimate activity. However you will have to weigh the inconvenience of an alert now and again vs not seeing an attacker possibly figuring out you had a DA in front of all your domain admins adding an account you did not get alerted on.
filter_legit:
SubjectUserName|startswith: DA.*
condition: selection and selection_group and not filter_legit
Creating these detections takes time, log data, and research to generate. While you could go to SigmaHQ repository and pull their full set of rules; they may not be tailored to your environment. You may just want some simple detection built for regular IT Administrative lookouts or you could be gunning for bad guys trying to do devious things in your network. Either way this has hopefully opened the door to you building your own detections. If you do not have the time to spare for detection engineering and cranking these out at the same speed that threats are being reported please reach out to us. We would be happy to help you secure your environment.