Secure60 Win Log Agent

Overview

Secure60 Win Log Agent is a lightweight Windows application that collects Windows event logs and sends them to your Secure60 Collector in a flat JSON format aligned with the Secure60 Common Information Model (CIM). It runs on Windows servers and workstations and can be used interactively or installed as a Windows service so it starts automatically at boot.

Key Capabilities

• Windows Event Log collection — Collects a built-in, ASD/ACSC-aligned set of security-relevant events out of the box (Security, System, PowerShell, Defender, Sysmon and more), or the channels you define (see Event logs)
• Secure60 integration — Sends events to your Secure60 Collector via HTTP/HTTPS with configurable retry and TLS
• Windows service — Install once; the agent runs as a native Windows service and starts at boot
• Configurable filtering — Filter by event ID, provider, time range (ignore_older), and optional XML query
• Checkpoint/resume — Tracks position per channel so collection resumes correctly after restart
• CIM-friendly output — Flat JSON with fields such as message_text, host_name, source_name, event_data_*, and CIM aliases for rules
• Software inventory for vulnerability management (v1.1.0+) — Periodically reports the OS build/patch level and installed updates so Secure60 can identify missing Microsoft security patches. On by default; reuses the same Collector connection

Quick Start

Step 1: Download and prepare files

1. Download the Windows executable from the Secure60 documentation site: secure60-win-log-agent-64bit-1.2.0.exe. Other versions available via support request.
2. Create a folder on the Windows machine (e.g. C:\Secure60Agent) and copy the downloaded exe into it. Create secure60-win-log-agent.yml in the same folder (Step 2 below).

Step 2: Configure the agent

Edit secure60-win-log-agent.yml in that folder and set where the agent sends events. Either destination is a complete configuration.

Via a Secure60 Collector (default). Set the Collector URL under output.http.hosts:

output:
  http:
    hosts: ["https://your-collector.secure60.local"]

Direct to Secure60 Ingest (quickest deployment, no Collector required). Set mode: ingest with the project id and an INGEST token for that project:

output:
  http:
    mode: "ingest"
    hosts: ["https://ingest.secure60.io"]
    project_id: "<your-project-id>"
    token: "<ingest-token>"

Tokens are created in the Secure60 portal under Organisation settings → Tokens (attach the project, access type INGEST). Environment variable alternatives and on-prem Ingest endpoints are covered in Sending directly to Ingest.

With no event_logs section, the agent collects its built-in default set of Windows event logs, which follows the ASD/ACSC Windows event logging and forwarding guidance (Security logons and account changes, process creation, services and scheduled tasks, PowerShell, Defender, Sysmon and others). The agent writes No event_logs configured, using built-in defaults: ... to its log at startup. To collect different channels or event IDs, see Event logs; to adjust retry and TLS, see Configuration Reference.

Step 3: Install as a Windows service

Open Command Prompt or PowerShell as Administrator, then:

cd C:\Secure60Agent
secure60-win-log-agent-64bit-1.2.0.exe install

The agent registers as a Windows service named Secure60 Win Log Agent. The service is configured to use the folder containing the executable as its working directory, so it finds secure60-win-log-agent.yml next to the exe.

Step 4: Start the service

net start Secure60WinLogAgent

The service starts and begins collecting and sending events. It is set to Automatic startup, so it will start again after a reboot.

You can confirm the service in Windows Services: open services.msc, find Secure60 Win Log Agent, and check that Status is Running and Startup Type is Automatic.

Run Options

The same executable supports interactive use and service management.

When running as a service, the agent uses the config file in the service working directory (the folder where you ran install). When running interactively, it uses the current directory or the path given by -c. (If you use a different build or version, replace secure60-win-log-agent-64bit-1.2.0.exe with your executable’s name in the commands above.)

Configuration Reference

The agent is configured via a single YAML file: secure60-win-log-agent.yml. By default the agent looks for this file in the current directory (interactive) or in the service working directory (when run as a service). Use -c to specify a different path when running interactively.

Event logs

The event_logs list defines which Windows event logs (channels) to collect. It is optional. When event_logs is absent or empty, the agent uses the default event logs below. When you provide a list, it replaces the defaults entirely; nothing is merged, so include every channel you want. Each entry can include:

Example of an explicit list (this replaces the defaults):

