Appearance
Understand Sensors
Sensors are lightweight, native agents that run directly on your endpoints -- servers, workstations, virtual machines, and cloud instances. They provide continuous, real-time visibility into each machine's security posture by collecting inventory data, security configurations, and system metadata without requiring network-based scanning.
What Is a Sensor?
A sensor is a single binary executable that you install on a target machine. Once enrolled with your AttackLens instance, the sensor runs as a background service and periodically reports data back to the backend. Sensors are designed to be:
- Lightweight: Minimal CPU and memory footprint. Sensors do not perform heavy processing on the endpoint; they collect raw data and transmit it to the backend for analysis.
- Cross-platform: Available for Linux (amd64/arm64), Windows (amd64), and macOS (amd64/arm64).
- Self-updating: Sensors automatically update themselves when a new version is available, with no manual intervention required.
- Secure: All communication between the sensor and the AttackLens backend is encrypted over HTTPS. Sensors authenticate using enrollment tokens and maintain a persistent identity after registration.
How Sensors Work
The sensor lifecycle follows four stages:
1. Enrollment
When you first run the sensor binary with the enroll command, the sensor contacts the AttackLens backend and presents its enrollment token. The backend validates the token, registers the sensor, and issues a unique sensor identity. From this point on, the sensor uses its own credentials to authenticate -- the enrollment token is no longer needed.
2. Data Collection
Once enrolled, the sensor begins collecting data from the local machine at regular intervals. The collection cycle includes:
| Data Category | What Is Collected |
|---|---|
| Installed Packages | All installed software packages, their versions, and sources (apt, yum, rpm, dpkg, MSI, Chocolatey, Homebrew, etc.) |
| Running Services | Active system services and their states (running, stopped, enabled, disabled) |
| Security Policies | Local security policy settings including password policies, account lockout policies, and user rights assignments |
| Authentication Configuration | SSH configuration, PAM settings, local user accounts, group memberships, sudo rules |
| Network Configuration | Network interfaces, firewall rules, listening ports, routing tables |
| System Metadata | Hostname, OS version, kernel version, architecture, uptime, hardware identifiers |
| Directory Membership | Active Directory or LDAP group memberships for the machine account |
| File Integrity | Checksums of critical system files and configuration files |
3. Reporting
Collected data is transmitted to the AttackLens backend over HTTPS. The sensor sends data:
- On a regular schedule: Configurable interval (default: every 60 minutes).
- On startup: The sensor performs a full collection immediately after starting.
- On demand: The backend can request an immediate collection cycle from a sensor.
The backend processes the incoming data and feeds it into the inventory system, vulnerability correlation engine, and posture evaluation pipeline.
4. Self-Update
Sensors include a built-in self-update mechanism. On every communication with the backend, the sensor reports its current version via HTTP headers. If a newer version is available, the backend responds with update metadata. The sensor downloads the new binary, verifies its integrity, and replaces itself -- all without manual intervention. See Sensor Auto-Update for details.
Sensors vs. Remote Scanning
AttackLens supports two methods for collecting data from endpoints:
| Sensors | Remote Scanner | |
|---|---|---|
| Deployment | Native binary on each endpoint | Centralized Docker container |
| Network access | Outbound HTTPS only | Requires SSH/WinRM access to targets |
| Data freshness | Continuous (scheduled intervals) | On-demand (triggered scans) |
| Firewall requirements | Minimal -- only outbound to AttackLens | Must reach target machines on SSH/WinRM ports |
| Best for | Endpoints behind firewalls, laptops, air-gapped networks | Infrastructure you cannot install agents on |
TIP
For most deployments, sensors are the recommended approach. They provide more frequent data collection, require fewer network permissions, and are easier to scale across large environments.
Sensor Statuses
Each sensor in AttackLens has a status that reflects its current state:
| Status | Meaning |
|---|---|
| Online | The sensor has checked in within the expected interval and is actively reporting data. |
| Offline | The sensor has not checked in within the expected interval. This may indicate the machine is powered off, the sensor service has stopped, or there is a network issue. |
| Pending | The sensor has been enrolled but has not yet completed its first data collection cycle. |
What Happens to the Data?
Data collected by sensors feeds into multiple AttackLens subsystems:
- Inventory: Installed packages and services appear in the asset's inventory records, enabling software tracking and license visibility.
- Vulnerability Correlation: Installed packages are matched against the vulnerability database (OSV, EPSS, CISA KEV) to identify known vulnerabilities on each endpoint.
- Posture Evaluation: Security configurations are evaluated against your active policies and rulesets to produce compliance findings.
- Attack Graph: Sensor data enriches the attack graph with real endpoint details -- open ports, running services, credentials, and misconfigurations become nodes and edges in the graph.
Next Steps
- Create an Enrollment Token -- Generate a token before deploying your first sensor.
- Deploy on Linux -- Step-by-step Linux installation.
- Deploy on Windows -- Step-by-step Windows installation.
- Deploy on macOS -- Step-by-step macOS installation.