T1007 system service discovery: what it reveals and where it shows up in intrusions
A SOC lead reviewing a suspicious session on a Linux server needs to know quickly whether the activity is routine administration or an adversary mapping the host. T1007 System Service Discovery is a Discovery technique in which an adversary enumerates services on a host or across a network to learn what is running and which services might be abused. The point for defenders is that service inventory is often one of the first questions an intruder asks after gaining a foothold, so the query itself is a signal worth catching. MITRE ATT&CK Discovery (TA0007) describes the tactic as the adversary trying to figure out the environment. Within that tactic, T1007 typically appears after initial access and before lateral movement or privilege escalation, when the intruder is deciding which hosts, service accounts and misconfigurations to pursue next. The platforms in scope for this page are Linux, macOS and Windows, and the mapping targets ATT&CK Enterprise version 20.0. Teams should confirm the version and any technique renames against the MITRE ATT&CK updates page before treating a mapping as current. Because service listing is also a routine administrative task, the decision that matters is how to separate expected inventory from unexpected enumeration. Start by confirming which administrative accounts, management tools and scheduled jobs legitimately query services on each host class, then record that baseline. Anything outside that baseline, especially enumeration from an account or parent process that has no business doing it, deserves a case. Document this baseline before the detection work begins, because it determines the false positive rate you can accept.
Which telemetry reveals system service discovery and which open-source tool collects it
This table maps each telemetry source to the T1007 behavior it can reveal, the signal to look for and the open-source collector that gathers it. Read the rows top to bottom: Process Creation and Command Execution carry most of the detection weight, while File Access and OS API Execution add context on Linux and macOS. Confirm each source on your own platforms before relying on it.
| Data source | Signal to look for | Collector and notes |
|---|---|---|
| Process Creation (DC0032) | Service enumeration utilities launched by an unexpected parent, such as a web server, script interpreter or user session with no admin role, on Windows, Linux and macOS | Sysmon via Wazuh on Windows; auditd via Wazuh on Linux and macOS. Primary signal; tune allowlists per host role |
| Command Execution (DC0064) | Command lines that list services, query init system state or read service manager output, captured with full arguments | Wazuh command monitoring or Velociraptor artifacts on Linux and macOS; Sysmon command line fields on Windows. Confirm argument capture is enabled |
| File Access (DC0055) | Reads of service unit files, init scripts, launchd property lists or service configuration directories by processes that do not normally touch them | Wazuh file integrity monitoring or auditd watch rules on Linux and macOS; Velociraptor for on-demand file hunts. Supporting source, not standalone |
| OS API Execution (DC0021) | Calls to service control interfaces from a process that does not normally manage services, on Windows | Secondary source. Confirm per platform whether your collector exposes this telemetry before building a rule on it |
| Process Access (DC0035) | Handle requests against the service control manager or service host processes from unexpected tools | Sysmon via Wazuh on Windows. Useful for corroboration; volume is high, so scope it to sensitive hosts |
| Network Traffic Content (DC0085) | Remote service queries over management protocols originating from a host that should not be querying services | Zeek or Suricata in Security Onion. Covers remote enumeration only; confirm protocol visibility in your sensor placement |
| Osquery process and service tables | Scheduled or ad hoc queries that record running services and their launch paths against a baseline | osquery through Wazuh or Fleet. Good for baselining and hunting; confirm table coverage for each operating system version |
Detection logic for T1007 that SOC teams can tune
The ideas below describe where T1007 System Service Discovery stands out from normal administration on Linux, macOS and Windows. Each one needs a baseline built from your own estate before any threshold is set, because service enumeration is routine work for configuration management, monitoring and administrators.
Enumeration utilities under unusual parents
Service listing utilities launched by parents such as web servers, office applications, database engines or interpreters are the clearest early signal for T1007. Build a baseline of which parent processes legitimately start service managers on each host group, then alert on first-seen parent and utility pairs. Expect false positives from configuration management agents, package installers and health checks that run under shells. Confirm the parent process lineage is captured through Process Creation telemetry before tuning, because a missing parent field makes this card unusable.
Bursts of status queries per session
A single account or session querying the status of many services in a short window is unusual for most users but normal for operators and monitoring tools. Set the threshold from observed query counts per session over a baseline period, and separate interactive logons from service accounts so each population gets its own limit. Watch for the same pattern repeated across several hosts from one source, which points to lateral enumeration. Monitoring agents and remote management consoles are the main false positive sources, so allowlist them by account and source host rather than by process name alone.
Non-administrative Windows service queries
On Windows, service control queries from processes running without administrative rights are worth reviewing, particularly when the calling process is a script host, a scheduled task created by a user or an unsigned binary. Use Command Execution and Process Creation records to compare the token context against a list of approved service inventory agents. Tune the rule by host role, since domain controllers and jump hosts generate more legitimate queries. Administrators using remote tools and endpoint management products will trigger this rule, so document each approved tool with its expected account.
launchd listings from unexpected contexts
On macOS, listing launchd-managed jobs from contexts other than management tools, logged-in administrators or known agents is the equivalent signal to Windows service queries. Baseline which users and parent applications normally inspect launch agents and daemons, then flag first-seen combinations and listings run by standard users outside a managed session. Endpoint security suites, backup software and MDM check-ins are the usual sources of noise. Validate that your collection captures the invoking user and parent for each Process Creation event on the macOS fleet.
How to validate the T1007 detection before you trust it
This sequence turns a T1007 System service discovery rule from a plausible idea into evidence: an approved emulation on test hosts, a confirmed alert path to the SOC, measured results and a regression run that repeats after every rule or agent change.
Agree scope and rules of engagement
The detection owner, the SOC lead, the platform owner and the people who run the cyber range sign a short written scope. It names the test hosts for Linux, macOS and Windows, the time window, the accounts that may be used, the people who can stop the exercise, and what must be rolled back afterward. Nothing runs on production hosts. The step is done when every named party has approved the scope in writing and the SOC has a contact for stopping the exercise.
Confirm the ATT&CK 20.0 technique and sub-technique mapping
Before any test, record which ATT&CK version the rule targets, and confirm that T1007 System service discovery is still the correct technique identifier and that its data components and detection strategy match what the rule reads. Use the Enterprise ATT&CK 20.0 STIX bundle as the reference, and note any platform-specific behavior you expect to see on Linux, macOS and Windows. The output is a short mapping sheet that lists the technique, the platforms in scope, the telemetry sources (typically Process Creation and Command Execution) and the expected detection logic described in words.
Run an approved emulation on a test host per platform
An engineer on the cyber range team runs a pre-approved emulation of the T1007 behavior on one dedicated test host for each platform in scope, following the agreed plan and logging the exact start and end times. The emulation should be drawn from a vetted library, not improvised. Each run is tied to a unique exercise identifier so it can be matched to alerts later. The step closes when every platform has a logged run with its identifier and timestamps.
Confirm the alert reaches the SOC
The SOC analyst on duty checks that each emulation produced an alert in the case management or alerting queue, and that the alert arrived at the expected severity and routing. Trace the path from the endpoint agent through the log pipeline into the SIEM, for example Wazuh or Security Onion, and note any point where the event was dropped, delayed or enriched incorrectly. The step is done when each platform has either a matching alert or a documented gap with a named owner.
Record time to alert, fields and false positives
For each run, record the time from emulation start to alert creation, the fields present on the alert (such as process name, parent process, command line and user), and the number of benign events that also fired the rule during the observation window. Also run a short set of ordinary administrative commands on the same hosts to measure false positives. Store the results in a table with the ATT&CK version and rule version. The output is a baseline that a reviewer can compare against later.
Review gaps and tune with change control
The detection engineer and SOC lead review the results together. Missing fields, slow alerts and noisy benign matches each get a ticket with a proposed change, reviewed under the team's normal change control. Tuning should be tested on the same test hosts before it is promoted. The step closes when each change has a recorded reason, a reviewer and a link to the baseline it was measured against.
Re-run the regression set after every change
Keep the emulation set and the benign activity set as a fixed regression package. Re-run it after every rule update, agent upgrade, log pipeline change or ATT&CK version change, and compare the new alert times, fields and false positive counts with the stored baseline. If a result moves outside the agreed tolerance, the change is rolled back or reviewed before it stays in production. The output is a dated regression record that auditors and the SOC can read.
Preventive controls that reduce what T1007 can reveal
Preventive controls will not stop an adversary from querying services, but they shrink what a query can reveal and make enumeration noisier and slower. The five mitigations below are the ones ATT&CK most often maps to Discovery techniques, so they are a practical starting point for T1007 System service discovery. Confirm how each one applies to your own platforms before you treat it as coverage.
Operating system configuration
ATT&CK mitigation M1028 covers hardening settings that limit what local users and processes can see about services, such as restricting which accounts can query service managers and removing unneeded service definitions. On Linux and macOS, review who can read unit or launch definitions and whether shared hosts expose service state to unprivileged users. Confirm the exact settings supported by each operating system version in your estate before you rely on them.
Audit of service control activity
ATT&CK mitigation M1047 corresponds to enabling audit policy so that service enumeration and configuration reads leave a record. Without it, T1007 activity on a host often leaves only ordinary process records. Ask your platform team which audit subsystems are enabled, how long records are kept, and whether they reach the central SIEM where detections can run.
Network segmentation of management paths
ATT&CK mitigation M1030 limits which hosts can reach service management ports and remote administration interfaces. Segmentation does not hide services on the local host, but it reduces what a compromised workload can learn about services on neighboring systems. Verify that management traffic is restricted to administrative subnets and that east-west rules are reviewed after each infrastructure change.
Disable or remove unneeded features
ATT&CK mitigation M1042 reduces the number of services that exist to be discovered. Unused daemons, legacy remote management components and sample services left on images all add entries to every enumeration result. Build an inventory of enabled services per role, remove what is not required, and check golden images and container base layers so the reduction persists after redeployment.
Limit account rights to service data
ATT&CK mitigation M1018 restricts which accounts can list or modify services. Many enumeration commands succeed for any local user, so reviewing standard account rights, service account scopes and privileged group membership determines how much an attacker can see after an initial foothold. Confirm with your identity team that service accounts follow least privilege and that changes to these rights are logged.
Triage and response when a T1007 alert fires
Start by establishing whether the discovery activity is authorized before treating it as an intrusion. For a T1007 alert, the analyst should confirm the full process lineage of the command that queried services (the parent process, the launching session, and the user context), then check that account against the change calendar, the approved monitoring or inventory job list, and the configuration management tool that normally runs service inventories. Service enumeration is routine for patching agents, backup software and vulnerability scanners, so a match on a known job with a known service account usually closes the alert with a documented reason. An unexpected parent, an interactive shell on a server that should not have one, or an account with no recent change record keeps the alert open. Record the decision and the evidence used in the case, so the closure can be reviewed later.
Correlate the alert with what happened before and after it. Pull authentication events for the same account and host over the preceding window, looking for logons from unfamiliar sources, failed attempts followed by success, or privilege changes. Check network telemetry from the same host for new outbound connections, SMB or RPC sessions to other systems, or remote management traffic that began shortly after the enumeration. Discovery on its own is a weak signal; discovery followed by credential access or lateral movement is the pattern that justifies escalation. Use the sibling detections for process and account discovery on the same host to see whether T1007 is one step in a broader sequence. The analyst should confirm, not assume, which log sources cover the host, because gaps in retention change how far back the correlation can reach.
Contain without destroying evidence, and hand off early when the pattern escalates. Prefer isolating the host at the network layer or restricting the account's access while keeping the machine powered on, so volatile data such as running processes, network connections and loaded service state remains available. Use Velociraptor or the EDR platform already in place to collect the artifacts needed for the investigation, including service configuration, process trees, recent binary execution and relevant event logs, and hash what is collected under the case's chain-of-custody procedure. Disabling the account or stopping a service should be a deliberate choice recorded in the timeline, because it can alter what responders see. Once credential access or lateral movement is observed, or the account cannot be tied to an approved job, hand the case to the incident response team with the timeline, collected artifacts and open questions. Confirm in advance, with your own IR retainer or internal team, who owns that decision and how quickly they must be engaged.
How to rehearse T1007 detection and response in a private cyber range
On Linux, the range should mirror a production-like host fleet with Wazuh agents installed on representative servers and workstations, reporting to a Wazuh manager that stores and indexes events. Security Onion or Zeek sensors on the management and server segments add network context, so responders can correlate host events with traffic from the same time window. Injects are scripted at a high level by the exercise lead, who decides which benign service-inventory activity to simulate and which hosts receive it, without writing operator steps into the playbook.
- Telemetry coverage: Confirm that process creation events, with command line and parent process fields, reach the Wazuh manager from every agent in scope within an agreed time window.
- Alert timing: Record how long it takes from inject to first alert, and compare that against the detection objective your team sets before the exercise.
- Field completeness: Check that user, host, parent process and command line fields are populated, since missing fields make triage slower.
- Severity accuracy: Verify that the alert severity matches the team's documented priority for service enumeration on servers versus workstations.
- Response records: Require triage notes, a containment decision with its rationale, and a lessons-learned entry for every alert raised.
Before the exercise, ask your provider to confirm which Wazuh rules and decoders are in the build and which version of the range images they target.
The macOS range uses Wazuh agents on representative developer and administrator endpoints, with the same manager and indexing path used for the other platforms so results can be compared. macOS telemetry often differs in fields and collection depth, so the range build should document exactly which unified logging or endpoint security sources the agents are configured to forward. Zeek or Security Onion on the endpoint segment gives network context, although most service inventory activity on a single Mac stays local and needs host telemetry to detect.
- Source validation: Confirm which process and command execution sources are forwarded from each macOS build, and record any gaps in the range runbook.
- Alert timing: Measure the interval from inject to alert on laptops that are asleep, on battery or on a VPN, since these conditions often delay ingestion.
- Field coverage: Check that the user context and parent process are present, because many macOS administration tools run under shared or elevated accounts.
- Severity logic: Confirm that alerts on managed fleet hosts are rated differently from alerts on unmanaged or personal devices, if your policy distinguishes them.
- Response quality: Require triage notes that state whether the activity came from a sanctioned management tool, and a containment decision recorded with the approver's name.
Ask the provider to confirm which macOS versions the range supports and which Wazuh agent version is validated for them.
The Windows range should include domain-joined workstations and servers running Wazuh agents, with Sysmon or an equivalent endpoint logging configuration if your standard requires it. The Wazuh manager receives events from all agents, and Security Onion or Zeek on the server segment adds network context for any remote queries that accompany the local activity. The exercise lead keeps injects at a high level, specifying the host groups, timing and expected benign activity, while the detection team builds and tests the rules independently.
- Log source readiness: Confirm that process creation logging, including command line capture, is enabled on every range host, and that the Wazuh agent forwards it without dropped events.
- Alert timing: Record time from inject to alert across domain controllers, servers and workstations separately, since ingestion load differs by host role.
- Field and correlation checks: Verify that the user, parent process and host name fields support correlation with logon events, so responders can see who ran the activity.
- Severity and tuning: Compare alert severity against the documented priority, and note any benign administrative scripts that generate noise, so they can be tuned without suppressing real detections.
- Response evidence: Require triage notes, a containment decision for affected endpoints, and a lessons-learned record that names any rule changes made after the exercise.
Before the exercise, confirm the logging baseline with your Windows administrators and the Sigma or Wazuh rule versions you plan to test.
Questions SOC leads and detection engineers ask about T1007
How do I separate administrator service checks from adversary system service discovery?
Start by treating the activity as a question of context, not command name, because the same service query can come from a patch script, a monitoring agent or an intruder. Build an allowlist of known administrative accounts, parent processes, jump hosts and change windows, and alert when service enumeration comes from an interactive session, an unexpected parent, or a host that has no scheduled maintenance. Pair the process telemetry with the account that launched it and the source host, then review a sample of benign hits with the operations team before tuning. Expect the allowlist to need regular review as administrators and tooling change.
How should I version a T1007 detection rule against ATT&CK 20.0?
Record the ATT&CK version in the rule metadata, the detection strategy or analytic identifier you map to, and the data components the rule depends on, so a future reader knows what the rule was written to cover. ATT&CK 20.0 is the version these pages target, and MITRE's update notes show that releases can rename, deprecate or revoke techniques and replace detections with detection strategies and analytics. Keep the rule in version control, tag each change with the ATT&CK version it was reviewed against, and re-check the mapping whenever you upgrade the reference. The ATT&CK updates page is the place to watch for changes.
Do Sigma rules cover system service discovery on all three platforms?
Do not assume a single rule covers Linux, macOS and Windows, because service enumeration uses different process names, logs and data sources on each platform. Check the Sigma rule repository for rules that reference each operating system, then test each one against your own log format, since field names change between Sysmon, auditd, endpoint agents and Wazuh decoders. Treat any gap you find as an open item in your coverage matrix rather than assuming the rule works. Confirm the exact rule set and its last update date in the repository before you cite it in an audit file.
How should I handle T1007 gaps when the technique has no sub-techniques?
T1007 is a single technique without sub-techniques, so the gap usually sits in platform coverage or in the telemetry a detection depends on, not in a sub-technique list. Document which platforms and log sources each rule covers, and mark anything your environment cannot observe as a named risk with an owner and a review date. Where a platform lacks process creation or command logging, look for a related data source such as file access or a service management log, and record the compensating control. Revisit the gap register after each ATT&CK release, because a technique's scope can change between versions.
How often should I rerun validation for a system service discovery detection?
Rerun validation after any change that could affect the detection, including logging agent upgrades, changes to Sysmon or auditd configuration, new administrative tooling, rule edits and ATT&CK version updates. Many teams also schedule a recurring run, such as monthly or quarterly, to catch silent breakage in log pipelines. Choose the interval with your change management and risk owners, and record the chosen interval in the detection standard so it is clear who sets it. Keep the results of each run with the date, the rule version and the telemetry source tested.
What evidence would an auditor expect for system service discovery detection?
An auditor will usually look for a clear link from the threat to the control, the rule that detects it, and proof that the rule works and is maintained. Expect to show the rule definition with its ATT&CK mapping and version, the log sources it depends on, the validation results from your cyber range or test environment, the alert and triage records from production, and the change history of the rule. Auditors do not issue certifications on your behalf, so confirm with your assessor which evidence format they accept and how far back they want records to go. DeployOpen can help prepare these artifacts for an assessment, but the audit conclusion comes from the independent assessor.
Can my team build and test this detection without outside help?
Yes, many SOC teams can build a basic detection for T1007 with their existing SIEM and endpoint telemetry, provided they have the logging coverage, the time to tune it and a safe test environment. The harder parts are usually consistent log collection across Linux, macOS and Windows, keeping mappings current across ATT&CK releases, and running repeatable validation. Decide which of these your team owns and which would benefit from a fixed-scope engagement, then agree the scope, deliverables and timeline in writing before any work starts. DeployOpen implements and tests open-source platforms inside your own infrastructure, so the same work can be done in your environment or in a private cyber range.
How DeployOpen builds T1007 detections and range exercises
DeployOpen starts every T1007 System service discovery engagement with a written scope that names the operating systems in play, the telemetry sources the client already collects, and the decisions the client wants to make at the end. For this technique that usually means agreeing which Linux, macOS and Windows hosts are in scope, which service-query activity is expected from administrators and configuration management, and whose approval is needed before any new collection is turned on. Because the work is fixed-scope, deliverables such as detection logic, test cases, tuning notes and an evidence pack are listed in the agreement before work begins, and any change to them goes through the same written process. Ask the implementer to show which Process Creation and Command Execution fields they plan to rely on, and to name the ATT&CK version the mapping targets, since MITRE can rename or deprecate content between releases.
Detections are then built on the client's own stack, typically Wazuh for host telemetry and alerting or Security Onion for network and log analysis, so that the rules, dashboards and retained data stay inside the client's environment. The engineering work covers normalizing service-listing commands and service manager queries across platforms, writing Sigma-style logic that can be translated to the client's SIEM, and suppressing known administrative baselines so that alerts stay reviewable. Where a platform does not expose a needed field by default, the plan should say so and name the collection change, rather than assuming it exists. Each rule is then exercised in a private cyber range with scripted purple team runs, and the results are recorded as test evidence: which runs fired, which were missed, and what tuning followed. DeployOpen prepares these controls, configurations and evidence for compliance readiness, but it does not issue audit reports or attestations. Independent auditors and certification bodies make that determination, so the client should confirm with its auditor which artifacts they expect.
