ADDS

ADDS-1 Adding in groups

index=`index_winsecurity` EventID IN (4728,4732,4756)
[|inputlookup "lookup_AD1_groups" | fields TargetSid]
| eval Subject_User=mvzip(SubjectDomainName,SubjectUserName,"\\")
| eval ctime = strftime(_time, "%Y-%m-%dT%H:%M:%S.%QZ")
| stats values(host) as host, values(EventID) as EventID, min(ctime) as first_time, max(ctime) as last_time by Subject_User,SubjectUserSid, TargetDomainName,TargetUserName ,TargetSid ,MemberName,MemberSid

Throttle: host, TargetUserName, MemberSid

Considerations

You can decline this rules for adding some built-in groups like Domain administrators. You can automate this alert to send directly an email to the customer or the internal CSIRT, there is no added value for analysts, but alerts have to be collected for correlation for other events.

Group

SID	Name	Type
S-1-5-32-544	Administrators	Built-in
S-1-5-32-548	Account Operators	Built-in
S-1-5-32-549	Server Operators	Built-in
S-1-5-32-550	Print Operators	Built-in
S-1-5-32-551	Backup Operators	Built-in
S-1-5-32-555	Builtin\Remote Desktop Users	Built-in
S-1-5-32-573	Builtin\Event Log Readers	Built-in
S-1-5-21-domain-500	Administrator	Global
S-1-5-21-domain-512	Domain Admins	Global
S-1-5-21-domain-518	Schema Admins	Global
S-1-5-21-domain-519	Enterprise Admins	Global
S-1-5-21-domain-571	Allowed RODC Password Replication Group	Global

ADDS-2 Potential DCSync

`index_winsecurity` EventID=4662 AccessMask="0x100" SubjectUserName!="*$"
|search NOT [|inputlookup DC_list.csv |fields Computer]
AND Properties IN "*Replicating Directory Changes All*",
"*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*",
"*{9923a32a-3607-11d2-b9be-0000f87a36b2}*",
"*{1131f6ac-9c07-11d1-f79f-00c04fc2dcd2}*")
| stats min(_time) as _time, count by SubjectDomainName, SubjectUserName, Computer, Logon_ID, ObjectName, ObjectServer, ObjectType, OperationType, status

Throttle: SubjectUserName, Computer

Considerations

We focus on the 3 GUID in the following table from microsoft, however we. add the Replicating Directory Changes Because the parsing of 4662 is not always perfect There could be some false positive by DC, ADConnect (msol account) Remove the known DC account from the list This alert should be critical and have a score of 100 in a RBA model You can check the full documentation from microsoft about control access right : Control Access Right Microsoft

Control

Control Access Right symbols	GUID
DS-Replication-Get-Changes	1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-All	1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-In-Filtered-Set	89e95b76-444d-4c62-991a-0facbeda640c

ADDS-3 Password Spraying (NTLM & Kerberos)

`index_winsecurity` EventCode=4771 Status=0x18 TargetUserName!="*$"
| bucket span=5m _time
| stats dc(TargetUserName) AS unique_accounts values(TargetUserName) as list_accounts by _time, IpAddress
| where unique_accounts > 10
`yourtable`

`index_winsecurity` EventCode=4776 TargetUserName!=*$ Status=0xC000006A
| bucket span=5m _time
| stats dc(TargetUserName) AS unique_accounts values(TargetUserName) as list_accounts by _time, Workstation
| where unique_accounts > 10
`yourtable`

Throttle IpAddress (Kerberos) OR Workstation(NTLM)

Considerations

Many immature SOC MSSP that lack an RBA model set thresholds at 3 or 5. This is a common mistake that leads to hundreds of false positives, adversely affecting the analysts’ quality of work. By setting a higher threshold, each alert raised will have more significance and will be analyzed more thoroughly, helping to avoid an overload of alerts. If you prefer to maintain a low threshold, consider implementing an RBA model with a scoring system. You might also want to calculate the Crossover Error Rate (CER) to determine the best threshold. Don’t hesitate to include a bucket span in these types of alerts, as it allows for replaying this search over an extended period while maintaining a 5-minute span.

ADDS-4 Kerberoasting

`index_winsecurity` EventCode=4769 Service_Name!="*$" (Ticket_Options=0x40810000 OR Ticket_Options=0x40800000 OR Ticket_Options=0x40810010) Ticket_Encryption_Type=0x17
| stats count min(_time) as firstTime max(_time) as lastTime by dest, service, service_id, Ticket_Options
| `convert_epoch_to_string(firstTime)`
| `convert_epoch_to_string(lastTime)`
| `yourtable`

Throttle
dest, service

ADDS-5 Pass-The-Hash

`index_winsecurity` EventCode=4624 (Logon_Type=3 Logon_Process=NtLmSsp NOT AccountName="ANONYMOUS LOGON") OR (Logon_Type=9 Logon_Process=seclogo)
| stats count min(_time) as firstTime max(_time) as lastTime by EventCode, Logon_Type, WorkstationName, user, dest
| `convert_epoch_to_string(firstTime)`
| `convert_epoch_to_string(lastTime)`
| `yourtable`

Throttle WorkstationName, user

Considerations

Look at the tables found in this great article from Jeff Warren to have more context about basic NTLM authentication vs Pass-The-Hash how-to-detect-pass-the-hash-attacks