Account created with a name mimicking a trusted or default account

Siemphony@siemphonylowT1036.010unverified

AN1077's real ask is a Levenshtein or visual-distance comparison against MonitoredAccountList — lib/sigma has no string-distance function and no lookup-table construct, so neither knob can be computed here. What survives is literal-string matching against the example names MITRE itself supplies in two places: the technique's own prose, which names "admin", "help" and "root" as the generic, trustworthy names adversaries reach for, and the analytic's own description, which names three concrete near-miss patterns verbatim — "admin1", "adm1n" and "backup_help". "backup" and "service" are added to the same contains list because the technique text separately calls out masquerading as accounts "associated with legitimate software, data backups, or container cluster management" — still MITRE's framing, not this pipeline's invention, just generalised from prose to a substring. This is a precision trade the rule accepts on purpose: `TargetUserName|contains: 'admin'` also matches any ordinary account whose name happens to contain that substring, and MITRE's own MonitoredAccountList knob is the intended fix — a real deployment must supply the set of legitimate accounts this pipeline has no way to know, so the false-positive list below is long and the level is set accordingly. TimeWindow, which would raise severity only when creation follows a discovery or deletion event, needs a cross-event join this corpus cannot express, so every match here carries the same weight regardless of what preceded it. The Linux leg, AN1078, is not attempted in this file: lib/sigma renders one logsource per rule, and 4720 is the cleaner single-event signal of the two. For the record, its two auditd legs are real but weaker — the account name lands in EXECVE's `a1` (or later, depending on options placed before it) rather than at a fixed position, the same positional uncertainty already accepted for systemctl and hping in this corpus's T1569.003 and T1499.001 rules — and its third leg, {product: linux, service: osquery} listing /etc/passwd, has no standardised Sigma field vocabulary anywhere in this corpus. Prerequisite: 4720 is written by the Audit User Account Management subcategory (Success), on by default and in both the Microsoft and CIS baselines, but a host whose audit policy was rewritten can still be blind — confirm with auditpol rather than assuming. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0383, 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.

SecurityEvent| where (EventID == 4720 and (TargetUserName contains "admin" or TargetUserName contains "help" or TargetUserName contains "root" or TargetUserName contains "backup" or TargetUserName contains "service" or TargetUserName contains "adm1n" or TargetUserName contains "backup_help"))

Splunk · SPL

Run this as a search.

