CIS Controls Secure Configuration of Enterprise Assets and Software Capability Group

A successful remote wipe removes enterprise files, local databases, cached content, and other managed data before an adversary with possession of the device can collect it.

Wiping managed email applications and locally cached mailbox files can prevent collection of Outlook PST or OST files and other locally stored enterprise email.

Wiping managed browsers and application data removes locally stored enterprise session cookies before they can be extracted from a lost or stolen device.

Remote wipe can remove managed files containing passwords, API keys, connection strings, or other credential material. The mitigation is limited to files covered by the wipe and does not address credentials stored elsewhere.

A full Windows device wipe removes local Registry hives containing enterprise credential material before they can be searched or exported. A selective enterprise-data wipe may not remove operating-system Registry data.

Wiping enterprise-managed key files, certificates, VPN profiles, and application containers can prevent private keys from being obtained from a lost device. Keys synchronized elsewhere or already exported remain exposed and should be revoked separately.

A full wipe of a managed macOS device removes locally stored Keychain databases and enterprise certificates. Items synchronized to other devices or already extracted are not revoked merely by wiping the device.

Remote wipe of managed browser profiles can remove locally stored enterprise passwords and related authentication data. Browser-synchronized credentials and already extracted copies require separate account or server-side action.

A full Windows wipe removes local Credential Manager vault files and associated enterprise credentials. Selective wipe implementations may not remove credentials stored outside managed application containers.

A full device wipe removes local shell-history files that may contain passwords, tokens, or sensitive commands. Selective enterprise wipes may not remove operating-system shell histories.

Remote wipe can remove a managed password-manager application, its local vault, and cached decrypted data. Cloud-hosted vault contents remain available and require account revocation, device removal, or token invalidation.

Automatic device lockout limits the number of consecutive authentication attempts that can be made against a portable device, directly reducing the likelihood that repeated breached username password attempts will succeed.

Automatic device lockout limits the number of consecutive authentication attempts that can be made against a portable device, directly reducing the likelihood that repeated online password attempts will succeed.

Automatic device lockout limits the number of consecutive authentication attempts that can be made against a portable device, directly reducing the likelihood that repeated online password attempts will succeed.

Automatic device lockout limits the number of consecutive authentication attempts that can be made against a portable device, directly reducing the likelihood that repeated online password attempts will succeed.

Directing DNS traffic through trusted enterprise resolvers can prevent systems from communicating directly with adversary-controlled DNS servers and can support blocking or sinkholing malicious DNS requests.

This is a partial mapping because DNS is one of the application-layer protocols covered by this technique. Configuring trusted DNS servers affects DNS-based command and control but does not mitigate web, mail, file-transfer, or publish-subscribe protocols.

Enforcing use of trusted DNS resolvers reduces the ability of enterprise assets to communicate directly with adversary-controlled DNS infrastructure for exfiltration. The mitigation applies only to implementations that use DNS or depend on unauthorized DNS servers.

DNS can carry encoded exfiltrated data over an unencrypted non-command-and-control protocol. Routing requests through controlled resolvers provides an enforcement point for blocking unauthorized DNS servers, suspicious domains, or abnormal query activity.

DNS can be used to tunnel command-and-control traffic or other protocols. Enforcing trusted resolvers and preventing direct DNS communication can disrupt conventional DNS tunneling,

Disabling unnecessary remote services eliminates the corresponding authentication and remote-access path, directly reducing lateral movement opportunities.

Disabling Remote Desktop Services where RDP is not operationally required prevents adversaries from connecting through that service.

Disabling unnecessary SMB file sharing and administrative shares directly removes common lateral movement, file-transfer, and remote-management paths.

Disabling DCOM when it is not required removes a remote RPC-based execution and management interface that adversaries may abuse.

Disabling the SSH daemon or Remote Login on systems that do not require it eliminates an SSH-based remote-access path.

Uninstalling unnecessary VNC server software removes the listener and prevents remote control through that implementation.

Disabling the WinRM service where it is unnecessary removes a remote command-execution and administration interface.

Disabling unnecessary cloud-native VM connection types, serial consoles, or direct management services eliminates those remote-administration paths.

Removing unnecessary shared folders and file-sharing services prevents adversaries from placing malicious content in those shares for other users or systems to execute.

