My Detection Work

title: AWS Identity Orientation and Authorization Failure Baseline
id: 3c1f7a92-6b04-4d55-9e88-2a0c5f31b7de
status: experimental
description: >
  Baselining rule for visibility. Surfaces sts:GetCallerIdentity and CloudTrail
  authorization failures so the Hunt and Analyst thresholds can be derived from local data.
  Deploy it to characterise the environment, then tune the higher tiers from what it shows.
  Answer three questions before deploying the higher tiers:
    1. Which principals call GetCallerIdentity routinely, and from which source IPs?
    2. Which principals carry chronic authorization failures, and on which
       (eventSource, eventName) pairs? That list becomes the Hunt tier allowlist.
    3. What is the normal distinct-namespace denial spread per principal? Most legitimate
       principals sit at 0-1. Re-derive the Hunt threshold from this, do not assume 5.
  Choosing the principal key: baseline on the identity that issued the session. A temporary
  ASIA* access key rotates per session, and an assumed-role ARN embeds a RoleSessionName that
  repeats only when the caller reuses it, so neither is a dependable long-term baseline
  identity. All three tiers key on COALESCE(useridentity.sessioncontext.sessionissuer.arn,
  useridentity.arn, useridentity.principalid, useridentity.accesskeyid) — the session issuer
  ARN (the role) for AssumedRole sessions, the caller ARN or principal ID otherwise, with
  accessKeyId as a last fallback. Keep the expression identical across tiers so baselines,
  aggregations, and joins agree on what a principal is.
  Only authorization and authentication failures count as denials — AccessDenied,
  AccessDeniedException, UnauthorizedOperation, Client.UnauthorizedOperation,
  AuthorizationError, AuthFailure. Throttling, validation, and missing-resource errors are
  also written to errorCode and say nothing about the caller's permissions, so counting every
  non-empty errorCode as probing inflates the denial ratio with application noise. Total event
  counts stay as the denominator. AWS documents errorCode and errorMessage as optional record
  fields, and some services report authorization failures inside responseElements rather
  than the top-level errorcode column this query reads. CloudTrail visibility also depends on
  support for the service and operation, the selected event category, and whether that
  integration records denied requests. Confirm those conditions before relying on the count.
  Avoid building detection on userAgent. AWS SDKs and tools commonly expose application-ID or
  custom user-agent metadata, so tool-name matches such as "Pacu" or "Boto3" are not durable.
  Baseline query (Athena). It needs a CloudTrail trail delivering management events to S3 and
  an Athena table over that data. Management events are selected by default when a trail is
  created, but the S3 delivery and the Athena table are not created automatically; console
  event history is automatic and covers 90 days, but is not queryable this way.
    WITH ct AS (
      SELECT COALESCE(useridentity.sessioncontext.sessionissuer.arn,
                      useridentity.arn,
                      useridentity.principalid,
                      useridentity.accesskeyid)                       AS principal,
             eventsource,
             eventname,
             sourceipaddress,
             useridentity.accesskeyid                                 AS access_key,
             COALESCE(errorcode, '') IN (
               'AccessDenied', 'AccessDeniedException', 'UnauthorizedOperation',
               'Client.UnauthorizedOperation', 'AuthorizationError', 'AuthFailure'
             )                                                        AS auth_denied
      FROM cloudtrail_logs
      WHERE from_iso8601_timestamp(eventtime) > now() - INTERVAL '30' DAY
    )
    SELECT principal,
           count(*)                                                   AS total_events,
           count_if(auth_denied)                                      AS auth_denials,
           count(DISTINCT CASE WHEN auth_denied THEN eventsource END) AS denied_namespaces,
           array_agg(DISTINCT concat(eventsource, ':', eventname))
             FILTER (WHERE auth_denied)                               AS denied_pairs,
           count_if(eventname = 'GetCallerIdentity')                  AS orientation_calls,
           count(DISTINCT sourceipaddress)                            AS src_ips,
           count(DISTINCT access_key)                                 AS session_keys
    FROM ct
    GROUP BY 1
    ORDER BY total_events DESC
  This tier keeps service and chronic-denial principals in the results, since identifying them
  is the point, and nothing here needs data-event logging.
