Failed remote logon from a source outside the private ranges

Siemphony@siemphonylowT1133unverified

Matches a failed logon (Security EventID 4625) of type NetworkCleartext (8) or RemoteInteractive/RDP (10) whose `IpAddress` falls outside RFC1918, CGNAT (100.64.0.0/10), loopback, link-local and IPv6 unique-local space — the external-origin leg of AN1004, the one part a single event can carry; the failure-count, geolocation and business-hours legs all need aggregation or enrichment this corpus's Sigma model cannot express, and a single event here cannot distinguish background internet scanning from a targeted attempt. LogonType 3 (plain network) was dropped because it also matches ordinary internal-service credential failures (SMB, LDAP) unrelated to an external remote-access service; 4776 is not used because it carries no source-address field and cannot satisfy this rule's external-origin filter. A successful external remote-service logon is EventID 4624, which this rule can never see, so a quiet result is not evidence that no external access occurred — and a VPN/Citrix gateway that re-authenticates on the user's behalf presents an internal address, hiding genuinely external attempts that pass through it. Prerequisite: 4625 needs the Logon subcategory of Audit Logon auditing Failure; where it is off, this rule returns zero rows, which reads as quiet but means blind. Addresses in IPv4-mapped IPv6 form (`::ffff:10.0.0.1`) are read as external by this filter; add per-estate handling if that form appears in your feed. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0354, 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 == 4625 and (LogonType =~ "8" or LogonType =~ "10")) and not ((IpAddress startswith "10." or IpAddress startswith "127." or IpAddress startswith "169.254." or IpAddress startswith "172.16." or IpAddress startswith "172.17." or IpAddress startswith "172.18." or IpAddress startswith "172.19." or IpAddress startswith "172.20." or IpAddress startswith "172.21." or IpAddress startswith "172.22." or IpAddress startswith "172.23." or IpAddress startswith "172.24." or IpAddress startswith "172.25." or IpAddress startswith "172.26." or IpAddress startswith "172.27." or IpAddress startswith "172.28." or IpAddress startswith "172.29." or IpAddress startswith "172.30." or IpAddress startswith "172.31." or IpAddress startswith "192.168." or IpAddress startswith "100.64." or IpAddress startswith "100.65." or IpAddress startswith "100.66." or IpAddress startswith "100.67." or IpAddress startswith "100.68." or IpAddress startswith "100.69." or IpAddress startswith "100.70." or IpAddress startswith "100.71." or IpAddress startswith "100.72." or IpAddress startswith "100.73." or IpAddress startswith "100.74." or IpAddress startswith "100.75." or IpAddress startswith "100.76." or IpAddress startswith "100.77." or IpAddress startswith "100.78." or IpAddress startswith "100.79." or IpAddress startswith "100.80." or IpAddress startswith "100.81." or IpAddress startswith "100.82." or IpAddress startswith "100.83." or IpAddress startswith "100.84." or IpAddress startswith "100.85." or IpAddress startswith "100.86." or IpAddress startswith "100.87." or IpAddress startswith "100.88." or IpAddress startswith "100.89." or IpAddress startswith "100.90." or IpAddress startswith "100.91." or IpAddress startswith "100.92." or IpAddress startswith "100.93." or IpAddress startswith "100.94." or IpAddress startswith "100.95." or IpAddress startswith "100.96." or IpAddress startswith "100.97." or IpAddress startswith "100.98." or IpAddress startswith "100.99." or IpAddress startswith "100.100." or IpAddress startswith "100.101." or IpAddress startswith "100.102." or IpAddress startswith "100.103." or IpAddress startswith "100.104." or IpAddress startswith "100.105." or IpAddress startswith "100.106." or IpAddress startswith "100.107." or IpAddress startswith "100.108." or IpAddress startswith "100.109." or IpAddress startswith "100.110." or IpAddress startswith "100.111." or IpAddress startswith "100.112." or IpAddress startswith "100.113." or IpAddress startswith "100.114." or IpAddress startswith "100.115." or IpAddress startswith "100.116." or IpAddress startswith "100.117." or IpAddress startswith "100.118." or IpAddress startswith "100.119." or IpAddress startswith "100.120." or IpAddress startswith "100.121." or IpAddress startswith "100.122." or IpAddress startswith "100.123." or IpAddress startswith "100.124." or IpAddress startswith "100.125." or IpAddress startswith "100.126." or IpAddress startswith "100.127." or IpAddress startswith "0.0.0.0" or IpAddress startswith "-" or IpAddress startswith "::1" or IpAddress startswith "fe80:" or IpAddress startswith "fc" or IpAddress startswith "fd")))