Uninstalling or disabling unnecessary externally accessible VPN, remote desktop, SSH, and management services directly reduces external entry points.

Removing unused public-facing applications, services, and web modules eliminates exploitable listeners and reduces the externally exposed attack surface.

A remote service that has been disabled or uninstalled can no longer be reached and exploited through its network interface.

Removing unauthorized or unnecessary remote-access products and disabling embedded remote-support functionality directly eliminates those access channels.

Uninstalling unnecessary remote desktop products prevents adversaries from abusing that specific software for persistent or interactive access.

Disabling unnecessary server extension mechanisms and components reduces the features adversaries can abuse to establish persistent server-side access.

Disabling unnecessary web server functionality, scripting engines, and dangerous application functions can prevent particular web shell implementations from executing.

Removing unused IIS modules, handlers, filters, and extensions directly reduces opportunities to install or abuse malicious IIS components.

Disabling unnecessary metadata services or insecure metadata-service versions directly prevents adversary access through those endpoints.

Removing unnecessary configuration-management protocols and repositories reduces the systems and services from which adversaries can collect configuration data.

Disabling SNMP where it is unnecessary removes the management service used to retrieve MIB and configuration information.

Removing unnecessary Telnet, HTTP management, TFTP, legacy SNMP, or similar configuration services reduces direct collection of network-device configurations.

Disabling unnecessary Wi-Fi, cellular, modem, Bluetooth, or other secondary network services removes potential alternative exfiltration channels.

Disabling the Bluetooth service and adapter functionality where it is unnecessary prevents Bluetooth-based data transfer from that asset.

Disabling unnecessary cloud services, command-line integrations, and administrative applications reduces available cloud-management paths, although required web consoles may remain accessible.

Removing unnecessary file-sharing services and shares reduces the network data repositories available for adversary collection.

Removing unnecessary plaintext and broadcast-based services reduces sensitive service traffic available for interception, although it does not prevent sniffing of remaining traffic.

Disabling unnecessary remote WMI and dependent management services reduces remote WMI execution, while local WMI functionality may remain available.

Disabling unnecessary network-device command-line services, especially Telnet or direct CLI access, removes a command interface adversaries could abuse.

Uninstalling unnecessary deployment agents and disabling unused remote-deployment functionality reduces the number of centralized execution mechanisms available to an adversary.

Removing unnecessary proxy, relay, port-forwarding, and tunneling services reduces the ability to turn an enterprise asset into a network intermediary.

Disabling unnecessary internal proxy listeners, SSH forwarding, port proxies, and routing functions impedes the use of a compromised asset as an internal pivot.

Disabling unnecessary SMB, WebClient, WebDAV, LLMNR, NBT-NS, and related services reduces mechanisms that can coerce outbound authentication.

Disabling the Background Intelligent Transfer Service where it is genuinely unnecessary prevents adversary use of BITS for transfer, execution, or persistence.

Removing unnecessary SMB, SSH, WinRM, file-sharing, and deployment services reduces common channels used to move tools between systems.

Disabling unnecessary extended stored procedures, scripting extensions, or database execution features reduces opportunities to establish persistence through the database server.

Removing unused mail transport agents and extension points reduces the components available for adversary persistence in messaging infrastructure.

Disabling unnecessary Terminal Services functionality reduces opportunities to replace or abuse associated DLL components, although required RDP systems remain exposed.

Removing unnecessary vSphere Installation Bundles and disabling unused ESXi extension functionality reduces the components available for hypervisor persistence.

Removing unnecessary container-management utilities, exposed APIs, and administrative services reduces the mechanisms available for remote container commands.

Minimal container images and removal of unnecessary tools, shells, runtimes, and privileged services reduce some prerequisites and post-exploitation options for container escape.

Disabling unnecessary remote services prevents sessions from being established through those services and therefore removes sessions that could later be hijacked.

Disabling unnecessary SSH and agent-forwarding functions removes some SSH sessions and forwarding sockets that adversaries could hijack.

Disabling unnecessary RDP services prevents creation of RDP sessions on those assets, eliminating that session-hijacking opportunity.

Disabling unnecessary Active Directory Certificate Services web enrollment, enrollment agents, legacy authentication protocols, and certificate-service roles reduces certificate abuse paths.

