Rule catalog

Cryptocurrency mining software - medium, pattern rule.

What happened: Cryptocurrency mining software (XMRig, NiceHash Miner) is installed. The signal says every place that records it - an uninstall key, Windows Installer (its record, or its installation or removal in the Application log), a Store package - and for which user.

Why it matters: Mining uses the host's processor and power for someone else's profit; XMRig is the miner intruders drop after gaining access, often as the only visible sign of a compromise that has other uses.

What to do next: Find how it starts (a service, a task, a Run key - the Persistence module) and its pool configuration; treat the host as compromised until its way in is known. Ask its owner whether it is approved here. If not: when it arrived (app.installed, the key's last write, the folder's creation time), who installed it (the user the signal names, the account signed in then), and what it connected to; look for it on other hosts - the inventory stacks every application across the fleet.

A proxy server or an interception proxy - medium, pattern rule.

What happened: Software that runs the host as a proxy for others (3proxy, CCProxy, WinGate, Privoxy, Squid) or intercepts its TLS traffic (mitmproxy) is installed. The signal says every place that records it - an uninstall key, Windows Installer (its record, or its installation or removal in the Application log), a Store package - and for which user. Tunnelling tools are the RemoteAccess module's (RA-TUNNEL-TOOL).

Why it matters: A proxy relays others' traffic through the host - an intruder's way to reach internal systems or to hide where their traffic comes from - and an interception proxy reads TLS traffic, passwords included.

What to do next: Find its configuration (who may use it, on which port) and how it starts (a service, a task - the Persistence module). Ask its owner whether it is approved here. If not: when it arrived (app.installed, the key's last write), who installed it (the user the signal names), and what connected to it (the Network module's listeners); look for it on other hosts - the inventory stacks every application across the fleet.

Proxyware or bandwidth-sharing software - medium, pattern rule.

What happened: Software that sells the host's internet connection as a proxy exit or shares its bandwidth for pay (Infatica - also as an SDK inside other software - Honeygain, EarnApp, PacketStream, Pawns.app, TraffMonetizer, Repocket, Packetshare, Peer2Profit, Bright VPN, Hola VPN, Tuxler) is installed. The signal says every place that records it - an uninstall key, Windows Installer (its record, or its installation or removal in the Application log), a Store package - and for which user.

Why it matters: Strangers' traffic leaves the network from this host's address: the organisation's IP is used for whatever they do - scraping, fraud, attacks - and it is blamed for it. It is often bundled with free software, and its SDK form runs inside an application of another name.

What to do next: Find what brought it - a bundled free program, or a user who installed it for pay - from its install date and the applications installed the same day. Ask its owner whether it is approved here. If not: when it arrived (app.installed, the key's last write, the folder's creation time), who installed it (the user the signal names, the account signed in then), and what it connected to; look for it on other hosts - the inventory stacks every application across the fleet.

Peer-to-peer file sharing or synchronisation software - low, pattern rule.

What happened: Peer-to-peer file sharing or synchronisation software (qBittorrent, µTorrent, BitTorrent, Resilio Sync) is installed. The signal says every place that records it - an uninstall key, Windows Installer (its record, or its installation or removal in the Application log), a Store package - and for which user.

Why it matters: It moves files to and from peers outside the organisation's control - a channel for exfiltration and for unlicensed or malicious downloads.

What to do next: Find what it shares or synchronises (its configured folders) and with whom. Ask its owner whether it is approved here. If not: when it arrived (app.installed, the key's last write, the folder's creation time), who installed it (the user the signal names, the account signed in then), and what it connected to; look for it on other hosts - the inventory stacks every application across the fleet.

Windows' automatic boot recovery is turned off - high, pattern rule.

What happened: The boot configuration's default entry turns automatic recovery off: recoveryenabled No, or bootstatuspolicy IgnoreAllFailures - the settings bcdedit writes on the default entry.

Why it matters: A host that fails to start will not offer its recovery options or repair itself. Ransomware sets both just before encrypting so the victim cannot boot into recovery to restore the system; Windows never sets them on its own, and an administrator rarely does.

What to do next: Find the bcdedit command and who ran it (Executions' EXEC-RECOVERY-DISABLED, the process creations and PowerShell histories), and look around that time for the other steps before encryption: shadow copies deleted, backups deleted, services stopped. Restore the settings (bcdedit, recoveryenabled Yes on the default entry) once the case allows.

Windows Backup's catalog was deleted - high, pattern rule.

What happened: Windows Backup's own log recorded that the system catalog of its backups was deleted (Microsoft-Windows-Backup, 161) - what wbadmin delete catalog does.

Why it matters: Without its catalog, Windows Backup no longer knows which backups exist: the host cannot be restored from them with its own tools. Ransomware deletes it with the shadow copies just before encrypting; an administrator does it rarely, to recover a damaged catalog.

What to do next: Find the wbadmin command and who ran it (Executions' EXEC-BACKUP-CATALOG-DELETED, the process creations and PowerShell histories), check whether the backups themselves are intact on their target, and look around that time for the other steps before encryption.

The Volume Shadow Copy service is disabled - high, pattern rule.

What happened: The Volume Shadow Copy service (VSS) or the Microsoft Software Shadow Copy Provider (swprv) is set to disabled in the service table now; Windows installs both to start on demand.

Why it matters: Without them no shadow copy can be made or used: System Restore, Windows Backup, Previous Versions and most backup products stop working on the host. Ransomware disables them so the files it encrypts cannot be restored; an administrator rarely does.

What to do next: Find when the service's key was last written (persist.modified) and what changed it - a sc.exe or PowerShell command line (Executions), a GPO (Directory's DIR-GPO-RECOVERY-SERVICE-OFF), a service change in the System log - and who ran it. Then look around that time for the other steps before encryption: copies deleted, boot recovery turned off, backups deleted.

System Restore is turned off by policy - medium, pattern rule.

What happened: A policy value turns System Restore off on the host: DisableSR = 1 (System Restore off) or DisableConfig = 1 (its configuration off) under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore - set by a local GPO or by Group Policy (not told apart here).

Why it matters: With it turned off by policy, Windows makes no restore points and the user cannot turn it back on: the host has no way back to an earlier state of Windows. Ransomware sets it; so do some organisations' hardening baselines.

What to do next: Check whether the domain's Group Policy sets it for every host (Directory's GPO settings, the same row on other hosts in the fleet) or only this one has it; a value set on one host alone, shortly before other recovery was taken away, points at an intruder - find what wrote it (reg.exe or PowerShell in the process creations and histories).

A backup service is disabled - medium, pattern rule.

What happened: A service Windows' own backups run on is set to disabled in the service table now: the Block Level Backup Engine Service (wbengine - Windows Server Backup), the Windows Backup service (SDRSVC) or the File History Service (fhsvc). Windows installs them to start on demand.

Why it matters: With it disabled, the backups that depend on it fail or never start, so a host may have no recent backup when one is needed. Ransomware turns backup services off before encrypting; an organisation may also disable one it does not use.