references:
  - https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/
  - https://attack.mitre.org/techniques/T1580/
  - https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html
  - https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
author: '@NovaSky0x1'
date: 2026-08-09
tags:
  - attack.discovery
  - attack.t1580
  - attack.t1526
  - detection.maturity.research
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_orientation:
    eventSource: 'sts.amazonaws.com'
    eventName: 'GetCallerIdentity'
  selection_denied:
    errorCode:
      - 'AccessDenied'
      - 'AccessDeniedException'
      - 'UnauthorizedOperation'
      - 'Client.UnauthorizedOperation'
      - 'AuthorizationError'
      - 'AuthFailure'
  condition: selection_orientation or selection_denied
falsepositives:
  - Expected at this tier. GetCallerIdentity is routine SDK, CI/CD, and Terraform behaviour
  - AWS Config rules and drift detection generating chronic denials on a fixed API set
  - Backup and inventory agents probing services they are not permitted to read
  - Developers running exploratory CLI commands against accounts they legitimately hold
level: informational

title: AWS Credential Permission Probing — Denial Breadth Across Service Namespaces
id: 8d4b21e6-70af-4c19-b3a6-9f5c2e6188a4
status: experimental
description: >
  Detects one principal generating authorization failures across five or more distinct
  service namespaces in a rolling window, with an authorization-failure ratio of at least
  0.5 against all events by that principal in the window. That is the shape of an operator
  mapping a credential whose scope they do not know.
  Breadth is a heuristic rather than an invariant: an operator with useful context, a readable
  identity policy, or a correct first guess can settle capability in a handful of calls, so
  this tier targets the generic, undirected case. Within it the distinct-namespace count
  discriminates better than raw denial volume, since a principal denied 200 times on one API
  is almost always misconfigured while one denied five times across five namespaces is mapping
  its own permissions.
  Choosing the principal key: aggregate on the identity that issued the session, using
  COALESCE(useridentity.sessioncontext.sessionissuer.arn, useridentity.arn,
  useridentity.principalid, useridentity.accesskeyid) as the Research and Analyst tiers do, so
  Research-tier allowlists apply unchanged. A temporary ASIA* key rotates per session and an
  assumed-role ARN repeats only when its RoleSessionName is reused, so grouping on either can
  split one operator's probing into single-event groups that never reach the threshold of 5.
  Populate filter_chronic_principals with session issuer ARNs for the same reason.
  Only authorization and authentication failures count toward the namespace breadth and the
  ratio numerator — AccessDenied, AccessDeniedException, UnauthorizedOperation,
  Client.UnauthorizedOperation, AuthorizationError, AuthFailure. Throttling, validation, and
  missing-resource errors also populate errorCode and carry no permission information, so
  counting every non-empty errorCode inflates both measures with application noise. The
  denominator stays every event by the principal in the window, successful or not. Services
  that report authorization failures inside responseElements rather than the top-level
  errorcode column are a blind spot. CloudTrail visibility also depends on support for the
  service and operation, the selected event category, and whether that integration records
  denied requests.
  Distinct-namespace counts and ratios cannot be expressed in Sigma, so the detection block
  below is a partial stub firing on any single authorization failure; deploy the query for
  production. It needs a CloudTrail trail delivering management events to S3 and an Athena
  table over that data — management events are selected by default when a trail is created,
  but the S3 delivery and the table are not. No data-event logging is needed at this tier.
  Athena:
    WITH ct AS (
      SELECT COALESCE(useridentity.sessioncontext.sessionissuer.arn,
                      useridentity.arn,
                      useridentity.principalid,
                      useridentity.accesskeyid)             AS principal,
             eventsource,
             COALESCE(errorcode, '') IN (
               'AccessDenied', 'AccessDeniedException', 'UnauthorizedOperation',
               'Client.UnauthorizedOperation', 'AuthorizationError', 'AuthFailure'
             )                                              AS auth_denied
      FROM cloudtrail_logs
      WHERE from_iso8601_timestamp(eventtime) > now() - INTERVAL '15' MINUTE
        AND useridentity.type <> 'AWSService'   -- matches filter_service_principals below
    )
    SELECT principal,
           count(*)                                                   AS total_events,
           count_if(auth_denied)                                      AS auth_denials,
           count(DISTINCT CASE WHEN auth_denied THEN eventsource END) AS denied_namespaces
    FROM ct
    GROUP BY 1
    HAVING count(DISTINCT CASE WHEN auth_denied THEN eventsource END) >= 5
       AND count_if(auth_denied) * 1.0 / count(*) >= 0.5
  Before production: re-derive both thresholds from the Research tier, build the chronic-denial
  allowlist, and add those principal exclusions to the Athena WHERE clause by hand, since
  filter_chronic_principals below constrains only the Sigma stub. Config rules, drift
  detection, and backup agents are the dominant false positives and they are stable and
  enumerable.
  Pacing defeats a 15-minute window; widening it to 24 hours catches slower operators at
  query cost. The Analyst tier's novelty scoring helps against a low call rate inside its own
  window, but that window is one day, so multi-day pacing evades it too.