Disabling unnecessary SaaS integrations, plug-ins, application consent features, and service connections reduces the number of integrations an adversary can authorize or abuse.

Replacing plaintext administrative protocols such as Telnet and HTTP with SSH and HTTPS prevents captured management traffic from directly exposing credentials, commands, and configuration data. Encryption does not prevent packet capture, but it materially reduces the value of the captured traffic.

Safeguard 4.6 directly concerns securely managing software and configuration-management platforms, including tools integrated with CI/CD systems. Restricting administrative access and managing deployment configuration through controlled, versioned mechanisms reduces unauthorized use of these platforms for execution and lateral movement.

Disabling obsolete management protocols and securely configuring required administrative services reduces the number of remotely reachable and vulnerable services. The safeguard does not patch vulnerabilities, but it directly removes insecure management paths that could be exploited.

Disabling unauthenticated Docker and Kubernetes API access and requiring secured channels such as SSH or TLS directly reduces unauthorized access to container-management interfaces. This closely matches the safeguard's requirement to access administrative interfaces through secure protocols.

Authenticated encryption through SSH, HTTPS, and TLS limits an adversary's ability to read or alter administrative traffic even after obtaining a network interception position. Certificate and SSH host-key validation remain essential to the effectiveness of the mitigation.

SSH and HTTPS provide confidentiality and integrity protection for management commands and configuration data in transit. This makes undetected modification of administrative traffic substantially more difficult.

Secure management protocols, authenticated access, and controlled configuration repositories directly reduce unauthorized collection of device and infrastructure configuration. Version-controlled Infrastructure-as-Code can also reduce the need to retrieve configurations through insecure management interfaces.

Migrating from insecure SNMP versions to SNMPv3 with authentication and privacy protection directly reduces unauthorized MIB collection. Restricting management access to approved systems further limits successful enumeration.

Using SSH, HTTPS, SNMPv3, and securely managed configuration repositories reduces exposure of network-device configurations and embedded credentials. Insecure services such as Telnet, HTTP, TFTP, or legacy management protocols create substantially greater collection risk.

Restricting Docker and Kubernetes administration to authenticated TLS, SSH, local sockets, or other secured management channels directly reduces unauthorized remote container commands. Version-controlled manifests and Infrastructure-as-Code also reduce unreviewed administrative changes.

HTTPS and other authenticated encrypted protocols make it more difficult for an adversary positioned in the network path to inject malicious content into management downloads or administrative sessions. This is a direct benefit of prohibiting plaintext HTTP management.

This safeguard explicitly prohibits fallback to insecure protocols such as HTTP and Telnet. Enforcing HTTPS, modern TLS, SSH, and policies such as HSTS directly limits attempts to downgrade management communications to weaker or plaintext alternatives.

Securely managing which remote services are permitted and requiring authenticated encrypted protocols reduces exposed administrative paths. The safeguard does not independently prevent adversaries from using valid credentials through an approved service.

Secure RDP configuration, gateways, TLS, and restricted administrative access reduce interception and direct exposure. RDP remains usable by an adversary who possesses authorized credentials or an active session.

Secure management can disable unnecessary administrative shares and require modern SMB signing or encryption where remote administration is needed. It does not fully prevent abuse of an authorized SMB management path.

Securely managing DCOM availability and restricting it to approved administrative workflows reduces remote abuse. DCOM does not have a simple SSH or HTTPS replacement, so effectiveness depends on disabling or tightly constraining it.

SSH protects administrative credentials and commands from plaintext interception and should replace Telnet. It does not prevent an adversary with valid credentials or an unauthorized SSH key from using the service.

Secure management can prohibit unencrypted VNC deployments or require encrypted tunnels and approved administrative tooling. The relationship is partial because some VNC implementations or tunnels remain accessible with valid credentials.

Requiring WinRM over HTTPS rather than unencrypted HTTP protects management credentials and commands in transit. Authorized-account abuse remains possible through the secured channel.

Securing cloud administrative consoles and APIs, using controlled automation, and managing resources through version-controlled Infrastructure-as-Code reduces ad hoc and insecure administration. It does not prevent malicious activity performed through a compromised authorized cloud account.

Approved and securely configured cloud-native VM connection methods reduce exposure from direct or insecure management services. Cloud control-plane access may bypass the guest operating system's network controls, so identity and cloud policy protections are also required.