Splunk · SPL

Run this as a search.

index=* ((EventID="4625" AND (LogonType="8" OR LogonType="10")) AND NOT ((IpAddress="10.*" OR IpAddress="127.*" OR IpAddress="169.254.*" OR IpAddress="172.16.*" OR IpAddress="172.17.*" OR IpAddress="172.18.*" OR IpAddress="172.19.*" OR IpAddress="172.20.*" OR IpAddress="172.21.*" OR IpAddress="172.22.*" OR IpAddress="172.23.*" OR IpAddress="172.24.*" OR IpAddress="172.25.*" OR IpAddress="172.26.*" OR IpAddress="172.27.*" OR IpAddress="172.28.*" OR IpAddress="172.29.*" OR IpAddress="172.30.*" OR IpAddress="172.31.*" OR IpAddress="192.168.*" OR IpAddress="100.64.*" OR IpAddress="100.65.*" OR IpAddress="100.66.*" OR IpAddress="100.67.*" OR IpAddress="100.68.*" OR IpAddress="100.69.*" OR IpAddress="100.70.*" OR IpAddress="100.71.*" OR IpAddress="100.72.*" OR IpAddress="100.73.*" OR IpAddress="100.74.*" OR IpAddress="100.75.*" OR IpAddress="100.76.*" OR IpAddress="100.77.*" OR IpAddress="100.78.*" OR IpAddress="100.79.*" OR IpAddress="100.80.*" OR IpAddress="100.81.*" OR IpAddress="100.82.*" OR IpAddress="100.83.*" OR IpAddress="100.84.*" OR IpAddress="100.85.*" OR IpAddress="100.86.*" OR IpAddress="100.87.*" OR IpAddress="100.88.*" OR IpAddress="100.89.*" OR IpAddress="100.90.*" OR IpAddress="100.91.*" OR IpAddress="100.92.*" OR IpAddress="100.93.*" OR IpAddress="100.94.*" OR IpAddress="100.95.*" OR IpAddress="100.96.*" OR IpAddress="100.97.*" OR IpAddress="100.98.*" OR IpAddress="100.99.*" OR IpAddress="100.100.*" OR IpAddress="100.101.*" OR IpAddress="100.102.*" OR IpAddress="100.103.*" OR IpAddress="100.104.*" OR IpAddress="100.105.*" OR IpAddress="100.106.*" OR IpAddress="100.107.*" OR IpAddress="100.108.*" OR IpAddress="100.109.*" OR IpAddress="100.110.*" OR IpAddress="100.111.*" OR IpAddress="100.112.*" OR IpAddress="100.113.*" OR IpAddress="100.114.*" OR IpAddress="100.115.*" OR IpAddress="100.116.*" OR IpAddress="100.117.*" OR IpAddress="100.118.*" OR IpAddress="100.119.*" OR IpAddress="100.120.*" OR IpAddress="100.121.*" OR IpAddress="100.122.*" OR IpAddress="100.123.*" OR IpAddress="100.124.*" OR IpAddress="100.125.*" OR IpAddress="100.126.*" OR IpAddress="100.127.*" OR IpAddress="0.0.0.0*" OR IpAddress="-*" OR IpAddress="::1*" OR IpAddress="fe80:*" OR IpAddress="fc*" OR IpAddress="fd*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 4625 AND (TO_LOWER(LogonType) == "8" OR TO_LOWER(LogonType) == "10")) AND NOT ((TO_LOWER(IpAddress) LIKE "10.*" OR TO_LOWER(IpAddress) LIKE "127.*" OR TO_LOWER(IpAddress) LIKE "169.254.*" OR TO_LOWER(IpAddress) LIKE "172.16.*" OR TO_LOWER(IpAddress) LIKE "172.17.*" OR TO_LOWER(IpAddress) LIKE "172.18.*" OR TO_LOWER(IpAddress) LIKE "172.19.*" OR TO_LOWER(IpAddress) LIKE "172.20.*" OR TO_LOWER(IpAddress) LIKE "172.21.*" OR TO_LOWER(IpAddress) LIKE "172.22.*" OR TO_LOWER(IpAddress) LIKE "172.23.*" OR TO_LOWER(IpAddress) LIKE "172.24.*" OR TO_LOWER(IpAddress) LIKE "172.25.*" OR TO_LOWER(IpAddress) LIKE "172.26.*" OR TO_LOWER(IpAddress) LIKE "172.27.*" OR TO_LOWER(IpAddress) LIKE "172.28.*" OR TO_LOWER(IpAddress) LIKE "172.29.*" OR TO_LOWER(IpAddress) LIKE "172.30.*" OR TO_LOWER(IpAddress) LIKE "172.31.*" OR TO_LOWER(IpAddress) LIKE "192.168.*" OR TO_LOWER(IpAddress) LIKE "100.64.*" OR TO_LOWER(IpAddress) LIKE "100.65.*" OR TO_LOWER(IpAddress) LIKE "100.66.*" OR TO_LOWER(IpAddress) LIKE "100.67.*" OR TO_LOWER(IpAddress) LIKE "100.68.*" OR TO_LOWER(IpAddress) LIKE "100.69.*" OR TO_LOWER(IpAddress) LIKE "100.70.*" OR TO_LOWER(IpAddress) LIKE "100.71.*" OR TO_LOWER(IpAddress) LIKE "100.72.*" OR TO_LOWER(IpAddress) LIKE "100.73.*" OR TO_LOWER(IpAddress) LIKE "100.74.*" OR TO_LOWER(IpAddress) LIKE "100.75.*" OR TO_LOWER(IpAddress) LIKE "100.76.*" OR TO_LOWER(IpAddress) LIKE "100.77.*" OR TO_LOWER(IpAddress) LIKE "100.78.*" OR TO_LOWER(IpAddress) LIKE "100.79.*" OR TO_LOWER(IpAddress) LIKE "100.80.*" OR TO_LOWER(IpAddress) LIKE "100.81.*" OR TO_LOWER(IpAddress) LIKE "100.82.*" OR TO_LOWER(IpAddress) LIKE "100.83.*" OR TO_LOWER(IpAddress) LIKE "100.84.*" OR TO_LOWER(IpAddress) LIKE "100.85.*" OR TO_LOWER(IpAddress) LIKE "100.86.*" OR TO_LOWER(IpAddress) LIKE "100.87.*" OR TO_LOWER(IpAddress) LIKE "100.88.*" OR TO_LOWER(IpAddress) LIKE "100.89.*" OR TO_LOWER(IpAddress) LIKE "100.90.*" OR TO_LOWER(IpAddress) LIKE "100.91.*" OR TO_LOWER(IpAddress) LIKE "100.92.*" OR TO_LOWER(IpAddress) LIKE "100.93.*" OR TO_LOWER(IpAddress) LIKE "100.94.*" OR TO_LOWER(IpAddress) LIKE "100.95.*" OR TO_LOWER(IpAddress) LIKE "100.96.*" OR TO_LOWER(IpAddress) LIKE "100.97.*" OR TO_LOWER(IpAddress) LIKE "100.98.*" OR TO_LOWER(IpAddress) LIKE "100.99.*" OR TO_LOWER(IpAddress) LIKE "100.100.*" OR TO_LOWER(IpAddress) LIKE "100.101.*" OR TO_LOWER(IpAddress) LIKE "100.102.*" OR TO_LOWER(IpAddress) LIKE "100.103.*" OR TO_LOWER(IpAddress) LIKE "100.104.*" OR TO_LOWER(IpAddress) LIKE "100.105.*" OR TO_LOWER(IpAddress) LIKE "100.106.*" OR TO_LOWER(IpAddress) LIKE "100.107.*" OR TO_LOWER(IpAddress) LIKE "100.108.*" OR TO_LOWER(IpAddress) LIKE "100.109.*" OR TO_LOWER(IpAddress) LIKE "100.110.*" OR TO_LOWER(IpAddress) LIKE "100.111.*" OR TO_LOWER(IpAddress) LIKE "100.112.*" OR TO_LOWER(IpAddress) LIKE "100.113.*" OR TO_LOWER(IpAddress) LIKE "100.114.*" OR TO_LOWER(IpAddress) LIKE "100.115.*" OR TO_LOWER(IpAddress) LIKE "100.116.*" OR TO_LOWER(IpAddress) LIKE "100.117.*" OR TO_LOWER(IpAddress) LIKE "100.118.*" OR TO_LOWER(IpAddress) LIKE "100.119.*" OR TO_LOWER(IpAddress) LIKE "100.120.*" OR TO_LOWER(IpAddress) LIKE "100.121.*" OR TO_LOWER(IpAddress) LIKE "100.122.*" OR TO_LOWER(IpAddress) LIKE "100.123.*" OR TO_LOWER(IpAddress) LIKE "100.124.*" OR TO_LOWER(IpAddress) LIKE "100.125.*" OR TO_LOWER(IpAddress) LIKE "100.126.*" OR TO_LOWER(IpAddress) LIKE "100.127.*" OR TO_LOWER(IpAddress) LIKE "0.0.0.0*" OR TO_LOWER(IpAddress) LIKE "-*" OR TO_LOWER(IpAddress) LIKE "::1*" OR TO_LOWER(IpAddress) LIKE "fe80:*" OR TO_LOWER(IpAddress) LIKE "fc*" OR TO_LOWER(IpAddress) LIKE "fd*")))

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)^4625$</field>    <field name="LogonType" type="pcre2">(?i)(^8$|^10$)</field>    <field name="IpAddress" negate="yes" type="pcre2">(?i)(^10\.|^127\.|^169\.254\.|^172\.16\.|^172\.17\.|^172\.18\.|^172\.19\.|^172\.20\.|^172\.21\.|^172\.22\.|^172\.23\.|^172\.24\.|^172\.25\.|^172\.26\.|^172\.27\.|^172\.28\.|^172\.29\.|^172\.30\.|^172\.31\.|^192\.168\.|^100\.64\.|^100\.65\.|^100\.66\.|^100\.67\.|^100\.68\.|^100\.69\.|^100\.70\.|^100\.71\.|^100\.72\.|^100\.73\.|^100\.74\.|^100\.75\.|^100\.76\.|^100\.77\.|^100\.78\.|^100\.79\.|^100\.80\.|^100\.81\.|^100\.82\.|^100\.83\.|^100\.84\.|^100\.85\.|^100\.86\.|^100\.87\.|^100\.88\.|^100\.89\.|^100\.90\.|^100\.91\.|^100\.92\.|^100\.93\.|^100\.94\.|^100\.95\.|^100\.96\.|^100\.97\.|^100\.98\.|^100\.99\.|^100\.100\.|^100\.101\.|^100\.102\.|^100\.103\.|^100\.104\.|^100\.105\.|^100\.106\.|^100\.107\.|^100\.108\.|^100\.109\.|^100\.110\.|^100\.111\.|^100\.112\.|^100\.113\.|^100\.114\.|^100\.115\.|^100\.116\.|^100\.117\.|^100\.118\.|^100\.119\.|^100\.120\.|^100\.121\.|^100\.122\.|^100\.123\.|^100\.124\.|^100\.125\.|^100\.126\.|^100\.127\.|^0\.0\.0\.0|^-|^::1|^fe80:|^fc|^fd)</field>    <description>Failed remote logon from a source outside the private ranges</description>    <mitre>      <id>T1133</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: low
Category: exploitation_initial_access
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: b72955d9-02d7-48b8-8cd7-6adb2e313767

ATT&CKT1133

T1133External Remote Services

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.

Lessonexploitation initial access

exploitation initial access

01 · What this rule detects

The moment an operator gets in from outside: a public-facing application exploited, a browser compromised by the page it loaded, a remote service exploited across the perimeter, an external remote access service used with credentials that were never theirs, or a device plugged into the estate by hand. The uncomfortable truth about this category is that the exploit itself is almost never in your endpoint telemetry. Memory corruption inside a web worker, a deserialisation gadget, a template injection — none of it produces a process, a file or a registry write. What produces telemetry is the consequence: the service process doing something it has never done, a second or two later.

02 · Telemetry you need

Process creation with ParentImage and full command line — Sysmon EventID 1, or Security 4688 with Audit Process Creation and the separate 'Include command line in process creation events' policy; both off by default, and 4688 without the second gives you the child name and no arguments, which is exactly the half you do not need here
The user context on that process creation — Sysmon EventID 1 User, 4688 SubjectUserName. IIS worker processes carry the app pool identity as IIS APPPOOL\<pool name>; on Linux the equivalent is www-data, apache, nginx or the Tomcat service account. This field is the anchor for the whole category
Sysmon EventID 11 (FileCreate) scoped to the document roots — C:\inetpub\wwwroot, /var/www, the Tomcat webapps directory — for web shells written as .aspx, .ashx, .jsp or .php. On Linux the same coverage needs an auditd watch on the docroot, which no distribution ships
Web server access logs with the query string: IIS W3C logging is on by default and records cs-uri-query, but no web server logs POST bodies, so a rule matching exploit strings in the URL is blind to every POST-borne exploit and to anything sent in a header. Treat request-content matching as a bonus layer, never the primary one
Authentication at the perimeter for external remote services — Security 4624 with LogonType 3 and 10 on the gateway, plus the VPN concentrator, NPS/RADIUS or identity-provider sign-in logs, which are the only records that carry the source address as the internet saw it
Security 6416 (a new external device was recognised) for hardware additions — requires Audit PnP Activity, off by default; the Microsoft-Windows-DriverFrameworks-UserMode/Operational log is disabled by default too, and Sysmon has no device event at all
Application Error 1000 and Windows Error Reporting 1001, or the Linux equivalent, for the crash-then-restart pattern that a failed remote service exploit leaves behind

03 · How the logic works

Build every rule in this category on the consequence, not the payload. The primary rule is a parent-child rule anchored on identity: a process whose parent is a service that faces the network — w3wp.exe, httpd, nginx, php-fpm, java under Tomcat, sshd, the print spooler, a database engine — and whose image is a shell, a script interpreter, a download utility or anything at all under a user-writable path. Anchor the exclusion side on the service account rather than the child, because the child is the attacker's choice and the account is not. The second rule is a file rule: the same service account writing an executable script type into a directory the web server will serve. Two traps are worth carrying away. The first is that payload signatures age out in days while w3wp.exe spawning cmd.exe has been a valid detection for twenty years — resist the pull towards matching CVE-specific strings, and if you write them, write them as an enrichment layer that never carries the rule on its own. The second is that the parent link is not guaranteed: an exploit that lands inside the worker process and stays there produces no child at all, and one that pivots through a scheduled task, a service or WMI gets its child reparented away from the web server, so the file-write rule and outbound-connection rule are separate detections rather than extra conditions on the first. For T1200 the story is different again — hardware additions produce device-enumeration events and nothing else, and unless PnP auditing is on, the first evidence you have of a rogue device is whatever it did afterwards.

04 · Common false positives

Content management systems updating themselves: WordPress, Drupal, Confluence and Jira plugin installers write PHP, JSP or class files into the docroot as the web server user, which is precisely the web shell rule
Deployment pipelines and release agents running post-deploy hooks under the application identity — an msbuild, npm, composer or artisan invocation whose parent is the app pool or the Tomcat service
CGI and PHP applications that shell out by design: mail handlers calling sendmail, image processing calling ImageMagick's convert or Ghostscript, PDF and report generation, and anything using exec() to reach a command-line utility
Web-based administration consoles whose entire purpose is running commands — Jenkins agents under Tomcat, cPanel, and the management interfaces on printers, storage arrays and network appliances
Application file-upload features storing user uploads inside the docroot, and web servers writing cache, session and compiled-template files into directories a docroot rule covers
Buggy applications crashing on their own schedule, which fires any rule built on the crash-and-restart pattern; and vulnerability scanners generating 500 responses and malformed request strings across the whole estate
Third-party support vendors and travelling staff connecting over VPN or the RDP gateway from addresses and countries never seen before, which is the entire logic of an external remote services rule
Docking stations, KVM switches, USB-C displays with built-in Ethernet and conference room equipment, all of which enumerate as new composite HID devices and new network adapters when someone moves desks

05 · Detection maturity

Tier 1 — starting point: Matches a fixed list of exploit strings in web server request logs and a web server process spawning cmd.exe or a shell.
Tier 2 — tuned: Matches any unexpected child of the service identity against a baselined allowlist, plus servable script types written into the docroot by that identity, with deployment accounts excluded by host.
Tier 3 — correlated: Correlates the anomalous child or file write with the request that preceded it, the outbound connection that followed, and whether the resulting artefact exists anywhere else in the estate.

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

Baseline what each service account already spawns before writing the rule — a healthy web server has a short, stable child list, and the rule you want is 'anything outside it', not a list of bad binaries
Exclude the deployment identity by account and source host together, never by child process; dropping cmd.exe from the child list to quieten one pipeline blinds the rule on every server you own
Where the false positive is a genuine CGI application, exclude on the script path or working directory rather than the interpreter, so an unfamiliar script in the same docroot still trips
Treat 'web server account writes a servable script type' as its own higher-severity rule and keep the exclusions for it separate from the process rule — the noise sources are different
Raise severity when the child process makes an outbound connection or when the file written has no counterpart anywhere else in the fleet; a web shell is almost always unique to the host it landed on
For external remote services, alert on the first-ever combination of account, source geography and device rather than on any single unfamiliar address — the address alone changes every time someone boards a train
If you cannot turn on PnP auditing fleet-wide, turn it on for the hosts where a rogue device would matter and say plainly in the rule that everywhere else is uncovered

Declared by the author

Continuous internet background authentication noise against any internet-exposed surface — an RD Gateway, published RDP host, Exchange/OWA, or a VPN concentrator that logs to Windows — from automated scanners and credential-stuffing bots probing default paths rather than targeted activity. On such a host this is the highest-volume match by a wide margin, thousands of events a day, which is why the level is low rather than high.
Remote staff with a stale saved credential after a password change: a phone or laptop mail client retries on every poll from the mobile carrier's or the home ISP's public address, producing a steady stream of network-cleartext 4625 events for a legitimate user until someone updates the saved password.
Cloud-hosted and partner integrations that authenticate from provider-owned public addresses — hybrid identity connectors, external monitoring probes, mail relays and third-party SaaS connectors — all of which are external by this rule's definition and are expected to be there, and which fail routinely on certificate rollover or token expiry.
Organisations that use publicly routable address space on their own internal network, or that route branch offices and site-to-site links over a public-addressed WAN, where an ordinary mistyped password at a desk in a branch office is counted as an external attempt.

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 T1133, evaluated against their — events.

Share this rule

/u/siemphony/b72955d9-02d7-48b8-8cd7-6adb2e313767

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.

Failed remote logon from a source outside the private ranges

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it