references:
  - https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/
  - https://sysdig.com/blog/scarleteel-2-0/
  - https://github.com/andresriancho/enumerate-iam
  - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html
  - https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
author: '@NovaSky0x1'
date: 2026-08-09
tags:
  - attack.discovery
  - attack.t1580
  - attack.t1526
  - detection.maturity.hunt
logsource:
  product: aws
  service: cloudtrail
detection:
  # Distinct-namespace and ratio aggregation cannot be expressed in Sigma.
  # Use the Athena query above for production. This stub is a partial signal only.
  selection:
    errorCode:
      - 'AccessDenied'
      - 'AccessDeniedException'
      - 'UnauthorizedOperation'
      - 'Client.UnauthorizedOperation'
      - 'AuthorizationError'
      - 'AuthFailure'
  filter_chronic_principals:
    # PENDING: populate from the Research-tier baseline before production, and mirror the
    # same exclusions into the Athena CTE. Use session issuer ARNs (the role), not session
    # ARNs or ASIA* keys.
    # userIdentity.sessionContext.sessionIssuer.arn|contains:
    #   - 'role/aws-config-role'
    #   - 'role/backup-inventory-agent'
    userIdentity.arn: ''  # placeholder — remove and populate before production
  filter_service_principals:
    userIdentity.type: 'AWSService'
  condition: selection and not filter_chronic_principals and not filter_service_principals
falsepositives:
  - AWS Config rules and drift detection probing resources they cannot read — chronic, stable, allowlistable
  - Backup and inventory agents sweeping services outside their grant
  - Terraform or CloudFormation against a partially-provisioned role, especially on first apply
  - Newly deployed service accounts before policies are finalised — expect a burst, then silence
  - CSPM and security scanners operating with intentionally reduced permissions
level: medium

