M1035: Limit Access to Resource Over Network
Restrict access to network resources, such as file shares, remote systems, and services, to only those users, accounts, or systems with a legitimate business requirement. This can include employing technologies like network concentrators, RDP gateways, and zero-trust network access (ZTNA) models, alongside hardening services and protocols. This mitigation can be implemented through the following measures:
Audit and Restrict Access:
- Regularly audit permissions for file shares, network services, and remote access tools. - Remove unnecessary access and enforce least privilege principles for users and services. - Use Active Directory and IAM tools to restrict access based on roles and attributes.
Deploy Secure Remote Access Solutions:
- Use RDP gateways, VPN concentrators, and ZTNA solutions to aggregate and secure remote access connections. - Configure access controls to restrict connections based on time, device, and user identity. - Enforce MFA for all remote access mechanisms.
Disable Unnecessary Services:
- Identify running services using tools like netstat (Windows/Linux) or Nmap. - Disable unused services, such as Telnet, FTP, and legacy SMB, to reduce the attack surface. - Use firewall rules to block traffic on unused ports and protocols.
Network Segmentation and Isolation:
- Use VLANs, firewalls, or micro-segmentation to isolate critical network resources from general access. - Restrict communication between subnets to prevent lateral movement.
Monitor and Log Access:
- Monitor access attempts to file shares, RDP, and remote network resources using SIEM tools. - Enable auditing and logging for successful and failed attempts to access restricted resources.
*Tools for Implementation*
File Share Management:
- Microsoft Active Directory Group Policies - Samba (Linux/Unix file share management) - AccessEnum (Windows access auditing tool)
Secure Remote Access:
- Microsoft Remote Desktop Gateway - Apache Guacamole (open-source RDP/VNC gateway) - Zero Trust solutions: Tailscale, Cloudflare Zero Trust
Service and Protocol Hardening:
- Nmap or Nessus for network service discovery - Windows Group Policy Editor for disabling SMBv1, Telnet, and legacy protocols - iptables or firewalld (Linux) for blocking unnecessary traffic
Network Segmentation:
- pfSense for open-source network isolation
Security context for executives and security teams
Limiting access to network resources is a foundational control for reducing how far an intruder with valid or stolen access can move. The business value is not just fewer open ports; it is clearer proof that file shares, remote access paths, services, cloud/container APIs, and critical network segments are reachable only by identities, devices, or systems with a legitimate need.
Executive priority
Treat M1035 as a resilience and auditability priority: it supports least privilege, reduces exposure of remote services and public-facing resources, and helps contain lateral movement paths such as Remote Services, RDP, SMB/admin shares, external remote services, and container administration interfaces. Leaders should ask whether access reviews, segmentation, MFA for remote access, and logging are evidenced across business-critical systems, not only documented as policy.
Technical view
For SOC, IR, identity, cloud, and network teams, validation should focus on whether restricted resources are actually restricted and monitored. Relationship context ties this mitigation to lateral movement via Remote Services, RDP, SMB/Windows Admin Shares, External Remote Services, public-facing applications, container APIs, cloud instance metadata access, adversary-in-the-middle conditions, and network-device boot paths such as TFTP Boot. Because ATT&CK provides no standalone detection text for this mitigation, coverage should be assessed through control validation, access logs, firewall/segmentation evidence, remote access authentication records, and service exposure reviews.
Likely telemetry
- Successful and failed access attempts to file shares, RDP, remote services, VPN/RDP gateway/ZTNA entry points, and other restricted network resources
- Directory/IAM group membership, role, attribute, and permission change records for users, service accounts, and systems
- Firewall, VLAN, micro-segmentation, and subnet communication logs showing allowed and denied connections
- Service discovery and exposure evidence for listening ports, legacy services, and unused protocols such as Telnet, FTP, or legacy SMB where present
- Remote access authentication events, including MFA enforcement outcomes where enabled
Detection direction
- Do not treat this mitigation as covered unless logs prove both successful and failed access attempts are collected for restricted resources.
- Validate that alerts distinguish expected administrative access from unusual access paths, new source subnets, unexpected identities, or access outside approved time/device conditions.
- Tune for relationship-driven risk: RDP, SMB/admin shares, VPN or other external remote services, public-facing services, container APIs, and cloud metadata access require different telemetry sources.
- Check blind spots created by unmanaged services, legacy protocols, incomplete file-share auditing, missing container or IaaS logs, and segmentation rules that allow broad east-west access.
- For false-positive control, maintain an approved inventory of remote access gateways, administrative systems, privileged groups, service accounts, and business-approved shares.
Mitigation priorities
- Start with an inventory of file shares, remote access tools, network services, public-facing services, container administration endpoints, and critical network resources.
- Audit permissions and remove unnecessary access; enforce least privilege for users, service accounts, systems, roles, and attributes through directory and IAM controls.
- Aggregate and secure remote access through controlled gateways or ZTNA-style access models, with MFA for remote access mechanisms where applicable.
- Disable unused services and legacy protocols, and block unused ports and protocols with host or network firewall rules.
- Segment critical resources using VLANs, firewalls, or micro-segmentation, and restrict communication between subnets to limit lateral movement.
Additional notes and limits
This is a broad mitigation rather than a technique-specific detection object. Its value is highest when mapped to concrete access paths: RDP, SMB, external remote services, public-facing applications, cloud metadata, container APIs, network device services, and restricted file shares. Glexia would assess it through evidence of access reviews, segmentation policy, remote access control, MFA enforcement, service hardening, and monitoring readiness.
The ATT&CK object does not specify platforms or official detection guidance for M1035. Platform relevance comes from the listed mitigated techniques and includes Windows, Linux, macOS, IaaS, Containers, Network Devices, ESXi, and SaaS only where those relationships apply. Local architecture, inventories, identities, and log availability are required to determine actual coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Limit Access to Resource Over Network
Restrict access to network resources, such as file shares, remote systems, and services, to only those users, accounts, or systems with a legitimate business requirement. This can include employing technologies like network concentrators, RDP gateways, and zero-trust network access (ZTNA) models, alongside hardening services and protocols. This mitigation can be implemented through the following measures:
Audit and Restrict Access:
- Regularly audit permissions for file shares, network services, and remote access tools. - Remove unnecessary access and enforce least privilege principles for users and services. - Use Active Directory and IAM tools to restrict access based on roles and attributes.
Deploy Secure Remote Access Solutions:
- Use RDP gateways, VPN concentrators, and ZTNA solutions to aggregate and secure remote access connections. - Configure access controls to restrict connections based on time, device, and user identity. - Enforce MFA for all remote access mechanisms.
Disable Unnecessary Services:
- Identify running services using tools like netstat (Windows/Linux) or Nmap. - Disable unused services, such as Telnet, FTP, and legacy SMB, to reduce the attack surface. - Use firewall rules to block traffic on unused ports and protocols.
Network Segmentation and Isolation:
- Use VLANs, firewalls, or micro-segmentation to isolate critical network resources from general access. - Restrict communication between subnets to prevent lateral movement.
Monitor and Log Access:
- Monitor access attempts to file shares, RDP, and remote network resources using SIEM tools. - Enable auditing and logging for successful and failed attempts to access restricted resources.
*Tools for Implementation*
File Share Management:
- Microsoft Active Directory Group Policies - Samba (Linux/Unix file share management) - AccessEnum (Windows access auditing tool)
Secure Remote Access:
- Microsoft Remote Desktop Gateway - Apache Guacamole (open-source RDP/VNC gateway) - Zero Trust solutions: Tailscale, Cloudflare Zero Trust
Service and Protocol Hardening:
- Nmap or Nessus for network service discovery - Windows Group Policy Editor for disabling SMBv1, Telnet, and legacy protocols - iptables or firewalld (Linux) for blocking unnecessary traffic
Network Segmentation:
- pfSense for open-source network isolation
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 | T1542 | Pre-OS Boot | Prevent access to file shares, remote access to systems, unnecessary services. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc. |
| Enterprise | T1557 | Adversary-in-the-Middle | Limit access to network infrastructure and resources that can be used to reshape traffic or otherwise produce AiTM conditions. |
| Enterprise | T1563.002 | RDP HijackingSub-technique | Use remote desktop gateways. |
| Enterprise | T1552.005 | Cloud Instance Metadata APISub-technique | Limit access to the Instance Metadata API using a host-based firewall such as iptables. |
| Enterprise | T1612 | Build Image on Host | Limit communications with the container service to local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API on port 2375. Instead, communicate with the Docker API over TLS on port 2376.[1] |
| Enterprise | T1021.001 | Remote Desktop ProtocolSub-technique | Use remote desktop gateways. |
| Enterprise | T1021 | Remote Services | Prevent unnecessary remote access to file shares, hypervisors, sensitive systems, etc. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc.[2] |
| Enterprise | T1200 | Hardware Additions | Establish network access control policies, such as using device certificates and the 802.1x standard. [3] Restrict use of DHCP to registered devices to prevent unregistered devices from communicating with trusted systems. |
| Enterprise | T1542.005 | TFTP BootSub-technique | Restrict use of protocols without encryption or authentication mechanisms. Limit access to administrative and management interfaces from untrusted network sources. |
| Enterprise | T1552.007 | Container APISub-technique | Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server.[1][4] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[5] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[6] |
| Enterprise | T1610 | Deploy Container | Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API, Kubernetes API Server, and container orchestration web applications.[1][4] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[5] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[6] |
| Enterprise | T1133 | External Remote Services | Limit access to remote services through centrally managed concentrators such as VPNs and other managed remote access systems. |
| Enterprise | T1552 | Unsecured Credentials | Limit network access to sensitive services, such as the Instance Metadata API. |
| Enterprise | T1021.002 | SMB/Windows Admin SharesSub-technique | Consider disabling Windows administrative shares. |
| Enterprise | T1613 | Container and Resource Discovery | Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server.[1][4] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[5] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[6] |
| Enterprise | T1190 | Exploit Public-Facing Application | Ensure that all publicly exposed services are actually intended to be so, and restrict access to any that should only be available internally. |
| Enterprise | T1557.002 | ARP Cache PoisoningSub-technique | Create static ARP entries for networked devices. Implementing static ARP entries may be infeasible for large networks. |
| Enterprise | T1546.008 | Accessibility FeaturesSub-technique | If possible, use a Remote Desktop Gateway to manage connections and security configuration of RDP within a network.[7] |
| Enterprise | T1609 | Container Administration Command | Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server.[1][4] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[5] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[6] |
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 | 4e83218b110c… |
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]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [2]Sygnia ESXi Ransomware 2024
Nital Ruzin and Omer Kidron. (2024, May 15). ESXi Ransomware Attacks: Evolution, Impact, and Defense Strategy. Retrieved April 4, 2025.
Open source URL - [3]Wikipedia 802.1x
Wikipedia. (2018, March 30). IEEE 802.1X. Retrieved April 11, 2018.
Open source URL - [4]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [5]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [6]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [7]TechNet RDP Gateway
Microsoft. (n.d.). Overview of Remote Desktop Gateway. Retrieved June 6, 2016.
Open source URL - [8]mitre-attackM1035Open source URL
- [9]mitre-attackM1035Open source URL
- [10]mitre-attackM1035Open source URL
- [11]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [12]Sygnia ESXi Ransomware 2024
Nital Ruzin and Omer Kidron. (2024, May 15). ESXi Ransomware Attacks: Evolution, Impact, and Defense Strategy. Retrieved April 4, 2025.
Open source URL - [13]Wikipedia 802.1x
Wikipedia. (2018, March 30). IEEE 802.1X. Retrieved April 11, 2018.
Open source URL - [14]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [15]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [16]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [17]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [18]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [19]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [20]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [21]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [22]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [23]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [24]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [25]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [26]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [27]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [28]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [29]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [30]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [31]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [32]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [33]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [34]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [35]TechNet RDP Gateway
Microsoft. (n.d.). Overview of Remote Desktop Gateway. Retrieved June 6, 2016.
Open source URL - [36]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [37]Docker Daemon Socket Protect
Docker. (n.d.). Protect the Docker Daemon Socket. Retrieved March 29, 2021.
Open source URL - [38]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [39]Kubernetes API Control Access
The Kubernetes Authors. (n.d.). Controlling Access to The Kubernetes API. Retrieved March 29, 2021.
Open source URL - [40]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [41]Kubernetes Cloud Native Security
Kubernetes. (n.d.). Overview of Cloud Native Security. Retrieved March 8, 2023.
Open source URL - [42]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open source URL - [43]Microsoft AKS Azure AD 2023
Microsoft. (2023, February 27). AKS-managed Azure Active Directory integration. Retrieved March 8, 2023.
Open 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.