PowerShell enables reversible encryption for an AD account

Siemphony@siemphonymediumT1556.005unverified

AN1621 bundles a Group Policy edit, "suspicious PowerShell commands modifying AD user properties," and the resulting account-property change into one multi-event correlation lib/sigma cannot express. This rule takes the middle piece on its own: PowerShell Script Block Logging (EventID 4104) capturing a call to `Set-ADUser` — the ActiveDirectory module's documented cmdlet for the per-account `AllowReversiblePasswordEncryption` property — together with the literal property name and an explicit `$true` value. That property name is this rule's own choice, not MITRE's `SuspiciousCmdletList` populated with a value, but it is the only PowerShell-native path to the exact property this technique describes: the AD attribute backing `AllowReversiblePasswordEncryption` is a UserAccountControl bit (ENCRYPTED_TEXT_PWD_ALLOWED), and `Set-ADUser` is the documented way to set it without hand-editing UAC bits directly. Requiring `$true` in the same block (rather than the cmdlet and property name alone) is a deliberate narrowing beyond what MITRE's knob asks for: it excludes a script that sets the property to `$false` — reverting or auditing the setting, not enabling it — at the cost of also missing `-AllowReversiblePasswordEncryption:$True` written with a different value token a future script might construct dynamically (a variable holding the boolean rather than the literal). MITRE's other two sources are not attempted. Security 4739 ("Domain Policy was changed") is the closest event for the domain-wide GPO form of this setting, but the specific flag this technique cares about (DOMAIN_PASSWORD_STORE_CLEARTEXT) is one bit inside the combined `PasswordProperties` bitmask on that event, and lib/sigma's allowed modifiers — contains, startswith, endswith, re, all, windash — have no bitwise-AND equivalent, so no honest selector on that field can isolate this flag from the other nine unrelated password/lockout properties the same event reports; matching bare `EventID: 4739` would fire on any domain password-policy edit at all, which is not what this analytic asks for. Sysmon EventID 1 process_creation is not attempted either: a GUI edit through Group Policy Management or Active Directory Users and Computers leaves no command line carrying the property name at all, so the only reliable command-line-visible expression of this technique is the PowerShell cmdlet already covered here. Prerequisite: Script Block Logging is off in a default install and in the MS/CIS baselines; without it the PowerShell channel carries no ScriptBlockText and this rule returns nothing. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0589, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

Event| where (((EventID == 4104 and ScriptBlockText contains "Set-ADUser") and ScriptBlockText contains "AllowReversiblePasswordEncryption") and ScriptBlockText contains "$true")

Splunk · SPL

Run this as a search.

