DET0483: Detection of System Service Discovery Commands Across OS Platforms
DET0483 is a detection strategy for identifying attempts to discover local system services across operating systems. For leaders, the value is not the comm...
Analyst context for executives and security teams
DET0483 is a detection strategy for identifying attempts to discover local system services across operating systems. For leaders, the value is not the command names themselves; it is that service discovery often helps an intruder understand what security tools, business applications, scheduled jobs, or operational services exist before deciding what to target next. Because the ATT&CK object has no official detection text and no platforms listed on the strategy itself, teams should treat it as a validation prompt tied to the related technique, T1007 System Service Discovery, which covers Linux, macOS, and Windows.
Executive priority
Prioritize this as a coverage and readiness question: can the SOC prove it can see service-enumeration behavior on the operating systems that matter most to business continuity? This matters for incident triage, audit evidence, and resilience planning because service discovery can reveal where adversaries are mapping critical systems. Budget and control discussions should focus on endpoint telemetry completeness, command-line visibility, and consistent logging across Windows, Linux, and macOS where those platforms are in scope.
Technical view
SOC and detection engineering teams should validate monitoring for service and scheduled-task discovery activity associated with T1007 System Service Discovery. The relationship context supports Linux, macOS, and Windows and the discovery tactic. Practical validation should confirm whether endpoint, process, shell, and command-line telemetry captures use of native utilities and administrative tools that enumerate services or scheduled tasks. Because the detection strategy object itself provides no official detection logic, teams should avoid assuming coverage and instead test local data availability, normalization, alert thresholds, and triage context.
Likely telemetry
- Endpoint process creation events with command-line arguments
- Shell and terminal execution logs where available
- Windows service control and task enumeration-related activity logs
- Linux and macOS command execution or audit telemetry for service and scheduled-task queries
- EDR telemetry showing parent process, user, host, and execution context
Detection direction
- Validate visibility for service discovery behavior across the related platforms: Linux, macOS, and Windows.
- Tune detections to distinguish routine administrator, monitoring, software deployment, and troubleshooting activity from unusual discovery by unexpected users, hosts, parent processes, or time windows.
- Correlate service discovery with nearby discovery behaviors, privilege context, remote logons, suspicious parent processes, or incident-scoped hosts rather than treating every service query as malicious.
- Check blind spots where command-line arguments are not collected, shell history is unavailable, EDR coverage is inconsistent, or non-Windows platforms are monitored less consistently.
- Use the related ATT&CK technique T1007 as the mapping anchor for reporting because the DET0483 object does not include its own official detection text.
Mitigation priorities
- First, ensure endpoint logging and EDR coverage are enabled and consistently retained on in-scope Windows, Linux, and macOS systems.
- Second, restrict administrative privileges so service and scheduled-task enumeration by non-administrative or unexpected accounts is easier to identify and investigate.
- Third, document approved administrative and monitoring use cases to reduce false positives and support compliance evidence.
- Fourth, integrate alerts with incident response playbooks that ask why the account or process needed service information and what actions followed.
- Fifth, review coverage gaps on critical servers and operationally important systems where service discovery could expose high-value dependencies.
Analyst notes and limits
This take is based on the supplied DET0483 metadata and its relationship to T1007 System Service Discovery. The ATT&CK object does not provide an official description, official detection logic, platforms, or tactics for the detection strategy itself. The concrete platform and tactic context comes from the related technique: System Service Discovery, discovery tactic, on Linux, macOS, and Windows.
No active exploitation, attribution, prevalence, impact, or guaranteed detection coverage is stated in the supplied fields. Local validation is required to determine which operating systems are present, what telemetry is collected, what administrative activity is normal, and whether detections are reliable in the environment.
Detection of System Service Discovery Commands Across OS Platforms
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1007 | System Service Discovery | This object detects System Service Discovery. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | fc7e303caa8a… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0483Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.