Requiring SSH rather than Telnet protects command-line interface credentials and commands in transit and reduces interception or manipulation. Once an adversary has authorized administrative access, the encrypted CLI still permits malicious commands.

Requiring secure protocols and centrally managed administrative access reduces risk from externally accessible management services. Additional protections such as multi-factor authentication, gateways, and network restrictions remain necessary.

Administrative web interfaces should use HTTPS and should not be exposed through unnecessary plaintext or legacy services. HTTPS does not remediate an application vulnerability, so this mitigation primarily reduces unnecessary exposure and traffic manipulation.

Version-controlled SSH configuration and managed deployment of approved keys can prevent or identify unauthorized additions to authorized_keys. File permissions and privileged access controls are still needed to prevent local modification.

Infrastructure-as-Code repositories may reveal infrastructure topology, administrative endpoints, configuration, and embedded credentials. Secure repository administration and keeping secrets outside version control reduce the value and accessibility of these repositories.

Secure software management can limit administration to approved and securely configured remote-access products. The safeguard does not prevent an approved tool or account from being abused by an adversary.

Securely managing development tools can disable unnecessary tunneling functions and restrict approved remote-development services. Legitimate HTTPS or SSH development channels may still be abused.

Organizations can centrally approve, configure, and secure remote-support software while removing unauthorized products. An adversary may still misuse an approved product or compromised support account.

Infrastructure code, configuration files, deployment manifests, and automation scripts frequently create a risk of embedded passwords or tokens. Secure management should keep credentials out of source-controlled configuration and use protected secret stores or runtime injection.

SSH administration depends on protecting private keys and preventing them from being embedded in repositories or widely distributed. Managed key storage, permissions, and rotation reduce the likelihood that stolen keys can be used for administration.

Requiring container deployments through approved, authenticated orchestration interfaces and version-controlled manifests reduces unauthorized container creation. A compromised orchestrator account or approved pipeline may still deploy a malicious container.

Securing container-management APIs and restricting builds to controlled Infrastructure-as-Code or pipeline processes reduces unauthorized image construction on managed hosts. It does not prevent misuse by a compromised authorized build identity.

Version-controlled Infrastructure-as-Code and controlled cloud-administration interfaces reduce unreviewed interactive commands and restrict administration to approved mechanisms. The technique remains possible through a compromised privileged cloud account.

Version-controlled infrastructure and reviewed changes can prevent untrusted code or malicious Infrastructure-as-Code modifications from automatically reaching privileged deployment pipelines. Additional CI/CD isolation, branch protection, and secrets controls are required.

SSH host-key validation, HTTPS certificate validation, SMB signing, and encrypted management channels reduce the ability to capture or relay administrative authentication. Disabling LLMNR, NBT-NS, and unnecessary SMB remains an important complementary control.

An adversary may still redirect management traffic through ARP poisoning, but properly validated SSH and HTTPS sessions protect the confidentiality and integrity of that traffic. The safeguard does not prevent the underlying ARP manipulation.

Secure protocols reduce credential theft and command manipulation even if DHCP spoofing redirects traffic. DHCP snooping and network-level controls are still required to prevent the spoofing behavior itself.

Version-controlled configuration and authenticated encrypted management channels reduce unauthorized or undetected changes to enterprise configuration. The safeguard does not protect every type of business or application data.

Version-controlled Infrastructure-as-Code provides history, review, comparison, and restoration for managed configurations, reducing the persistence of unauthorized configuration changes. This applies only where the affected configuration is actually managed as code.

Securely configuring remote services can reduce unnecessary sessions and restrict features that facilitate hijacking. Encryption does not prevent an adversary already executing on a system from taking control of an existing session.

Disabling SSH agent forwarding and tightly managing SSH configuration reduces some hijacking paths. It does not prevent local theft or reuse of an established SSH socket or session.

Secure RDP gateways and restricted administration reduce access to RDP sessions. They do not prevent a locally privileged adversary from taking control of an existing session.

Secure SSH configuration can disable unnecessary forwarding and proxy features, reducing the ability to turn a managed asset into a pivot.

Securely configuring SSH, VPN, and administrative tools can disable unnecessary port forwarding and tunneling functions. The safeguard does not prevent tunneling through an otherwise approved secure protocol when that capability is operationally required.