title: AWS Capability Confirmation — Novel Denial Breadth Followed by Success in a Denied Namespace
id: b6e09f34-25cd-4a71-8c02-71d4a3e5f9b8
status: experimental
description: >
  Fires when a principal is denied on (eventSource, eventName) pairs it has never been observed
  calling in 30 days, across three or more namespaces, and then succeeds in a namespace that
  just denied it — the clearest available evidence that an operator located an exploitable path.
  Both signals are heuristics rather than invariants. Permission enumeration does not require
  cross-namespace breadth when context or a readable policy narrows the search, and it does not
  require a denied-then-allowed transition, since an operator can stop after the denials or
  succeed on the first call attempted. What holds is that any capability not already known from
  context or a readable policy has to be tested through the relevant AWS API, and the AWS
  service returns an authorization outcome. CloudTrail sees the request only when the service
  and operation are supported, the relevant event category is selected, and that integration
  records denied requests.
  The baseline holds every (principal, eventSource, eventName) tuple observed in the preceding
  30 days, successful or failed. Restricting it to successes would make a routinely denied
  tuple — a Config rule probing a resource it can never read — look novel every day.
  Two keys, deliberately. The 30-day baseline uses a stable principal (session issuer ARN
  first, then caller ARN, principal ID, access key) so a role's history survives session
  turnover, while the denial-to-success correlation additionally joins on an actor key (access
  key first, since a temporary credential's ASIA* key is unique to one session, then caller ARN
  or principal ID, then the stable principal) so a denial in one session under a shared role
  cannot join a different session's success. Neither an ASIA* key nor an assumed-role ARN is a
  dependable long-term baseline identity: the key rotates per session, and the ARN embeds a
  RoleSessionName that repeats only when the caller reuses it.
  A novel denial means an authorization or authentication failure — AccessDenied,
  AccessDeniedException, UnauthorizedOperation, Client.UnauthorizedOperation,
  AuthorizationError, AuthFailure. Throttling, validation, and missing-resource errors carry no
  permission information and do not count toward the three-namespace breadth. Success is the
  absence of any error code, and errorcode is NULL on success in the AWS sample CloudTrail
  table, so it must be tested with IS NULL rather than = ''. Services reporting authorization
  failures inside responseElements rather than the top-level errorcode column are a blind spot
  for the novel-denial half and can also be misread as successes by that test, so normalize
  them into errorcode first.
  Fidelity rises sharply when the successful call is itself sensitive — CreateAccessKey,
  AttachUserPolicy, UpdateAssumeRolePolicy, GetSecretValue, or CreateSnapshot, all management
  events. s3:GetObject against a bucket this principal has never read is a strong signal too,
  but it is an object-level data event, present only where a data-event selector covers that
  bucket, so treat it as optional coverage and otherwise leave it out of the selection below.
  Baseline comparison and cross-event correlation cannot be expressed in Sigma, so the stub
  below covers only the sensitive-success half; deploy the query for production. It needs a
  CloudTrail trail delivering management events to S3 and an Athena table over that data —
  management events are selected by default when a trail is created; the S3 delivery and the
  table are not. Athena:
    WITH ct AS (                             -- both keys and the denial test applied once
      SELECT COALESCE(useridentity.sessioncontext.sessionissuer.arn,
                      useridentity.arn,
                      useridentity.principalid,
                      useridentity.accesskeyid)             AS principal,
             COALESCE(useridentity.accesskeyid,
                      useridentity.arn,
                      useridentity.principalid,
                      useridentity.sessioncontext.sessionissuer.arn) AS actor_key,
             useridentity.arn AS identity_arn, eventsource, eventname,
             sourceipaddress, errorcode,
             from_iso8601_timestamp(eventtime)              AS ts,
             COALESCE(errorcode, '') IN (
               'AccessDenied', 'AccessDeniedException', 'UnauthorizedOperation',
               'Client.UnauthorizedOperation', 'AuthorizationError', 'AuthFailure'
             )                                              AS auth_denied
      FROM cloudtrail_logs
      WHERE from_iso8601_timestamp(eventtime) > now() - INTERVAL '31' DAY
        AND useridentity.type <> 'AWSService'  -- matches filter_service_principals below
    ),
    baseline AS (            -- every tuple seen for this principal, successful or denied
      SELECT DISTINCT principal, eventsource, eventname, 1 AS seen
      FROM ct
      WHERE ts BETWEEN now() - INTERVAL '31' DAY AND now() - INTERVAL '1' DAY
    ),
    novel_denials AS (                       -- auth failures on never-before-seen tuples
      SELECT c.principal, c.actor_key, c.eventsource, min(c.ts) AS first_denial
      FROM ct c
      LEFT JOIN baseline b
        ON  b.principal = c.principal AND b.eventsource = c.eventsource
        AND b.eventname = c.eventname
      WHERE c.ts > now() - INTERVAL '1' DAY AND c.auth_denied AND b.seen IS NULL
      GROUP BY 1, 2, 3
    ),
    probing AS (                             -- actors novel-denied in >= 3 namespaces
      SELECT principal, actor_key FROM novel_denials
      GROUP BY 1, 2
      HAVING count(DISTINCT eventsource) >= 3
    )
    SELECT s.ts, s.identity_arn, s.principal, s.actor_key, s.eventsource, s.eventname,
           s.sourceipaddress, d.first_denial
    FROM ct s
    JOIN novel_denials d          -- same actor, same namespace that denied it
      ON  d.principal = s.principal AND d.actor_key = s.actor_key
      AND d.eventsource = s.eventsource
    JOIN probing p
      ON  p.principal = s.principal AND p.actor_key = s.actor_key
    WHERE s.ts > now() - INTERVAL '1' DAY
      AND s.ts > d.first_denial              -- success after the denial
      AND (s.errorcode IS NULL OR s.errorcode = '')
    ORDER BY s.ts
  Requires a stable 30-day CloudTrail history; expect elevated false positives in younger
  environments or right after a large deployment change. Novelty helps against a low call rate
  inside the observation window, but that window is one day here, so multi-day pacing evades it
  unless the window is widened at query cost. Apply the environment's chronic and
  legitimate-principal allowlist inside the Athena CTE before production, since
  filter_legit_software below constrains only the Sigma stub. Avoid keying on userAgent.
