Login page file written under a portal web root

Siemphony@siemphonymediumT1056.003unverified

AN1321 describes tampering with an IIS, OWA or SharePoint login page, and Sysmon File Creation — which also fires when an existing file is overwritten — is the one log source in this brief that carries both halves of it: the path on `TargetFilename` and the writing process on `Image`, which is what MITRE's ProcessName knob needs. Path alone is not enough here (a write anywhere under a web root is already covered as defacement in T1491.001), so the selection requires a portal or Exchange/SharePoint path *and* a filename that is the authentication page itself. The Linux leg AN1320 was not taken: its auditd source splits the path onto a PATH record and the writing process onto a separate SYSCALL record, so the "correlate the edit with a web shell" half of the analytic cannot be built in one selection. Prerequisite: Sysmon must be installed *and* its FileCreate rules must include the web root — several widely used baseline configurations exclude high-churn web directories, so no matches here can mean the directory is not being watched rather than that nothing was written. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0480, 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.

DeviceFileEvents| where (((FolderPath contains "\\inetpub\\wwwroot\\" or FolderPath contains "\\ClientAccess\\Owa\\" or FolderPath contains "\\FrontEnd\\HttpProxy\\owa\\" or FolderPath contains "\\Web Server Extensions\\") and (FolderPath endswith "login.aspx" or FolderPath endswith "logon.aspx" or FolderPath endswith "signin.aspx" or FolderPath endswith "default.aspx" or FolderPath endswith "auth.aspx" or FolderPath endswith "login.asp" or FolderPath endswith "login.php" or FolderPath endswith "login.js" or FolderPath endswith "logon.js" or FolderPath endswith "login.html" or FolderPath endswith "login.htm")) and not ((InitiatingProcessFolderPath endswith "\\msdeploy.exe" or InitiatingProcessFolderPath endswith "\\TrustedInstaller.exe" or InitiatingProcessFolderPath endswith "\\TiWorker.exe")))

Splunk · SPL

Run this as a search.

index=* (((TargetFilename="*\\inetpub\\wwwroot\\*" OR TargetFilename="*\\ClientAccess\\Owa\\*" OR TargetFilename="*\\FrontEnd\\HttpProxy\\owa\\*" OR TargetFilename="*\\Web Server Extensions\\*") AND (TargetFilename="*login.aspx" OR TargetFilename="*logon.aspx" OR TargetFilename="*signin.aspx" OR TargetFilename="*default.aspx" OR TargetFilename="*auth.aspx" OR TargetFilename="*login.asp" OR TargetFilename="*login.php" OR TargetFilename="*login.js" OR TargetFilename="*logon.js" OR TargetFilename="*login.html" OR TargetFilename="*login.htm")) AND NOT ((Image="*\\msdeploy.exe" OR Image="*\\TrustedInstaller.exe" OR Image="*\\TiWorker.exe")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(file.path) LIKE "*\\\\inetpub\\\\wwwroot\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\clientaccess\\\\owa\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\frontend\\\\httpproxy\\\\owa\\\\*" OR TO_LOWER(file.path) LIKE "*\\\\web server extensions\\\\*") AND (TO_LOWER(file.path) LIKE "*login.aspx" OR TO_LOWER(file.path) LIKE "*logon.aspx" OR TO_LOWER(file.path) LIKE "*signin.aspx" OR TO_LOWER(file.path) LIKE "*default.aspx" OR TO_LOWER(file.path) LIKE "*auth.aspx" OR TO_LOWER(file.path) LIKE "*login.asp" OR TO_LOWER(file.path) LIKE "*login.php" OR TO_LOWER(file.path) LIKE "*login.js" OR TO_LOWER(file.path) LIKE "*logon.js" OR TO_LOWER(file.path) LIKE "*login.html" OR TO_LOWER(file.path) LIKE "*login.htm")) AND NOT ((TO_LOWER(process.executable) LIKE "*\\\\msdeploy.exe" OR TO_LOWER(process.executable) LIKE "*\\\\trustedinstaller.exe" OR TO_LOWER(process.executable) LIKE "*\\\\tiworker.exe")))

Wazuh · XML rule

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

