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 — Monitors Application, System, Security, and custom channels (e.g. PowerShell, ForwardedEvents)
• 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

What’s new in 1.1.3

The agent now reports its software inventory before announcing the scan that produced it. Previously the scan was announced first, so for as long as the inventory rows were still arriving the host appeared in Secure60 with an inventory of nothing — and dropped out of the Software Inventory views until they landed. Large inventories are also sent in batches of 1000 rows rather than one request. Upgrading is a straight replacement of the executable — no configuration change is needed.

What’s new in 1.1.2

Sysmon events now carry the parent process, loaded image, call trace, signature and registry detail under their standard Secure60 field names, so the managed Windows detections that rely on them work without any extra configuration.

Step 1: Download and prepare files

1. Download the Windows executable from the Secure60 documentation site: secure60-win-log-agent-64bit-1.1.3.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. At minimum, set your Secure60 Collector URL under output.http.hosts:

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

You can leave other defaults or adjust event logs, retry, and TLS as described in 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.1.3.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.1.3.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. Each entry can include:

Example:

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

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.1.3.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 collector URL first — Before installing the service, set output.http.hosts in secure60-win-log-agent.yml to your Secure60 Collector URL.

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 — Use ignore_older (e.g. 72h) or event_id filters to reduce volume and focus on the channels and events you need.

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.