AN1101: Analytic 1101
Adversary invokes 'dpkg -l', 'rpm -qa', or other package managers via shell or script to enumerate installed software.
Analyst context for executives and security teams
This analytic matters because Linux package inventory enumeration can help an intruder understand what software, tools, and potential weaknesses exist on a host. For leaders, the value is not that the commands are rare—they may be used by administrators—but whether the SOC can distinguish routine system administration from suspicious discovery activity during an incident.
Executive priority
Prioritize this as a Linux visibility and incident-readiness check. It supports decisions about endpoint telemetry coverage, audit evidence for software inventory monitoring, and whether responders can reconstruct early discovery behavior on servers or workstations. Because ATT&CK provides no detection logic or relationships for this analytic, treat it as a validation target rather than a complete detection strategy.
Technical view
Validate whether Linux endpoint logging captures shell or script execution of package manager inventory commands such as 'dpkg -l' and 'rpm -qa', as described in the official analytic. SOC teams should tune around expected administrative, patching, configuration management, and vulnerability-management activity, then look for unusual parent processes, users, hosts, timing, or correlation with other discovery behavior where local telemetry supports it.
Likely telemetry
- Linux process creation telemetry
- Command-line arguments for shell and script execution
- User, host, and parent-process context
- Script execution logs where available
- Administrative automation or configuration-management activity records
Detection direction
- Confirm Linux process command-line collection is enabled and retained long enough for investigations.
- Baseline legitimate package inventory activity from administrators, patch tools, and vulnerability-management workflows.
- Tune detections for suspicious context rather than the command alone, because package listing can be normal administrative behavior.
- Review whether shell-launched and script-launched package manager activity are both visible.
- Correlate with other local discovery or post-compromise indicators only when supported by the organization’s telemetry; no ATT&CK relationship context was supplied.
Mitigation priorities
- Ensure authorized software inventory, patching, and vulnerability-management processes are documented so SOC teams can distinguish expected activity.
- Strengthen Linux endpoint logging for process creation and command-line visibility before relying on this analytic.
- Apply least-privilege and administrative access governance to reduce unnecessary interactive access to Linux hosts.
- Use incident response playbooks to triage suspicious package enumeration in context: user legitimacy, host role, parent process, timing, and surrounding activity.
Analyst notes and limits
This is a detection analytic object for Linux. The official description is limited to adversary invocation of package managers via shell or script to enumerate installed software. No tactic, detection text, relationships, mitigations, or data source mappings were supplied, so the take focuses on practical validation and tuning considerations rather than a prescriptive rule.
ATT&CK fields supplied for this object are sparse. There is no official detection logic, no relationship context, and no stated tactic. Local baselines and telemetry quality are required to determine whether this behavior is suspicious in a specific environment.
Analytic 1101
Adversary invokes 'dpkg -l', 'rpm -qa', or other package managers via shell or script to enumerate installed software.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 362f96e4626e… |
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 AN1101Open 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.