Demo - Regex

•  any string as is but a particular string: ^(?!particularString$).*
• Grouped match (it will return named group, give a host FQDN, below will return domainName   ^.*?\.(?<domainName>.*)
• Matches duplicate line ^((?-s).+?)\R(?=(?s).*?^\1(?:\R|\z))
• AD domain NETBIOS name when standalone
  [a-zA-Z0-9](?!.*[,:~!@#\$%\^'\.\(\)\{\}_ \/\\]).{0,14}\\
  
• SAMaccountName
  ^(?!.*[\"\/\\\[\]:;|=,\+\*\?<>]).{1,19}$

• AD domain NETBIOS name when followed by \userName (this also groups domain/user)
  ([a-zA-Z0-9](?![^\\]*[,:~!@#\$%\^'\.\(\)\{\}_ \/]).{0,14})\\((?!.*[\"\/\\\[\]:;|=,\+\*\?<>]).{1,19})
• same for powershell match
  
  -match '^    ([a-zA-Z0-9](?![^\\]*[,:~!@#\$%\^''\.\(\)\{\}_ \/]).{0,14})\\((?!.*[\"\/\\\[\]:;|=,\+\*\?<>]).{1,19})'
• DN --> OU path (stripping CN name)
  -match '^((.+?),)(OU=.*|CN=.*)' $OUPath = $matches[3]

Azure AD: Risky User VS. Risky Sign-in

 

Differences between “Risky Sign-In” and “Risk User”

• Risky sign-in: abnormally in sign in activities, such as unusual location, impossible travels etc.
• Risky user: An account that MS believes to have high probability of having been comprised (e.g. leaked credential)

 

More importantly, the difference lies in how they are dealt with:

• Risky Sign-in: requires additional authentication (e.g. MFA)
• Risky User: Make old credential invalid (e.g. reset password)

 

If we are to target “Risky Users”, Risky User Policy can be used to force password change. 

 

Similarly, If we are to target “Risky Sign Ins”, we can use “Risky Sign in Policy” to enforce MFA.

Tracking AD authentications - what to audit, what to ignore

Audit category "Logon/Logoff" means the actual logon/off activity where a session is established.

Audit category "Account Logon/Logoff" means *authentication*. It's different from "logon/logoff", it's not "logon/logoff" 

There are 2 places in Windows/AD environment where authentication can happen, 

• locally to SAM database (NTLM), or 
• against AD. 

When a principal authenticates against AD, it could be NTLM or Kerberos. 

[update] MS added 2 new features called "Local KDC" and IAkerb respectively. The former feature allows a local auth happens using Kerberos 

 You are going to see a lot of "logon/logoff" events either on member server, or on DC. 

• When it's on member server, it could be local user or AD user established logon session after auth
• When it's on DC - you should see DC same as a resource member server, because logon/logoff events happens when a user accesses it as client. You will see almost all AD users have logon events on DCs with type 3 (remote) because users need to access DC in various ways in domain - e.g., pulling GPO from SYSVOL folder 

For the purpose of tracking user's "logon" activity into AD, you really want to track their "authentication" activity. You should ignore all "logon/logoff" events from DC because this is redundant. For any logon event there must be preceding authentication event. Auth event alone is enough to determine if a user has recent activity against AD. 

This means to check only 4776-NTLM, 4768, Kerberos, see section below 

• logon/off events
• 4624 : logon
  Note: There are tons 4624 for all users on DC (logon type 3, remote) because user need to connect to SYSVOL etc. 
• Related events 
• 4634: log off (e.g. log off session from a remote server) 
• 4647: user initiated logoff (e.g. in interactive console logoff) 
• 4625: failed to logon 
• 4672: special logon (local) 
• 4648: local logon
• AD auth events (a.k.a *Account* Logon/off events) 
• 4776: If reported on DC, tried to validate credentials via NTLM. 
• Fields to extract in Splunk:(when reported on local, SAM) 
• user: user, or Logon_Account 
• domain: dest|dest_nt_host, remove short host name final query: EventCode=4776 | regex user!=".*\$$" | rex field=dest "^.*?\.(?.*)"| strcat domain "\\" user ID 
• 4768 Kerberos TGT validation: 
• Field to extract in Splunk
• user: user | Account_Name | src_user 
•  domain: user_account_domain | dest_nt_domain 
• Related events:
• 4771: Kerberos pre-auth failed 
• 4772: TGT request failed 
• 4769 Kerberos Service Ticket requested (good for knowing what resource an account is accessing) 
• 4770: ST renewed