<group name="sigma,windows,file_event,">  <!-- 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="TargetFilename" type="pcre2">(?i)(\\inetpub\\wwwroot\\|\\ClientAccess\\Owa\\|\\FrontEnd\\HttpProxy\\owa\\|\\Web Server Extensions\\)</field>    <field name="TargetFilename" type="pcre2">(?i)(login\.aspx$|logon\.aspx$|signin\.aspx$|default\.aspx$|auth\.aspx$|login\.asp$|login\.php$|login\.js$|logon\.js$|login\.html$|login\.htm$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(\\msdeploy\.exe$|\\TrustedInstaller\.exe$|\\TiWorker\.exe$)</field>    <description>Login page file written under a portal web root</description>    <mitre>      <id>T1056.003</id>    </mitre>  </rule></group>

At a glance

Logsource: file_event / windows
Level: medium
Category: process_injection
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 2a555dba-a047-4687-bf82-6478bc5e5cc0

ATT&CKT1056.003

T1056.003Web Portal Capture

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.

Lessonprocess injection

process injectionAI draft — unreviewed

01 · What this rule detects

AN1321 describes tampering with an IIS, OWA or SharePoint login page — script injected into the authentication page so that submitted credentials are copied out as users sign in. The rule written here catches one narrow signature of that: a file whose name is an authentication page being written under a portal web root by a process other than a known servicing binary. It is a write-side rule, not a content rule. Nothing inspects what landed in the file.

02 · Telemetry you need

Sysmon File Creation (EventID 11), mapped to Sigma's file_event/windows logsource — the only source AN1321 offers. Two prerequisites decide whether this ever returns a row. Sysmon must be installed and its FileCreate rules must actually cover the web root; several widely used baseline configs exclude high-churn web directories, so silence here can mean the path is unwatched rather than untouched. Second, EID 11 fires on creation and on truncating overwrite, and has no modify event. An in-place append to an existing logon.aspx — a web shell calling File.AppendAllText, an echo ... >> logon.aspx — emits nothing at all, and that is the shape most real portal tampering takes. Covering it needs a read/write SACL feed (Security 4663) or file-integrity monitoring, and 4663 carries ObjectName/ProcessName rather than TargetFilename/Image, so it is a separate rule with its own field mapping, not a drop-in feed.

03 · How the logic works

Path alone was rejected deliberately: any write under a web root is already published as defacement under T1491.001, so the filename gate is what makes this a credential-capture rule rather than a duplicate. Both lists populate MITRE's FilePath knob; the specific paths and filenames are the pipeline's own, chosen for IIS, OWA and SharePoint only. filter_servicing populates MITRE's ProcessName knob, which MITRE frames as exclude legitimate updaters, alert on suspicious editors — only the exclusion half is built.

04 · Common false positives

Loudly, and mostly from deployment. Only Web Deploy is filtered, so a CI release, a robocopy job, an xcopy or a CMS save that rewrites login.aspx or default.aspx still matches, on every publish. Exchange and SharePoint cumulative updates replace the OWA and layouts pages across every server in a patch window. default.aspx is the weakest entry in the list: under \inetpub\wwwroot\ it is a site's home page far more often than its login page, and it overlaps the published T1491.001 rule. An administrator editing a login page in notepad.exe for branding is indistinguishable from the suspicious-editor case MITRE names.

05 · Detection maturity

tier_1: , the lowest tier, and it stays there until the rule has been run against real data. It has never been executed against a log line. The level is medium, which the rule's own first false positive contradicts — routine publishing is the dominant match, and low is the honest reading until the filters above exist. AN1320 (Linux/auditd) and AN1322 (macOS) are unbuilt.

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

Drop default.aspx, or keep it only when paired with a portal-specific path. Widen filter_servicing to the identities that actually publish in your estate — build agents, the app-pool w3wp.exe, deployment service accounts — before trusting the level. Extend the filename list to your own portal: signin.jsp, logon.php and the index.php of Pulse/Ivanti and Citrix appliances all pass untouched today. MITRE's TimeWindow knob, which correlates the edit with the web-shell request that made it, is unused — Sigma cannot express it.

Declared by the author

Ordinary application publishing. A CI release, an xcopy deploy or a CMS save rewrites login.aspx and default.aspx on every publish, and only Web Deploy itself is filtered out here — a build agent, PowerShell script or robocopy job doing the same publish still matches, which makes this the highest-volume source by a wide margin in any estate that deploys web content regularly.
Exchange and SharePoint cumulative updates and security hotfixes, which replace the OWA and layouts authentication pages under the paths selected here on every servicing event, producing a burst across every server in the patch window.
An administrator hand-editing default.aspx or a login page for branding, a maintenance banner or an SSO configuration change, typically with notepad.exe — which is also the editor MITRE's ProcessName knob names as suspicious, so the writing process does not separate the two cases on its own.
Backup, restore and DR replication agents rewriting the whole web root during a recovery test or a site migration.

Noise check0 of 3 fired

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

Share this rule

/u/siemphony/2a555dba-a047-4687-bf82-6478bc5e5cc0

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.

Login page file written under a portal web root

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it