What to do next: Check whether the host is meant to use that backup (its last backup in the Backup module's recovery table), when the service's key was last written (persist.modified) and what disabled it - a command line, a GPO, a service change in the System log - and whether other recovery was taken away around the same time.

Windows lost every shadow copy of a volume - medium, pattern rule.

What happened: Windows recorded (volsnap, System log) that every shadow copy of a volume was deleted because its storage could not grow in time (25), or aborted because the storage reached the limit an administrator set (36). The routine deletion of the oldest copy to stay within the limit is not this.

Why it matters: Every earlier version of the volume's files was gone from that moment. A limit an administrator set (36) is the effect of shrinking the storage on purpose - a quieter way to remove the copies than deleting them, used by ransomware; heavy disk activity can also outrun the storage (25).

What to do next: Look for a vssadmin resize shadowstorage command shortly before (Executions' EXEC-SHADOW-STORAGE-SHRUNK) and who ran it, and at the volume's storage limit now (the recovery table). For 25, check whether heavy disk activity at that time explains it - mass file writes are also what encryption looks like.

A volume's shadow copy storage is limited to almost nothing - medium, pattern rule.

What happened: The most a volume's shadow copy storage may grow to is under 1% of the volume (shadow.storage_max) - too little to hold the changes between two copies of a working system. Windows sets 10% or more by default.

Why it matters: Windows deletes a volume's shadow copies as soon as they outgrow their storage, so a tiny limit leaves the host with no earlier versions of its files in practice - the effect ransomware seeks by resizing the storage, without a deletion in the logs.

What to do next: Find when and by whom it was set: a vssadmin resize shadowstorage command (Executions' EXEC-SHADOW-STORAGE-SHRUNK, the process creations and PowerShell histories), volsnap's records of copies lost since (BACKUP-SHADOW-COPIES-LOST). An administrator who limited it on purpose would normally have given gigabytes.

A downloaded file whose name hides what it is - high, pattern rule.

What happened: A downloaded file's name hides what it is (download.disguised): its content is an executable but its name ends in another extension, or its name puts a document's extension before its real one (invoice.pdf.exe) - Windows hides known extensions by default, so the user sees only the first.

Why it matters: A name that hides an executable is made to be opened by someone who thinks it is a document - the way phishing attachments and fake downloads get run. Legitimate software has no reason to do it.

What to do next: Check whether it ran (download.ran) and persists (download.persists); where it came from (download.url, download.referrer); the file's signature and hash. If it ran, look at the account's activity from that time on.

A downloaded file is configured to run again - high, pattern rule.

What happened: A file downloaded from the Internet is what a service, scheduled task or auto-start entry runs (download.persists): it is set to run again at startup, sign-in or on a schedule.

Why it matters: Installers put their programs in Program Files before they register them; a persistent entry that runs a file where the browser saved it (Downloads, Desktop) is how a dropper keeps a foothold. A user's portable tool set to start with Windows does the same.

What to do next: Check the entry (Persistence names it) - who created it and when - and the file: its signature, hash, where it came from (download.url) and whether it ran (download.ran).

A file downloaded from a bare Internet address - medium, pattern rule.

What happened: A file that runs or carries code was served from a bare public IP address rather than a host name (download.url_host, download.url).

Why it matters: Legitimate software is served from named hosts; a file from a bare address comes from a server someone set up quickly - how staged payloads and exploit kits deliver files.

What to do next: Check the address against threat intelligence and the host's other connections (Network); check the file and whether it ran.

A downloaded script or shortcut ran - medium, pattern rule.

What happened: A script or shortcut downloaded from the Internet ran: Executions recorded a process whose command line names it (download.ran).

Why it matters: Scripts and shortcuts carry no signature and run whatever they say; one run straight from the browser's download is how many first-stage loaders start (a .js, .hta, .lnk or .bat in an archive or as a fake document).

What to do next: Read the file (it is plain text, or a shortcut's target), the process that ran it and what that process started; check where it came from (download.url).

A downloaded program or installer that is not validly signed - medium, pattern rule.

What happened: A program or installer downloaded from the Internet is still on disk and is not signed, or its signature does not verify (file.signature).

Why it matters: Most legitimate software is signed by its publisher; an unsigned or broken signature means no one vouches for the file - where malware, cracked software and many free tools are. download.ran says whether Executions saw it run.

What to do next: Check where it came from (download.url, download.referrer), its hash (file.sha256) against threat intelligence, whether it ran (download.ran) and persists (download.persists).

A download the browser flagged was kept by the user - medium, pattern rule.

What happened: The browser flagged a download as dangerous and the user chose to keep it (download.danger: flagged by the browser, kept by the user).

Why it matters: The browser's reputation check judged the file risky; keeping it anyway is how a user runs what a social-engineering page told them to. The check also flags rare but legitimate software.

What to do next: Check what the file is (download.kind, its signature and hash), where it came from, and whether it ran (download.ran).

A browser started with an extension loaded from a folder (--load-extension) - medium, pattern rule.

What happened: A Chromium-based browser was started with --load-extension: it loads an unpacked extension from the folder named, bypassing the store and the browser's extension settings.

Why it matters: Loading an extension from the command line is how browser-hijacking malware runs its extension from a scheduled task or a shortcut it changed. Extension developers use it too.

What to do next: Check the folder named in the command line (its manifest and scripts), the parent process (a scheduled task, a changed shortcut) and Persistence for what starts the browser this way.

A browser extension not installed from a store - medium, pattern rule.

What happened: An enabled browser extension was not installed from a browser's store: the browser records it was installed from a package file, loaded from an unpacked folder or the command line, placed in the profile by another program, loaded temporarily for debugging - or forced by a policy or an external program from a server that is not a store (extension.installed_by, extension.update_url).

Why it matters: A store reviews an extension before it is offered and serves its files signed; an extension that bypassed it was put there by whoever wrote the package, the folder or the policy - how malicious extensions are sideloaded to read pages, steal sessions and inject ads. Developers and some organisations' own extensions are installed this way too.

What to do next: Check its folder (extension.folder) - its manifest and scripts - and where it updates from: whoever runs that server can change it. For a policy or an external program, find who wrote the value (extension.forced_by). Compare its install time with the user's activity and the other signals of the account.

A browser extension whose signature is missing or broken - medium, pattern rule.

What happened: An enabled extension of a Gecko-based browser (Firefox and its forks) is recorded by the browser as not signed or with a broken signature (extension.signature).

Why it matters: Release versions of Firefox refuse an extension Mozilla has not signed; one running unsigned means signature checking was turned off (a developer or unbranded build, or a changed setting), or its files were changed after signing.

What to do next: Check how it was installed and its folder; check the profile's settings (xpinstall.signatures.required in prefs.js or user.js) and who changed them.

A browser started for remote control (remote debugging) - medium, pattern rule.

What happened: A browser was started with remote debugging on (--remote-debugging-port or --remote-debugging-pipe): any program that reaches the port can drive the browser and read everything in it.

Why it matters: Remote debugging gives full control of the browser's profile - its pages and its cookies, decrypted - which is how cookie-stealing tools take a user's signed-in sessions without touching the cookie file. Test automation and developers start browsers this way too.

What to do next: Check the parent process and the account, and whether the browser used the user's own profile (no --user-data-dir, or one pointing at the real profile). Look for the program that connected to the port (Network) and for sessions used from elsewhere afterwards.

A site visited by its bare Internet address - medium, pattern rule.

What happened: A browser profile's history holds visits to a site by its bare public IP address rather than a host name (visit.host) - its pages and the latest visit are in the signal.

Why it matters: People reach sites by name; a bare address is typed or linked when someone set up a server quickly - phishing kits, payload servers, control panels. Some devices and services are reached this way legitimately.

What to do next: Check the address against threat intelligence and the host's connections (Network); look at the pages visited (visit.urls) and what was downloaded around that time.

A program or script downloaded by a browser extension - low, pattern rule.

What happened: A browser extension, not the user, started the download of a program, installer or script (download.by_extension).

Why it matters: An extension that fetches programs can be delivering them; download-manager extensions start every download legitimately.

What to do next: Check the extension (the Extensions page, its permissions and how it was installed) and the file it fetched.

A file downloaded from a file-sharing, paste or tunnel service - low, pattern rule.

What happened: A file that runs or carries code was served by an anonymous file-sharing, paste or tunnel service (download.url_host): anyone can put a file there without an account or a review.

Why it matters: These services host many malware payloads because anything can be uploaded and links change fast; they also host ordinary files people share.

What to do next: Check the referrer (who sent the user there), the file (kind, signature, hash) and whether it ran.

A file that runs or carries code downloaded in the period given - low, pattern rule.

What happened: A program, installer, script, shortcut, disk image, archive or macro document was downloaded inside the period the analyst gave (the profile's window) - by the browser's time, or the file's creation for a file known only by its Mark of the Web.

Why it matters: What came in around an incident is where an intrusion often starts; the period is the analyst's, so every such download in it is worth a look.

What to do next: Check each file's kind, signature, where it came from and whether it ran.

A browser extension that may read every site and its cookies, debug pages, change the proxy or talk to local programs - low, pattern rule.

What happened: An enabled browser extension, not part of the browser, declares permissions to read and change every site together with reading cookies, debugging pages, changing the proxy or talking to programs on this computer (extension.capabilities).

Why it matters: Together these let an extension read and steal the user's signed-in sessions, redirect their traffic or pass what it sees to a program outside the browser - what session-stealing extensions ask for. Password managers, developer tools and security products ask for them too: it is what it may do, not what it did.

What to do next: Check it is an extension the user or the organisation chose: how it was installed (extension.installed_by), where it updates from, and whether it is rare on the fleet (the stacked extension list). An extension not from a store with these permissions deserves the closest look.

A site visited under a top-level domain often abused - low, pattern rule.

What happened: A browser profile's history holds visits to a site whose top-level domain is among those most used for abuse (visit.tld) - cheap or free to register, with little checking of who registers.

Why it matters: Phishing and malware sites cluster under a few top-level domains, and domains like .zip and .mov look like file names in a link. Most sites under them are still ordinary.

What to do next: Check the host against threat intelligence and its pages (visit.urls); look for downloads from it and credentials entered around that time.

The AdminSDHolder object was changed - high, pattern rule.

What happened: The domain controller's Security log records a change to CN=AdminSDHolder,CN=System (5136), by the account this signal names.

Why it matters: AdminSDHolder's permissions are copied to every privileged account and group of the domain about once an hour, so a permission added to it returns on all of them even after it is removed from one. It is almost never changed.

What to do next: Read the change (directory.attribute, directory.value - a permission is SDDL), who made it, and reset AdminSDHolder's permissions to the domain's default unless the change is documented.

Kerberos delegation was set on an account - high, pattern rule.

What happened: An account or computer was made trusted for delegation (4738 or 4742, its account flags), or given a list of services it may delegate to (5136, msDS-AllowedToDelegateTo or msDS-AllowedToActOnBehalfOfOtherIdentity).

Why it matters: An account trusted for delegation can act on behalf of the users who connect to it; resource-based delegation lets the account named act towards the object changed. Both are rarely changed outside planned work.

What to do next: Check which account was changed and by whom, whether a change request explains it, and remove the setting unless it does. Promoting a new domain controller sets "trusted for delegation" on its computer account.

A command to copy or export the directory database - high, pattern rule.

What happened: A command named the directory database file (ntds.dit), or created an install-from-media export with ntdsutil ("ifm" / "create full").

Why it matters: The directory database holds every account's password hash. Administrators export it to promote a domain controller from media; any other copy is a copy of the domain's secrets.

What to do next: Check who ran it and when, whether a domain controller promotion explains it, and where the copy went (the command's destination, then any upload from this host). Unless explained, treat every domain password as exposed.

A member was added to a domain's most privileged group - high, pattern rule.

What happened: A member was added to Domain Admins (-512), Schema Admins (-518), Enterprise Admins (-519) or the domain's Administrators group (S-1-5-32-544) - 4728, 4732 or 4756 on this domain controller.

Why it matters: Members of these groups control the whole domain, every host in it included. Changes to them are rare and planned.

What to do next: Check the member added and who added it (this signal names both), whether a change request explains it, and what the member did afterwards (Logons on this and other hosts).

One account requested RC4 service tickets for several services within an hour - high, fact rule.

What happened: {max_rc4_account} requested RC4-encrypted service tickets for {max_rc4_services} different services within 60 minutes ({max_rc4_hour}): {max_rc4_service_list}.

Why it matters: A service ticket is encrypted with its service account's password; RC4 tickets can be tested against password guesses offline, far faster than AES ones. Ordinary use asks for a few services, usually with AES.

What to do next: Identify the requesting account and the host it worked from (its logons), check the services' accounts for weak or old passwords and change them, and prefer AES for service accounts (msDS-SupportedEncryptionTypes).

Directory replication rights used by an account that is not a computer - high, pattern rule.

What happened: An account whose name does not end in $ used the rights to replicate the directory's changes (4662: Replicating Directory Changes, ... All or ... In Filtered Set). Domain controllers replicate as their computer accounts.

Why it matters: Replication returns every account's password hash. Outside domain controllers, the only common legitimate user of these rights is a directory synchronisation service account (Microsoft Entra Connect's MSOL_ or Sync_ account). Anything else is a request for the domain's secrets (DCSync).

What to do next: Check the account: a known synchronisation account is expected; any other means treating every password in the domain as exposed - find the host it came from (its logon session on this DC, Logons), and contain both.

An executable in SYSVOL is named as another kind of file - high, pattern rule.

What happened: A file in SYSVOL starts with an executable's header (MZ) but its name ends in another extension - or none.

Why it matters: Group Policy itself never writes an executable under another name, and administrators have no reason to. A program named to look like data in a share every host reads is hidden on purpose.

What to do next: Get the file's hash, look for a GPO that references it (the gpo_settings table), check which hosts fetched or ran it, and keep a copy before it is removed.

A GPO's task or script names a web address - medium, pattern rule.

What happened: A task, script or shortcut a GPO defines has a web address (http:// or https://) in its command or arguments.

Why it matters: A command deployed by Group Policy that names a web address fetches something from it on every host the GPO applies to. Deployments normally use internal shares.

What to do next: Note the address and check it against proxy and DNS logs; confirm the setting with the Group Policy owners and check who edited the GPO and when.

A GPO copies an executable or script to hosts - medium, pattern rule.

What happened: A GPO's Files preference copies a file whose name is an executable, installer or script to each host or user the GPO applies to.

Why it matters: A program copied to every host by Group Policy is often run by another setting of the same GPO. Software is more often deployed by a software-distribution tool than copied this way.

What to do next: Get the source file (setting.source) - hash, signature, when it was written - and look for a task or script in the same GPO that runs the copy (the gpo_settings table). Confirm with the Group Policy owners.

A GPO adds a Microsoft Defender exclusion - medium, pattern rule.

What happened: A GPO sets a Microsoft Defender exclusion - a path, extension or process Defender will not scan on the hosts the GPO applies to.

Why it matters: Everything under an excluded path is not scanned on any of those hosts. Exclusions are set for legitimate software too, which is why each one deserves a documented reason.

What to do next: Read what is excluded (setting.name), check whether that path holds anything on the hosts (Executions, Persistence), and confirm with the security team.

A GPO turns a Microsoft Defender protection off - medium, pattern rule.

What happened: A GPO sets a Microsoft Defender policy value whose name starts with "Disable" to 1, or sets the Defender service's start type to disabled.

Why it matters: While the policy applies, the hosts it reaches run with that protection off, and Defender records nothing for it. Turning protection off through Group Policy affects every host at once.

What to do next: Read which value it sets and on which hosts the GPO applies; check the Protection module's view of those hosts; confirm with the Group Policy owners and the security team.

A GPO setting that runs or places a program was written in the period - medium, pattern rule.

What happened: A task, script, file copy, shortcut or service setting of a GPO was written (its file in SYSVOL, or Group Policy's copy of it on this host) inside the period the analyst gave, or belongs to a GPO created in it.

Why it matters: A GPO created or edited during the period of an incident to run or place a program on many hosts is one of the first things to rule out, because it reaches every host it applies to at once.

What to do next: Read what the setting runs or copies, who edited the GPO and when (gpo.changed_by), where it is linked, and confirm with the Group Policy owners. If unexplained, the hosts it applies to are in scope.

A GPO defines an immediate task - medium, pattern rule.

What happened: A Group Policy object defines an immediate task (a Group Policy Preferences task that runs once on each host or user the GPO applies to, at its next refresh, and is then removed).

Why it matters: An immediate task leaves no lasting scheduled task on the hosts, so the GPO is where it is seen. A recently added or edited one deserves a reason, because it runs on every host the GPO reaches.

What to do next: Read the program and arguments it runs, who edited the GPO and when (gpo.changed_by, gpo.changed, setting.changed) and where the GPO is linked (gpo.links). Confirm it with the team that owns Group Policy; if nobody does, look for the program on the hosts the GPO applies to (Executions).

A GPO was linked to a domain, OU or site - medium, pattern rule.

What happened: The domain controller's Security log records a GPO linked to a directory object (a gPLink change that adds a GPO it did not name before - 5136), by the account this signal names.

Why it matters: Linking is what makes a GPO apply: from the next refresh, every host under that object runs its settings. A link to the domain itself reaches every host.

What to do next: Read where it was linked (directory.object) and what the GPO deploys (its GUID in the group_policy table); confirm with the account that linked it.

A GPO adds members to the local Administrators group - medium, pattern rule.

What happened: A GPO adds an account or group to the local Administrators group (S-1-5-32-544) of the hosts it applies to - by a Local Users and Groups preference, or by the security template's group membership.

Why it matters: Every member it adds is an administrator of every host the GPO applies to. Many domains manage administrators this way; a member added recently, or one nobody recognises, is worth a check.

What to do next: Read who is added (setting.value), check that account (Users, Logons) and who edited the GPO and when; confirm with the Group Policy owners.

A GPO disables or stops a backup or recovery service - medium, pattern rule.

What happened: A GPO sets the Volume Shadow Copy service (VSS), its provider (swprv), Windows Backup (wbengine, SDRSVC) or the Windows Firewall service (MpsSvc) to disabled, or stops it.

Why it matters: With these services off, the hosts the GPO applies to cannot make or restore shadow copies or backups (or lose their firewall) - recovery from damage to their files becomes harder.

What to do next: Confirm the setting with the Group Policy owners; check the hosts it applies to for shadow copies and backups (Executions: shadow copies deleted, recovery disabled).

A GPO runs a program from a folder users can write to - medium, pattern rule.

What happened: A task, script or shortcut a GPO defines runs a program from a folder ordinary users can write to (a temporary folder, ProgramData, AppData or Public), as written in its command or arguments.

Why it matters: Software deployed by administrators normally lives in Program Files or Windows. A program in a user-writable folder may have been placed there by something else - often by a file copy in the same GPO.

What to do next: Check whether the same GPO also copies a file into that folder (the gpo_settings table), get the file from a host it applied to (hash, signature), and confirm the setting with the Group Policy owners.

A GPO stores a password - medium, pattern rule.

What happened: A Group Policy Preferences setting stores a password (cpassword). Its encryption key was published by Microsoft (MS14-025), so any account that can read SYSVOL can recover it.

Why it matters: Every account of the domain can read SYSVOL, so the password is effectively known to all of them - for an account that often has administrative rights on many hosts.

What to do next: Change the password of the account named in the setting, remove the setting from the GPO, and check that account's recent logons (Logons) for use from unexpected hosts.

A GPO's task runs a program from a network share - medium, pattern rule.

What happened: A scheduled or immediate task a GPO defines runs a program from a network share - a \\server\share path in its command or arguments.

Why it matters: Every host the GPO applies to fetches that program from the share and runs it. Tasks deployed by Group Policy usually run software already installed on the host.

What to do next: Find the file on the share (on a domain controller, SYSVOL's executables are in the sysvol_files table): its hash, signature and when it was written. Check who edited the GPO and when, and confirm the task with the Group Policy owners.

Many wrong passwords for one account within an hour - medium, fact rule.

What happened: {max_dc_failures_account} failed {max_dc_failures_account_hour} times with a wrong password within 60 minutes ({max_dc_failures_hour}), as this domain controller recorded (Kerberos and NTLM).

Why it matters: People mistype a password a few times, not tens of times an hour; this many failures is guessing, or a service or task with an old password.

What to do next: Find the sources of the failures (the domain controller's records for the account), tell a stale saved password (one source, a steady rate) from guessing, and check whether a success followed.

Wrong passwords for many accounts from one source within an hour - medium, fact rule.

What happened: {max_dc_spray_accounts} different accounts failed with a wrong password or an unknown account name from {max_dc_spray_source} within 60 minutes ({max_dc_spray_hour}), as this domain controller recorded (Kerberos and NTLM): {max_dc_spray_account_list}.

Why it matters: Trying one or two passwords against many accounts avoids lockouts. A domain controller sees it for the whole domain, not one host. A misconfigured scanner or a service with old credentials can look similar.

What to do next: Identify the source host, check whether any of the accounts then authenticated successfully, and reset any that did.

A member was added to a sensitive domain group - medium, pattern rule.

What happened: A member was added to Account Operators, Server Operators, Print Operators, Backup Operators, Group Policy Creator Owners or DnsAdmins - groups whose rights reach domain controllers or Group Policy.

Why it matters: These groups can sign in to domain controllers, back up their files, create GPOs or configure DNS - each a short step from control of the domain. They are usually empty or small.

What to do next: Check the member added and who added it, whether a change request explains it, and the member's activity afterwards.

An executable or script in SYSVOL was written in the period - medium, pattern rule.

What happened: An executable, installer, script or shortcut in SYSVOL (NETLOGON included) was created or written on this domain controller inside the period the analyst gave.

Why it matters: Every host of the domain can read SYSVOL; a program placed there can be fetched and run by any of them, which is why a new one during an incident is worth a check.

What to do next: Get the file's hash and signature, look for a GPO that references it (the gpo_settings table: command and source), and check which hosts ran it (Executions).

Tickets were issued to accounts that do not require Kerberos pre-authentication - medium, fact rule.

What happened: The domain controller issued ticket-granting tickets without pre-authentication (4768, pre-authentication type 0) for {tickets_without_preauth} account(s): {tickets_without_preauth_list}.

Why it matters: For an account that does not require pre-authentication, anyone can ask for a ticket encrypted with its password and test guesses offline. Some legacy applications need the setting; most accounts never should.

What to do next: Check why each account has "Do not require Kerberos pre-authentication" set (Users: account changes), turn it off unless an application needs it, and change the passwords of those that keep it.

A GPO was created - low, pattern rule.

What happened: The domain controller's Security log records a Group Policy object created (5137, class groupPolicyContainer), by the account this signal names.

Why it matters: Creating GPOs is routine administration, and also the first step of deploying anything through Group Policy. Knowing who created which GPO and when helps place any later change.

What to do next: Read the GPO's content (the group_policy and gpo_settings tables, by its GUID) and confirm the creation with the account that made it.

A script that tampers with the Antimalware Scan Interface - high, pattern rule.

What happened: A command line, a script block PowerShell ran or a command in a user's PowerShell history referred to the Antimalware Scan Interface's internals - AmsiUtils, amsiInitFailed, AmsiScanBuffer, AmsiOpenSession or amsiContext - the names the published ways of switching AMSI off in a PowerShell session use.

Why it matters: AMSI is how the antivirus sees a script's content after it is decoded. A script reaching into its internals is almost always turning it off so the code after it runs unscanned; ordinary scripts and administration never touch these names. Security tools and their tests are the rare exception.

What to do next: Read the whole block and the blocks the same account ran just after it: they are what the bypass was for. Find the process and account that ran it and how the script reached the host, and check the antivirus's own log for detections around that time.

A command to delete Windows backups or their catalog - high, pattern rule.

What happened: wbadmin deleted the Windows Server Backup catalog, system state backups or backup versions (wbadmin delete catalog, delete systemstatebackup, delete backup) - on a command line, in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: With its catalog deleted, Windows no longer knows its backups exist and cannot restore from them; deleting system state backups removes the way back for a server or domain controller. Ransomware does this before encrypting, beside deleting shadow copies; an administrator does it rarely, to reclaim space or after moving a backup target.

What to do next: Find who ran it and from what parent, and look for the rest of the same preparation on this and other hosts in the same hour: shadow copies deleted, recovery turned off, services stopped. Check whether the backups themselves - on their target disk or share - are still intact.

A PowerShell command that decodes text and runs it as code - high, pattern rule.

What happened: PowerShell decoded or decompressed content (FromBase64String, GzipStream, DeflateStream) and ran text as code (Invoke-Expression, iex) in the same command line, script block, history line or transcript command.

Why it matters: Decoding a payload and running it from memory hides the code from anyone who reads the command, and from tools that look for known words: what actually ran is only in the decoded text. Scripts that administer hosts rarely need either step, let alone both together.

What to do next: Decode the content yourself (it is in the text) and read what it runs - without running it. Find the account and process that ran it and how the text reached the host (a file, a scheduled task, a service, a remote session), then follow the next script blocks, processes, files and connections of that account.

A PowerShell command that downloads code and runs it - high, pattern rule.

What happened: PowerShell fetched content from the network (Net.WebClient's DownloadString, DownloadData or DownloadFile, Invoke-WebRequest, Invoke-RestMethod, Start-BitsTransfer) and ran it with Invoke-Expression (iex) - on its command line, in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: Downloading code and running it straight from memory is how most PowerShell-based malware and attack frameworks stage their next step: nothing is written to disk for antivirus to scan, and the code can change with every request. A few installers work this way too, from their vendor's address.

What to do next: Read the address it fetched from and decide whether it is a known vendor's. If it is not, fetch nothing from it yourself; search the proxy and DNS logs for it, find what the downloaded code did (the next script blocks, processes, files and connections of the same account), and search the other hosts for the same address.

A command to save the SAM, SECURITY or SYSTEM registry hive to a file - high, pattern rule.

What happened: reg.exe saved or exported a whole credential-bearing registry hive - HKLM\SAM, HKLM\SECURITY or HKLM\SYSTEM - to a file, on a command line in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: The SAM hive holds the local accounts' password hashes, SECURITY the cached domain logons and LSA secrets (service account passwords among them), and SYSTEM the key that decrypts both. Saved together they are taken off the host and read offline; saving them is a standard credential-theft step, and rare in administration.

What to do next: Find the files the command wrote and whether they left the host (copies to shares, archives, uploads). Treat the local accounts' passwords, cached domain logons and service account passwords on this host as taken: reset them, check whether the local Administrator password is shared with other hosts, and look for their use elsewhere.

LSASS memory was dumped, or a command tried to - high, pattern rule.

What happened: A command dumped, or tried to dump, the memory of LSASS - the process that holds the credentials of everyone signed in: comsvcs.dll's MiniDump (by name or ordinal #24) through rundll32, a command line naming lsass with a full-memory dump switch (-ma), or a script calling MiniDumpWriteDump on lsass.

Why it matters: LSASS's memory holds password hashes, Kerberos tickets and sometimes clear-text passwords of every account signed in to the host. A dump is read offline to take those credentials and move to other hosts as those accounts - often a domain administrator's. Legitimate dumps of LSASS are made only by support engineers on request.

What to do next: Assume the credentials of every account signed in to this host since its last restart are taken: list them (Users and Logons modules), reset their passwords, and look for their use from other hosts afterwards. Find the dump file the command names, who ran the command and how they got onto the host.

An Office application spawned a shell or scripting engine - high, pattern rule.

What happened: An Office application (Word, Excel, PowerPoint, Outlook, Access or Publisher) was the direct parent of a shell or script host (cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe or mshta.exe).

Why it matters: Office documents do not normally start shells. This is one of the most reliable single indicators that a document - a macro, an embedded object or an exploit - ran code on the host after it was opened, typically the first stage of a phishing compromise.

What to do next: Identify the document that was open in the parent application at the process's start time (Office recent files, Outlook attachments, the user's Downloads and Content.Outlook folders). Read the child's command line to see what it ran, then look for what that stage did next: files written to the user's profile, scheduled tasks or Run keys, network connections, and later processes started by the same user.

A command to turn off or erase PowerShell's command history - high, pattern rule.

What happened: A command stopped PowerShell from keeping its history (Set-PSReadLineOption -HistorySaveStyle SaveNothing, or PSReadLine removed from the session) or deleted or overwrote a history file (ConsoleHost_history.txt), in a command line, script block, history line or transcript command.

Why it matters: The history file is where an analyst reads what was typed. Turning it off or erasing it removes that record on purpose, for the session or for good; administrators very rarely do either.

What to do next: Find the account and session that did it and when. What was typed after it is not in the history: look for it in script blocks (4104), transcripts, process creations and the shadow copies' history files, and check the same account on other hosts.

PowerShell text written to be unreadable - high, pattern rule.

What happened: The text of a script block, history line or transcript command measured as hidden with high confidence - three or more of the indicators Signal measures, each named with its count on the signal (powershell.obfuscation_indicators).

Why it matters: Writing code so a reader cannot follow it (backticks inside names, strings built piece by piece, reordered format strings, random case, long encoded runs, symbol-heavy text) is how attack tools keep their words from being found. Three measures together are rarely reached by written code.

What to do next: Read the whole block and the blocks PowerShell recorded after it from the same account: once decoded, PowerShell logs the code it actually runs as another block. Find how the text reached the host and what the account did next.

A command to turn off Windows recovery - high, pattern rule.

What happened: A command turned off the host's automatic recovery: bcdedit setting recoveryenabled to no or bootstatuspolicy to ignoreallfailures, or reagentc /disable turning off the Windows Recovery Environment - on a command line, in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: Ransomware turns recovery off, beside deleting shadow copies, so the host cannot be repaired or rolled back after it encrypts. Administrators rarely change these settings, and almost never on a workstation outside a planned build.

What to do next: Find who ran it and from what parent, and look for the rest of the same preparation on this and other hosts in the same hour: shadow copies or the backup catalog deleted, security or backup services stopped. Restore the settings once the host is contained (bcdedit: recoveryenabled yes on the boot entry; reagentc /enable).

A PowerShell command that loads a program from decoded bytes - high, pattern rule.

What happened: PowerShell loaded a .NET assembly from bytes in memory ([Reflection.Assembly]::Load or AppDomain's Load) that it decoded or downloaded (FromBase64String, GzipStream, DeflateStream, DownloadData) in the same command line, script block, history line or transcript command.

Why it matters: A program loaded from bytes never exists as a file: no antivirus scan of the disk, no Prefetch, no signature check sees it. Tools and implants are run this way so that only memory holds them; software that ships its own libraries loads them from files.

What to do next: Decode the bytes from the text (do not run them) and identify the program - its hash, its names. Find the account and process that ran the block, what started that process, and what it did next: connections, child processes, files and credentials touched.

A WMI subscription's script ran - high, pattern rule.

What happened: scrcons.exe - the process Windows runs a WMI subscription's ActiveScriptEventConsumer in - ran, or started another program.

Why it matters: scrcons.exe runs only when a permanent WMI subscription with a script consumer fires: a script stored in WMI's repository, with no file on disk, run as SYSTEM whenever its event happens. Almost no legitimate software uses script consumers; they are a known way to keep code running on a host.

What to do next: Find the subscription: Persistence lists every WMI subscription with its consumer's script and its filter's trigger (and its registration, WMI-Activity 5861). Read the script, find who registered it and when, and what the process it started did. Removing the subscription stops it; the repository keeps no history of it.

A command to delete volume shadow copies - high, pattern rule.

What happened: A command deleted the host's volume shadow copies: vssadmin delete shadows, wmic shadowcopy delete, or a PowerShell call deleting Win32_ShadowCopy objects - on a command line, in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: Shadow copies are the host's built-in way back to earlier versions of its files. Deleting them is a step almost every ransomware operation takes minutes before it encrypts, so the files cannot be restored without paying; legitimate deletion by hand is rare, and is normally a backup or storage administrator's planned task.

What to do next: Treat it as ransomware in progress until shown otherwise: find who ran it (account, parent process, logon session) and when, then look on this and other hosts for the same account's activity in the minutes around it - backups and recovery turned off, services stopped, files renamed or ransom notes written. Isolate the host if encryption has begun.

A command to resize shadow copy storage to almost nothing - high, pattern rule.

What happened: A command limited a volume's shadow copy storage to a size in megabytes or kilobytes - vssadmin resize shadowstorage with /maxsize in MB or KB - on a command line, in a script block PowerShell ran, or in a user's PowerShell history.

Why it matters: Windows keeps shadow copies only while their storage holds them: shrunk to a few hundred megabytes, the storage overflows and Windows deletes the copies itself. Ransomware operations use it as a quieter way to remove the host's earlier versions of its files than deleting them outright; an administrator sizing storage normally gives gigabytes or a percentage.

What to do next: Find who ran it (account, parent process, logon session) and when, and check the volume's storage and copies now (the Backup module's Shadow copies row, its volsnap records of copies lost). Then look around that time on this and other hosts for the other steps before encryption - copies deleted, backups and recovery turned off, services stopped.

A living-off-the-land binary ran with a known-abuse pattern - high, pattern rule.

What happened: A built-in Windows binary ran with a well-documented abuse pattern: certutil decoding or downloading a file (-decode, -urlcache), regsvr32 loading a remote or script-component DLL (scrobj.dll, /i:http), mshta fetching an http(s) URL, or rundll32 running an inline javascript: URL.

Why it matters: These signed Microsoft binaries are trusted by default, which is why attackers use them to download, decode or run payloads without bringing an executable of their own - a proxy-execution technique that can slip past application allow-listing. The matched arguments are rarely used by legitimate software.

What to do next: Read the command line and note any URL and any file written or decoded. Check whether that file still exists, its hash and signature, and whether it ran afterwards. Look at the parent process and the account to see what started the chain, and search the other hosts for the same URL or file name.

A Windows system process name ran from the wrong folder - high, pattern rule.

What happened: A program named like one of Windows' core processes - svchost.exe, lsass.exe, csrss.exe, smss.exe, wininit.exe, winlogon.exe, services.exe, spoolsv.exe, taskhostw.exe or lsaiso.exe - ran from a folder other than the one Windows runs it from (System32, or SysWOW64 for the 32-bit svchost.exe).

Why it matters: Windows starts these programs only from its own folder. A copy elsewhere borrows the name so that it passes a glance at a process list; it is malware far more often than anything else, since no installer has a reason to ship its own svchost.exe.

What to do next: Check the file's signature and hash, and whether it still runs and with what parent and account. Find how it got there (the process that wrote it, the account), what it connects to, and what persistence starts it again - a service, a task or a Run key naming its path (Persistence module).

A PowerShell command that starts a process on another host through WMI - high, pattern rule.

What happened: PowerShell called Win32_Process's Create method on another computer (Invoke-WmiMethod or Invoke-CimMethod with -ComputerName or a CIM session), in a command line, script block, history line or transcript command.

Why it matters: Starting a process on another host through WMI is a way to move from this host to others with an account's rights there, leaving no service or task behind. Deployment tools do it from their own servers; from an ordinary host it is rarely legitimate.

What to do next: Name the target computer and the command line from the text. On the target, find the process WmiPrvSE.exe started at that time and the network logon (4624 type 3) of the account that preceded it. On this host, find how the account's rights were obtained and what else it reached.

A COM object started a shell or scripting engine - medium, pattern rule.

What happened: A shell or script host (cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe or rundll32.exe) was started by dllhost.exe - the COM surrogate, where Windows runs a COM object for a caller on this host or, through DCOM, on another - or by mmc.exe, whose MMC20.Application object can run commands for a caller on another host.

Why it matters: COM objects that run commands can be called from another host through DCOM with an account's rights: the command then has a COM host as its parent and no trace of the caller. Software rarely starts a shell from the COM surrogate or the management console. Left out after the pass: a shell the COM surrogate started in the system's own logon session (a DCOM caller's command runs under the caller's account). A shell a management console started is always kept, whoever started the console.

What to do next: Read the command line. Look for the caller: a network logon (4624 type 3) of the account just before it, and the source address's host; on that host, the PowerShell or program that created the object. Then follow what the started process did.

PowerShell ran with an encoded command - medium, pattern rule.

What happened: PowerShell (powershell.exe or pwsh.exe) ran with -EncodedCommand - or its short aliases -e and -ec, or an unambiguous abbreviation such as -enc - executing a base64-encoded script instead of a plain-text one.

Why it matters: Encoding hides a script from casual review and from simple command-line matching. Some management tools use it legitimately, but it is standard in commodity malware, loaders and offensive frameworks - download cradles and in-memory payloads in particular.

What to do next: Decode the base64 argument (it is UTF-16LE text) and read what the script does. Check the parent process and the account: a management agent or a known administrative script under a service account is usually benign; an Office application, a browser, a script host or an interactive user is not. If the script downloads or runs code, find what it fetched, from where, and what ran afterwards.

PowerShell 2.0 was started - medium, pattern rule.

What happened: The Windows PowerShell engine started at version 2.0 (Windows PowerShell 400), from the command line shown - typically powershell.exe -Version 2.

Why it matters: PowerShell 2.0 has neither Script Block Logging nor the Antimalware Scan Interface: whatever ran in it was recorded by no PowerShell log and checked by no antivirus scan of scripts. Starting it on purpose is a known way to hide a script; very old management tools are the rare legitimate exception.

What to do next: Read the command line for what was run, and find the process creation (4688 or Sysmon) of the same moment for its parent and account. Look at what the same account did around that time - files written, connections, other processes - since the script's own content was not logged. Remove the PowerShell 2.0 feature where nothing needs it.

PowerShell text that looks written to be unreadable - medium, pattern rule.

What happened: The text of a script block, history line or transcript command measured as hidden with medium confidence - two of the indicators Signal measures, each named with its count on the signal (powershell.obfuscation_indicators).

Why it matters: Writing code so a reader cannot follow it (backticks inside names, strings built piece by piece, reordered format strings, random case, long encoded runs, symbol-heavy text) is how attack tools keep their words from being found. Two measures together are also reached by some packed or generated scripts.

What to do next: Read the whole block and the blocks PowerShell recorded after it from the same account: once decoded, PowerShell logs the code it actually runs as another block. Find how the text reached the host and what the account did next.

A PowerShell command that starts a process through WMI - medium, pattern rule.

What happened: PowerShell called Win32_Process's Create method (Invoke-WmiMethod, Invoke-CimMethod or [wmiclass]) on this host, in a command line, script block, history line or transcript command.

Why it matters: A process started through WMI is the child of the WMI service's host (WmiPrvSE.exe), not of PowerShell: the link between the script and what it started is broken in the process tree. Management tools do this; so does code that wants its next step to look unrelated.

What to do next: Read which command line was passed to Create, and find that process's creation (4688 or Sysmon) with WmiPrvSE.exe as its parent around the same time. Check the account that ran the script and whether the same was done on other hosts.

WMI loaded a provider from an unusual folder - medium, pattern rule.

What happened: WMI loaded a provider DLL (WMI-Activity 5857) from a folder providers are not installed to - not the Windows folder, Program Files or Microsoft's own ProgramData folders: a profile, Temp, ProgramData or another drive's folder.

Why it matters: A WMI provider is code WMI loads into its own host process, running as a service account, whenever a client asks for its classes. Registering a provider is a way to have code run inside WMI's trusted process; installers put theirs in the Windows folder or Program Files.

What to do next: Check the DLL: its signature, publisher and hash (the signal's program facts), when it appeared, and the provider's registration in WMI (its CLSID under the namespace). Find what registered it and whether other hosts load the same provider.

A WMI client worked with script or command consumers - medium, pattern rule.

What happened: A WMI client's failed operation or temporary subscription (WMI-Activity 5858, 5860) named a consumer that runs code (CommandLineEventConsumer, ActiveScriptEventConsumer), the programs that run them (scrcons.exe, wbemcons.dll), a script file (.vbs, .ps1) or a script object (ActiveXObject).

Why it matters: Creating, changing or querying code-running consumers is how a permanent WMI subscription is set up or checked; a failure means someone tried, whether or not a later attempt succeeded. Administration rarely touches these classes.

What to do next: Read the operation and its result code (access denied, invalid class...), the client's computer, account and process. Check Persistence's WMI subscriptions for one registered around that time (5861), and the account's other activity.

WMI started a shell or scripting engine - medium, pattern rule.

What happened: A shell or script host (cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe or rundll32.exe) was started by WmiPrvSE.exe, the WMI provider host - by a call to Win32_Process's Create method, made on this host or from another one.

Why it matters: Starting a command through WMI is a common way to run code on a host remotely with an account's rights, and its parent is WMI's host rather than whatever asked for it. Some management and inventory software does the same; an interactive shell or a script engine is less usual for them.

What to do next: Read the command line for what was run. Look for the caller: a network logon (4624 type 3) of the process's account just before it, WMI-Activity's records of the same moment, and on other hosts the WMI calls to this one (Invoke-WmiMethod or Invoke-CimMethod with -ComputerName, wmic /node). Then follow what the started process did.

A process ran from a suspicious location - low, pattern rule.

What happened: An executable ran from a place programs are not installed to: directly in a temporary folder (a user's Temp, or C:\Windows\Temp) or in C:\ProgramData itself, or anywhere under the Public profile or the Recycle Bin.

Why it matters: These places are writable without administrative rights, and a dropped payload is written straight into them; malware also hides in the Recycle Bin and the Public profile. Installers and build tools run from subfolders of Temp and ProgramData, and downloads from a user's Downloads - those are left out (a download that ran is Browsers' signal), so what remains is rarely benign; it is low severity because the place alone does not prove what the program is.

What to do next: Check the executable's signature and signer, whether the file still exists, and its hash against threat intelligence. Look at the parent process - a browser, mail client or Office application suggests a download or an attachment - and at what the process started in turn. Treat it as urgent if the file is unsigned, its name imitates a Windows binary, or it appears among this host's other signals.

A remote shell was opened on this host through WinRM - low, pattern rule.

What happened: WinRM created a shell on this host for a client (WinRM 91) - remote PowerShell (Enter-PSSession, Invoke-Command) or another WinRM shell - as the account and for the endpoint named on the signal. The record does not name the client computer.

Why it matters: A WinRM shell runs commands on this host with the account's rights, from another computer. Administrators and management tools use it; so does anyone moving between hosts with a stolen account. What ran in it is in the PowerShell logs, not here.

What to do next: Find the client: the network logon (4624 type 3) of the account at that time names its address. Check the account and that address against who manages this host, then read what ran in the session - script blocks (4104), processes started by wsmprovhost.exe (process.launched_by winrm) - and the client host's own records.

This host opened WinRM sessions to another host - low, pattern rule.

What happened: A WinRM session was opened from this host to another computer (WinRM 6) - remote PowerShell or other remote management - by the account and to the computer named on the signal. Sessions to this host itself are left out.

Why it matters: From an ordinary workstation or server, sessions to other hosts are how an account's reach extends beyond this one - an administrator's work, or someone moving between hosts. Which peers, how many and as whom decides which.

What to do next: Check the peers and the account against this host's role. On each peer, find the inbound shell (WinRM 91) and the network logon (4624 type 3) from this host at that time, and what ran there. Here, read the script blocks (4104) and the history of the account around the sessions.

Another computer used WMI on this host - low, pattern rule.

What happened: WMI recorded a client on another computer (WMI-Activity 5858, an operation that failed, or 5860, a temporary subscription) - the computer and account are named on the signal. WMI does not record the operations that succeeded: this is where a remote client is seen at all.

Why it matters: WMI from another host is how management, monitoring and inventory systems work - and how code is run on a host remotely. Which computer and account it was, and whether they are the host's known management systems, decides which.

What to do next: Check the client computer and account against the hosts and accounts that manage this one. If they are not, read the operation (a method such as Win32_Process.Create, a query) and find the network logon (4624 type 3) of the account at that time, then what it did on this host and on others.

An event log was cleared - high, pattern rule.

What happened: The Event Log service recorded that an event log was emptied (System event 104): the record names the log and the account that cleared it.

Why it matters: Clearing a log destroys the evidence it held - which is why intruders clear the logs that would show their activity (Sysmon, PowerShell, Windows Defender, RDP and task-scheduler logs; the Security log's own clear is event 1102). Administrators rarely clear logs on purpose, and a clear never removes the record of itself.

What to do next: Note which log was emptied, when and by which account - every clear of this log by this account is one signal, each clear on its timeline. Ask whether that account clears logs as part of its job. Everything the log held before that moment is gone from this host: look for the same activity in the other logs, on the other hosts and in central log collection (SIEM, Windows Event Forwarding) if it collected that log before the clear.

Security log was cleared - high, pattern rule.

What happened: The Security log was cleared (event 1102).

Why it matters: Clearing the log destroys the record of logons, privilege use and process activity before that moment. It is occasionally routine administration, but it is also a standard step in covering the tracks of an intrusion.

What to do next: Note who cleared the log and when - every clear by this account is one signal, each clear on its timeline; several clears are a much stronger sign of deliberate anti-forensic activity than one. Establish whether that account was expected to do so, then rebuild the lost period from other sources: forwarded events or a SIEM, EDR telemetry, the System log (event 104 for other logs cleared) and this host's other artifacts.

Security auditing is effectively disabled - medium, fact rule.

What happened: None of the {audit_subcategories_total} audit subcategories read on this host has Success or Failure auditing enabled.

Why it matters: Windows is recording almost no security events: logons, privilege use, process creation and policy changes all go unlogged, so this log cannot show what happened on the host.

What to do next: Establish whether auditing was disabled deliberately and when - a 4719 event, if the log still holds one, or the Group Policy applied to the host. Rely on other sources for this host, and restore an audit policy baseline.

Auditing that Group Policy applied is off on this host - medium, fact rule.

What happened: Group Policy's advanced audit policy (every GPO merged; from {audit_gpos}) turns on auditing that the policy in force does not have: {audit_gpo_not_in_force_list}.

Why it matters: Group Policy requires these events, but the host is not writing them: the audit policy was changed on this host after Group Policy applied it - with auditpol or a program setting the policy directly - which is how auditing is turned off to hide what follows. A legacy audit category that overrides these subcategories is ruled out (it is left out of this signal).

What to do next: Read the audit policy changes (event 4719) for who turned these subcategories off and when, if the log still holds them, and what that account did around that time. Treat the activity of the subcategories named as unrecorded since then.

A log that records from the start is turned off - medium, fact rule.

What happened: These event logs, which Windows (or the product that adds them) records to from the start, are turned off: {logs_turned_off_list}.

Why it matters: A log that is turned off records nothing from that moment on - what Signal reads from it (named beside each log) is missing for the time since. Turning a log off is one of the ways an intruder stops a host from recording what follows; an administrator rarely does it.

What to do next: Find out when and by whom each log was turned off - the log's last record is about when it stopped; look for the change in the other logs and in the commands run around that time. Rely on other sources for what the log would have recorded, and turn it back on once the host's state is preserved.

Audit policy was changed by an account other than the computer - medium, pattern rule.

What happened: The system audit policy was changed (event 4719) outside the system's own logon session - a user or service account changed it directly, rather than Group Policy or the local security policy being applied (which runs as the system, logon session 0x3e7).

Why it matters: Changing the audit policy by hand is rare; switching auditing off for a subcategory stops its events being recorded from that moment on, which is a standard way to hide later activity (for example turning off process creation or logon auditing before acting).

What to do next: Check which subcategory changed and how (the event's audit.subcategory and audit.changes - "Success removed" or "Failure removed" means auditing was turned off), who changed it, and from which logon session. Establish whether that account was expected to do so, then compare the host's current effective audit policy (Inventories page) with its baseline and look for event IDs that stop after the change.

Nothing has been recorded in the Security log since the host last started - medium, fact rule.

What happened: The host started at {boot_time}, {hours_since_boot} hours before this survey, but the newest event in its Security log is from {newest_event} - before the start.

Why it matters: Every start of Windows writes Security events (4608, the start of the audit system, and the logons that follow) while auditing works. A log whose newest event predates the start has recorded nothing since - auditing or the Event Log service is broken or was disabled before or during the start, and everything done on the host since is missing from this log.

What to do next: Check the Event Log service's state and the audit policy now, the System log's events around {boot_time} (service start failures, event 6005/6006), and anything that could have been configured to stop auditing at start (a Group Policy, a startup script, a changed service). Treat all activity since the start as unrecorded here.

The audit log could not be written - low, pattern rule.

What happened: Windows could not write events to the Security log (event 521).

Why it matters: Events generated while the log was failing were lost, not merely absent: activity in that period cannot be reconstructed from this log. It happens when the log is full and cannot overwrite, or when something interferes with the audit subsystem.

What to do next: Check whether the log was full at that time (the host's Security log size card) and its retention setting, and look for security products or tampering acting on the Event Log service around the event's time. Treat activity around that time as unrecorded and take it from other sources.

Events from different computer names are interleaved in this log - low, fact rule.

What happened: {computer_names_seen} computer names appear in the Computer field of this host's Security log, and their events overlap in time: {computer_names}.

Why it matters: A host's own log names only itself at any one time; a rename or a domain join shows as one name followed by the next, which does not raise this signal. Names logging at the same time mean events that did not all originate on this host as it is now: a Windows Event Forwarding collector, records copied or replayed from another machine, or possibly a Windows setup or upgrade phase logging briefly under a temporary, generated WIN-... name.

What to do next: Look at which name overlaps which, and for how long (the ranges above). A short burst under a generated WIN-XXXXXXXXXXX name that coincides with a Windows upgrade or reinstall on the host is most likely setup activity - confirm the upgrade date (the OS install date, the Windows.old folder, setup logs) before dismissing it. Otherwise check whether this host collects forwarded events; if it does not, examine the events that name the other computers - who and what they record, and whether their times fit this host's activity.

The system time was changed by a program other than the time service - low, pattern rule.

What happened: The system time was changed (event 4616) by a program other than the Windows Time service or a hypervisor's time synchronisation - each signal names the program and the account, with how far the clock moved and from what time to what time.

Why it matters: Every record written after a change of the clock carries a time shifted by the same amount, so the host's timeline no longer lines up with other hosts and with itself - and a clock set back can make files and records look older than they are. The Windows Time service and the hypervisors' time synchronisation change it routinely (left out); another program doing so is rare.

What to do next: Check which program changed the time, as whom, and by how much (a few seconds from a third-party time client is benign). Shift the times of the records after the change by that amount when building the timeline, and look at what the account did around the change.

A logon from an Internet address - high, pattern rule.

What happened: An account logged on over the network or by Remote Desktop from an Internet (public, routable) address.

Why it matters: Remote Desktop and file sharing exposed to the Internet are among the most common ways into a network: scanned constantly, brute-forced, and logged on to with stolen credentials. A successful logon from the Internet means the exposure is real and an account was used through it.

What to do next: Identify the address (owner, geolocation, threat intelligence) and whether this account is expected to connect from there. Look at what the session did - the processes the account started after the logon's time, and further logons from this host. If unexpected, disable the account, block the address, and close the exposure (firewall, VPN in front of Remote Desktop).

Many failed logons for one account within an hour - medium, fact rule.

What happened: The account {max_failures_account} failed to log on {max_failures_account_hour} times within 60 minutes ({max_failures_hour}) - the most for any account within any 60 minutes in this log.

Why it matters: People mistype a password a few times, not tens of times an hour: this many failures is a password-guessing attack, or a service or scheduled task running with an old password. A guessing attack that succeeds leaves a logon for the same account shortly after.

What to do next: Look at the failures' sources and reasons (Inventories, Logons: failed logons - "wrong password" means the account exists) and whether a successful logon for the account followed from the same source. Distinguish a stale saved password (one source, steady rate, a service's process) from an attack (remote sources, bursts, several accounts). Block the source, and reset the password if a logon succeeded.

A local account logged on from another computer - medium, pattern rule.

What happened: An account defined in this host's own account database logged on over the network or by Remote Desktop from another computer.

Why it matters: In a domain, people log on with domain accounts; a local account used from another machine is how lateral movement with a shared local administrator password - or its stolen hash (pass-the-hash) - usually looks. On a host in a workgroup every account is local, so people's own accounts reaching a shared folder are left out there; Windows' own local accounts (the built-in Administrator, Guest) are kept, being what a shared local administrator password or its stolen hash is used with.

What to do next: Check whether this host is in a domain and whether the account is expected to be used remotely (a documented break-glass or vendor account). Identify the source computer and what it was doing then, and look for the same local account logging on to other hosts from the same source. If unexpected, reset the password (and make local administrator passwords unique per host - Windows LAPS).

A logon with new credentials (runas /netonly, or pass-the-hash) - medium, pattern rule.

What happened: A logon of type 9 (new credentials) through the seclogo logon process: a process was started to use another account's credentials for network access, while running locally as its own user.

Why it matters: This is what `runas /netonly` records - and exactly what pass-the-hash and overpass-the-hash tools record, because they create the same kind of logon with a stolen hash instead of a password. Administrators use runas /netonly occasionally; on most hosts it is rare.

What to do next: Identify the account that started it (the event's subject, the same user's logon session) and the process that followed (Executions: process creations in that logon session). A pass-the-hash tool is often followed by network logons to other hosts with the credentials it carried. Confirm with the user whether they ran runas /netonly at that time.

Failed logons for many accounts from one source within an hour - medium, fact rule.

What happened: {max_spray_accounts} different accounts failed to log on from {max_spray_source} within 60 minutes ({max_spray_hour}).

Why it matters: Trying a few common passwords against many accounts - password spraying - avoids lockouts and is how many intrusions start. One source failing for many accounts in a short time is its signature (or a misconfigured scanner or monitoring tool).

What to do next: Identify the source (an address outside the network, or an internal host that should not be authenticating as several users), list the accounts it tried (Inventories, Logons: failed logons, filtered by the source), and check whether any of them then logged on successfully - from that source or any other. Block the source and reset any account that logged on.

Remote Desktop is reachable from the Internet - medium, pattern rule.

What happened: Remote Desktop accepted connections from, or refused a wrong user name or password from, Internet (public, routable) addresses (RdpCoreTS 131 or 140) - {count} such record(s); each signal lists its addresses.

Why it matters: A Remote Desktop port reachable from the Internet is scanned within hours and brute-forced constantly; it is one of the most common ways ransomware operators get in. Nothing here says anyone signed in - that is LOGON-FROM-PUBLIC-IP - but the exposure is real.

What to do next: Confirm how the port is reachable (a public address, a port forward on the router, a cloud security group) and close it or put it behind a VPN or a Remote Desktop gateway. Check for sign-ins from the same addresses (LOGON-FROM-PUBLIC-IP), for failed logons (LOGON-FAILURES-FROM-PUBLIC-IP), and whether Network Level Authentication is required (the Logons telemetry).

Remote Desktop sign-ins the Security log has no logon for - medium, fact rule.

What happened: {rdp_signins_without_logon} Remote Desktop sign-in(s) recorded by the session manager (LocalSessionManager 21) have no Remote Desktop logon (4624, type 10 or 12) of the same account within two minutes, although the Security log reaches over their time: {rdp_signins_without_logon_list}.

Why it matters: Every Remote Desktop sign-in creates a logon session, which the Security log records while logon auditing is on. A sign-in it has no record of means its record is gone - the log was cleared or edited, events were dropped - or auditing was off at that moment. An intruder who removes their traces from the Security log often forgets the Remote Desktop Services logs.

What to do next: Check the Security log around each time: is it continuous (LogIntegrity: clears, audit policy changes, gaps), and was logon auditing on? Then treat the session as real and unexplained: the account, its source address, what it did (process creations, other logons) and when it signed out (23). Rule out an account written differently in the two logs (a Microsoft or Entra ID account) before concluding.

Remote Desktop connections from this host to many servers in one day - medium, fact rule.

What happened: The account {max_rdp_servers_account} ran this host's Remote Desktop client against {max_rdp_servers_account_day} different servers on {max_rdp_servers_day} (UTC) (RDPClient 1024 - each a connection attempt, as typed: one server written as a name and as an address counts twice).

Why it matters: Hopping by Remote Desktop from one host to many others is how intruders move laterally and look for data once they hold an account; administrators do it too, from their own workstations or jump servers.

What to do next: Check whether this host is an administrator's workstation or a jump server and the account an administrator's. If not, list the servers (Inventories, Logons: Remote Desktop client connections), check each one for the sign-in at that time, and look at how this account got onto this host.

Remote Desktop accepts connections without Network Level Authentication - medium, fact rule.

What happened: The host accepts Remote Desktop connections (fDenyTSConnections is 0) and does not require Network Level Authentication (UserAuthentication is not 1, or the legacy RDP security layer is set) - as the registry says now, Group Policy's values first.

Why it matters: Without Network Level Authentication, anyone who reaches the port gets a session and the Windows sign-in screen before proving who they are: password guessing happens on the sign-in screen, and flaws in the session code before sign-in (BlueKeep, CVE-2019-0708) are reachable unauthenticated. It also changes what the logs mean: RemoteConnectionManager 1149 ("User authentication succeeded") is then written for the connection, before any password is checked.

What to do next: Require Network Level Authentication (System Properties, Remote; or Group Policy: Require user authentication for remote connections by using Network Level Authentication) unless a documented client cannot use it. Read this host's 1149 records as connections, not sign-ins, and check the Remote Desktop sign-ins (21) and logons (4624 type 10) instead.

A logon was tried with a disabled account - low, pattern rule.

What happened: A logon failed because the account is disabled (sub-status 0xC0000072).

Why it matters: Nobody should be using a disabled account: tries with one are an attacker working through known account names (Administrator, Guest), stale credentials saved somewhere, or a former employee's account still in use.

What to do next: Identify the account and source (this signal's line); if it is a built-in or former employee's account, find where the credentials are saved or who is trying them, and make sure the account stays disabled.

Failed logons from Internet addresses - low, pattern rule.

What happened: Logons failed from an Internet (public, routable) address.

Why it matters: Nothing logged on - but the host's logon services are reachable from the Internet and someone is trying them, the usual prelude to a brute-force or spraying success. {count} such failures are in this log.

What to do next: Confirm which service is exposed (Remote Desktop, file sharing, WinRM) and whether it should be; look for successful logons from the same addresses (a signal of their own, if any). Close or protect the exposure.

Windows reads its hosts file from another folder - high, pattern rule.

What happened: The TCP/IP stack's DataBasePath - the folder Windows reads the hosts file (and its networks, protocols and services files) from - is not Windows' own drivers\etc folder. The signal names the folder it points to.

Why it matters: Whoever controls that folder decides what names resolve to on this host, while the hosts file every analyst and tool checks stays clean. Nothing in Windows changes this value in normal use.

What to do next: Read the hosts file in the folder named and look for redirections; find when the value was written (the Tcpip\Parameters key's last write) and what ran then (Executions, Persistence). Restore %SystemRoot%\System32\drivers\etc.

The hosts file redirects a security or update service - high, pattern rule.

What happened: The hosts file maps a name of Windows Update, Microsoft Defender or SmartScreen, or of an antivirus or security vendor, to an address of its own choosing - which wins over DNS. The signal names the entry and the file.

Why it matters: Pointing these names at nothing (0.0.0.0, 127.0.0.1) stops the host from updating its antivirus and Windows and from reporting to its security console - what malware does to keep running; pointing them elsewhere sends the host's updates to an impostor. Some privacy and 'debloat' tools also block Microsoft names, which is why the entry itself must be read.

What to do next: Read the hosts file (the signal names it) and when it was last written; find what wrote it at that time (Executions, Persistence, the antivirus's own log). Remove the entry, then check that the antivirus updates and reports again, and look for what it was hiding.

A Windows binary abused to fetch or run code connected to the Internet - high, pattern rule.

What happened: A Windows program attackers use to download or run code while looking legitimate - mshta, rundll32, regsvr32, certutil, MSBuild, InstallUtil, RegAsm, RegSvcs, wscript, cscript, CMSTP, odbcconf, msxsl, hh, control, esentutl, expand, extrac32, finger or bitsadmin - connected out to an address on the Internet. The signal names every address, from the host's connections now and the logs that record them (Security 5156, Sysmon 3).

Why it matters: These programs rarely need the Internet themselves; when they connect out, they are most often fetching a script or payload (a remote .hta, a scriptlet for regsvr32, a file for certutil) or carrying a loaded DLL's command-and-control - code running under a signed Windows name.

What to do next: Find the process's command line and parent (Executions: 4688, Sysmon 1) - the URL or DLL it was given says what it fetched or ran. Check the address against threat intelligence and look for the file it wrote and what ran next. A rundll32 connection from a known vendor's DLL is the commonest benign case - the command line shows it.

An unsigned program is listening for connections - medium, pattern rule.

What happened: A program whose file is not validly signed (unsigned, or its signature or certificate chain does not verify) holds a TCP port open for connections on an address other than loopback, right now. The signal names the program, its process ID, account, signature state and every port it listens on.

Why it matters: Almost every program that legitimately accepts network connections on a Windows host is signed by its publisher; an unsigned listener is a backdoor, a tunnel or a tool someone brought, until shown otherwise. In-house and open-source tools are sometimes unsigned, which is why this is medium on its own.

What to do next: Identify the program: its folder, its hash against threat intelligence, its application (the Applications inventory) and how it started (Executions, Persistence). Find who connected to it (the host's connections now, the firewall's log, Sysmon 3 or Security 5156 where they exist). Ask its owner whether it is expected here.

A program from a user or temporary folder is listening for connections - medium, pattern rule.

What happened: A program running from a folder programs are not installed to - a temporary folder, the Public profile, the Recycle Bin, C:\ProgramData (other than Microsoft Defender's own platform folder), or one of a user's personal folders (Downloads, Documents, Pictures, Videos, Music and the like) - holds a TCP port open for connections on an address other than loopback, right now. The signal names the program, its process ID, account and every port it listens on.

Why it matters: A listener lets anyone who can reach the host connect to that program: a backdoor, a bind shell or a tunnel's end waits like this. These folders are writable without administrative rights and are where dropped and downloaded payloads run from. Portable tools and some installers listen from them too.

What to do next: Record the process (PID, command line, parent, account) and preserve the executable before it ends; check its signature, signer and hash. Look at who has connected to the port (the host's connections now, the firewall's log, Sysmon 3 or Security 5156 where they exist) and at how the program started (Executions, Persistence). Treat it as urgent if the file is unsigned, or the port is reachable from outside.

PowerShell connected to the Internet - medium, pattern rule.

What happened: PowerShell (powershell.exe, pwsh.exe or the ISE) connected out to an address on the Internet. The signal names every address, from the host's connections now and the logs that record them (Security 5156, Sysmon 3).

Why it matters: Download cradles, stagers and command-and-control frameworks run in PowerShell; a connection out from it is the moment a script fetched or sent something. Administrators and installers also download with PowerShell (modules from the PowerShell Gallery, vendor scripts), which is why this is medium on its own.

What to do next: Find what the script was: PowerShell's script blocks (4104) and history around the connection's time, the process's command line and parent (Executions). Check the address against threat intelligence, and look for files written and processes started right after.

Web traffic is sent through a program on this host - medium, pattern rule.

What happened: A proxy setting - a user's, the machine's or WinHTTP's, or an automatic configuration script's address - points at this host itself (127.0.0.1, ::1). Every web request that setting governs goes through whatever program listens on that port.

Why it matters: A local proxy sees, and can change, the user's web traffic - including secure sites when it has added its own certificate: how banking trojans and credential stealers intercept sessions. Debugging proxies (Fiddler) and some security and filtering products do the same, which is why this is medium on its own.

What to do next: Find the program listening on the proxy's port (Network's listeners table) and identify it; check the user's trusted root certificates for one added recently. If it is not a known tool, treat the user's web sessions and passwords as exposed.

Web traffic is sent through a proxy at a bare Internet address - medium, pattern rule.

What happened: A proxy setting - a user's, the machine's or WinHTTP's, or an automatic configuration script's address - names a bare Internet address rather than a name. Every web request that setting governs goes through that address.

Why it matters: An organisation's proxy is usually named; a proxy at a bare public address is how traffic is redirected to an attacker who reads and changes it, or how proxyware and adware route a user's browsing. A cloud security service can also be configured this way.

What to do next: Check the address against threat intelligence and the organisation's proxy configuration; find when the setting was written (its key's last write) and what ran then (Executions, Applications). Remove it if unknown, and treat the user's web sessions as exposed.

A program outside Windows is listening on a remote-access port - medium, pattern rule.

What happened: A program that is not part of Windows (not under C:\Windows) holds open a port remote-access tools use - SSH (22), Telnet (23), Remote Desktop (3389), Radmin (4899), VNC (5500, 5800, 5900, 5901), TeamViewer (5938), DameWare (6129), AnyDesk (6568, 7070), ScreenConnect (8040, 8041), RustDesk (21116, 21118) - on an address other than loopback, right now.

Why it matters: Someone can reach this host's desktop or shell through it, outside Windows' own Remote Desktop and its logging - one of the commonest ways intruders keep access. An IT department's sanctioned tool listens like this too.

What to do next: Identify the program and its application (the Applications inventory), and whether it is the organisation's sanctioned tool. If not: when it was installed or first ran (Applications, Executions), who connected to it (the host's connections now, the firewall's log, the tool's own connection log), and whether other hosts run it.

A whole drive is shared - medium, pattern rule.

What happened: The Server service offers a share whose folder is the root of a drive (C:\, D:\) - beyond the administrative shares (C$, ADMIN$) Windows creates for administrators itself. The signal names the share and the drive.

Why it matters: Everything on the drive is reachable over the network by whoever the share's permissions allow - often Everyone. Ransomware operators share whole drives to encrypt or collect from them across the network, and intruders to stage data. Some file servers are set up this way on purpose.

What to do next: Check the share's permissions and when it was created (the Shares key's last write, Security 5142 where audited); ask the host's owner whether it is intended. If not, remove it and look for access to it (Security 5140/5145 where audited, other hosts' connections to this one's port 445).

The host connected to file sharing (SMB) on the Internet - medium, pattern rule.

What happened: This host opened a connection to port 445 or 139 - Windows file sharing - at an address on the Internet. The signal names every address, from the host's connections now, the logs that record them (Security 5156, Sysmon 3) and the firewall's log.

Why it matters: Windows sends the user's NTLM credentials to an SMB server it connects to: a link, a shortcut or a document pointing at an attacker's \\address\share leaks a crackable hash of the user's password. SMB out to the Internet is also a way to copy data off the host. Organisations block it at the edge; this one reached it from here.

What to do next: Find what opened it - a document, a shortcut (.lnk, .url, .library-ms), an e-mail - from the program (System, for the SMB client) and the user signed in at the time. Check the address against threat intelligence, treat the user's password hash as leaked and reset the password if the address is not a known service, and check the network's edge for SMB out.

A program from a user or temporary folder connected to the Internet - medium, pattern rule.

What happened: A program running from a folder programs are not installed to - a temporary folder, the Public profile, the Recycle Bin, C:\ProgramData (other than Microsoft Defender's own platform folder), or one of a user's personal folders (Downloads, Documents, Pictures, Videos, Music and the like) - has a connection with an address on the Internet. The signal names the program and every address it was connected with, from the host's connections now and the logs that record them (Security 5156, Sysmon 3).

Why it matters: Payloads dropped or downloaded into these folders call their operator from there: this is what command-and-control, a download of the next stage or data leaving the host looks like. Updaters and portable tools also connect from these folders, so the address and the program decide.

What to do next: Check the program's signature and hash, and the addresses against threat intelligence (the remote_addresses table lists every Internet address and the programs that used it). Find how the program arrived and started (Executions, Persistence). If it is still running, record it and its connections before anything ends it.

An accessibility program is hijacked through its debugger - critical, pattern rule.

What happened: An Image File Execution Options Debugger is set for an accessibility program that runs at the logon screen (sethc - Sticky Keys, utilman, osk, magnify, narrator, displayswitch, atbroker): Windows runs the debugger instead, as SYSTEM, from the logon screen.

Why it matters: It gives anyone at the logon screen - locally or over Remote Desktop - a SYSTEM command prompt without signing in (press Shift five times). No legitimate software sets a debugger for these programs.

What to do next: Read what it runs (persist.command), usually cmd.exe. Remove the Debugger value once preserved, and treat the host as compromised: find when the key was written (persist.modified), and the Remote Desktop and console logons after it.

AppInit or AppCert DLLs are loaded into programs - high, pattern rule.

What happened: AppInit_DLLs is set with LoadAppInit_DLLs on, or an AppCertDlls value exists: Windows loads the DLL into every program that loads user32.dll (AppInit) or that creates a process (AppCert).

Why it matters: It injects a DLL into nearly every process on the host - a powerful, old persistence and interception technique. Modern software does not use it (Secure Boot disables AppInit on many hosts); a value here is almost always malware or old security software.

What to do next: Check the DLL (persist.program): signature, vendor, creation time. Check when the key was written (persist.modified). Remove the value once preserved.

BootExecute runs something besides autocheck - high, pattern rule.

What happened: The Session Manager's BootExecute lists a program other than Windows' own "autocheck autochk *": it runs before Windows starts, while the system is still booting.

Why it matters: A BootExecute program runs earlier than any security software, with full rights - used by a few disk tools (defragmenters, encryption) and by rootkits.

What to do next: Identify the program (a native executable in System32), its signature and vendor, and when the Session Manager key was written (persist.modified).

A user's COM class overrides the machine's with an unsigned DLL in a user folder - high, pattern rule.

What happened: A user's CLSID\{...}\InprocServer32 overrides a class the machine defines, pointing to a DLL in a user-writable folder that is not validly signed. Programs that use the class load that DLL instead of the real one.

Why it matters: COM hijacking needs no administrator rights and fires whenever an ordinary program (Explorer, Office, the browser) uses the class - a quiet, durable foothold. Real per-user COM servers (OneDrive's) are signed by their vendor.

What to do next: Check the DLL (persist.program): hash, creation time, what it is. Look up the class ID to see what it normally is. Remove the override once preserved.

A user logon script is set in the user's Environment key - high, pattern rule.

What happened: A user's HKCU\Environment\UserInitMprLogonScript value is set: Windows runs it at every logon of that user. The signal names the user and what it runs.

Why it matters: This value is a little-known logon script location that needs no administrator rights and no Group Policy; legitimate logon scripts come from Group Policy or Active Directory, not this value. Setting it is a known way to persist and to escalate when an administrator logs on.

What to do next: Read what it runs (persist.command) and check that file. Find when the value was written (persist.modified - the Environment key's last write) and what the user's session was doing then. Remove the value once preserved.

A non-default LSA package is loaded - high, pattern rule.

What happened: The LSA's Authentication, Security or Notification Packages list a DLL that is not one of Windows' own (msv1_0, kerberos, schannel, wdigest, tspkg, pku2u, cloudAP, negoexts, scecli, rassfm, livessp...). LSASS loads it at every start.

Why it matters: An LSA package runs inside LSASS and sees credentials: a password filter (Notification Packages) receives every new password in clear text; a security package can capture logons. Some are legitimate - password-policy products on domain controllers - and all are worth knowing.

What to do next: Find the DLL (System32\<name>.dll), check its signature and vendor, and when the Lsa key was last written (persist.modified). An unknown package is a credential-theft implant until proven otherwise.

The Office test key loads a DLL - high, pattern rule.

What happened: Software\Microsoft\Office test\Special\Perf names a DLL (persist.where, persist.command) - for the machine or a user. Office loads it every time an Office application starts.

Why it matters: The key is a developer's leftover Office still honours; no installed product uses it. A DLL there runs inside Word, Excel and Outlook for whoever opens them - a durable foothold that survives Office updates.

What to do next: Copy the DLL (persist.program) and its hash, check its signature and creation time, and when the key was written (persist.modified). Look for what wrote it at that time (process creations, the account). Remove the value once preserved.

A Run key starts a script host - high, pattern rule.

What happened: A Run or RunOnce value (or startup entry) starts mshta, wscript or cscript, or a shell or proxy host (PowerShell, cmd, rundll32, regsvr32) with an encoded, hidden or downloaded command or a script in a user folder.

Why it matters: Applications start their own programs at logon. A script host started at every logon - especially with a web address or encoded command - is a fileless foothold: the payload is in the value, a script, or on the internet.

What to do next: Read the whole command (persist.command), decode an encoded one, and check any script or address it names. Check when the key was written (persist.modified). Look for the same value on other hosts.

A service runs a command shell or script host - high, pattern rule.

What happened: A service was installed whose program is a command shell or script host (cmd.exe, PowerShell, mshta, wscript or cscript) rather than a service program of its own. The installation is in the System log (7045) and, when audited, the Security log (4697) - the signal names which, and whether the service is still configured now.

Why it matters: Real services are programs built to be services. A service that runs a shell is a one-off way to make the Service Control Manager execute a command as SYSTEM - the pattern remote-execution tools and intruders use to run code on a host they have credentials for, often removed again moments later.

What to do next: Read the image path: it holds the whole command that ran. If the Security log recorded the installation, it names the account that installed it (log.subject) and its logon session; otherwise find the logon behind it (network logons and explicit-credential use around that time). Check whether the same service name or command appears on other hosts at the same time - remote execution usually reaches several.

A service runs from a user-writable folder - high, pattern rule.

What happened: A service was installed whose program is in a folder any user can write to: under C:\Users (a profile, AppData, Public, Downloads), the Windows temporary folder, the Recycle Bin or C:\PerfLogs. The installation is in the System log (7045) and, when audited, the Security log (4697) - the signal names which, and whether the service is still configured now.

Why it matters: A service runs at every start, usually as LocalSystem. Installed software keeps its service programs under Program Files or Windows; a service pointing into a user-writable folder is how dropped tools gain persistence and SYSTEM rights - and anyone able to write that folder can replace what the service runs.

What to do next: Check the program the service runs: whether it still exists, its signature, signer and hash. If the Security log recorded the installation, it names the account that installed it (log.subject) and its logon session - follow that session back to its logon. Then look at the activity around the installation: the file's creation, other services or tasks created at the same time, on this host and others.

A netsh helper, print monitor, print processor or time provider loads an unusual DLL - high, pattern rule.

What happened: A DLL registered as a netsh helper, a print monitor or processor, or a time provider (persist.location, persist.entry) is outside System32 and SysWOW64, or not validly signed (persist.program, file.signature).

Why it matters: These DLLs are loaded by system processes - the print spooler and the time service run as SYSTEM at every start; netsh loads its helpers whenever it runs. Windows' own and printer vendors' are signed and in System32; anything else gives code SYSTEM's rights at every boot.

What to do next: Copy the DLL and its hash; check its signer, version resource and creation time against the registry key's write time (persist.modified). Find what installed it - a printer driver package explains a print monitor or processor. Compare with the organisation's other hosts.

A scheduled task is hidden from the Task Scheduler - high, pattern rule.

What happened: A scheduled task is configured in the TaskCache registry - where the Task Scheduler service runs tasks from - and its definition is there, but its entry has no security descriptor (SD) value, so schtasks and the Task Scheduler window do not show it. task.hidden says everything that hides it; persist.sources says where it was found.

Why it matters: Deleting a task's security descriptor makes it invisible to schtasks, the Task Scheduler window and most tools while it keeps running - the technique Microsoft documented in 2022 in the HAFNIUM group's Tarrask malware. No software does this by accident: it is a deliberate attempt to keep a foothold out of sight.

What to do next: Read what the task runs (persist.command) and check that program: its signature, hash and creation time. Preserve the TaskCache keys (Tree, and Tasks\ with the task's Id) before anything else - removing the task through the usual tools will not work. Find who made it: the TaskScheduler and Security logs' task changes for this path, and the activity around persist.modified. Look for the same task path on other hosts.

A scheduled task runs a script host with a hidden or downloaded command - high, pattern rule.

What happened: A scheduled task runs a shell or script host (PowerShell, cmd, mshta, wscript, cscript, rundll32, regsvr32) with a command line that hides or fetches what it runs: an encoded command, a hidden window, a web address, a script in a temporary or user folder.

Why it matters: Software that needs a scheduled job ships a program for it. A task that hands an encoded or downloaded command to a script host is the classic fileless foothold: nothing on disk but the task, run again at every trigger.

What to do next: Decode the command (persist.command): an encoded PowerShell command is Base64 of UTF-16. Find what it fetches or runs, and whether it ran (the TaskScheduler log's 200/201 for this task, process creations). Find who registered the task, and look for the same command on other hosts.

A scheduled task runs a program from a user-writable folder - high, pattern rule.

What happened: A scheduled task configured on the host runs a program from a folder any user can write to: under C:\Users (a profile, AppData, Public), the Windows temporary folder, the Recycle Bin or C:\PerfLogs - and the program is not validly signed.

Why it matters: Tasks are the most common persistence after Run keys. Installed software runs its tasks from Program Files or Windows; an unsigned program in a user-writable folder, started by a task, is how dropped tools come back after every logon or reboot - often as SYSTEM.

What to do next: Check the program: whether it exists, its hash and creation time. Read the task's triggers and principal (task.run_as) and who registered it (task.author is only a claim; the TaskScheduler and Security logs' task changes say who). Look for the same task path or program on other hosts.

Winlogon starts something other than Windows' own shell or Userinit - high, pattern rule.

What happened: Winlogon's Shell is not explorer.exe, or its Userinit is not C:\Windows\system32\userinit.exe, - or a user has a Shell of their own. Winlogon starts these at every logon.

Why it matters: Winlogon's Shell and Userinit values are run at every logon of every user; malware appends its own program to them ("userinit.exe, C:\...\x.exe") to start before the desktop. Kiosk and thin-client builds replace the shell on purpose - rare on an ordinary workstation or server.

What to do next: Compare the value with the defaults (Shell explorer.exe; Userinit C:\Windows\system32\userinit.exe,). Check every program it names, and when the Winlogon key was last written (persist.modified). Restore the default once preserved, unless the host is a deliberate kiosk.

A WMI subscription runs a command or script - high, pattern rule.

What happened: A permanent WMI event subscription (in root\subscription) binds an event filter to a CommandLineEventConsumer or ActiveScriptEventConsumer: whenever the filter's event happens - a time, a logon, a process start - WMI runs the command or script, as SYSTEM.

Why it matters: WMI subscriptions are one of the stealthiest footholds: nothing in Run keys, services or tasks, no file needed for an ActiveScript consumer, and they survive reboots. Windows' own subscriptions use log consumers, not command or script ones; some management software uses command consumers, rarely.

What to do next: Read the consumer's command or script (persist.command) and the filter's query (wmi.query) - what triggers it. Preserve the subscription (filter, consumer, binding), then remove it. Look for the same consumer name on other hosts.

An Active Setup component runs a program from a user-writable folder, or an unsigned one - medium, pattern rule.

What happened: An Active Setup component's StubPath (persist.where, persist.command) runs a program from a user-writable folder, or one that is not validly signed (persist.program, file.signature). Windows runs every component's StubPath once for each user at their next logon.

Why it matters: Active Setup runs its command in each user's session as that user, including administrators who log on later - a way to reach every account from one machine-wide key. Windows' and installed products' components run signed programs from their own folders.

What to do next: Read the command and check the program: hash, signer, creation time, and the component key's write time (persist.modified). Remove the component once preserved; check which users have logged on since (they ran it).

A BITS job transferred from a public IP address rather than a host name - medium, pattern rule.

What happened: The Bits-Client log records a BITS job transferring from a URL whose host is a public IP address (bits.url, bits.url_scope), created by bits.client, owned by bits.owner.

Why it matters: Updaters and Windows reach their vendors by name; a transfer from a bare public address is how a file is pulled from a server with no domain - a common staging pattern - through a trusted Windows service.

What to do next: Check the address (owner, reputation, the organisation's other hosts' connections to it - Network), what the file was (bits.file) and whether it ran or persisted afterwards (Executions, Persistence).

A BITS job was created by a shell, a script host or bitsadmin - medium, pattern rule.

What happened: The Bits-Client log records a BITS job created by a command shell, PowerShell, a script host, mshta, rundll32, regsvr32 or bitsadmin (bits.client), owned by bits.owner, transferring bits.url.

Why it matters: Applications and Windows create BITS jobs through their own programs; a job created from a shell or script is someone using BITS by hand - to bring a file past the proxy as a trusted Windows service, or as a job that runs a command when it ends and survives reboots. The command itself is in no event.

What to do next: Find the process creation of the client at bits.events' first time for its command line and parent. Check what the URL served and whether the file it brought ran (Executions). List the host's current BITS jobs (Get-BitsTransfer -AllUsers, as an administrator) for a notify command.

A program is started through another one's debugger or exit monitor - medium, pattern rule.

What happened: An Image File Execution Options Debugger, or a SilentProcessExit MonitorProcess, is set: whenever the named program starts (Debugger) or exits (MonitorProcess), Windows starts the configured program.

Why it matters: It makes one program's start run another - persistence that fires whenever an ordinary program runs, invisible in Run keys and tasks. Some is legitimate: Process Explorer and Process Hacker replace Task Manager this way, and developers debug with it.

What to do next: Read what it runs (persist.command) and for which program (persist.entry). A known tool replacing Task Manager is benign; anything else - especially a program in a user folder, or a script host - is a foothold. Check when the key was written (persist.modified).

An Office add-in loads an unsigned DLL from a user-writable folder - medium, pattern rule.

What happened: An Office add-in - a COM add-in's DLL, or an Excel XLL - registered for the machine or a user (persist.location, persist.where) loads a DLL or XLL from a user-writable folder that is not validly signed (persist.program, file.signature).

Why it matters: An add-in runs inside the Office application every time it starts, as whoever opens it. Most vendors' add-ins are signed and installed under Program Files; an unsigned one in a user folder is how an intruder keeps code running through Office without administrator rights.

What to do next: Check the file: hash, signer, creation time, what product it belongs to, and whether the user installed it knowingly. Compare with the organisation's other hosts - an add-in only this host has stands out.

A file is in Word's or Excel's startup folder - medium, pattern rule.

What happened: A file is in Word's STARTUP or Excel's XLSTART folder, the machine's or a user's (persist.where, persist.entry). Word loads every template there, Excel opens every workbook there, each time the application starts.

Why it matters: A template or workbook with macros in these folders runs its code whenever the user opens Word or Excel - a persistence that needs no administrator rights and looks like an ordinary document. Organisations deploy shared templates there too.

What to do next: Check whether the file carries macros and who put it there (its creation time, persist.modified). Compare with the organisation's deployed templates and the other hosts.

A PowerShell profile runs for every user - medium, pattern rule.

What happened: A PowerShell profile script for all users exists (in the Windows PowerShell folder): it runs at the start of every PowerShell session on the host, of every user, including administrators and scripts.

Why it matters: Windows ships no profile; administrators rarely create one for everybody. Code there runs with the rights of whoever starts PowerShell - a quiet way to persist and to catch an administrator's session.

What to do next: Read the script (persist.command is its path) and check when it was written (persist.modified). Remove anything nobody can account for.

A Run key starts an unsigned program from a user-writable folder - medium, pattern rule.

What happened: A Run or RunOnce value (or the old Load/Run values) starts a program from a folder any user can write to - under C:\Users, the Windows temporary folder, the Recycle Bin or C:\PerfLogs - and the program is not validly signed.

Why it matters: Run keys are the most common persistence there is. Many real per-user applications live in AppData, but they are signed by their vendor; an unsigned program there, started at every logon, is how commodity malware and dropped tools stay.

What to do next: Check the program: its hash, creation time and what it is. Check when the key was written (persist.modified). Look for the same value or program on other hosts.

A user's screensaver is a program outside System32, or not validly signed - medium, pattern rule.

What happened: A user's screensaver (Control Panel\Desktop SCRNSAVE.EXE, or its policy) is a program outside System32 and SysWOW64, or one that is not validly signed (persist.program, file.signature).

Why it matters: Windows runs the screensaver - an ordinary program, whatever its extension - whenever the user's session is idle. Windows' screensavers are in System32 and signed; another is a way to run code at every idle period as that user.

What to do next: Check the program: hash, signer, creation time, and when the value was set (persist.modified). Compare with what the organisation's policy deploys.

A script is in a Startup folder - medium, pattern rule.

What happened: A Startup folder (the machine's, or a user's) holds a script (.bat, .cmd, .vbs, .vbe, .js, .jse, .wsf, .hta, .ps1) or a shortcut to a script host.

Why it matters: Whatever is in a Startup folder runs at every logon. Applications put shortcuts to their programs there; a script there is a simple, common way for malware and intruders to persist.

What to do next: Read the script (persist.command is its path, or the shortcut's target) and check when it was written (persist.modified). Remove it once preserved.

A person's account registered a task that runs a program outside Program Files and System32 - medium, pattern rule.

What happened: A scheduled task was registered or updated by a person's account (not SYSTEM or a service) to run a program outside Program Files and System32. The signal names the account, the task and what it runs.

Why it matters: Installers register their tasks as SYSTEM or through their own services, for programs they put in Program Files. A person's account creating a task for a program elsewhere is how an intruder with a foothold, or a remote-execution tool, makes it run again.

What to do next: Check the account and logon session (log.subject, log.subject_logon_id): was that person working then, from where (the logon's source)? Check the program and whether the task still exists (the signal says when it is configured now).

A legacy .job scheduled task exists - medium, pattern rule.

What happened: A scheduled task is defined as a legacy .job file in C:\Windows\Tasks - the Task Scheduler 1.0 format that the at command and old tools create.

Why it matters: Current Windows and current software register tasks in the Task Scheduler 2.0 format (XML and the TaskCache registry). A .job file today is left over from very old software, or made by a tool that uses the old interface - which some intrusion tools still do, because fewer defenders look there.

What to do next: Read what it runs (persist.command), check that program, and the file's time (persist.modified). If nothing installed on the host explains it, treat it as the intruder's.

A scheduled task is defined in the registry but not shown by the Task Scheduler - medium, pattern rule.

What happened: A scheduled task has a definition in the TaskCache registry (TaskCache\Tasks, with its security descriptor), but no task XML file under System32\Tasks, and the Task Scheduler's own list (what schtasks and the Task Scheduler window show) does not include it. task.hidden says which; persist.command is what the registry definition runs.

Why it matters: Windows writes every task to both places and lists it; a definition left only in the registry is either a task Windows failed to clean up or one whose file was deleted to keep it from tools that read the task files and the Task Scheduler's list. It is weaker than a missing security descriptor (PERSIST-TASK-HIDDEN), but worth knowing what it runs.

What to do next: Read persist.command and check the program it names: its signature, hash and creation time. Compare the task path with other hosts (a Windows leftover appears on many). Find when it changed: persist.modified, and the TaskScheduler and Security logs' task changes for this path.

A driver is not signed, or its signature does not verify - medium, pattern rule.

What happened: A kernel or file system driver that loads - running now, or set to start at boot, at system start or automatically - has no signature, or a signature that does not verify (file.signature: unsigned or invalid), checked against the file at its path when Signal ran. A driver that starts only on demand and is not running is left out: Windows ships drivers for devices a host never had, whose catalogs are registered only when the device is installed.

Why it matters: A driver runs in the kernel, with full control of the host and below every security product. 64-bit Windows refuses to load an unsigned driver unless driver signing is disabled or test signing is on - so an unsigned driver that loads points either at a host whose protections were weakened, or at a rootkit waiting for them to be.

What to do next: Check whether the driver is loaded (its state), the file's hash (file.sha256) against threat intelligence, when its service key and file were created, and whether test signing or driver signing enforcement was changed on the host (bcdedit). Find what installed it: the service installation event, the process and account around that time.

A driver with a known vulnerability is installed - medium, pattern rule.

What happened: A driver was installed, or is configured now, whose file name is that of a driver with a published vulnerability that lets a program read and write kernel memory - drivers attackers bring themselves to switch off security products ("bring your own vulnerable driver"): rtcore64.sys, rtcore32.sys, gdrv.sys, dbutil_2_3.sys, iqvw64e.sys, capcom.sys, asrdrv101.sys, asrdrv102.sys, asrdrv103.sys, asrdrv104.sys, mhyprot2.sys, aswarpot.sys, kprocesshacker.sys, zamguard64.sys, zam64.sys, truesight.sys, winring0x64.sys, cpuz141.sys.

Why it matters: Through such a driver, a program with administrative rights reaches the kernel: it can end protected processes - EDR and antivirus first, as ransomware operators do before encrypting - remove kernel callbacks or load unsigned code. A legitimate tool (hardware monitoring, overclocking, an old utility) can also ship one; the name is a lead, the file's hash decides.

What to do next: Compare the file's hash (file.sha256, when configured now) with the LOLDrivers list (loldrivers.io) to confirm it is the vulnerable version. Find what installed it and when (the installation event, the process and account), whether the security products on the host stopped or lost their protection around then (Protection module), and whether a legitimate tool on the host explains it.

Defender is active but its AMSI provider is not registered - high, fact rule.

What happened: Microsoft Defender Antivirus is the active antivirus (Normal mode), but its Antimalware Scan Interface provider is not registered (HKLM\SOFTWARE\Microsoft\AMSI\Providers): script hosts hand their content to no Defender scan.

Why it matters: Without its AMSI provider Defender does not see what PowerShell, the script engines and Office macros run after decoding - fileless and obfuscated scripts run unscanned while the antivirus reports itself on. Removing the registration is a known way to blind it.

What to do next: Check the AMSI Providers key and its history (the auto-start entries; the registry's last write), find who changed it - process creations and the Security log around that time - and restore the registration (a Defender platform update or repair re-registers it). Treat scripts run since as unscanned.

An AMSI provider that is not an antivirus's is registered - high, pattern rule.

What happened: An Antimalware Scan Interface provider is registered whose DLL is not signed, or is outside the folders antivirus products install to (the Windows folder, Program Files, Defender's platform folder): every script host - PowerShell, the script engines, Office macros - loads it and hands it the content of every script it runs.

Why it matters: An AMSI provider sees all script content after decoding and can answer that it is clean. A provider that is not a security product's is a way to hide scripts from the antivirus, or to read them, and to run code in every script host; an antivirus's own provider is signed and in its install folder.

What to do next: Identify the DLL: its signature, publisher, hash and when it appeared (the entry's last write). Compare the providers with the antivirus products installed (Protection) - a provider with no product is not legitimate. Find what registered it, and check that the antivirus's own provider is still registered.

A threat was detected and not remediated - high, pattern rule.

What happened: The antivirus detected a threat and its log records no remediation of it: no action was recorded after the detection, the product took no action, or the action was one that leaves the item in place. The signal names the threat, the file or resource, the process that touched it and the account, and every event the log holds about the detection.

Why it matters: The threat may still be on the host and may have run. An unremediated detection is either one the product could not act on yet (a file in use, a scan still pending), one whose outcome event was lost (the log rolled or was cleared), or one someone dismissed.

What to do next: Check whether the file still exists (av.path) and its hash, signature and creation time; look at the process that touched it (av.process) and the account (av.user) - follow that process back in the Processes signals and the logon behind the account. Then check the product's current threat list and quarantine for this detection, and other hosts for the same threat name.

Every Windows Firewall rule was deleted - high, pattern rule.

What happened: Every rule was deleted from the Windows Defender Firewall's local store - the host's own persistent configuration (Firewall log 2033, 2059) - by the account and program named. Windows deleting the rules of the stores it rebuilds (Group Policy's result, the dynamic store) is routine and left out.

Why it matters: With its rules gone the firewall applies only its defaults - and the exceptions services needed are gone too, or, after a reset, whatever an intruder adds next is the only rule. Resetting the firewall is rare outside a rebuild; it is a way to undo the organisation's filtering.

What to do next: Find who did it and with what (the account and program on the signal, process creations at that time - netsh advfirewall reset, a PowerShell command). Compare the rules now with what Group Policy sets, and check what became reachable.

No antivirus is active on the host - high, fact rule.

What happened: No antivirus product is active on this host: {av_products_seen}.

Why it matters: Nothing on this host detects or blocks malware now, and nothing records detections: an empty detection history here means nothing was looked for, not that nothing ran. Turning the antivirus off is one of the first things an intruder does before running their tools.

What to do next: Find out when and how protection went away: the antivirus log's protection events (real-time protection turned off, settings changed - the Protection signals), the System log's service changes, and the Security log's process creations around that time for commands that stop, uninstall or reconfigure it. Treat the host as unprotected since then.

Antivirus protection was turned off - high, pattern rule.

What happened: Antivirus protection was turned off: real-time protection (event 5001), spyware or virus scanning (5010, 5012), or a protection setting set to disable it (5007: a Disable value set to 1 under Real-Time Protection, or the product as a whole). The signal names the event or the setting.

Why it matters: While protection is off, nothing is detected or blocked, and the log records no detections - an intruder turns it off before running their tools. A user or an administrator turning it off for a moment to install something is the common harmless case, and is usually followed by it being turned back on.

What to do next: Check whether it was turned back on (a 5000, or the same setting set back to 0) and how long it was off; check that it is on now (the protection KPI). Find who turned it off: the Security log's process creations and logons at that time (a command, a script, a settings change in the product's own window). Look at what ran on the host while it was off.

The antivirus failed to remediate a threat - high, pattern rule.

What happened: The antivirus detected a threat and tried to clean, quarantine or remove it, and the action failed (events 1118 or 1119). The signal names the threat, the file or resource, the action that failed and why.

Why it matters: The threat is still on the host. A failure is often a file locked by a running process - the threat itself running - or something protecting the file from the product.

What to do next: Read why it failed (av.error). Check whether the file still exists and whether a process runs from it (the Executions module's running processes); look at the process that touched it (av.process). Isolate the host if the threat is running, and remove it with the product's offline scan or by hand.

A quarantined item was restored - high, pattern rule.

What happened: An item the antivirus had quarantined was restored to its place (event 1009). The signal names the threat, the item and, where the event records it, who restored it.

Why it matters: The product had caught it; someone put it back. A restore is how a user gets back a file they believe is clean - and how an intruder gets back a tool the antivirus took away.

What to do next: Check the restored file now: whether it exists, its hash and signature, and whether it ran after the restore (the Executions signals). Find who restored it and why; if nobody can justify it, quarantine it again and look at what that account did around the time.

Tamper Protection blocked a change to the antivirus - high, pattern rule.

What happened: Microsoft Defender's Tamper Protection reverted a change to a protected setting (event 5013). The signal names the setting and the values the event records.

Why it matters: Something tried to change a protected setting - usually to turn protection off - outside the product's own management, and was stopped. The attempt itself is the evidence: a script or tool tried to weaken the antivirus.

What to do next: Find what made the change at that moment: the Security log's process creations (a command line writing the setting, or a tool), and the account and logon session behind it. The attempt failed here; check what else the same process or account did, and whether it tried on other hosts.

Tamper Protection was turned off - high, pattern rule.

What happened: Microsoft Defender's Tamper Protection was turned off (event 5007: Features\TamperProtection set to 4 or 0). On the host it was observed on, 4 was written when it was turned off and 5 when it was turned back on - Microsoft does not document the values.

Why it matters: Tamper Protection is what stops anything outside the product's own management from turning its protections off. Turning it off is the step before turning protection off - by a user in the Windows Security window, or by someone preparing to disable the antivirus.

What to do next: Look at what changed right after it: protection turned off, exclusions added, a threat allowed (the other Protection signals, minutes later). Check whether it was turned back on (the same setting set to 5) and is on now (the Tamper Protection telemetry). Find who was signed in at that time.

A detected threat was allowed - high, pattern rule.

What happened: The antivirus detected a threat and allowed it - by a person's choice in the product, or by a default action set for that threat (event 1117 with action Allow). The signal names the threat, the file and the account.

Why it matters: An allowed threat is left in place and runs freely, and the same threat is allowed again wherever the setting applies. Allowing a detection is sometimes a real false positive being dismissed, and sometimes an intruder, or a user, getting their tool past the antivirus.

What to do next: Judge the file the allow was for: its path, hash and signature, and who uses it. Find who allowed it - the account and the time - and whether the threat's default action was also set to allow (a setting change near the same time).

User Account Control is off - high, pattern rule.

What happened: EnableLUA is 0: User Account Control is off - every program an administrator starts runs with full administrator rights, without a prompt, and Windows' protections that rely on UAC (protected mode, the consent prompt) are off.

Why it matters: With UAC off, anything that runs as an administrator - a document's macro, a downloaded program - has full control of the host at once. Windows turns it on by default; it is turned off on purpose, by an administrator or by malware that wants its next step to need no prompt.

What to do next: Find when and by whom it was turned off (the key's last write, process creations and Group Policy around then). Check what ran with administrator rights since. Turn it back on (it needs a restart).

Windows keeps clear-text passwords in memory (WDigest) - high, pattern rule.

What happened: WDigest's UseLogonCredential is 1: Windows keeps the password of every account that signs in, in clear text, in LSASS's memory. Windows has not done so by default since Windows 8.1; the value has to be set.

Why it matters: Anyone who can read LSASS's memory - a credential dumping tool run as administrator - gets every signed-in account's password in clear text, not only its hash. Setting this value is a known step before dumping credentials; very old applications that need digest authentication are the rare reason.

What to do next: Find when the value was set (the key's last write) and by what - process creations and the Security log at that time. Treat the passwords of every account that signed in since as exposed: reset them, starting with privileged ones, and look for credential dumping (Executions' LSASS rule, Defender's detections). Set it back to 0.

A script was stopped as it ran (AMSI) - medium, pattern rule.

What happened: The antivirus detected a threat in a script's or macro's content as it ran - through the Antimalware Scan Interface (AMSI), after any decoding - and blocked it: PowerShell, the Windows script engines or an Office macro was running malicious code in memory. The threat, the program running it and the account are named.

Why it matters: An AMSI detection is not a file sitting on disk: code was being executed when it was stopped. What ran before it in the same script, and how the script was started, are what the analyst needs; a block often means the attacker will try another way.

What to do next: Find the script block PowerShell logged at that time (Executions: 4104, transcripts, history) and the process that ran it - its parent, command line and account. Look for what started it (a document, a task, a remote session) and for the attempts after it.

Cloud-delivered protection was turned off - medium, pattern rule.

What happened: Microsoft Defender's cloud-delivered protection (MAPS) was turned off (event 5007: SpyNet\SpyNetReporting set to 0).

Why it matters: Without the cloud the product recognises only what its local security intelligence already knows: new and rare threats - the ones made for one target - go undetected. It is turned off alongside real-time protection when the antivirus is being disabled.

What to do next: Check whether it was turned back on and is on now (the cloud protection telemetry), and what else changed at the same time (the other Protection signals). Find who made the change.

Windows blocked a driver or program its policy does not allow - medium, pattern rule.

What happened: Code integrity blocked a driver or file from loading (3077 - App Control for Business, or the vulnerable driver blocklist), or AppLocker prevented a program or script from running (8004, 8007). The file, the policy and the process are named; audit-mode records (3076, 8003, 8006) are counted on the detections card, not signals.

Why it matters: A blocked driver is often one known to be exploitable - loading it is how attackers get into the kernel to switch protections off; a blocked program is one the organisation decided must not run. Either way something tried, and may try another way.

What to do next: Identify the file - its hash, signer and where it came from - and the process or account that tried to load or run it. For a driver on the blocklist, find the program that ships it (a tool installed on purpose, or one dropped). Look at what that account did around the block.

A remediated threat came back - medium, pattern rule.

What happened: The antivirus detected a threat on a file or resource where it had already detected and remediated the same threat earlier in the log's window (av.returned): the remediation did not hold.

Why it matters: A threat that returns after it was cleaned or quarantined is being put back - by a download repeated, a task, a service or a script that restores it, or a person. Whatever brings it back was not found and is still on the host.

What to do next: Compare the detections' times and the process that touched the file each time (av.process): the same process, a scheduled time or a logon points at what restores it. Look in Persistence for an entry that writes or runs that path, and in Executions for what ran just before each detection.

An antivirus exclusion was added - medium, pattern rule.

What happened: An exclusion was added to the antivirus (event 5007 under Exclusions): a path, a process, a file extension or an address it no longer scans. The excluded item is the last part of the setting's name. One signal per antivirus product: every exclusion added is one of its occurrences.

Why it matters: What is excluded is invisible to the antivirus. Vendors and administrators add exclusions for real reasons (databases, backup agents); an intruder adds one for the folder their tools are in, so they are never detected again.

What to do next: Judge the excluded item: a folder a user can write to, a whole drive, a shell or script host, or a common executable extension is risky whoever added it. Check that it is still configured (Inventories, Antivirus exclusions), what was written to the excluded place after the change, and who made it - the Security log's process creations and logons at that time.

Exploit protection blocked a program's operation - medium, pattern rule.

What happened: Microsoft Defender's exploit protection blocked an operation (1121, 1123, 1126): an attack surface reduction rule stopped a technique, controlled folder access stopped a program writing to a protected folder, or network protection stopped a connection - the rule, the program and its target are named. Operations only audited (1122, 1124, 1125) are counted in the detections card, not signals.

Why it matters: The rules stop techniques attacks use - Office starting programs, scripts running downloads, credentials read from LSASS, unknown programs encrypting documents - so a block is often the moment an attack was stopped. Legitimate software trips some rules too, which is why the program and its target decide.

What to do next: Read which rule acted and on what. For a program that should not be doing it, find how it got there and what else it did (Executions, the detections, Persistence); for a known program, decide whether it needs an exclusion for that rule rather than the rule turned off.

A Windows Firewall profile is off on the host itself - medium, pattern rule.

What happened: A Windows Firewall profile is off by the host's own setting, not by Group Policy: on a network of that kind, nothing filters connections to the host's services. A profile Group Policy turns off is the organisation's configuration, shown in telemetry, not a signal.

Why it matters: Turning the firewall off exposes every listening service - remote desktop, SMB, a tool's own listener - to the networks the profile covers. An administrator troubleshooting does it and forgets; so does someone who wants a backdoor reachable.

What to do next: Check which profile the host's network uses now (the Firewall log's 2010 events), what listens (Network), and when the setting changed (the Firewall log's setting changes, the key's last write). Turn it back on, or set the exception that is actually needed.

A protection of the active antivirus is off now - medium, pattern rule.

What happened: The antivirus is the active one on this host (Normal mode) and reports a protection off now: real-time protection, behaviour monitoring, download scanning or on-access scanning. The signal says which.

Why it matters: What the protection covers is not detected now: with real-time protection off, files are scanned only when a scan runs. Protection off on the active product is either a deliberate change (signals of the change itself, if the log still holds it) or a broken product.

What to do next: Find when it went off: the Protection signals for the change (protection turned off, a setting, Tamper Protection), the antivirus log's window if none. Check whether a policy forces it off (the setting under Policies), and what ran on the host since. Turn it back on once the change is understood.

A real-time protection feature failed - medium, pattern rule.

What happened: A real-time protection feature of the antivirus failed (Defender 3002) - the feature and the error are named on the signal.

Why it matters: While the feature is failed, what it watches (files opened, behaviour, scripts, network inspection) is not checked. A failure can be a broken update or a resource problem; it is also what tampering with the product's driver or service looks like.

What to do next: Check whether real-time protection is on now (the Protection card) and whether the failure repeats. Look at what happened just before it: product updates (2001-2006), driver or service changes in the System log, processes that touched the product's files or services.

Local administrators get full rights from the network - medium, pattern rule.

What happened: LocalAccountTokenFilterPolicy is 1: a local administrator account that signs in from the network gets its full administrator rights, where Windows by default gives it a filtered, standard token.

Why it matters: This is what lets a local administrator's password - or its hash - be used from another host to run commands here (remote services, WMI, scheduled tasks). Some management tools ask for it; it is also set to open the way for lateral movement with a shared local administrator password.

What to do next: Find when and by what it was set, and whether a management tool documents needing it. Check the network logons (4624 type 3) of local accounts since, and whether the local administrator's password is the same on other hosts (LAPS). Set it back to 0 where nothing needs it.

A risky antivirus exclusion is configured - medium, pattern rule.

What happened: The antivirus excludes something that leaves a large or attacker-friendly blind spot: a whole drive or everything, a folder any user can write to (under C:\Users, the Windows temporary folder, the Recycle Bin, PerfLogs, or such a folder by its environment variable), a command shell or script host as a process, or a common executable or script extension.

Why it matters: Anything placed in that location, run by that process or saved with that extension is never scanned. A vendor needs nothing this broad; an intruder who can add an exclusion makes it this broad - or exactly the folder their tools are in.

What to do next: Find when and by whom it was added: the antivirus log's setting changes (the Antivirus signals, if the log still holds it), Group Policy or management settings if it is a policy exclusion. Look at what is in the excluded place now and what ran from it. Remove it unless someone can justify it.

A threat was detected and remediated - low, pattern rule.

What happened: The antivirus detected a threat and remediated it - cleaned, quarantined, removed or blocked it (event 1117 after 1116). One signal per antivirus product on the host: every remediated detection is one of its occurrences, each naming the threat and the file or resource; the example names the process that touched it and the account. A threat that came back after it was remediated is also PROT-DETECTION-RETURNED's signal.

Why it matters: The file was dealt with, but it reached the host: something downloaded, wrote or dropped it, and that may have succeeded with other files the product did not recognise. A tool category (hacking tools, remote access) on a host that has no business with it is a hands-on-keyboard intruder more often than an accident.

What to do next: Find how it arrived: the process that touched it (av.process), the account (av.user), the folder (a download, a temporary folder, a share) and what happened on the host around the detection's time - logons, process creations, other detections. Check other hosts for the same threat name.

A remote access tool started a command shell or a system tool - high, pattern rule.

What happened: A process of a remote access product started a command shell or a system tool, or the product's own log records it ran a command (remote.started names each, with its time, account and command line where recorded - ScreenConnect keeps only a command's length).

Why it matters: The tool's process as the parent means the command came through the tool - someone working on the host remotely; discovery commands, account changes and security changes run this way are an intruder's hands-on activity.

What to do next: Read each command line and its time against the tool's sessions (the remote_sessions table): which session, which peer. Follow what the commands did in the Executions, Users and Persistence modules.

Files moved through a remote access tool - high, pattern rule.

What happened: A remote access product's own log records a file moved through it (transfer.file), in the direction its words give (transfer.action), during a session (session.peer_id).

Why it matters: Remote access tools move files without a browser, a share or e-mail - the way intruders bring their tools in and take data out. A transfer is recorded by the tool, so a deleted file still leaves its name.

What to do next: Find the file (transfer.file) and its side: sent from this host means data that left - check what it held; written to this host means something brought in - check whether it ran (transfer.ran) and where it is now. Match it with the session's peer and time.

A remote access tool not on the approved list - high, pattern rule.

What happened: A remote access product is on the host and the analyst's approved list (the profile's modules.RemoteAccess.approved_tools) does not include it - or includes the product only for another tenant or server than the one this copy is enrolled to (remote.account, remote.tenant, remote.server).

Why it matters: An unapproved remote access tool is an unmanaged way into the host. Approving by tenant matters: an intruder's own copy of an approved product looks the same as IT's except for who it is enrolled to.

What to do next: Find its owner and why it is here; if no one claims it, treat its sessions (remote.sessions, the remote_sessions table) as the intruder's and look at what was done during them. Look for the same product and peer IDs on other hosts.

A port forward relays connections through the host - high, pattern rule.

What happened: Windows forwards connections it receives on a port to another address and port (netsh interface portproxy - remote.path_value names both; remote.path_target_scope says whether the target is on the Internet).

Why it matters: A port forward turns the host into a relay: an intruder reaches a system they cannot reach directly - Remote Desktop on a server, a domain controller - through a host they control, or exposes an internal service. Few organisations configure one.

What to do next: Find when it was configured (remote.path_changed, the key's last write) and by whom (the processes around that time - netsh.exe in the Executions module); check the Network module for connections to the listening port and from the host to the target.

A remote access tool ran without being installed - high, pattern rule.

What happened: A copy of a remote access product ran, or left its files, from outside any install location - a user's Downloads, Desktop, AppData or temporary folder, ProgramData, a share - with no installation behind it (remote.portable names each copy, who ran it, how often and when, and whether the file is still there). A copy that ran only before the product was installed is the installer and is said so, not counted.

Why it matters: A remote access tool run straight from a download needs no administrator and no installation record, lives only while it runs and leaves only its run records and a per-user folder - the way intruders use it to take control for a session, and the way social-engineering callers have victims run it. A long-standing installation is the common legitimate case; a portable copy is rarely IT's.

What to do next: Find who ran it and when (remote.portable, remote.run_as) and what led to it - a download (remote.downloaded), an e-mail, a support call. Read its sessions (remote.sessions, the remote_sessions table): who connected, from where, and what moved. Check what happened on the host while it ran: processes it started (remote.started), logons, files written.

A file moved through a remote access tool was then run - high, pattern rule.

What happened: A file a remote access product's log records as transferred has the name of a program that ran afterwards (transfer.ran names each run, its time and source) - by name, so a lead to confirm by path.

Why it matters: A program brought in through a remote session and run is the intruder's tool at work: scanners, credential tools, encryptors arrive this way.

What to do next: Confirm the path and hash of the program that ran (the Executions module), what it did, and whether it is still there; tie it to the session's peer and time.

A remote access tool runs under another file name - high, pattern rule.

What happened: A program whose version resource names a remote access product has a file name that is not one of the product's (remote.renamed names the file and what its version resource says) - the file was renamed after it was built.

Why it matters: Vendors do not ship their programs under other names; renaming a remote access tool - to a Windows process's name, an update's, a random one - is done to pass a glance at the process list or a block list by file name.

What to do next: Check where the renamed file is and who put it there (its folder, its creation time, the account that ran it - remote.run_as), and what started it (a service, a task - remote.service, remote.persists). Treat its sessions as unapproved until its owner explains it.

A remote access tool is set to start in Safe Mode - high, pattern rule.

What happened: A service of a remote access product is registered to start in Safe Mode with networking (remote.safe_mode names the key and its last write).

Why it matters: In Safe Mode most security software does not start; ransomware operators register their remote access tool there and restart the host into it to keep control while they encrypt.

What to do next: Check when the key was written and by whom (the incident's timeline), and whether the host was restarted into Safe Mode since (System log). Treat the host as at immediate risk.

A remote access tool's service runs from a user or temporary folder - high, pattern rule.

What happened: A service of a remote access product runs its program from a user's folder, a temporary folder or ProgramData (remote.service_user_folder) - where no installer puts a service.

Why it matters: A service starts with the host, as SYSTEM; one registered to a copy in a user or temporary folder makes a portable tool permanent without a proper installation - a common way to keep access.

What to do next: Find when the service was created (System 7045, the Persistence module) and by whom, and check the program file (remote.signer). Read the tool's sessions since the service's creation.

Remote Desktop sessions can be shadowed without the user's consent - high, pattern rule.

What happened: The Remote Desktop shadowing policy lets an administrator view or control a user's session without the user consenting (remote.path_value, remote.path_detail).

Why it matters: Shadowing without consent shows someone the user's screen - what they type and read - without their knowledge; intruders enable it to watch users of a server silently.

What to do next: Find who set the policy and when (remote.path_changed; a local or a Group Policy value), and look for shadowing in the Remote Desktop logs (mstsc /shadow runs in the Executions module).

Remote Assistance can be offered without being asked - medium, pattern rule.

What happened: Group Policy lets a helper offer Remote Assistance to this host without the user inviting it (remote.path_value; remote.path_detail says whether the helper may take control).

Why it matters: Unsolicited assistance is a built-in way to view or control a user's session that needs no third-party tool; the user is asked to accept, which social engineering gets past.

What to do next: Check that the organisation's help desk uses it and which accounts the policy names as helpers (the Offer Remote Assistance policy); look for msra.exe runs (the Windows Remote Assistance tool record).

A remote access tool reports to a server that is not its vendor's - medium, pattern rule.

What happened: A remote access product is configured to report to a server outside its vendor's own (remote.server) - an organisation's own server, or someone's.

Why it matters: A self-hosted server keeps the sessions out of the vendor's records and reports; intruders run their own relay or console for that reason. Organisations host their own too - the server's owner is the question.

What to do next: Find who owns the server (its name, its address in the Network module, the fleet: is it the same on the organisation's other hosts?). If it is not the organisation's, treat the tool as an intruder's channel.

Someone connected to the host through a remote access tool - medium, pattern rule.

What happened: A remote access product's own log records an incoming session: the other side's ID and name, the address the tool recorded, how the session was allowed, when it began and how long it lasted (session.*).

Why it matters: An incoming session is someone else controlling the host. Its peer ID is the same whichever host it connects to - the same ID on several hosts is one party reaching many.

What to do next: Identify the peer: is its ID or name the organisation's support (ask the tool's owner)? Check the address (session.address_scope, the Network module). Look at what happened on the host during the session - processes, logons, files - and at the files it moved (session.transfers). Search the fleet for the same peer ID.

A remote access tool first seen inside the period - medium, pattern rule.

What happened: A remote access product is first recorded inside the period the analyst gave (the profile's window): its installation, the creation of its folders, its first run or its first log line (remote.first_seen).

Why it matters: A remote access tool that arrives during the time of an incident is a candidate for how the intruder got in or came back; one installed long before is more likely the organisation's.

What to do next: Compare remote.first_seen with the incident's timeline: what came just before (a download - remote.downloaded, a logon, a process) and what came after (its sessions, the processes it started). Find who installed or ran it (remote.installed, remote.run_as).

A remote access tool's own log is missing or begins late - medium, pattern rule.

What happened: A remote access product that is installed or ran has none of the log it writes whenever it runs, or its logs begin after its first run (remote.log_state, remote.logs).

Why it matters: A tool's own log is the record of who connected and what moved; removing or trimming it is how a user hides use of it, and how an intruder covers a session. A tool run under another profile, or a log the product rotated away, explains some of these.

What to do next: Check the folder for the log's other files (rotated copies), the profile the tool ran as, and the folder's last write; take what the other sources say of its use - its runs, the processes it started, the network connections of its process - as the record instead.

A remote access tool was removed after it was used - medium, pattern rule.

What happened: A remote access product left evidence of use but is gone: Windows Installer recorded its removal, or the program its runs name is no longer on disk (remote.removed).

Why it matters: Removing a tool after use is how an intruder cleans up and how a user hides it; what remains - its runs, its folders and logs - is the evidence.

What to do next: Read what remains (remote.logs, remote.sessions, remote.portable) for when it was used and by whom; compare the removal's time with the incident's timeline.

Several different remote access tools on one host - medium, pattern rule.

What happened: More than one remote access product is on the host (remote.others names them all). With the profile's approved list given, it fires only when two or more of them are not approved.

Why it matters: An organisation usually standardises on one; ransomware operators often install a second and a third so that removing one does not lock them out.

What to do next: Find which of them the organisation uses and look at the others first: when each arrived (remote.first_seen), who installed or ran it, and their sessions.

An SSH key is authorized to sign in - medium, pattern rule.

What happened: The OpenSSH server accepts a key for the administrators or for a user (remote.path_kind; remote.path_value names the key by its type, comment and SHA-256 fingerprint - never the key; remote.path_detail says whether the server is installed and the key's restrictions).

Why it matters: An authorized key is a standing way in that needs no password: whoever holds the private key signs in - as an administrator when it is in administrators_authorized_keys. Intruders add their own key to come back; one added for the administrators is the strongest form.

What to do next: Ask whose key it is (its comment, its fingerprint - search the fleet for the same one); check when the file was written (remote.path_changed) and whether the OpenSSH server runs and is reachable (the Network module's listeners, port 22).

A tunnelling tool is on the host - medium, pattern rule.

What happened: A tool that tunnels connections between this host and a server outside the network (ngrok, Cloudflare Tunnel, FRP, Chisel, rathole, GOST, ligolo-ng, dev tunnels) or joins it to an overlay network (Tailscale, ZeroTier) is installed, ran, or left its files (remote.mode, remote.portable, remote.installed) - with the server or tunnel it is configured for (remote.server, remote.tool_id) and whether an account token is set (remote.token, never the token).

Why it matters: A tunnel opens the host - or the network behind it - to the outside through an outbound connection the firewall allows: intruders use one to reach internal systems and their own tools from outside, and ransomware operators to keep access. Developers and administrators use some of these too.

What to do next: Find who ran it and how it starts (remote.run_as, remote.service, remote.persists), where it tunnels to (remote.server, its configuration beside the program) and which ports it exposes; check the Network module for its connections. Ask its owner whether it is approved here.

Unattended access is configured - medium, pattern rule.

What happened: A remote access product's configuration holds an unattended access password or key (remote.unattended names where, and when it was last written) - someone can connect without a person at the host accepting. The value is never read into the output.

Why it matters: Unattended access is how a tool becomes a standing way in: intruders set a password of their own so they can return whenever they like.

What to do next: Check when it was set (the file's or key's last write) against the tool's installation and the incident's timeline, and whether the organisation configures this product unattended. Read its incoming sessions allowed by that password (session.auth).

WinRM accepts unencrypted traffic or Basic authentication - medium, pattern rule.

What happened: The WinRM service is configured to accept unencrypted traffic or Basic authentication (remote.path_kind, remote.path_value - from its configuration or Group Policy; remote.path_detail says the service's state).

Why it matters: Unencrypted WinRM over HTTP carries commands and their output readable on the network, and Basic authentication sends the password itself; both let someone on the network read or replay credentials used to manage the host remotely.

What to do next: Check whether this is deliberate (Group Policy, a management product), whether the service runs and listens (the WinRM listener rows, the Network module), and who connected to it (logon type 3 in the Logons module).

This host's WinRM client trusts every host - medium, pattern rule.

What happened: The WinRM client's trusted hosts include "*" (remote.path_value): it connects to any host and sends it credentials without checking who the host is.

Why it matters: With every host trusted, a credential used from this host for remote management can be sent to a host impersonating another; intruders set it to manage hosts by address from a foothold.

What to do next: Check who set it and when (remote.path_changed; Group Policy if from the policy key), and which hosts this one managed (outbound connections to 5985/5986 in the Network module, explicit credentials in the Logons module).

A remote access tool is on the host - low, pattern rule.

What happened: A remote access product is on the host - installed, run without installation, or its own files left (remote.mode) - read from every place that records it (remote.sources): its installation, services, the programs that ran, its folders, configuration and logs. A product the profile's approved list (modules.RemoteAccess.approved_tools) approves is left out: its presence is not a signal, what it did still is.

Why it matters: Remote access tools let someone control the host through the vendor's cloud, past the firewall, with signed software security products rarely block - which is why intruders and ransomware operators install or run them for access and to come back. Organisations use them too: the question is whether this one is theirs.

What to do next: Check whether the organisation approves this product (give the list as the profile's modules.RemoteAccess.approved_tools to have it compared). Read the rest of the record: how it got here (remote.installed, remote.portable, remote.downloaded), who it is enrolled to (remote.account, remote.tenant, remote.server), and what its logs record (remote.sessions, remote.peers) - the other signals of this tool say what stands out.

A predefined pivot point from the profile "{profile_name}" was found on this host - critical, fact rule.

What happened: {pivots_found} of the {pivots_given} pivot point(s) in the run's profile were found on this host: each signal is one pivot point, its occurrences every record and direct check that holds it.

Why it matters: The host shares a file, an account, an address or another trace with the incident the profile describes: it is in scope - it may be where the intruder went next, or where they came from.

What to do next: Treat the host as part of the incident: preserve its evidence before anything is changed, then read each pivot point's occurrences - which source holds it, when, under which account - and the entity pages they lead to. Add what is new on this host (programs, accounts, addresses) to the profile as pivot points, and run the fleet again.

An account was set to need no password, no Kerberos pre-authentication, or a reversible password - high, pattern rule.

What happened: An account change (event 4738) turned on a flag that weakens how the account authenticates: password not required, Kerberos pre-authentication not required, or password stored with reversible encryption (log.account_flags_set says which).

Why it matters: "Password not required" lets the account have an empty password; without Kerberos pre-authentication, anyone can request a ticket for the account and crack its password offline (AS-REP roasting); reversible encryption keeps a password that can be recovered as text. Each is a way to take over the account later, and none is set by Windows on its own.

What to do next: Check who changed it (this signal names them) and whether it is documented (a legacy application that needs it); clear the flag unless it is. Look at the account's logons since, and whether its password was reset or it was added to a group around the same time.

A local account's name ends in $ - high, pattern rule.

What happened: A local account's name ends in "$" - the naming `net user` hides from its list.

Why it matters: Only computer accounts end in "$", and they live in a domain, not in a host's own account database. A local user named this way is hidden from the most common way of listing accounts - a known persistence technique.

What to do next: Find when and by whom it was created (event 4720), whether it is an administrator (this row and the Users page say), and its logons. Unless it is explained, treat it as an intruder's account: disable it and scope what it was used for.

A local account is named like a Windows identity - high, pattern rule.

What happened: A local account carries the name of an identity Windows defines itself (SYSTEM, LOCAL SERVICE, NETWORK SERVICE, a DWM-n or UMFD-n session account, TrustedInstaller), or is named Administrator or Guest without being the built-in account of that name.

Why it matters: Windows' own identities are never local accounts, and the built-in Administrator and Guest are known by their relative IDs, not their names. A local account named like them is made to be overlooked - in a list of accounts, in logon events, and by tools that leave Windows' own identities out by name. Signal classifies accounts by SID, which is why it shows this one.

What to do next: Find when and by whom it was created (event 4720), what groups it is in, and its logons. Unless it is explained, treat it as an intruder's account.

SID history was added to an account - high, pattern rule.

What happened: SID history was added to an account (event 4765), or an attempt to add it failed (4766): the account carries the SID(s) this signal names, and every right they have.

Why it matters: SID history exists for migrating accounts between domains and is otherwise almost never changed. An intruder who adds a privileged SID - a Domain Admins group's, from this or another domain - to an ordinary account makes it an administrator without any group membership showing it.

What to do next: Check which SID was added (log.sid_history) and what it is - a privileged group's ends in -512 (Domain Admins) or -519 (Enterprise Admins) - and who added it; unless a documented domain migration explains it, remove the SID history, reset the account's password, and investigate how the account that made the change got the rights to do it.

A user account was created - medium, pattern rule.

What happened: A user account was created (event 4720): the account named on the signal's line, by the account this signal names.

Why it matters: Creating an account is a standard way for an intruder to keep access (a local account survives password resets of the ones they stole). On a host where accounts are not normally created by hand, every creation deserves a reason.

What to do next: Check who created it and from which logon session, whether it was then added to a group (4732 - Administrators especially), and its logons afterwards. Compare with the change or ticket that should explain it.

A member was added to the local Administrators group - medium, pattern rule.

What happened: A member was added to the host's local Administrators group (event 4732, group SID S-1-5-32-544 - the same in every language).

Why it matters: Local administrator rights give full control of the host: an intruder adds an account they control to keep that control, and it is also how rights creep in over time.

What to do next: Check the member added and who added it (this signal's line names both), whether that was expected, and what the member did as an administrator afterwards (its logons, administrative logons, processes).

A broad group is a member of the local Administrators group - medium, pattern rule.

What happened: A group that stands for many or all users - Everyone, Authenticated Users, Interactive, Users, or a domain's Domain Users or Domain Computers - is a member of the host's local Administrators group.

Why it matters: Every account in that group is an administrator of this host: any user, or any computer of the domain, has full control of it. It is a serious misconfiguration, and a way an intruder can grant themselves rights that look like policy.

What to do next: Remove the group from Administrators unless there is a documented reason, find when it was added (event 4732, or the Group Policy that sets the group's members), and review administrative activity on the host since then.

An account was enabled again after a long time disabled - medium, fact rule.

What happened: {accounts_reenabled} account(s) were enabled (event 4722) at least 30 days after they were disabled (4725), both in the Security log: {accounts_reenabled_list}.

Why it matters: An account nobody has used for weeks is an intruder's favourite: enabling it gives them a working, legitimate-looking account that its owner will not notice being used - often a former employee's or a vendor's.

What to do next: Check who enabled it (the account's changes, on the Users page) and whether a change request explains it; then the account's logons since (Logons: account, type, source), its group changes (4732), and its password reset (4724). Disable it again unless the enabling is explained.

The Guest account is enabled - medium, pattern rule.

What happened: The built-in Guest account (relative ID 501, whatever it is named) is enabled on this host.

Why it matters: Guest is disabled on every supported Windows by default. Enabled, it is an account anyone can sign in with - often with no password - locally or over the network, and intruders enable it to keep a way back in that looks like a Windows default.

What to do next: Find who enabled it and when (event 4722, if the log still holds it - this signal names it when it does), check its password state and its logons (Logons: account, type, source), and whether it was added to any group. Disable it unless there is a documented reason.

An account's password was reset by another account - medium, pattern rule.

What happened: An account's password was reset (event 4724) - set without the old one, by the account this signal names, not by the account's own user (who changes it with 4723).

Why it matters: Resetting a password is how an intruder with administrative rights takes over an existing account - it keeps the account's history and groups and looks routine. Administrators and help desks reset passwords too, and creating an account with a password can record one right after its creation (4720).

What to do next: Check who reset it and whether a ticket or the account's creation explains it; then whether the account signed in afterwards, from where (Logons), and whether its user still can. Unless it is explained, reset it again and investigate the account that made the change.

A user account was deleted - low, pattern rule.

What happened: A user account was deleted (event 4726) by the account this signal names. If the account was created in the log's window too, the Users page lists both, with what it did in between.

Why it matters: Intruders delete the accounts they created once they are done with them, to leave less behind; deleting accounts is also how they lock people out (ransomware operators do it before encrypting). It is also ordinary administration.

What to do next: Check whether the account was created recently (4720 - the account's changes on the Users page), what it did while it existed (its logons and processes), and who deleted it. A profile folder may remain on disk (Users: profile folders no account owns), still holding its files.

A handler runs code for a static file type - high, pattern rule.

What happened: A handler mapping (IIS's configuration or an application's web.config) has a server-side code handler - ISAPI, CGI, FastCGI or an ASP.NET page, handler or service factory - serve a file type that is normally static: images, text, style sheets, browser scripts, documents (web.module_path, web.module_image, web.module_declared).

Why it matters: With such a mapping, a file that looks like an image or a text file runs as code when it is requested - a webshell can hide among the site's ordinary files, where a review of its scripts does not look.

What to do next: Read the declaring file (web.module_declared) and its last write time; list the files of that type under the site and check which were written apart from its deployments. Remove the mapping once the files are preserved, and compare with the organisation's other servers.

IIS loads a native module from an unusual place, or one not validly signed - high, pattern rule.

What happened: IIS's configuration loads a native module (globalModules) whose DLL is outside IIS's, the .NET Framework's and Program Files' folders, or is unsigned or not validly signed (web.module_location, file.signature, web.module_image).

Why it matters: A native module runs inside every IIS worker and sees every request of every site; IIS's own modules and installed products' live in those folders and are signed. A module elsewhere, or unsigned, can read requests and credentials without a single script on disk.

What to do next: Copy the DLL and its hash; check its signer, version resource and creation time, and when applicationHost.config was last written. Find what installed it (Windows Installer, the account that wrote the file) and compare with the organisation's other IIS servers - a module only this server loads stands out.

A web server process started a shell or a system tool - high, pattern rule.

What happened: A web server's process - IIS's worker (w3wp.exe), Exchange's Unified Messaging worker, Apache httpd, nginx, PHP's FastCGI process or Tomcat's service - was the direct parent of a command shell, PowerShell, a script host, or a Windows tool that reports on the host and its network (process.parent_name, process.name).

Why it matters: Web servers serve requests; they rarely start shells. A webshell, or an exploited application, runs its commands this way - so this is often the moment someone acted on the host through a site, as that site's account.

What to do next: Read the command line and the account (an IIS pool's account names the pool). Find the site whose pool or server it was, and its request log at that minute - the request that caused it names the script and the client address. Check that site's scripts (WEB-WEBSHELL-* on this host) and what else the same parent started.

A server-side script carries strong webshell indicators - high, pattern rule.

What happened: A server-side script in a web site's folders carries indicators that together point strongly to a webshell (web.confidence high): the antivirus detected it, its name disguises its type, or three or more of - written alone after the site's last deployment, placed in an upload, image or temporary folder, the only script among static files, a hidden or system attribute, requested with POST, written inside the period (web.indicators).

Why it matters: A webshell lets whoever can reach the site run commands on the host as the site's account (web.identity on the site) - often the first foothold on a public-facing server, and a way back in after other access is removed. Its content was not read: the confidence comes from where and how it was placed.

What to do next: Read the script's indicators and requests (web.indicators, web.requests). Copy the file and its hash before anything changes it, and compare it with the site's source or a clean deployment: a file the application's owners do not recognise is the finding. Search the site's request log for every request to its URL (web.url) - the client addresses and times - and the host for what the web server's process started around those times (WEB-SERVER-STARTED-PROCESS, Executions). Look for other scripts written at the same time on this and the organisation's other web servers.

A server-side script carries webshell indicators - medium, pattern rule.

What happened: A server-side script in a web site's folders carries two webshell indicators, or a hidden or system attribute (web.confidence medium; web.indicators).

Why it matters: Two of these together are unusual for a file the site's deployment put there; a webshell placed by hand often shows them. Applications that let users upload content, and fixes made by hand, show some of them too.

What to do next: Read the script's indicators and requests (web.indicators, web.requests). Copy the file and its hash, and compare it with the site's source or a clean deployment: a file the application's owners do not recognise is the finding. Search the site's request log for requests to its URL (web.url) and the host for what the web server's process started around those times.

A server-side script carries one webshell indicator - low, pattern rule.

What happened: A server-side script in a web site's folders carries one webshell indicator (web.confidence low; web.indicators): written alone after the site's last deployment, in an upload, image or temporary folder, the only script among static files, requested with POST, or written inside the period.

Why it matters: One indicator alone is common - a fix made by hand, a page added later - but it is how a webshell placed after the site's deployment looks from the outside. Weigh it with the site's other signals and where it listens (web.bindings).

What to do next: Check whether the application's owners know the file (web.file, its times). If not, treat it as the medium and high signals: copy it with its hash, and read the site's request log for its URL (web.url).