Version-controlled domain or tenant configuration can make unauthorized policy changes visible and allow restoration to approved state. Many identity policies are still managed directly through consoles or APIs rather than Infrastructure-as-Code.

Managing Group Policy definitions through controlled configuration processes can identify or reverse unauthorized changes. Version control does not prevent direct modification by an account that retains write access to the policy.

Version-controlled Infrastructure-as-Code can define expected compute infrastructure and identify or reverse out-of-band changes. An adversary with sufficient cloud permissions may still modify resources directly.

Infrastructure-as-Code provides an approved baseline for quotas, instance settings, and compute configurations, allowing unauthorized drift to be identified or corrected.

A default-deny endpoint firewall directly restricts unsolicited remote-service connections and permits access only through explicitly approved services, ports, and management paths.

Restricting TCP 3389 to approved management sources directly prevents unauthorized RDP connections and reduces RDP-based lateral movement.

Blocking or tightly restricting TCP 445 and 139 directly impedes access to administrative shares and other SMB-based lateral movement paths.

A default-deny firewall can block inbound SSH or restrict TCP 22 to approved management systems, directly limiting remote access to SSH-enabled end-user devices.

VNC requires an accessible listener, commonly on TCP 5900 and related ports. Blocking those ports unless specifically authorized directly prevents unauthorized VNC access.

Restricting TCP 5985 and 5986 to approved systems directly limits adversary use of WinRM for remote administration and lateral movement.

Exploiting a remote service requires network reachability to that service. Default-deny endpoint rules remove unnecessary exposure and can restrict necessary services to trusted source systems.

Default-deny rules directly block arbitrary and unexpected ports unless they have been explicitly approved, limiting adversary communications over non-standard ports.

A firewall can restrict DCOM by controlling RPC endpoint mapper traffic and dynamic RPC ports. The relationship is direct, but implementation is more complex than filtering a single fixed port.

Restrictive outbound rules can prevent an endpoint from using unapproved protocols and ports for data exfiltration. The technique remains possible over protocols the organization must allow.

The firewall can block unapproved encrypted protocols, ports, or destinations used for exfiltration. It generally cannot identify malicious content inside an allowed encrypted connection.

Default-deny egress controls can prevent asymmetric encrypted sessions using unauthorized ports or services. Connections through an approved service may still succeed.

Unapproved outbound services and ports used for cleartext exfiltration can be directly blocked. Effectiveness decreases when the adversary uses an operationally required protocol.

Endpoint firewalls can restrict which application protocols and services may communicate externally. The mapping is partial because common application protocols may need to remain available.

FTP, SFTP, FTPS, and related file-transfer traffic can be denied or limited to approved destinations. File transfer over a generally permitted web protocol may remain possible.

SMTP, IMAP, and POP traffic can be restricted to authorized mail infrastructure, reducing adversary use of attacker-controlled mail services for command and control.

The firewall can force devices to use approved DNS resolvers and block direct DNS traffic to external systems. It does not by itself identify malicious data embedded in DNS traffic sent through an approved resolver.

Default-deny policies can block MQTT and other publish/subscribe services unless they are explicitly required. An approved publish/subscribe service could still be misused.

Restricting inbound listeners and lateral outbound connections makes it more difficult for a compromised endpoint to act as an unauthorized proxy for other systems.

A host firewall can deny unnecessary ICMP, GRE, raw IP, and other non-application protocols that adversaries may use for command and control.

Default-deny egress policies can prevent compromised endpoints from retrieving payloads from unapproved systems, ports, or protocols. Transfers from an approved destination remain possible.

Blocking outbound SMB, NetBIOS, and unnecessary WebDAV traffic prevents many attempts to coerce an endpoint into authenticating to an attacker-controlled system. WebDAV over permitted web ports may require application-aware filtering.

Stateful default-deny firewalls can block unsolicited signaling traffic and the resulting unauthorized connections for some implementations of this technique. Effectiveness depends on the signaling mechanism.

A managed firewall can prevent unauthorized knock sequences from opening services and can preserve the default-deny state. The relationship becomes weaker if malware has already obtained privileges to modify firewall rules.

Application-aware or destination-restricted firewall policies can block communications to unauthorized remote-access services. Tools communicating through generally permitted HTTPS may bypass basic port filtering.