references:
  - https://unit42.paloaltonetworks.com/large-scale-cloud-extortion-operation/
  - https://sysdig.com/blog/scarleteel-2-0/
  - https://github.com/RhinoSecurityLabs/pacu
  - https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html
  - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html
  - https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
author: '@NovaSky0x1'
date: 2026-08-09
tags:
  - attack.discovery
  - attack.t1580
  - attack.t1526
  - detection.maturity.analyst
logsource:
  product: aws
  service: cloudtrail
detection:
  # Baseline anti-join and denied-to-allowed correlation cannot be expressed in Sigma.
  # Use the Athena query above for production. This stub covers the sensitive-success
  # half only and must be correlated with the novel-denial condition to reach the
  # stated fidelity. Every eventName below is a management event; adding data-event
  # names such as GetObject requires an S3 object-level data-event selector.
  selection_sensitive_success:
    eventName:
      - 'CreateAccessKey'
      - 'AttachUserPolicy'
      - 'AttachRolePolicy'
      - 'PutUserPolicy'
      - 'UpdateAssumeRolePolicy'
      - 'CreateLoginProfile'
      - 'UpdateLoginProfile'
      - 'GetSecretValue'
      - 'CreateSnapshot'
      - 'ModifySnapshotAttribute'
  filter_failed:
    errorCode|exists: true
  filter_service_principals:
    userIdentity.type: 'AWSService'
  filter_legit_software:
    # PENDING: populate with the approved administrative and automation principals that
    # legitimately call these APIs — IaC deployment roles, break-glass roles, IAM
    # provisioning pipelines, backup services taking snapshots — and mirror the same
    # exclusions into the Athena CTE. Key on the session issuer ARN (the role), not on
    # session ARNs or ASIA* access keys.
    # userIdentity.sessionContext.sessionIssuer.arn|contains:
    #   - 'role/terraform-deploy'
    #   - 'role/iam-provisioning-pipeline'
    userIdentity.arn: ''  # placeholder — remove and populate before production
  condition: selection_sensitive_success and not filter_failed and not filter_service_principals and not filter_legit_software
falsepositives:
  - Break-glass or IR administrators exploring an unfamiliar account under legitimate authority
  - Newly onboarded engineers whose principal has no 30-day baseline yet
  - Migration and refactoring work legitimately calling APIs a principal has never called
  - Penetration tests and red-team engagements — check the engagement window before escalating
  - Environments with less than 30 days of CloudTrail history
level: high

title: LSASS Memory Access by Non-System Process (Research Baseline)
id: c08fffe8-ab3c-4e16-abd8-61e648faf95b
status: experimental
description: >
  Detects any non-core-OS process opening a handle to lsass.exe with memory-read
  access rights. This research-level rule establishes a baseline of all LSASS
  access in the environment (AV/EDR products, WerFault, Task Manager, monitoring
  tools, and actual attacks) all appear. Run this for one week to build an
  environment-specific allowlist of legitimate LSASS accessors before tuning to
  Hunt level. The chokepoint is invariant: every credential dumping tool (Mimikatz,
  nanodump, comsvcs.dll, ProcDump, HandleKatz, direct syscall loaders) must obtain
  a kernel handle to lsass.exe. Sysmon Event ID 10 captures this regardless of the
  API path used.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
  - https://github.com/fortra/nanodump