event_logs:
  - name: Application
    ignore_older: 72h
  - name: System
  - name: Security
  - name: Windows PowerShell
    event_id: 400, 403, 600, 800
  - name: Microsoft-Windows-PowerShell/Operational
    event_id: 4103, 4104, 4105, 4106

Long event_id lists are split across several query clauses automatically, so they stay within the Windows limit on the number of expressions in one event query.

Default event logs

The default set is an allow-list of event IDs per channel. Each channel is collected with ignore_older: 72h, which limits the first start to the last 72 hours; after that the agent resumes from its checkpoint. The shipped secure60-win-log-agent.yml contains the same list, so you can edit it in place.

Security event IDs

Many Security events exist only when the matching Windows audit policy is enabled, and an event that is never generated costs nothing to collect. In particular, 4688 requires Audit Process Creation (and Include command line in process creation events to carry the command line), 4698-4702 require Audit Other Object Access Events, and 5136-5141 require Audit Directory Service Changes. The ASD/ACSC publication below lists the Group Policy settings for each category. If Sysmon is installed, its process creation event (Event ID 1) is richer than 4688 and the two can be used together.

Why an event ID allow-list

• Coverage. The IDs come from the ASD/ACSC guidance, which assesses each category for detection value and noise, cross-checked against the NSA recommended events and Microsoft’s events to monitor. The WMI event subscription and Remote Desktop authentication events are additions: low-volume persistence and remote access indicators that detection content commonly relies on.
• Volume. The Security log also carries object access (4656, 4663), Windows Filtering Platform (5152-5159) and Kerberos service ticket (4769) events at rates that dominate storage without adding much to detection. ASD describes its advice as an ideal balance between collection of important events and management of data volumes and filters its forwarding subscriptions by event ID for that reason. The agent does the same at the source.
• Whole channel for Sysmon only. The Sysmon configuration file already decides what Sysmon records, so the channel is collected in full. ASD forwards the equivalent Sysmon event IDs in full as well.
• Query limits. Windows rejects event queries with too many XPath expressions. The agent splits long ID lists into several clauses and counts a range as two expressions, so the Security list (about 30 entries) runs as two clauses.

Differences from the sources: ASD filters 4624 by logon type and drops Kerberos logons, while the agent’s event_id filter selects by ID only, so all logon types are collected (an xml_query entry can apply a logon-type filter). Events 4105 and 4106 (script start and stop) and 4689 (process exit) are omitted because each doubles the volume of the event it pairs with and adds little to detection.

Channels that are not present

Channels such as Microsoft-Windows-Sysmon/Operational and the AppLocker channels exist only when the component is installed. The agent logs one warning per missing channel (channel "..." is not present on this host; skipping it and checking again every 15m0s), keeps collecting the others, and starts collecting from a channel when it appears, for example after Sysmon is installed. Nothing needs to be removed from the configuration.

Common additions

Add these to an explicit event_logs list (copy the default entries you want to keep first, as a list you provide replaces the defaults):

Sources

• ASD/ACSC, Windows event logging and forwarding, and its Windows Event Logging repository of forwarding subscriptions, which give the event IDs per category.
• NSA, Spotting the Adversary with Windows Event Log Monitoring, and the maintained Event-Forwarding-Guidance recommended events list.
• Microsoft, Appendix L: Events to Monitor.
• Microsoft, Microsoft Defender Antivirus event IDs.
• NIST, SP 800-92 Guide to Computer Security Log Management, for selecting log sources by risk and volume.
• Microsoft, Sysmon.

Output (Secure60 Collector)

Events are sent to the URL(s) under output.http:

Example:

output:
  http:
    hosts: ["https://collector.secure60.local:8080"]
    headers:
      Content-Type: "application/json"
      X-Secure60-Agent: "win-log-agent"
    retry:
      max_attempts: 3
      wait_min: 1s
      wait_max: 10s
    ssl:
      verification_mode: "none"   # use "full" and certificate_authorities in production

Sending directly to Ingest (instead of a Collector)

Available in v1.1.1+. By default the agent sends to an on-prem Collector (mode: collector). It can instead send straight to the Secure60 Ingest API (cloud or on-prem) — no Collector required — by setting mode: ingest with the target project id and a token:

output:
  http:
    mode: "ingest"
    hosts: ["https://ingest.secure60.io"]   # ingest base; the agent appends /ingest/1.0/http/project/<id>
    project_id: "301"
    token: "eyJ..."

In ingest mode the agent POSTs to <base>/ingest/1.0/http/project/<project_id>. The mode applies to all output (event logs and inventory). You can also supply these via environment variables instead of the file — S60_SEND_MODE, S60_INGEST_BASE, S60_PROJECT_ID, S60_TOKEN (for a Windows service, set them as machine/system environment variables). Get the token and project id from the Secure60 portal under Organisation settings → Tokens (attach the project, access type INGEST).

Software inventory (vulnerability management)

Available in v1.1.0+. In addition to event logs, the agent can periodically report a software inventory — the operating system build/patch level and installed updates — to the same Collector. Secure60 uses this to identify missing Microsoft security patches and surface them in Vulnerability Management. No additional connection settings are required; it reuses output.http.

The agent schedules these inventory scans itself on a timer (no Windows Scheduled Task needed) — the first runs shortly after the service starts, then on the configured interval.

Example:

inventory:
  enabled: true
  interval_hours: 12

Inventory collection reads the OS build/revision from the registry and installed updates via WMI; the service account (LocalSystem) has the required access by default.

Registry and logging

Example:

registry_file: ".secure60-win-log-agent.yml"
logging:
  level: info

Config file location and overrides

• When run as a service: The service is installed with its working directory set to the folder containing the exe. Place secure60-win-log-agent.yml in that folder so the agent finds it automatically.
• When run interactively: The agent looks for secure60-win-log-agent.yml in the current directory. To use another path:
  secure60-win-log-agent-64bit-1.2.0.exe -c "C:\Path\To\MyConfig.yml"

Changing the config (e.g. output.http.hosts or event_logs) requires restarting the agent (or the service) for changes to take effect.

Logging

The agent writes log output so you can troubleshoot issues whether it runs interactively or as a service.

• Log file: All log output is written to secure60-win-log-agent.log in the same folder as the executable. The file is created or appended to when the agent starts. When you run the agent from a console, the same output is also shown in the console; when run as a service, only the log file receives output. If the log file cannot be opened (e.g. permissions), the agent falls back to stderr and continues running.
• Windows Event Log: On Windows, key events are also written to the Windows Application event log with source Secure60WinLogAgent. You can view them in Event Viewer under Windows Logs → Application. The agent records:
  • Information: Agent started, agent stopped.
  • Error: Config or startup failures (e.g. failed to load config, checkpoint error).

The event log source is registered when you run install and removed when you run uninstall. Use the log file for detailed messages (e.g. HTTP retries, event log backoff); use Event Viewer for start/stop and critical errors.

Data format

Events are sent to the collector as a JSON array. Each event is a flat object (no nested structures) with lowercase keys, aligned with Secure60 CIM where applicable. Fields include:

• source_name: windows-log
• host_name: Machine name (from the event)
• event_data_channel: Channel (e.g. Security, Application)
• event_id, provider_name, record_id, time_created, message_text (rendered message when enabled)
• event_data_*: Flattened event data (e.g. event_data_targetusername, event_data_ipaddress)
• CIM-style fields such as auth_username, user_name, ip_src_address, process_image, event_command when the event supplies the corresponding data

The agent sends only message_text for the rendered message (no separate message field).

Best practices

1. Use a dedicated folder — Keep the exe and YAML in one folder (e.g. C:\Secure60Agent) and install the service from there so the working directory and config path are predictable.

2. Set the destination first — Before installing the service, set either the Collector URL or the Ingest settings in secure60-win-log-agent.yml (see Step 2). No event log configuration is required.

3. TLS in production — For production, use ssl.verification_mode: "full" and configure ssl.certificate_authorities (and client cert/key if required).

4. Limit event volume if needed — The default set already filters by event ID. To reduce volume further, remove entries from an explicit event_logs list or shorten ignore_older; to widen it, add the common additions.

5. Confirm the service after install — After install and net start Secure60WinLogAgent, check services.msc to confirm Status is Running and Startup Type is Automatic.

6. Upgrades — To upgrade, stop the service, replace the exe (and update the YAML if needed), then start the service again. The checkpoint file is preserved so collection continues from the last position.

Version history

Upgrades replace the executable in place; existing configuration files continue to work unchanged.