The firewall can block application traffic, service endpoints, or dedicated ports associated with unauthorized remote-desktop products. Effectiveness depends on whether the product uses an otherwise permitted web connection.

Blocking unnecessary local-link, legacy name-resolution, and file-sharing protocols reduces the network conditions available for several adversary-in-the-middle behaviors. Other sub-techniques require switch or network-infrastructure protections.

Blocking LLMNR, NBT-NS, mDNS, NetBIOS, and unnecessary SMB traffic reduces poisoning and relay opportunities involving end-user devices. Disabling the protocols and enforcing SMB signing remain stronger complementary mitigations.

Restricting SMB, WinRM, SSH, VNC, and other peer-to-peer services impedes common channels used to transfer adversary tools between endpoints.

Limiting approved ports, protocols, services, and destinations can prevent many unauthorized tunnels. Tunnels encapsulated within an approved HTTPS, DNS, or SSH connection may still succeed.

Destination-aware or application-aware firewall restrictions can disrupt web-based command and control, but basic port filtering cannot distinguish malicious traffic from legitimate browsing.

Blocking known proxy infrastructure and unauthorized listeners can disrupt some proxy usage. Proxies operating through approved web services or destinations may remain accessible.

Firewall egress restrictions can block known or unauthorized external proxy destinations. External proxies commonly operate over permitted HTTP or HTTPS, limiting basic port-filtering effectiveness.

Destination filtering may prevent access to identified anonymity or command-and-control infrastructure.

Host firewall map help when an external remote service terminates directly on the end-user device. Many VPN, VDI, and access-gateway implementations terminate on centralized infrastructure outside the endpoint firewall's control.

Process-aware firewall rules may restrict BITS to approved destinations. The firewall does not prevent local creation or execution of a BITS job and may not distinguish BITS traffic over allowed web ports.

Stateful firewall may block the triggering traffic or resulting connection. Socket filters may observe raw traffic or reuse an already permitted protocol, limiting the safeguard's effectiveness.

Process-aware host firewall can prevent verclsid.exe from making outbound connections which is part of the outcomes of this technique. But it does not prevent the local signed-binary proxy-execution behavior that defines the technique.

Firewall policy can block unapproved IDE-tunneling services or destinations. Developer endpoints may legitimately require the same HTTPS or SSH channels, reducing the usefulness of simple port filtering.

Host firewall can discard traffic targeting blocked ports, protocols, or identified hostile sources, reducing malicious traffic processed by the endpoint.

Dropping unwanted inbound traffic through dynamic host based firewalls may reduce some operating-system resource floods.

The firewall can block floods against services that do not need to be exposed or restrict permitted sources.

Application-aware or source-restricted firewall rules may reduce hostile requests reaching an exposed endpoint application. Basic port filtering cannot distinguish an exhaustion attack from legitimate requests to an explicitly allowed application service.

Destination-aware egress rules may block connections to unauthorized cloud environments. Basic port filtering cannot determine which cloud account owns an HTTPS destination, and some transfers occur entirely within the cloud.

Blocking unnecessary remote-service connectivity reduces the opportunity to reach a session that could be hijacked.

Restricting SSH reachability reduces remote paths to SSH sessions.

Restricting RDP to approved sources limits remote access to sessions.

Destination-aware or application-aware endpoint firewall can restrict access to unauthorized cloud consoles, APIs, and command-line management endpoints.

Endpoint egress rules can prevent a compromised end-user device from reaching cloud-native VM connection services, APIs, or management endpoints. Cloud-native console access targets the cloud control plane and may not traverse the destination VM's host firewall.

An application-aware or destination-restricted endpoint firewall can block unauthorized web, cloud, file-sharing, or social-media services used for command and control.

A firewall that restricts outbound applications or destinations can prevent malware from contacting unauthorized web services used to retrieve secondary command-and-control addresses.

Blocking unauthorized web-service destinations or preventing unapproved processes from accessing the network can disrupt bidirectional command-and-control communications.

Endpoint firewall policy can prevent malware from sending data or retrieving instructions through unauthorized web services. One-way traffic to an approved and commonly used service may be difficult to distinguish from legitimate activity through basic port filtering.

A host firewall can discard traffic targeting blocked ports, protocols, or identified hostile sources, reducing the amount of malicious traffic processed by the endpoint.