author: "@NovaSky0x1"
date: 2026/03/30
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.t1003
  - detection.maturity.research
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'  # PROCESS_ALL_ACCESS
      - '0x1010'    # PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION (Mimikatz classic)
      - '0x1410'    # PROCESS_VM_READ | PROCESS_QUERY_INFORMATION | PROCESS_QUERY_LIMITED_INFORMATION
      - '0x0810'    # PROCESS_VM_READ | PROCESS_QUERY_INFORMATION (nanodump)
      - '0x1038'    # PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION
      - '0x1438'    # PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_QUERY_INFORMATION
      - '0x0040'    # PROCESS_DUP_HANDLE (handle duplication, HandleKatz, nanodump duphandle mode)
      - '0x0010'    # PROCESS_VM_READ alone
  filter_os_core:
    SourceImage|startswith:
      - 'C:\Windows\System32\csrss.exe'
      - 'C:\Windows\System32\lsass.exe'
      - 'C:\Windows\System32\services.exe'
      - 'C:\Windows\System32\svchost.exe'
      - 'C:\Windows\System32\wininit.exe'
      - 'C:\Windows\System32\lsaiso.exe'
      - 'C:\Windows\System32\smss.exe'
      - 'C:\Windows\System32\winlogon.exe'
  condition: selection and not filter_os_core
falsepositives:
  - Antivirus and EDR agents performing routine LSASS inspection (MsMpEng.exe, SentinelAgent.exe, CSFalconService.exe, CylanceSvc.exe)
  - WerFault.exe collecting crash diagnostics for lsass.exe
  - Task Manager (taskmgr.exe) when an administrator manually creates a process dump
  - Performance and diagnostic tools (procexp64.exe, procmon64.exe, perfmon.exe)
  - WMI provider host (wmiprvse.exe) during certain management queries
  - Windows Defender Advanced Threat Protection sensor (MsSense.exe)
level: informational

title: LSASS Access with Suspicious CallTrace or Non-Standard Source Path
id: 3d932b09-9d74-428d-bb0f-9368b28c6bb9
status: experimental
description: >
  Hunt-level detection for LSASS credential dumping. Adds behavioral context to the
  research baseline to separate attack tooling from legitimate security products.
  CallTrace analysis reveals the mechanism used to read LSASS memory: dbgcore.dll
  and dbghelp.dll indicate MiniDumpWriteDump (ProcDump, comsvcs.dll, custom dump
  tools), while UNKNOWN indicates direct syscalls or ntdll unhooking. Legitimate
  AV/EDR products produce clean API call stacks without these indicators. Source
  path filtering captures tools staged in user-writable directories; attack tools
  land in Temp, Downloads, AppData while legitimate security products run from
  Program Files. This rule excludes known AV/EDR paths and WerFault to reduce the
  research baseline to actionable hunt leads.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://github.com/fortra/nanodump
  - https://github.com/codewhitesec/HandleKatz
  - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
  - https://www.microsoft.com/en-us/security/blog/2022/10/05/detecting-and-preventing-lsass-credential-dumping-attacks/
author: "@NovaSky0x1"
date: 2026/03/30
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.t1003
  - detection.maturity.hunt
logsource:
  category: process_access
  product: windows
detection:
  selection_lsass_access:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'
      - '0x1010'
      - '0x1410'
      - '0x0810'
      - '0x1038'
      - '0x1438'
      - '0x0040'
  selection_suspicious_calltrace:
    CallTrace|contains:
      - 'dbgcore.dll'
      - 'dbghelp.dll'
      - 'UNKNOWN'
  selection_suspicious_source_path:
    SourceImage|contains:
      - '\Temp\'
      - '\tmp\'
      - '\Downloads\'
      - '\AppData\'
      - '\Users\Public\'
      - '\ProgramData\'
      - '\Desktop\'
      - '\Recycle'
  filter_os_core:
    SourceImage|startswith:
      - 'C:\Windows\System32\csrss.exe'
      - 'C:\Windows\System32\lsass.exe'
      - 'C:\Windows\System32\services.exe'
      - 'C:\Windows\System32\svchost.exe'
      - 'C:\Windows\System32\wininit.exe'
      - 'C:\Windows\System32\lsaiso.exe'
      - 'C:\Windows\System32\smss.exe'
      - 'C:\Windows\System32\winlogon.exe'
  filter_security_products:
    SourceImage|contains:
      - '\Program Files\Windows Defender\'
      - '\Program Files\Microsoft Security Client\'
      - '\Program Files\CrowdStrike\'
      - '\Program Files\SentinelOne\'
      - '\Program Files\Cylance\'
      - '\Program Files\Carbon Black\'
      - '\Program Files\Sophos\'
      - '\Program Files\ESET\'
      - '\Program Files\Kaspersky\'
      - '\Program Files\Trend Micro\'
      - '\Program Files (x86)\Trend Micro\'
      - '\Program Files\Bitdefender\'
      - '\Program Files\Malwarebytes\'
      - '\Program Files\Palo Alto Networks\'
  filter_werfault:
    SourceImage|endswith: '\WerFault.exe'
  condition: >
    selection_lsass_access
    and (selection_suspicious_calltrace or selection_suspicious_source_path)
    and not (filter_os_core or filter_security_products or filter_werfault)