index=* (EventID="4720" AND (TargetUserName="*admin*" OR TargetUserName="*help*" OR TargetUserName="*root*" OR TargetUserName="*backup*" OR TargetUserName="*service*" OR TargetUserName="*adm1n*" OR TargetUserName="*backup_help*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 4720 AND (TO_LOWER(TargetUserName) LIKE "*admin*" OR TO_LOWER(TargetUserName) LIKE "*help*" OR TO_LOWER(TargetUserName) LIKE "*root*" OR TO_LOWER(TargetUserName) LIKE "*backup*" OR TO_LOWER(TargetUserName) LIKE "*service*" OR TO_LOWER(TargetUserName) LIKE "*adm1n*" OR TO_LOWER(TargetUserName) LIKE "*backup_help*"))

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="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4720$</field>    <field name="TargetUserName" type="pcre2">(?i)(admin|help|root|backup|service|adm1n|backup_help)</field>    <description>Account created with a name mimicking a trusted or default account</description>    <mitre>      <id>T1036.010</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: low
Category: masquerading
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 6e8509b2-8e45-4fb5-a4fc-e78834dcf685

ATT&CKT1036.010

T1036.010Masquerade Account Name

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.

Lessonmasquerading

masqueradingAI draft — unreviewed

01 · What this rule detects

Creation of a Windows local account (EventID 4720) whose TargetUserName contains a substring drawn from names MITRE itself associates with masquerading: admin, help, root, backup, service, adm1n, backup_help. AN1077 asks for a Levenshtein or visual-distance comparison against a MonitoredAccountList; lib/sigma has neither a string-distance function nor a lookup table, so this rule falls back to literal substring matching on the example names MITRE's own technique prose and analytic description supply.

02 · Telemetry you need

windows/security, EventID 4720. Written by the Audit User Account Management subcategory (Success), on by default and present in both the Microsoft and CIS baselines — but a host whose audit policy has been rewritten can still be blind, so confirm with auditpol rather than assuming.

03 · How the logic works

condition: selection_account_created and selection_trusted_name_pattern. selection_account_created gates on EventID: 4720. selection_trusted_name_pattern requires TargetUserName|contains one of the seven strings above — five taken almost verbatim from the technique's own text (which names "admin", "help" and "root" as the generic names adversaries reach for) and the analytic's description (which names "admin1", "adm1n" and "backup_help" as concrete near-misses), plus "backup" and "service" generalised from the technique's line about masquerading as accounts "associated with legitimate software, data backups, or container cluster management." None of the seven values are this pipeline's invention, but the list itself — which strings to keep, which to drop — is the pipeline's editorial choice, not a field copied from the brief. This is a precision trade taken on purpose: contains: 'admin' also matches any ordinary account whose name happens to contain that substring. MITRE's own fix is the MonitoredAccountList knob — a real deployment supplying its own set of legitimate accounts — which this rule cannot compute, so the false-positive list is long by design. The TimeWindow knob, which would raise severity only when creation follows a discovery or deletion event, needs a cross-event join lib/sigma cannot express, so every match here carries equal weight regardless of what preceded it. The reviewer's one substantive finding: AN1077 also covers accounts renamed to a mimicking name (EventID 4781, NewTargetUserName), and this rule only catches creation. That gap is real and currently undisclosed in the rule's own description — treat the rule as creation-only.

04 · Common false positives

The rule's own false-positive list names the loudest source directly: role- based helpdesk and IT naming conventions — helpdesk_l2, it_admin_jdoe, svc_backup — created by ordinary onboarding, not an adversary; this is why level is low. Also expected: installer-created service accounts naming themselves after backup or monitoring agents; documented break-glass accounts such as admin_breakglass; and training or lab environments that create a helpdesk- or admin-named account repeatedly as part of an exercise.

05 · Detection maturity

tier_1: . UNVERIFIED — derived from DET0383 and never run against real 4720 output. The substring list is untested against any actual estate's naming conventions; before trusting a hit, confirm the account is not a documented break-glass, installer, or training artefact, and be aware the rule is silent on renames until a 4781 leg is added.

Tuning & false positivesexperimental · 4 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

Supply a real MonitoredAccountList — the set of accounts this substring match cannot distinguish from noise — and suppress on it. Exclude known helpdesk and installer naming patterns by convention rather than by individual name. If rename coverage matters, add a second rule against 4781 filtered on NewTargetUserName, since that field, not TargetUserName, is what the rename event carries.

Declared by the author

Routine IT and helpdesk account provisioning using role-based naming that happens to contain one of these substrings — accounts such as helpdesk_l2, it_admin_jdoe, svc_backup or backup_svc_sql created by ordinary onboarding, not by an adversary. On an estate with such a naming convention this is the loudest source by a wide margin and is why the level here is low rather than high.
Software and appliance installers creating a dedicated local service account as part of setup — backup agents, monitoring agents, and database engines routinely name their own service account with 'service', 'admin' or 'backup' in it, on every host the package is deployed to.
Documented break-glass or emergency-access accounts deliberately named to resemble a built-in, such as admin_breakglass or local_admin_dr, created once and then left dormant until an actual outage.
Training, lab and onboarding environments where a demo or coursework account named admin, helpdesk or similar is created intentionally and repeatedly as part of the exercise.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 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 T1036.010, evaluated against their — events.

Share this rule

/u/siemphony/6e8509b2-8e45-4fb5-a4fc-e78834dcf685

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.

Account created with a name mimicking a trusted or default account

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it