A host firewall rules can block unnecessary protocols, targeted ports, or known attacking sources and may reduce endpoint resource consumption during smaller floods. High-volume floods normally require upstream filtering because traffic may saturate the connection before reaching the device.

A host firewall can drop unsolicited reflected traffic and deny unnecessary UDP protocols used in amplification attacks. It cannot recover bandwidth already consumed by the reflected traffic, and spoofed or distributed sources reduce source-based filtering effectiveness.

Blocking inbound SMB (TCP 445/139) is a primary server firewall function and directly reduces lateral movement via administrative shares.

Restricting TCP 3389 to authorized management hosts directly limits unauthorized RDP access to servers.

A default-deny host firewall directly restricts inbound remote service access to servers, reducing opportunities for remote administration and lateral movement.

DCOM relies on RPC communications that can be restricted through host firewall rules, limiting remote DCOM access to authorized systems. Dynamic RPC ports make the effectiveness dependent on careful firewall configuration.

A default-deny server firewall can directly restrict inbound SSH, normally TCP 22, to approved management systems. This reduces unauthorized remote administration and lateral movement against Linux, macOS, and other SSH-enabled servers.

A server firewall prevents unauthorized inbound VNC connections unless the relevant service and source systems are explicitly permitted.

Restricting WinRM ports, commonly TCP 5985 and 5986, to approved administrative systems directly limits unauthorized remote management of servers.

When outbound filtering is configured, a server firewall can block unauthorized protocols used to exfiltrate data. Effectiveness depends on whether egress rules are enforced rather than allowing unrestricted outbound traffic.

Outbound firewall restrictions can block unapproved encrypted non-C2 protocols or destinations used for exfiltration. The control is less effective when the traffic uses an explicitly permitted protocol and destination.

A managed egress policy can prevent servers from establishing unapproved asymmetric encrypted connections used to transfer data. This mitigation depends on restrictive outbound rules and destination controls.

A host firewall can block unauthorized outbound protocols and ports used for unencrypted data exfiltration. Exfiltration over an explicitly permitted service may remain possible.

Application-aware or restrictive outbound firewall rules can limit unauthorized HTTP, HTTPS, DNS, SMTP, and other application-layer communications used for command and control. A basic port-only policy provides limited protection when adversaries use permitted protocols.

Restricting outbound server connections can prevent malware from reaching unauthorized proxy infrastructure or accepting proxy traffic on unapproved ports. Proxy activity over approved channels may still succeed.

Host firewalls can restrict raw IP, ICMP, GRE, and other non-application-layer protocols used for command and control. The mitigation depends on denying protocols that the server does not explicitly require.

Restrictive outbound firewall rules can prevent a compromised server from downloading tools or payloads from unapproved external systems. The mapping is partial because transfers over approved destinations and protocols may still be possible.

A default-deny host firewall reduces the exposure of externally accessible remote services by permitting only explicitly authorized ports, protocols, and source systems.

A host firewall cannot remove vulnerabilities in a public-facing application, but it can ensure that only intended application ports are reachable and restrict access by source where operationally feasible. This reduces unnecessary exposure and possible exploitation paths.

Port knocking relies on specific traffic patterns that cause a firewall or related mechanism to expose a service port. Managed default-deny rules and monitoring of unauthorized firewall changes can restrict the trigger traffic and prevent unapproved ports from being opened.

Exploitation of a remote service requires network reachability to the vulnerable service. A default-deny server firewall reduces the number of reachable services and limits access to authorized source systems.

Host firewall rules can block inbound or outbound communications associated with unauthorized remote access software. The firewall does not prevent the software from being installed or executed when it communicates over an allowed channel.

Egress filtering can restrict server connections to unauthorized cloud services or accounts, making cloud-based data transfer more difficult. The mitigation depends on destination-aware outbound controls.

Blocking unnecessary LLMNR, NBT-NS, mDNS, NetBIOS, and SMB traffic can reduce name-resolution poisoning and relay opportunities involving servers. Disabling the protocols and enforcing SMB signing remain stronger primary mitigations.

A host firewall may restrict follow-on connections created through ARP poisoning, but it has limited ability to prevent manipulation of Layer 2 address resolution itself. This is therefore a weak and environment-dependent mitigation.

