T1070.007: Clear Network Connection History and Configurations
Adversaries may clear or remove evidence of malicious network connections in order to clean up traces of their operations. Configuration settings as well as various artifacts that highlight connection history may be created on a system and/or in application logs from behaviors that require network connections, such as Remote Services or External Remote Services. Defenders may use these artifacts to monitor or otherwise analyze network connections created by adversaries.
Network connection history may be stored in various locations. For example, RDP connection history may be stored in Windows Registry values under [1]:
* HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default * HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
Windows may also store information about recent RDP connections in files such as C:\Users\\%username%\Documents\Default.rdp and `C:\Users\%username%\AppData\Local\Microsoft\Terminal Server Client\Cache\`.[2] Similarly, macOS and Linux hosts may store information highlighting connection history in system logs (such as those stored in `/Library/Logs` and/or `/var/log/`).[3][4][5]
Malicious network connections may also require changes to third-party applications or network configuration settings, such as Disable or Modify System Firewall or tampering to enable Proxy. Adversaries may delete or modify this data to conceal indicators and/or impede defensive analysis.
Analyst context for executives and security teams
This technique matters because it targets the evidence defenders need to reconstruct remote access and network activity. If RDP history, system logs, application logs, firewall settings, proxy settings, or network-device artifacts are deleted or altered, incident responders may lose the timeline needed to determine how an intruder moved, what systems were accessed, and whether recovery is complete.
Executive priority
Prioritize this where remote administration, external remote access, network devices, or regulated logging evidence are important to operations. The business question is not only “can we detect the intrusion?” but “can we prove what happened after someone tries to erase connection traces?” This is especially relevant to IR readiness, audit defensibility, and resilience planning for environments where network infrastructure or critical operations depend on trustworthy connection records.
Technical view
For Linux, macOS, Windows, and network devices, validate whether defenders can observe deletion or modification of network connection history and related configuration. On Windows, ATT&CK highlights RDP artifacts in Terminal Server Client registry keys, Default.rdp, and Terminal Server Client cache paths. On macOS and Linux, review system log sources such as /Library/Logs, /var/log, Apple unified logs, and systemd journal data. Also correlate tampering with changes to firewall or proxy configuration, especially where activity follows Remote Services or External Remote Services behavior. The related detection strategy DET0049 indicates behavioral detection of network history and configuration tampering; teams should test whether that logic is implemented locally and supported by retained telemetry.
Likely telemetry
- Windows Registry auditing for RDP-related Terminal Server Client keys
- File monitoring for Default.rdp and Terminal Server Client cache artifacts
- macOS system and unified log records related to remote login or screen sharing
- Linux /var/log and systemd journal records
- Application logs that record remote or network connections
Detection direction
- Validate behavioral detections for deletion, truncation, or modification of connection history and network configuration artifacts rather than relying only on the presence of logs.
- Compare endpoint-local records with centralized/off-host logs to identify gaps that may indicate tampering.
- Tune for legitimate administrator cleanup, troubleshooting, privacy-maintenance actions, and standard configuration management to reduce false positives.
- Correlate history/configuration tampering with remote access events, firewall changes, proxy changes, and suspicious gaps in session history.
- Include network devices in coverage planning; ATT&CK relationships include activity involving routers and edge-oriented operations, so endpoint-only visibility may miss material evidence.
Mitigation priorities
- Implement remote data storage or centralized log management so critical evidence is not only stored on the system being investigated.
- Restrict registry permissions for sensitive Windows keys, including those that store remote connection history, so only authorized users or processes can modify them.
- Review access controls around log directories, application logs, firewall configuration, proxy settings, and network-device configurations.
- Make preservation of off-host logs and configuration history part of incident response playbooks before rebuilding or reimaging systems.
- Use threat-intelligence relationships, including RedPenguin, Volt Typhoon, UNC3886, and SUNBURST mappings, as prioritization context only; do not treat those relationships as proof of local activity.
Analyst notes and limits
This is a stealth sub-technique under Indicator Removal. The supplied relationships show use by a campaign, groups, and software, and mitigations M1024 and M1029 are directly relevant. The most useful defensive validation is whether teams can still reconstruct network activity after local history or configuration artifacts are altered.
MITRE did not provide official detection text for this object. The listed artifact paths and log locations are examples, not a complete inventory. Actual coverage depends on local OS versions, logging configuration, retention, endpoint controls, network-device management, and whether logs are forwarded off-host before tampering occurs.
Clear Network Connection History and Configurations
Adversaries may clear or remove evidence of malicious network connections in order to clean up traces of their operations. Configuration settings as well as various artifacts that highlight connection history may be created on a system and/or in application logs from behaviors that require network connections, such as Remote Services or External Remote Services. Defenders may use these artifacts to monitor or otherwise analyze network connections created by adversaries.
Network connection history may be stored in various locations. For example, RDP connection history may be stored in Windows Registry values under [1]:
* HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default * HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
Windows may also store information about recent RDP connections in files such as C:\Users\\%username%\Documents\Default.rdp and `C:\Users\%username%\AppData\Local\Microsoft\Terminal Server Client\Cache\`.[2] Similarly, macOS and Linux hosts may store information highlighting connection history in system logs (such as those stored in `/Library/Logs` and/or `/var/log/`).[3][4][5]
Malicious network connections may also require changes to third-party applications or network configuration settings, such as Disable or Modify System Firewall or tampering to enable Proxy. Adversaries may delete or modify this data to conceal indicators and/or impede defensive analysis.
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.
Related techniques
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 | T1070 | Indicator Removal | This object subtechnique of Indicator Removal. |
Groups, software, and campaigns
G1048: UNC3886
UNC3886 is a China-nexus cyberespionage group that has been active since at least 2022, targeting defense, technology, and telecommunication organizations located in the United States and the Asia-Pacific-Japan (APJ) regions. UNC3886 has displayed a deep understanding of edge devices and virtualization technologies through the exploitation of zero-day vulnerabilities and the use of novel malware families and utilities.[1][2]
G1017: Volt Typhoon
Volt Typhoon is a People's Republic of China (PRC) state-sponsored actor that has been active since at least 2021, primarily targeting critical infrastructure organizations in the US and its territories including Guam. Volt Typhoon's targeting and pattern of behavior have been assessed as pre-positioning to enable lateral movement to operational technology (OT) assets for potential destructive or disruptive attacks. Volt Typhoon has emphasized stealth in operations using web shells, living-off-the-land (LOTL) binaries, hands on keyboard activities, and stolen credentials.[1][2][3][4]. The group has leveraged compromised SOHO routers to proxy command and control traffic and obscure its infrastructure, activity associated with the KV botnet.[5].
Reporting indicates a separate initial access cluster, SYLVANITE, has been observed exploiting internet-facing edge devices and transferring access to Volt Typhoon, also tracked as VOLTZITE, for follow-on operations. [6]
S0559: SUNBURST
C0056: RedPenguin
The RedPenguin project was launched by Juniper in July 2024 to investigate reported malware infections of Juniper MX Series routers. RedPenguin activity was separately attributed to UNC3886 and included the deployment of multiple custom versions of the publicly-available TINYSHELL backdoor on Juniper routers.[1][2]
All related ATT&CK context
Mitigation direction
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 | 2.0 | Current bundle | 05f74404f19b… |
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]
Microsoft RDP Removal
Microsoft. (2021, September 24). How to remove entries from the Remote Desktop Connection Computer box. Retrieved June 15, 2022.
Open source URL -
[2]
Moran RDPieces
Moran, B. (2020, November 18). Putting Together the RDPieces. Retrieved October 17, 2022.
Open source URL -
[3]
Apple Culprit Access
rjben. (2012, May 30). How do you find the culprit when unauthorized access to a computer is a problem?. Retrieved August 3, 2022.
Open source URL -
[4]
FreeDesktop Journal
freedesktop.org. (n.d.). systemd-journald.service. Retrieved June 15, 2022.
Open source URL -
[5]
Apple Unified Log Analysis Remote Login and Screen Sharing
Sarah Edwards. (2020, April 30). Analysis of Apple Unified Logs: Quarantine Edition [Entry 6] – Working From Home? Remote Logins. Retrieved August 19, 2021.
Open source URL -
[6]
mitre-attack T1070.007Open 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.