Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphony’s repertoire

Account created with a name mimicking a trusted or default account

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 detection

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

title: Account created with a name mimicking a trusted or default accountid: 6e8509b2-8e45-4fb5-a4fc-e78834dcf685status: experimentaldescription: |  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.references:  - https://attack.mitre.org/techniques/T1036/010  - https://attack.mitre.org/detectionstrategies/DET0383author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-18tags:  - attack.defense-evasion  - attack.t1036.010logsource:  product: windows  service: securitydetection:  selection_account_created:    EventID: 4720  selection_trusted_name_pattern:    TargetUserName|contains:      - 'admin'      - 'help'      - 'root'      - 'backup'      - 'service'      - 'adm1n'      - 'backup_help'  condition: selection_account_created and selection_trusted_name_patternfalsepositives:  - "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."level: low

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(winlog.event_data.TargetUserName) LIKE "*admin*" OR TO_LOWER(winlog.event_data.TargetUserName) LIKE "*help*" OR TO_LOWER(winlog.event_data.TargetUserName) LIKE "*root*" OR TO_LOWER(winlog.event_data.TargetUserName) LIKE "*backup*" OR TO_LOWER(winlog.event_data.TargetUserName) LIKE "*service*" OR TO_LOWER(winlog.event_data.TargetUserName) LIKE "*adm1n*" OR TO_LOWER(winlog.event_data.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>

Verdicts · reactions · comments

Community

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

Log in to react
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.

Log in to report a verdict.

Log in to join the discussion.

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