A host firewall may limit some follow-on communications after a malicious DHCP configuration is accepted, but it does not directly prevent DHCP spoofing. Network access controls and DHCP protections are the primary mitigations.

Lateral tool transfers often rely on SMB, WinRM, SSH, or other network services that are directly governed by server firewall rules. Restricting those services to approved systems impedes common transfer channels.

A default-deny firewall blocks communication over arbitrary or non-standard ports unless they are explicitly permitted, directly limiting adversary use of unexpected ports.

Restricting permitted ports, protocols, and destinations can impede protocol tunneling from compromised servers. Tunnels carried inside an explicitly allowed protocol may still bypass simple port-based filtering.

Blocking unnecessary SNMP traffic and restricting authorized SNMP sources reduces the ability to query management information from servers or server-hosted management services. The applicability depends on whether the server exposes SNMP.

Adversaries may disable or alter host firewall configurations to expose services or enable unrestricted network communication, directly undermining the safeguard. Implementing and actively managing the firewall establishes the required configuration and supports identifying or correcting unauthorized changes.

This sub-technique concerns changes to cloud firewall rules or security groups rather than a host-based firewall installed on a server. The relationship to Safeguard 4.4 is therefore indirect and primarily relevant where server firewall management also encompasses associated cloud firewall controls.

This sub-technique targets firewalls implemented on network infrastructure rather than host-based firewalls on servers. Its relationship to Safeguard 4.4 is weak and applies only where the server firewall management process also governs supporting network firewall policy.

This sub-technique explicitly covers disabling or modifying the Windows host firewall, including changing profiles or rules to expose services or permit command-and-control traffic. Implementing and managing the required firewall configuration helps identify, prevent, or reverse unauthorized changes.

Default accounts are defined as built-in or factory/provider-set accounts across systems, software, and devices. Managing, changing default passwords, disabling state accounts, or otherwise hardening them through additional mechanisms directly constrains an adversary's abuse of the valid account technique.

Default accounts are defined as built-in or factory/provider-set accounts across systems, software, and devices. Managing, changing default passwords, disabling state accounts, or otherwise hardening them through additional mechanisms directly constrains an adversary's abuse of the valid account technique.

Default accounts are defined as built-in or factory/provider-set accounts across systems, software, and devices. Managing, changing default passwords, disabling state accounts, or otherwise hardening them through additional mechanisms directly constrains an adversary's abuse of the valid account technique.

Default accounts are defined as built-in or factory/provider-set accounts across systems, software, and devices. Managing, changing default passwords, disabling state accounts, or otherwise hardening them through additional mechanisms directly constrains an adversary's abuse of the valid account technique.

Default accounts are defined as built-in or factory/provider-set accounts across systems, software, and devices. Managing, changing default passwords, disabling state accounts, or otherwise hardening them through additional mechanisms directly constrains an adversary's abuse of the valid account technique.

The safeguard forces a renewed authentication checkpoint after inactivity and therefore reduces any possibility of opportunistic use of a still-authenticated user on an open unlocked enterprise asset.

This technique may be mitigated depending on where ingress and egress is tightly controlled. For example, the use network signatures such as IP addresses or domain names to identify traffic for specific adversary malware can be used to mitigate activity at the network level.

ATT&CK mentions that the mitigation of some variants of this technique could be achieved through the use of stateful firewalls, depending upon how it is implemented.

ATT&CK mentions to limit access to the Instance Metadata API using a host-based firewall such as iptables. A properly configured Web Application Firewall (WAF) may help prevent external adversaries from exploiting Server-side Request Forgery (SSRF) attacks that allow access to the Cloud Instance Metadata API.

Consider modifying host firewall rules to prevent egress traffic from verclsid.exe.

This technique may be lessened or mitigated though the use of firewall policy that constrains relay and redirect paths.

Modify network and/or host firewall rules, as well as other network controls, to only allow legitimate BITS traffic.

ATT&CK mentions that the mitigation of some variants of this technique could be achieved through the use of stateful firewalls, depending upon how it is implemented.

Adversaries use web protocols to blend with normal traffic. A server firewall can partially restrict which destinations, ports, and web services a server may contact, though it will not stop all HTTP/S abuse.

Adversaries leverage RDP if it is reachable. Firewall rules are among the most direct ways to prevent unauthorized RDP reachability to servers.