index=* (((EventID="4104" AND ScriptBlockText="*Set-ADUser*") AND ScriptBlockText="*AllowReversiblePasswordEncryption*") AND ScriptBlockText="*$true*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((event.code == 4104 AND TO_LOWER(powershell.file.script_block_text) LIKE "*set-aduser*") AND TO_LOWER(powershell.file.script_block_text) LIKE "*allowreversiblepasswordencryption*") AND TO_LOWER(powershell.file.script_block_text) LIKE "*$true*")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4104$</field>    <field name="ScriptBlockText" type="pcre2">(?i)Set-ADUser</field>    <field name="ScriptBlockText" type="pcre2">(?i)AllowReversiblePasswordEncryption</field>    <field name="ScriptBlockText" type="pcre2">(?i)\$true</field>    <description>PowerShell enables reversible encryption for an AD account</description>    <mitre>      <id>T1556.005</id>    </mitre>  </rule></group>

At a glance

Logsource: powershell / windows
Level: medium
Category: account_manipulation
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 47abc99a-264e-49c9-ac17-187aabc2a1fd

ATT&CKT1556.005

T1556.005Reversible Encryption

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

02 · Telemetry you need

{product: windows, service: powershell}, EventID 4104 (Script Block Logging). This is off in a default install and in the MS/CIS baselines — without it the PowerShell channel carries no ScriptBlockText and the rule returns nothing, which reads as quiet but means the sensor was never on.

03 · How the logic works

Four selection blocks, all ANDed: selection_event pins EventID: 4104; selection_cmdlet requires ScriptBlockText|contains: 'Set-ADUser'; selection_property requires AllowReversiblePasswordEncryption in the same block; selection_enable requires the literal $true. The property name is the rule's own choice, not a direct instance of MITRE's SuspiciousCmdletList knob populated with a value — but the description argues it's the only PowerShell-native path to this exact property, since the underlying UAC bit has no other documented cmdlet-level setter. Requiring $true in the same block, rather than stopping at cmdlet-plus-property, is a deliberate narrowing beyond what MITRE's knob calls for. It buys precision — a script that sets the property back to $false, reverting or auditing the setting, does not match — at a real cost: a script that constructs the value dynamically (a variable holding the boolean rather than the literal token $true) evades this selector entirely. MITRE's other two AN1621 sources are declined, not just skipped. Security 4739 ("Domain Policy was changed") is the closest event for the domain-wide GPO form of this setting, but the specific flag (DOMAIN_PASSWORD_STORE_CLEARTEXT) is one bit inside a combined PasswordProperties bitmask, and lib/sigma has no bitwise-AND modifier to isolate it from the other nine unrelated password/lockout properties on that same event — matching bare EventID: 4739 would fire on any domain password-policy edit, not this one. Sysmon process_creation is declined too: a GUI edit through Group Policy Management or ADUC leaves no command line carrying the property name at all, so the PowerShell cmdlet path covered here is the only reliable command-line-visible expression of the technique.

04 · Common false positives

level: medium. The loudest listed false positive is legacy application onboarding: administrators deliberately enabling reversible encryption for a service account because a RADIUS/CHAP, older client, or digest-auth integration genuinely requires it — Microsoft's own documentation describes this as a supported legacy-compatibility scenario, not a misconfiguration. Second, identity-governance and provisioning automation (an HR joiner/mover pipeline, an IAM connector) that sets a wide range of ADUser boolean properties in one templated script can include this property among many never intended to actually land as $true in production. Third, security assessment and red/purple-team tooling that toggles the property on and back off to verify detective controls, rather than to establish access.

05 · Detection maturity

tier_1: .** Machine-derived from a MITRE scaffold with no query logic, never executed against real Script Block Logging output. Reaching
tier_2: means running it against an environment where 4104 is actually enabled, confirming the legacy-onboarding volume, and building the allowlist before this rule is trusted for anything beyond triage.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Cross-reference hits against a known allowlist of legacy-integration service accounts before alerting — that first false positive is structural, not incidental, and will recur on every onboarding of that kind. Watch for the $false follow-up within the same session as a strong signal the toggle was an audit, not an attack. Because this rule requires the literal $true token, treat a Set-ADUser+property hit without it as a coverage gap, not a clean result — build a companion selector for variable-driven value assignment if this becomes a priority.

Declared by the author

Legacy application onboarding: administrators deliberately enabling reversible encryption for a specific service account because a RADIUS/CHAP, older Mac OS X client, or digest-authentication integration requires it, exactly the supported legacy-compatibility scenario Microsoft's own documentation describes for this property.
Identity-governance and account-provisioning automation (an HR-driven joiner/mover/leaver pipeline, an IAM connector script) that sets a wide range of ADUser boolean properties in a single templated script, where a generic property-setting loop or example script includes AllowReversiblePasswordEncryption among many other flags it was never intended to actually flip to true in production.
Security-assessment and compliance tooling (a PCI/HIPAA account-hardening audit script, a red-team or purple-team engagement script) that intentionally toggles the property to $true and back to $false to verify detective controls or produce evidence of the setting's effect, rather than to establish persistent access.

Noise check0 of 4 fired

Fires on none of the 4 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 4 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1556.005, evaluated against their — events.

Share this rule

/u/siemphony/47abc99a-264e-49c9-ac17-187aabc2a1fd

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

PowerShell enables reversible encryption for an AD account

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it