S0124: Pisloader
Pisloader is a malware family that is notable due to its use of DNS as a C2 protocol as well as its use of anti-analysis tactics. It has been used by APT18 and is similar to another malware family, HTTPBrowser, that has been used by the group. [1]
Analyst context for executives and security teams
Pisloader matters because it combines Windows malware behavior with DNS-based command and control and anti-analysis/obfuscation traits. For leaders, the practical issue is whether the organization can see suspicious DNS activity, connect it to endpoint behavior, and preserve enough evidence to support incident response decisions before follow-on discovery, persistence, or tool transfer occurs.
Executive priority
Prioritize validation of DNS monitoring, Windows endpoint visibility, and persistence detection. DNS is often broadly allowed for business operations, which can make C2 activity harder to distinguish from normal traffic. Security leaders should ask whether SOC teams can correlate unusual DNS patterns with Windows command shell execution, system/file discovery, registry run key changes, and inbound tool transfer. This is also useful compliance evidence: it demonstrates that monitoring covers command-and-control, persistence, and discovery behaviors rather than relying only on malware names or signatures.
Technical view
ATT&CK identifies Pisloader as Windows malware notable for DNS C2 and anti-analysis tactics, used by APT18, and related to techniques including System Network Configuration Discovery, Obfuscated Files or Information, Windows Command Shell, DNS C2, System Information Discovery, File and Directory Discovery, Ingress Tool Transfer, Standard Encoding, and Registry Run Keys / Startup Folder. SOC and IR teams should validate whether DNS telemetry can be tied back to host process context and whether Windows endpoint logs capture command shell use, discovery commands, file writes/transfers, and Run key or startup folder persistence. Because official detection guidance is not provided, detection engineering should be behavior-led and environment-tested rather than based solely on the malware family name.
Likely telemetry
- DNS query and response logs, including query names, frequency, domains, record types, response codes, and resolver/client attribution
- Windows endpoint process creation telemetry, especially command shell activity
- Windows registry monitoring for Run key changes and startup folder modifications
- File creation and modification telemetry for downloaded or transferred tools/files
- Endpoint alerts or metadata indicating obfuscated, encoded, packed, or difficult-to-analyze files
Detection direction
- Validate DNS analytics for unusual beaconing, high-volume or structured subdomain queries, uncommon domains, encoded-looking labels, and client systems making atypical DNS requests.
- Correlate suspicious DNS behavior with Windows process execution, especially cmd.exe activity and local discovery commands.
- Monitor for Registry Run key and startup folder changes, then triage them alongside DNS C2 indicators and newly created files.
- Tune detections to reduce false positives from legitimate software updaters, administrative scripts, monitoring agents, and enterprise DNS-heavy applications.
- Confirm whether DNS logs retain enough client attribution and history to support incident scoping; resolver-only visibility may be insufficient without endpoint correlation.
Mitigation priorities
- Ensure DNS logging and retention are sufficient for investigation and threat hunting.
- Restrict and monitor direct external DNS where possible by requiring approved resolvers and reviewing egress paths.
- Harden Windows persistence locations through monitoring and access control around Run keys and startup folders.
- Improve endpoint detection coverage for command shell execution, discovery activity, suspicious file creation, and tool transfer behavior.
- Build incident response playbooks that connect DNS C2 findings to endpoint containment, persistence review, and evidence preservation.
Analyst notes and limits
The supplied ATT&CK data supports a focus on Windows hosts, DNS command-and-control, anti-analysis/obfuscation, discovery, command shell execution, ingress tool transfer, standard encoding, and Run key/startup folder persistence. APT18 is listed as using Pisloader, but local attribution should require independent evidence.
Official ATT&CK detection guidance is not provided for this object. The description and relationships identify behaviors but do not provide current indicators, prevalence, active exploitation status, or environment-specific detection thresholds. Local DNS architecture, endpoint telemetry quality, and retention determine practical coverage.
Pisloader
Pisloader is a malware family that is notable due to its use of DNS as a C2 protocol as well as its use of anti-analysis tactics. It has been used by APT18 and is similar to another malware family, HTTPBrowser, that has been used by the group. [1]
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 | T1547.001 | Registry Run Keys / Startup Folder Sub-technique | Pisloader establishes persistence via a Registry Run key.CitationPalo Alto DNS Requests |
| Enterprise | T1059.003 | Windows Command Shell Sub-technique | Pisloader uses cmd.exe to set the Registry Run key value. It also has a command to spawn a command shell.CitationPalo Alto DNS Requests |
| Enterprise | T1132.001 | Standard Encoding Sub-technique | Responses from the Pisloader C2 server are base32-encoded.CitationPalo Alto DNS Requests |
| Enterprise | T1016 | System Network Configuration Discovery | Pisloader has a command to collect the victim's IP address.CitationPalo Alto DNS Requests |
| Enterprise | T1071.004 | DNS Sub-technique | Pisloader uses DNS as its C2 protocol.CitationPalo Alto DNS Requests |
| Enterprise | T1027 | Obfuscated Files or Information | Pisloader obfuscates files by splitting strings into smaller sub-strings and including "garbage" strings that are never used. The malware also uses return-oriented programming (ROP) technique and single-byte XOR to obfuscate data.CitationPalo Alto DNS Requests |
| Enterprise | T1105 | Ingress Tool Transfer | Pisloader has a command to upload a file to the victim machine.CitationPalo Alto DNS Requests |
| Enterprise | T1082 | System Information Discovery | Pisloader has a command to collect victim system information, including the system name and OS version.CitationPalo Alto DNS Requests |
| Enterprise | T1083 | File and Directory Discovery | Pisloader has commands to list drives on the victim machine and to list file information for a given directory.CitationPalo Alto DNS Requests |
Groups, software, and campaigns
G0026: APT18
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.1 | Current bundle | 69cae75e20fd… |
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]
Palo Alto DNS Requests
Grunzweig, J., et al. (2016, May 24). New Wekby Attacks Use DNS Requests As Command and Control Mechanism. Retrieved August 17, 2016.
Open source URL -
[2]
Pisloader
(Citation: Palo Alto DNS Requests)
-
[3]
mitre-attack S0124Open 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.