How remote system discovery shows up in intrusions and what it reveals
A SOC analyst sees one internal host making short, repeated reachability checks against many neighboring hosts, often shortly after an unfamiliar logon. T1018 Remote System Discovery gives an attacker a map of which remote systems exist, which of them answer, and which ones are worth touching next. Under MITRE ATT&CK tactic TA0007 Discovery, the technique is typically used once a foothold exists and the attacker needs to know what sits around it. This page targets Enterprise ATT&CK version 20.0, so detection mappings below name that version. In intrusions, the activity usually appears as a burst of name lookups, address probes or remote queries launched from a workstation, a server or a management host that rarely performs that role, and it often precedes lateral movement or credential access.
What the attacker learns matters for triage. A successful sweep reveals host names, addresses, operating system hints and the services that answer, which tells the adversary where administrative protocols are open and where backup, hypervisor or domain infrastructure lives. Defenders should therefore ask three questions early: which account or process generated the traffic, whether the source host has a documented reason to reach so many peers, and whether the targets include high-value segments such as ESXi management networks, identity servers or network device management planes. Confirm with your asset inventory and change records which hosts are expected to run scanning or inventory agents, because those tools produce the same pattern as an intruder.
Plan for the overlap with neighboring techniques before you write rules. Remote system discovery often happens alongside network service discovery, system network connections discovery and account discovery, so an alert on T1018 alone can be noisy. Decide which sources you will correlate, such as process telemetry on the source host and flow records at segment boundaries, and agree with network and platform teams who owns the response when the source is a legitimate management system. Check the current technique and data component definitions in the MITRE ATT&CK tactic page for Discovery before you finalize mappings, since ATT&CK releases can rename or revise content.
Which telemetry reveals remote system discovery on ESXi, Linux, macOS and network devices
This table maps each telemetry source to the T1018 signal it provides, the platforms where it applies, and the open-source collector that gathers it. Read it as a coverage checklist: a platform with only one row of evidence has a blind spot, and network devices and ESXi hosts need collection paths that differ from endpoint agents.
| Telemetry | Signal for T1018 | Platforms and collector |
|---|---|---|
| Process Creation (DC0032) | Records each new process that queries neighboring hosts, such as name resolution, reachability or remote service lookups launched from a user or service account | Linux and macOS: Wazuh agent or Auditd with process execution rules; ESXi: syslog forwarded from the host |
| Command Execution (DC0064) | Captures the command line and parent process, which shows whether a host-level tool was invoked against a list of remote addresses or hostnames | Linux and macOS: Wazuh agent command logging or Auditd; network devices: AAA and command accounting logs sent via syslog |
| File Access (DC0055) | Shows reads of host lists, known hosts files, ARP or DNS caches and inventory data that an operator may use to choose remote targets | Linux and macOS: Wazuh file integrity or Auditd file watches on defined paths; ESXi: host logs forwarded through syslog |
| Network Traffic Content (DC0085), where it adds signal | Shows repeated probes or banner requests across many hosts in a short window, which endpoint logs alone may not show | Zeek or Suricata sensors on segment span or tap points; confirm which protocols each sensor decodes in your environment |
| OS API Execution (DC0021), where it adds signal | Adds visibility into native API calls on endpoints that do not spawn separate processes | Endpoint telemetry with API hooking support; confirm availability and coverage with the chosen collector vendor |
| Network device syslog | Records management sessions and command accounting on routers, switches and firewalls, which indicates who queried remote system state | Syslog receiver such as a Wazuh manager or Security Onion pipeline; confirm the device logs the commands you need |
Detection logic for T1018 that SOC teams can tune
T1018 Remote System Discovery is hard to separate from legitimate network activity because scanners, monitoring and backup tools generate the same fan-out patterns. The cards below describe detection ideas in words, each with the threshold to tune, the baseline to build and the false positive sources to exclude before alerting.
Many distinct internal destinations
Alert when one host opens connections to an unusually high number of distinct internal addresses within a short window. Start by measuring each host's normal count per hour over several weeks, then set the threshold above the 95th percentile for its role rather than a single global number. Expect vulnerability scanners, configuration management servers, backup agents and monitoring collectors to dominate the results. Maintain a reviewed allowlist of these sources, tied to change records, and confirm the fan-out logic in Zeek connection logs or Wazuh network telemetry before paging anyone.
Ping and connection fan-out from servers
Servers rarely originate ICMP echo requests or refused TCP connection attempts across a subnet. Treat sustained sweeps from a server-tier host as a higher priority than the same activity from a workstation. Build the baseline from the monitoring platform's known polling schedule, and record which ports and subnets each server normally touches. Expect uptime checks, hypervisor clustering heartbeats and load balancer health probes to create similar patterns. Suricata or Zeek notices for failed connection bursts can carry this logic, but the reader should confirm the exact rule syntax in their own environment.
Discovery from unbaselined accounts
Flag remote discovery activity from accounts or hosts that have no prior history of network enumeration. New service accounts, recently provisioned jump hosts and accounts that were dormant for a long period deserve a lower alert threshold. Establish the baseline by joining authentication events with the first-seen date of each source host and account. Expect newly onboarded administrators, migration projects and penetration tests to appear as new actors, so require a matching change ticket or test window before closing the alert.
Cross-platform correlation with ESXi hosts
Correlate discovery-style behavior on ESXi management interfaces with similar patterns from Linux workstations in the same time window. A workstation probing hypervisor management addresses, followed by connection attempts from the same source to other infrastructure ranges, is a stronger signal than either event alone. Build the baseline from known administrative jump paths and vCenter management traffic. Expect hypervisor maintenance tools, backup proxies and remote administration consoles to create legitimate cross-platform paths, so maintain a documented list of approved administrative sources and review it at each change window.
Tuning false positives with change context
Feed scanner schedules, backup windows and configuration management runs into the detection pipeline as suppression context rather than deleting alerts. Each suppression should name its owner, its source host, its time window and the ATT&CK version the mapping targets. Review suppressions quarterly, since ATT&CK releases can rename or revoke techniques and infrastructure changes shift normal traffic. Ask the platform owner to confirm which data components their sensors actually collect, because a detection cannot fire on telemetry that is not gathered.
How to prove the T1018 detection fires before you trust it
This sequence turns T1018 detection logic into evidence: a scoped, repeatable emulation in a private range that records whether each platform's alerts fire, how fast, how accurately, and against which ATT&CK version. The output is a dated detection record your team can defend and re-run after every change.
Agree scope and rules of engagement
The detection owner, the range operator, and the system owners for each platform in scope agree in writing what will be emulated, which ESXi hosts, Linux, macOS, and network device segments are included, which accounts may be used, and when runs may happen. Name a stop condition and an escalation contact for the range. The sequence is done when the signed scope lists each platform, each telemetry source expected to see activity, and the rollback owner. Confirm with your range provider how isolation and snapshot restore are handled, since DeployOpen scopes these items in writing before work starts.
Define the expected detection result per platform
Before any emulation runs, the team writes down what each platform should produce: which data components apply (Process Creation, Command Execution, and File Access are the ones most often referenced for this family of techniques), which log sources should carry them, and what a correct alert looks like. Map each expectation to the detection strategy or analytic your team uses and to the ATT&CK version it targets. This record is the baseline that later runs are compared against, so a run cannot quietly change its own pass criteria.
Emulate host discovery behavior on each platform
The range operator performs approved remote host discovery behavior on each in-scope platform, one platform at a time, in a fixed order that is recorded with the run. Activity stays within the agreed scope and uses the agreed accounts. The operator does not publish or reuse the exact activity sequences outside the range. The step is complete when every platform has a logged run window with a start and end time, a named source host, and the target set, so that every event can be traced back to a known action.
Capture the telemetry each run produces
Collect the raw events from the SIEM, the Wazuh or Security Onion pipeline, endpoint agents, and network sensors for each run window, without filtering by alert status. Store the source, target, timestamp, and data component for every relevant event. Check that the telemetry arrived at all, separately from whether a rule fired. A missing log source is a collection finding, not a detection pass, and it should be logged as such before the alert review begins.
Compare alerts against the expected result
Review each run against the baseline from the earlier step. For each platform, record whether an alert fired, whether it matched the expected rule, the latency between the first emulated event and the alert, the fidelity (whether the alert names the right source, target, and technique), and any false positives raised by ordinary administration during the window. Treat an alert that fires for the wrong reason as a partial result. The step closes when every expected detection has one of four outcomes recorded: fired, fired with low fidelity, not fired, or not tested.
Record the run evidence in a detection register
Write one register entry per platform per run containing the run identifier, date, operator, scope reference, ATT&CK version and STIX bundle used for the mapping, rule or analytic identifier, outcome, latency, fidelity notes, and false positive count. Store the raw telemetry extract next to the entry so an auditor or peer reviewer can reproduce the comparison. The register is the evidence that the detection was tested, not just written, and it is the input for compliance readiness conversations.
Version the detection against ATT&CK 20.0
Pin each detection to the ATT&CK version it was tested against, using enterprise-attack 20.0 and its STIX 2.1 bundle as the mapping reference for the T1018 technique and its relationships to data components and mitigations. Because releases can rename, deprecate, or revoke techniques, the team checks the mapping at each new ATT&CK release and notes any change in the register. A detection whose version is not recorded cannot be trusted after an upstream change, so the version field is required before a rule is promoted to production.
Re-run after every detection change
Any change to a rule, analytic, log source, or parser triggers a re-run of the affected platform emulations under the same scope and baseline, and a new register entry. Compare the new results with the prior run to confirm the change improved fidelity or closed a gap without adding false positives elsewhere. The sequence is repeatable by design, and the team records each re-run so the detection history shows both what changed and why it was accepted.
How telemetry from hosts and network devices becomes a T1018 alert
A T1018 alert is only as good as the path its telemetry takes, so the first decision is which sources feed the pipeline. On ESXi, Linux and macOS hosts, endpoint or host agents should forward process creation and command execution events, because T1018 activity shows up as short bursts of name resolution, ping-style probing or remote management tools launched from unexpected parents. Network sensors such as Zeek or Suricata add the connection pattern: one source touching many hosts on a management port within a short window. Events from each source are normalized into a common schema in the SIEM, for example Wazuh or a comparable platform, and correlated by source account and host so that an analyst sees one sweep rather than hundreds of separate lines.
Retention and time synchronization decide whether that correlation holds up. Keep process and command logs long enough to cover your investigation window and your change calendar, and confirm the retention period with your SIEM and legal teams instead of assuming a default. Clock drift is a common cause of broken correlation between ESXi hosts, Linux servers and sensor timestamps, so confirm that every source uses the same time service and that the SIEM stores event time separately from ingest time. Also check that ESXi host logs are actually forwarded, since they are often missed in standard Linux collection.
Every rule should carry its ATT&CK mapping in its metadata: the technique ID T1018, the detection strategy identifier and the data components it relies on, such as Process Creation (DC0032) and Command Execution (DC0064). Record the ATT&CK version the mapping targets, because releases can rename or deprecate techniques. This mapping lets you prove coverage during an assessment and shows which rules break when a data source is retired. Ask your team to review the current version of the MITRE ATT&CK technique page before each rule change, so the alert logic and its documentation stay aligned.
Preventive controls that reduce remote system discovery
Remote system discovery succeeds when a compromised host can reach many peers, when those peers expose services freely, and when the activity goes unlogged. The five ATT&CK mitigations below address those three conditions, and each one makes the detections on this page more reliable. Confirm each control in your own environment before relying on it.
Limit reachability with network segmentation
Network Segmentation (M1030) restricts which hosts can open connections to which others, so a foothold on one workstation cannot enumerate the whole address space. For T1018, the practical question is how many peers a typical server or endpoint can reach on ports used for administration, name resolution and file sharing. Map the allowed flows for each zone, then confirm that management networks, user subnets and server tiers are separated by enforced policy rather than by addressing alone. Segmentation also narrows the scope of what your detections need to cover.
Block fan-out and scanning patterns
Network Intrusion Prevention (M1031) inspects traffic and can block or alert on scanning behavior, such as one source contacting many hosts in a short window. Discovery activity against remote systems often appears as sweeping probes before any targeted session. Confirm whether your sensors run in prevention mode or detection mode for internal east-west traffic, and whether the rule sets include scan and sweep signatures. Tune thresholds with your backup, monitoring and vulnerability scanners in mind, so that approved scanners are allowlisted by source and not silently ignored.
Keep the logs detections depend on
Audit (M1047) is the control that ensures the telemetry used for detection exists in the first place. For T1018, that means process creation events, command execution records and file access auditing on Linux, macOS and ESXi hosts, forwarded to a central store. Confirm which audit rules are active on each host class, whether the logs are complete during peak load, and whether an administrator can disable auditing without generating an alert. Missing audit coverage makes every other detection on this page unverifiable.
Restrict host features and services
Operating System Configuration (M1028) covers hardening settings that reduce what a host reveals to a remote peer, such as unnecessary listening services, permissive remote management protocols and default sharing options. Fewer open services mean fewer responses for an adversary to harvest during discovery, and clearer baselines for your analytics. Review each server baseline against the services it actually needs, and document exceptions with an owner. Confirm the configuration is enforced by your configuration management tooling and not only applied at build time.
Remove unneeded features and programs
Disable or Remove Feature or Program (M1042) reduces the number of tools and protocols available on a host. Remote discovery often depends on utilities that ship with the operating system or that administrators installed for convenience, such as network query tools, remote shells and management agents. Inventory installed utilities on Linux, macOS and ESXi hosts, remove those with no operational purpose, and record the exceptions. Confirm that removals are reflected in your asset inventory, because a removed tool that reappears through a package update will silently break the baseline.
What to do in the first hour after a T1018 alert
Start by confirming who is doing the scanning and whether that activity was expected. Identify the source host, the account or service identity behind the process, and the change or ticket that would authorize a vulnerability scanner, asset inventory job or network management poller to sweep that address range. If an approved scanner matches the source, the alert becomes a tuning question rather than an incident. If no approved activity explains it, treat the source as unknown until proven otherwise. In parallel, pull the source host's process creation and command execution history for the window before and after the alert, looking for the same tooling appearing on other hosts, new parent processes, or a login shortly before the sweep. Your Wazuh, Security Onion or Velociraptor records should let an analyst answer these questions within the hour, provided retention covers the period. Confirm retention settings for each source now, not during the incident.
Containment should preserve evidence. For a source host, prefer restricting its outbound reachability at the network boundary or segmentation layer over powering it off or reimaging it, so that process listings, memory and logs remain available for review. Disable the implicated account only after you have recorded its active sessions. On the target side, scope the set of addresses and hosts that received the probes by pulling connection records from the sensors you run, such as Zeek connection logs or Suricata events, and by checking which of those hosts show follow-on activity. Limit the scoped set to what the telemetry supports. If a sensor was blind to a segment, record that gap explicitly. Escalate to the incident commander and legal or privacy contacts when the source is unidentified, when the account belongs to a privileged or service identity, when the target set includes regulated systems, or when the discovery is followed by authentication attempts or lateral movement indicators.
Close the loop within the first hour by writing down what the alert taught you. Record the decision, the evidence used, and whether the rule fired correctly, then route the result to detection engineering so the approved scanner list, source allowlists and rule thresholds can be updated under change control. Map the finding to the ATT&CK version your runbook targets, and check that the runbook's data component references still match the ATT&CK version you are operating against, since releases can rename or deprecate content. Ask your detection engineers to confirm whether the Process Creation and Command Execution telemetry you relied on is consistently collected on the platforms involved. Update the runbook only with findings that were verified, and schedule a replay of the scenario in your cyber range to confirm that the tuned rule still fires for the behavior you care about.
Rehearsing T1018 detection and response in a private cyber range
The analyst track runs in a private range that mirrors the production SIEM and case management workflow, with Linux, macOS and ESXi hosts sending telemetry to a Wazuh or Security Onion stack. The exercise team introduces injects such as a scripted host sweep from a compromised workstation, followed by a second sweep from a different subnet, so analysts must decide whether the activity is one event or two. Good performance is measured by observable facts: the time between the first Process Creation or Command Execution event and the alert appearing in the queue, whether the analyst grouped related alerts into one case, and whether the escalation note named the source host, the account, the time window and the hosts that responded. Ask the range team to record these timestamps so the drill produces numbers you can compare across rounds, rather than impressions.
- Alert timing: Record when the raw event was ingested and when the alert was raised, and treat any gap as a finding to investigate.
- Triage consistency: Check that two analysts given the same inject reach the same disposition and cite the same evidence.
- Escalation handoff: Score whether the escalation includes the source, targets, account, time window and the commands seen, without exposing exploit detail.
- Noise handling: Include a legitimate inventory scan from the vulnerability management tool so analysts practice distinguishing approved activity.
- Case closure: Confirm the closure note records the containment decision and the logs that support it.
Check whether the escalation a senior analyst receives is complete enough to act on without a follow-up call.
The detection engineering track replays recorded telemetry from the exercise into a test pipeline rather than running live activity against production sensors. The range keeps labeled datasets for each platform, separating benign administrative discovery from the adversary-style sweeps, so engineers can measure how rules behave on both. Work is mapped to a named ATT&CK version and to the data components relevant to T1018, including Process Creation, Command Execution and File Access, so each rule states which telemetry it depends on. Engineers then tune thresholds, allow lists and field mappings against the replay and record the true positive and false positive counts for each change. Ask for a rule changelog that ties every edit to a replay result, because undocumented tuning is the most common reason detections drift after a platform upgrade.
- Replay fidelity: Confirm the replay preserves original timestamps and host identifiers, since correlation rules fail quietly when these change.
- Rule ownership: Give each rule a named owner, a target ATT&CK version and a review date.
- Benign baselines: Keep labeled administrative activity, such as a configuration management run, to measure false positives.
- Field coverage: Check that the sensors for each platform emit the fields the rule needs, and note any platform that does not.
- Version drift: Re-run the replay after each ATT&CK or platform release, since techniques can be renamed or deprecated.
Check whether a rule that passes the replay still fires when the same activity arrives through a delayed or reordered log pipeline.
The platform track verifies that the telemetry the analysts and engineers depend on is actually produced and delivered. In the range, ESXi hosts, Linux servers and network devices forward logs through the same collectors used in production, and the exercise team uses injects that break the path on purpose, such as a disabled forwarder, a changed syslog destination or a rotated log file that stops being read. Platform engineers confirm which events are emitted for administrative commands on ESXi, which audit records Linux keeps for command execution, and which network device logs record management sessions. The measurement is coverage: for each injected discovery action, did a matching event arrive at the SIEM, how many seconds later, and with which fields populated. Treat any missing event as a logging gap to remediate before the next drill, and document the gap in the same register used for audit evidence.
- ESXi logging: Verify that host and shell activity reaches the collector, and record the forwarding configuration as an item to review.
- Linux audit coverage: Confirm that the audit rules in place produce command execution records for the commands the drill uses.
- Network device sessions: Check that management logins and show-command activity are logged with a usable source address.
- Clock accuracy: Confirm that all sources share a synchronized time reference, since mismatched clocks break cross-host timelines.
- Delivery gaps: Record dropped or delayed events under load and whether the platform alerts on forwarder failure.
Check whether a single disabled forwarder would be noticed by the platform team before the SOC notices a silent drop in alerts.
Questions SOC leads and detection engineers ask about T1018
How do I separate T1018 remote system discovery from authorized vulnerability scanning?
Separate them by source, schedule and intent rather than by the packets alone, because both produce many host probes. Build an allowlist of scanner hosts, service accounts and change windows that your vulnerability management team owns, and require that each scan job be registered before it runs. Then alert on discovery activity from any source that is not on that list, or on scanner-like behavior outside the approved window. Document the allowlist as a controlled asset so auditors and responders can see how a legitimate scan was distinguished from a suspicious one.
Which logs do I need from ESXi and network devices to detect T1018?
For ESXi hosts, you need the host's shell and authentication events, the hostd and vpxa logs forwarded to a central collector, and any command execution recorded by your privileged access tooling. For network devices, collect management-plane logins, command accounting where the platform supports it, and syslog entries for ICMP, ARP or SNMP queries against management interfaces. Confirm each log source and its exact field names with the vendor documentation for your version, because the availability of command accounting differs between device families. Without these sources, the ATT&CK data components Process Creation and Command Execution will have little to map against on those platforms.
How do I version T1018 detections across ATT&CK releases such as v18 and v20?
Record the ATT&CK version in every detection's metadata and map each rule to the technique ID, the detection strategy ID and the data components it uses. ATT&CK v18, released October 28, 2025, replaced technique-page detections with detection strategies and analytics, and it deprecated data sources in favor of data components, so rules written against older data source names need re-mapping. Enterprise ATT&CK 20.0 is the version this page targets, and releases can rename, deprecate or revoke techniques, so check the ATT&CK updates page and the STIX bundle for each new release. Keep a changelog per rule so reviewers can see which mapping changed and why.
How do I measure the false positive rate of a T1018 detection during tuning?
Measure it as the share of alerts that analysts close as benign, counted per rule and per source, over a fixed review window. Tag every closed alert with a disposition such as authorized scan, inventory tool, administrator action or confirmed suspicious activity, so the rate reflects analyst judgment rather than guesswork. Track the rate before and after each allowlist or threshold change, and record the result in the rule's changelog. Set a target with your own SOC leads, since no industry benchmark for this rule type is supplied here, and confirm the review window against your alert volume.
How often should a SOC rehearse T1018 detection and response in a cyber range?
Rehearse it on a schedule tied to change events: after each significant ATT&CK release that touches the technique, after new logging sources go live, and after major changes to scanner tooling or network segmentation. Many teams also run a recurring exercise at a cadence set by their own risk review, and they add an unscheduled run after any real discovery alert that revealed a gap. Each rehearsal should check that the detection fires on ESXi, Linux, macOS and network device telemetry, that the alert reaches the right queue, and that the response runbook is followed. Agree the cadence and scope in writing before the exercise starts.
Can my own team build and run T1018 detections without outside help?
Yes, many teams can, provided they have staff who know Wazuh, Zeek or Suricata, Sigma rule authoring and the logging sources on their platforms. The work divides into log onboarding, rule authoring and mapping, allowlist ownership, tuning and rehearsal, and each piece recurs after every ATT&CK release and infrastructure change. The effort is driven by how many platforms you cover, how much logging already exists and how often your environment changes. If you want outside help, DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and runs private cyber ranges, under a written, fixed scope that you can compare with your internal estimate.
What does a T1018 cyber range exercise need in place before it starts?
It needs an isolated range that mirrors your ESXi hosts, Linux and macOS endpoints and network devices closely enough that telemetry looks the same, plus a logging pipeline that matches production. Define in advance which discovery behaviors are in scope, which accounts run them, and who is the control party who can stop the exercise. Agree what success looks like, such as which alerts should fire and how fast responders must triage them, and record evidence for each check. Confirm the range boundaries with your security and network teams so the exercise never reaches production systems.
How DeployOpen builds and tests T1018 detections in your environment
DeployOpen starts every T1018 Remote system discovery engagement with a written scope that names the platforms in question, such as ESXi hosts, Linux and macOS endpoints, and network devices, along with the telemetry sources you already run. The scope document also records which ATT&CK version the detection mapping targets, because ATT&CK releases can rename, deprecate or revoke techniques and detection strategies. Before any collection is switched on, you should confirm who owns each log source, what retention period your policy requires, and which network segments and hosts are in bounds for testing. Agreeing these points up front is what keeps the work fixed-scope and keeps deliverables and timelines clear before work starts.
Implementation then takes place inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped network. For this technique, the collection work typically covers process creation and command execution records from Linux, macOS and ESXi hosts, file access records for the configuration and log paths these tools read, and network-facing telemetry from network devices where your vendor exposes it. DeployOpen configures open-source collection and forwarding, such as Wazuh agents and Zeek or Suricata sensors, and documents each source, its field names and its known gaps. Ask the implementation team to confirm in writing which of these sources are native on each platform and which require extra auditing or a vendor add-on, since that determines whether a gap is a configuration task or a design limit.
Purple team validation is planned as a joint exercise between your detection engineers and the testing team, with each planned discovery behavior mapped to the data components the detection depends on, such as Process Creation (DC0032) and Command Execution (DC0064). Cyber range scenarios for T1018 reproduce discovery activity from a controlled foothold on the test segment, then record which detections fired, how quickly, and which events were missing. Results feed back into tuning of alert thresholds and allow-lists for legitimate administration tools, so that routine management activity does not bury the signal. Ask for the validation plan, the scenario list and the evidence format before scheduling, and confirm that any reports you receive are the input for your own assessment, since DeployOpen prepares evidence but does not issue audit reports or certifications.
How DeployOpen builds detections, purple team exercises and range scenarios for T1018
DeployOpen works on T1018 Remote system discovery as a scoped engagement inside the client's own infrastructure, starting from the telemetry the client already collects. The work turns that telemetry into detections, validates them in a private cyber range and hands over documented, versioned detection content.
How we scope
- Written scope names the platforms in play, such as ESXi, Linux, macOS and network devices, before any detection work starts.
- Scope lists which telemetry sources exist today, including process creation, command execution and file access logs.
- Scope states the ATT&CK version the detection mapping targets, so later technique changes do not silently break coverage.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Detection logic is written for the client's SIEM or open-source stack, such as Wazuh, Security Onion or Sigma-based rules.
- Logic is mapped to the relevant ATT&CK data components and detection strategies for T1018 and its applicable context.
- Each detection is tested against sample benign administrative activity to estimate false positive exposure before handover.
- Coverage gaps where a required data source is missing are recorded as explicit findings, not hidden in the rule set.
How we hand over
- Purple team exercises in a private cyber range replay agreed T1018 scenarios so the client's analysts can observe the alerts.
- Deliverables include rule files, data source requirements, validation results and a short response runbook for analysts.
- Documentation records what was tested, what fired, what did not and which ATT&CK version the mapping targets.
- Clients confirm with their own teams which findings are accepted, deferred or assigned for remediation.
How we support
- Ongoing support is available as a retainer for tuning rules after new platforms, log sources or ATT&CK releases appear.
- Retained work can include periodic re-running of T1018 range scenarios after changes to the monitored estate.
- Ask any provider to confirm in writing which telemetry, platforms and response steps are covered under a retainer.