falsepositives:
  - IT administrators running portable diagnostic tools from non-standard paths that inspect LSASS
  - Custom monitoring agents installed outside Program Files that query process information
  - Authorized penetration testing tools during sanctioned engagements
  - Third-party security products not in the exclusion list (requires environment-specific tuning)
level: medium

title: 'LSASS Credential Dump: Non-Standard Process with Dump Mechanism and Suspicious Access Rights'
id: 2abc46f9-9c70-47cf-932e-fe803e06f5c7
status: experimental
description: >
  High-fidelity detection for LSASS credential dumping. Detects a non-standard process
  (outside System32 and Program Files) opening a handle to lsass.exe with credential-dump
  access rights where the CallTrace reveals MiniDumpWriteDump usage (dbgcore.dll,
  dbghelp.dll) or direct syscall evasion (UNKNOWN). This triple-AND (suspicious access
  mask, dump mechanism fingerprint, and non-standard source path) eliminates virtually
  all legitimate LSASS access. AV/EDR products run from Program Files with clean
  CallTraces; attack tools run from temp paths with dbgcore.dll or UNKNOWN stacks.
  A secondary selection covers handle duplication (GrantedAccess 0x0040) from non-standard
  paths, the HandleKatz and nanodump evasion technique that uses NtDuplicateObject to
  clone an existing LSASS handle instead of requesting a direct read handle. This
  GrantedAccess value targeting lsass.exe from outside System32/Program Files has no
  legitimate use case. Supplementary detections for comsvcs.dll MiniDump LOLBin
  (process_creation), SSP injection (image_load), and dump file artifacts (file_event)
  should be implemented as companion rules at the SIEM level for coverage across event
  types. If this rule fires, assume credential compromise and begin host isolation.
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://github.com/fortra/nanodump
  - https://github.com/codewhitesec/HandleKatz
  - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
  - https://www.microsoft.com/en-us/security/blog/2022/10/05/detecting-and-preventing-lsass-credential-dumping-attacks/
  - https://unit42.paloaltonetworks.com/mimikatz-overview/
author: "@NovaSky0x1"
date: 2026/03/30
tags:
  - attack.credential_access
  - attack.t1003.001
  - attack.t1003
  - detection.maturity.analyst
logsource:
  category: process_access
  product: windows
detection:
  selection_lsass_target:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'
      - '0x1010'
      - '0x1410'
      - '0x0810'
      - '0x1038'
      - '0x1438'
  selection_dump_mechanism:
    CallTrace|contains:
      - 'dbgcore.dll'
      - 'dbghelp.dll'
      - 'UNKNOWN'
  selection_nonstandard_source:
    SourceImage|not|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
  selection_handle_duplication:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess: '0x0040'
    SourceImage|not|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
  filter_os_core:
    SourceImage|startswith:
      - 'C:\Windows\System32\csrss.exe'
      - 'C:\Windows\System32\lsass.exe'
      - 'C:\Windows\System32\services.exe'
      - 'C:\Windows\System32\svchost.exe'
      - 'C:\Windows\System32\wininit.exe'
      - 'C:\Windows\System32\lsaiso.exe'
      - 'C:\Windows\System32\smss.exe'
      - 'C:\Windows\System32\winlogon.exe'
  condition: >
    (selection_lsass_target and selection_dump_mechanism and selection_nonstandard_source and not filter_os_core)
    or selection_handle_duplication
falsepositives:
  - Portable diagnostic tools run by administrators from non-standard paths that access LSASS (should be blocked by policy in hardened environments)
  - Authorized red team or penetration testing tools during sanctioned engagements
level: high