Detection rules › Kusto

GitLab - User Impersonation

Status
available
Severity
medium
Time window
1d
Group by
AuthorName, TargetDetails
Source
github.com/Azure/Azure-Sentinel

'This queries GitLab Audit Logs for user impersonation. A malicious operator or a compromised admin account could leverage the impersonation feature of GitLab to change code or repository settings bypassing usual processes. This hunting queries allows you to track the audit actions done under impersonation.'

MITRE ATT&CK coverage

TacticTechniques
PersistenceT1078 Valid Accounts

Rule body kusto

id: 0f4f16a2-b464-4c10-9a42-993da3e15a40
name: GitLab - User Impersonation
description: |
  'This queries GitLab Audit Logs for user impersonation. A malicious operator or a compromised admin account could leverage the impersonation feature of GitLab to change code or repository settings bypassing usual processes. This hunting queries allows you to track the audit actions done under impersonation.'
severity: Medium
status: Available
requiredDataConnectors:
  - connectorId: SyslogAma
    dataTypes: 
      - Syslog
queryFrequency: 1h
queryPeriod: 1d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - Persistence
relevantTechniques:
  - T1078
query: |
  let impersonationStart = (GitLabAudit
  | where CustomMessage == 'Started Impersonation');
  let impersonationStop = (GitLabAudit
  | where CustomMessage == 'Stopped Impersonation');
  impersonationStart
  | join kind=inner impersonationStop on $left.TargetID == $right.TargetID and $left.AuthorID == $right.AuthorID 
  | where EventTime1 > EventTime
  | extend TimeGenerated, AuthorID, AuthorName, TargetID, TargetDetails = TargetDetails, IPStart = IPAddress, IPStop = IPAddress1, ImpStartTime = EventTime, ImpStopTime = EventTime1, EntityName
  | join kind=inner (GitLabAudit | extend ActionTime = EventTime, AuthorName) on $left.TargetDetails == $right.AuthorName 
  | where ImpStartTime < ActionTime and ActionTime > ImpStopTime
entityMappings:
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: IPStart
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: IPStop
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: EntityName
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: TargetDetails
version: 1.0.2
kind: Scheduled

Stages and Predicates

Let binding: impersonationStop

let impersonationStop = (GitLabAudit
| where CustomMessage == 'Stopped Impersonation');

The stages below define let impersonationStart (the rule's main pipeline source).

Stage 1: source

GitLabAudit

Stage 2: where

| where CustomMessage == 'Started Impersonation'

The stages below run on impersonationStart (the outer pipeline).

Stage 3: join

impersonationStart
| join kind=inner impersonationStop on $left.TargetID == $right.TargetID and $left.AuthorID == $right.AuthorID

Stage 4: where

| where EventTime1 > EventTime

Stage 5: extend

| extend TimeGenerated, AuthorID, AuthorName, TargetID, TargetDetails = TargetDetails, IPStart = IPAddress, IPStop = IPAddress1, ImpStartTime = EventTime, ImpStopTime = EventTime1, EntityName

Stage 6: join

| join kind=inner (GitLabAudit | extend ActionTime = EventTime, AuthorName) on $left.TargetDetails == $right.AuthorName

Stage 7: where

| where ImpStartTime < ActionTime and ActionTime > ImpStopTime

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
ActionTimegt
  • ImpStopTime transforms: cased
CustomMessageeq
  • Started Impersonation transforms: cased
  • Stopped Impersonation transforms: cased
EventTime1gt
  • EventTime transforms: cased
ImpStartTimelt
  • ActionTime transforms: cased

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

FieldSource
AuthorIDextend
AuthorNameextend
EntityNameextend
IPStartextend
IPStopextend
ImpStartTimeextend
ImpStopTimeextend
TargetDetailsextend
TargetIDextend
TimeGeneratedextend