Sysmon Configuration Management

Athena manages the Microsoft Sysmon configuration on your Windows endpoints. It shows which machines run Sysmon and which configuration each one has loaded. You can keep named, versioned configurations, build and validate rules in an editor, and deploy a revision to the fleet. A machine that runs a different configuration is flagged as drifted. Optionally, a Compliance rule keeps checking every machine and re-applies the configuration automatically. Everything runs on your server, so it works the same on an air-gapped network.

Where Sysmon appears#

• Policies → Sysmon (/policies/sysmon), in the Policies group of the left navigation. It has the fleet status, the agents table and your configurations. Screens you open from it (New configuration and the rule editor) show a Policies / Sysmon breadcrumb. Until October 2026 this was the Settings → Sysmon tab; old /settings/sysmon bookmarks still redirect for one release.
• Agent details → Sysmon, a tab after the Compliance tabs. It shows one machine's state, Sysmon version, schema, expected revision, last report, loaded config file and full config hash. It also has a refresh button, a Sysmon policies link and, when Athena knows which configuration the machine should run, Open configuration in editor.
• Dashboard → Sysmon fleet, a wide widget with counts for In sync, Drift, Not managed, No config, Error and Offline, plus an Open Sysmon link.

Sysmon has three permissions:

• View Sysmon (sysmon.view), held by the built-in Helpdesk, Operator and Admin roles. It is needed to see any of the screens above and for every read in the REST API. Without Manage Sysmon, the Sysmon page is read-only.
• Manage Sysmon (sysmon.manage), held by Operator and Admin. It is needed for every change: uploading, editing, renaming and deploying configurations, turning enforcement on or off, and refreshing status.
• Delete Sysmon configurations (sysmon.config.delete), held by Admin only.

See Roles & Permissions and Policies: who can see and change what.

How status is reported#

Each Windows agent reports its Sysmon state: whether Sysmon is installed, its version and schema version, the path of the loaded config file, and the SHA-256 hash of the loaded configuration. The server asks for a report:

• whenever an agent connects;
• from every connected agent every 5 minutes (you can change this; see Server configuration);
• when you click Refresh on the Sysmon tab (all connected agents) or on an agent's Sysmon tab (that agent only). Results arrive within seconds. Refresh again to see them;
• from the targeted agents 30 seconds and 2 minutes after a deploy, so the outcome shows without waiting for the next cycle;
• when the Sysmon Status Check action runs as a scheduled job.

The last report from each agent is saved in the database, so the status survives a server restart.

Agent states

Athena compares each agent's loaded hash with the hash of the revision that agent was last deployed. It does not compare against a fleet-wide value. So machines targeted with different configurations are each judged against their own revision.

Offline is not a state. It is an extra marker: an agent with Sysmon installed that is not connected right now counts as Offline in the strip and filters, and its row keeps its last known state.

Status strip and agents table

The top of the Sysmon tab shows a strip of counts: agents targeted, in sync, drifted, no config, not managed, error, not installed, unknown and offline. On the right is the most recently deployed revision (active: <configuration> · rev N). Agents targeted is the number of machines a deploy would reach right now: Sysmon installed and connected.

The Agents table lists every reporting machine with its Hostname, Sysmon version, Schema, Loaded config path (hover it to see the hash), State, Expected rev and Last report time. Use Filter by hostname and the state chips (All, each state, Offline) to narrow it down. The table shows 50 rows per page, with Previous and Next buttons.

Configurations and revisions#

Athena keeps Sysmon XML as named configurations, and each configuration has numbered revisions (rev 1, rev 2, …). Every load (upload, paste or blank) starts a new configuration at rev 1. Each save from the rule editor adds the next revision to the configuration you are editing. Every revision is stored byte for byte, and its SHA-256 is exactly the hash Sysmon reports once that configuration is loaded. That is how drift detection works.

The Configurations list on the Sysmon tab shows, for each configuration: its name, an Active badge if it holds the most recently deployed revision, the latest revision number, how many agents it is deployed to, and when it was last changed. The actions are:

