Query: alert when Detects changes to "DsrmAdminLogonBehavior" registry value. During a Domain Controller (DC) promotion, administrators cr
Matching passage: Sigma rule: Detects changes to "DsrmAdminLogonBehavior" registry value. During a Domain Controller (DC) promotion, administrators cr. Logsource: windows / registry_set. Rule: title: Directory Service Restore Mode(DSRM) Registry Value Tampering id: b61e87c0-50db-4b2e-8986-6a2be94b33b0 related: - id: 53ad8e36-f573-46bf-97e4-15ba5bf4bb51 type: similar status: test description: 'Detects changes to "DsrmAdminLogonBehavior" registry value. During a Domain Controller (DC) promotion, administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes. The DSRM account is an “Administrator” account that logs in with the DSRM mode when the server is booting up to restore AD backups or recover the server from a failure. Attackers could abuse DSRM account to maintain their persistence and access to the organization''s Active Directory. If the "DsrmAdminLogonBehavior" value is set to "0", the administrator account can only be used if the DC starts in DSRM. If the "DsrmAdminLogonBehavior" value is set to "1", the administrator account can only be used if the local AD DS service is stopped. If the "DsrmAdminLogonBehavior" value is set to "2", the administrator account can always be used. ' references: - https://adsecurity.org/?p=1785 - https://www.sentinelone.com/blog/detecting-dsrm-account-misconfigurations/ - https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/dsrm-credentials author: Nischal Khadgi date: 2024-07-11 tags: - attack.credential-access - attack.persistence - attack.defense-impairment - attack.t1556 logsource: category: registry_set product: windows detection: selection: TargetObject|endswith: \Control\Lsa\DsrmAdminLogonBehavior filter_main_default_value: Details: DWORD (0x00000000) condition: selection and not 1 of filter_main_* falsepositives: - Unknown level: high
Near-miss passage: Sigma rule: Detects deployments of pods within the kube-system namespace, which could be intended to imitate system pods. System pod. Logsource: kubernetes / application / audit. Rule: title: Creation Of Pod In System Namespace id: a80d927d-ac6e-443f-a867-e8d6e3897318 status: test description: 'Detects deployments of pods within the kube-system namespace, which could be intended to imitate system pods. System pods, created by controllers such as Deployments or DaemonSets have random suffixes in their names. Attackers can use this fact and name their backdoor pods as if they were created by these controllers to avoid detection. Deployment of such a backdoor container e.g. named kube-proxy-bv61v, could be attempted in the kube-system namespace alongside the other administrative containers. ' references: - https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Pod%20or%20container%20name%20similarily/ author: Leo Tsaousis (@laripping) date: 2024-03-26 tags: - attack.stealth - attack.t1036.005 logsource: category: application product: kubernetes service: audit detection: selection: verb: create objectRef.resource: pods objectRef.namespace: kube-system condition: selection falsepositives: - System components such as daemon-set-controller and kube-scheduler also create pods in the kube-system namespace level: medium