• Rename (pencil icon): changes the name only, up to 100 characters. Revisions, hashes and agents are not affected.
• Open in editor: opens the latest revision in the rule editor.
• Deploy: deploys the latest revision (see Deploying).
• N revision(s): expands the revision history. Each revision shows its number and file name, its global id (#id, used in URLs, the API and deployment names), an optional note, the date, who made it, its size and the start of its SHA-256. Each revision can be opened in the editor, viewed (its XML exactly as stored) or deployed on its own.
• Enforce and Auto-fix switches: see Continuous enforcement.

Adding a configuration

Use the Upload a Sysmon config (.xml) control on the tab, or click New configuration to open /policies/sysmon/new, which has three options:

• Load from file: drop or browse to an .xml file (UTF-8 or UTF-16). Athena parses it and shows how many rules, event types and unmapped nodes it found, and the schema it declares. The original bytes are kept as-is.
• Paste XML: the same parser and checks, for XML on your clipboard.
• Create from blank: an empty <Sysmon> root at a schema you pick. The default is your fleet's schema ceiling (see below).

Optionally enter a Configuration name. If you leave it empty, the configuration is named after the file. Athena refuses a file that is:

• empty;
• larger than 5 MB;
• not well-formed XML (DTDs are not allowed);
• missing the <Sysmon> root element;
• missing a schemaversion attribute on that root.

A file that passes these checks but has schema validation errors is still stored. It is marked invalid, and you can open it in the editor to fix it, but you cannot build or deploy it until the errors are fixed. Deploying a configuration that Sysmon would reject would fail, and the machines would keep their old rules.

Schema ceiling

Every Sysmon version supports schemas up to a certain version. A configuration that declares a newer schema than a machine's Sysmon supports is rejected there. The apply fails, and that machine silently keeps its old rules. Athena calculates a schema ceiling for the target from the lowest Sysmon version installed in it. When a loaded file declares a schema above the ceiling, the New configuration screen warns you and says how many agents would reject it. Then you can choose Downgrade to <ceiling> and open, which saves a copy that declares the ceiling as a new revision. You can also leave those agents out of the deploy target.

The rule editor#

Open in editor opens a revision at /policies/sysmon/editor/<id>. The editor has these parts:

• an Event types rail for turning event types on or off. Rules of an event type you turn off are kept in the XML and come back unchanged when you turn it back on;
• rule groups for each event type, each set to match any or all of its conditions. You can add or remove conditions. Fields and operators that the selected schema does not support are shown as unavailable;
• a Live XML pane. XML the editor cannot display is kept verbatim and never re-written;
• a Rollout pane for the selected target: the expected hash, how many agents already run this revision, how many run another configuration, and how many are blocked by their schema.

The toolbar has a Target picker (All Sysmon agents, any collection, or any tag), with the number of agents for each. It also has these buttons:

• Validate: checks the configuration, including unsaved edits, against the schema the target runs.
• Save & build package: saves your edits as the next revision and builds its deployment package.
• Save as new configuration: saves your edits as rev 1 of a new configuration and leaves the original unchanged.
• Export: downloads the saved revision exactly as stored.
• Deploy: deploys the saved revision to the selected target.

You must save before you deploy, because a deploy always sends the saved revision. A revision that is not UTF-8 or UTF-16 cannot be opened in the editor, but it can still be deployed as stored.

Deploying a revision#

Deploy on the Sysmon tab sends the revision to every connected agent that has Sysmon installed. From the editor or the API you can narrow the target to a collection or a tag. Athena:

1. refuses the deploy if the revision has validation errors, or if no connected agent in the target has Sysmon installed ("No connected agent has Sysmon installed - nothing to deploy to.");
2. builds the revision's deployment package, if it has none yet;
3. starts a normal deployment named Sysmon · <configuration> · rev N, which you can follow under Active Deployments and Deployment History. On each agent it runs sysmon -c with the revision's file. If Sysmon rejects the file, it exits with a non-zero code and that agent's step fails;
4. records this revision as what each targeted agent should run. Agents outside the target keep their previous expectation;
5. asks the targeted agents to report again after 30 seconds and after 2 minutes.

The confirmation reads "… is deploying to N agent(s). It counts as applied only when those agents report In sync." A successful deployment step alone does not prove the configuration was loaded. Only In sync proves it.

• Offline machines are not reached. A deploy targets only agents that are connected at that moment. Deploy again later for machines that were offline, or use enforcement so they are corrected when they next evaluate compliance.
• Rolling back means deploying an earlier revision again. There is no separate rollback mechanism.
• Sysmon is a separately licensed module. Your license must include it, or deploys and every other Sysmon feature are unavailable. See Separately licensed modules.

Continuous enforcement (Compliance)#

A deploy is a one-time action. To keep checking the fleet afterwards, turn on Enforce for a configuration. Athena then creates a Compliance baseline named Sysmon · <configuration> (#<id>), with one Windows rule … loaded, and assigns it. On each evaluation the rule runs sysmon -c on the machine and passes only if the loaded configuration's SHA-256 matches the configuration's latest deployed revision. It fails, with a warning saying why, when Sysmon is not installed, has no configuration loaded, runs another configuration, or cannot be run.

• Deploy first. A configuration that was never deployed cannot be enforced ("Deploy this configuration before enforcing it").
• The rule follows your deploys. When you deploy a newer revision of an enforced configuration, the rule is updated to expect it. If the rule cannot be updated, enforcement is switched off rather than left checking a stale revision.
• Auto-fix (off by default): when a machine runs a different configuration, the rule's remediation writes this revision's exact XML to the machine and loads it with sysmon -c. Remediation fails if Sysmon rejects the file.
• Target: by default the baseline is assigned to Sysmon installed, a dynamic collection that Athena maintains, with every agent that reports Sysmon installed. Through the API you can target any existing collection instead (collection:<id>). Compliance cannot target tags.
• Interval: the rule is evaluated every 60 minutes by default. Through the API you can set 1 to 1440 minutes.
• Size limit: a revision larger than 1 MB cannot be enforced, because it is embedded in the Compliance rule. Revisions up to 5 MB can still be deployed.
• Once enforcement is on, the Compliance button next to the switches opens the baseline. Do not edit the baseline or rule by hand: they are managed from Policies → Sysmon, and manual edits are overwritten on the next deploy.
• Turning Enforce off removes the rule and its baseline. If enforcement cannot be set up, it is switched off and the error is shown.

Results appear like those of any other baseline. See Compliance & Baselines and Compliance Evaluation.

Filter fields, reports and scheduling#

Filter fields

The Sysmon state of each agent is available as filter fields. You can use them in dynamic collections, tagging rules, monitors and reports. For example, Module.sysmon.State equals Drift builds a collection of drifted machines.

Report data source

Reports can use the Sysmon Agents data source, with these columns: Hostname, Sysmon Version, Schema Version, State, Config Hash, Expected Revision, Expected Configuration and Last Report.

Scheduled status checks

Scheduled Jobs include a Sysmon Status Check action ("Re-check Sysmon status on all agents"). It asks every connected agent to report, like the Refresh button does.

Audit trail#

Sysmon actions are recorded in the Audit Log with the user who performed them:

REST API#

You can script everything the Sysmon tab does. All endpoints are under /api/modules/sysmon. Every endpoint needs sysmon.view, and every POST, PUT, PATCH and DELETE also needs sysmon.manage. Responses use the standard Athena envelope (success, data, message). A refused request returns 400, with validation errors listed. An unknown revision or configuration returns 404. Wherever a target is accepted, it is all (the default), collection:<id> or tag:<name>.

For example, to deploy revision 12 to one collection:

curl -k -X POST -H "Authorization: Bearer <token>" \
  "https://<server>:8443/api/modules/sysmon/revisions/12/deploy?target=collection:<collection-id>"

The 12 in the path is the revision's global id (the #id shown in the revision list), not its rev N number within the configuration.

Server configuration#

Set these in appsettings.json or as environment variables (use __ for :). See Configuration.

Troubleshooting#

Related#

• Compliance & Baselines: where enforcement results appear.
• Deployment Tracking: follow a Sysmon deploy per agent.
• Filter Field Reference: how filter fields work in collections and reports.
• Audit Event Types Reference: the full list of audit events.
• Air-Gapped Operation: running Athena with no outbound connectivity.