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
M1035: Limit Access to Resource Over Network describes 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 t...
Executive priority
M1035: Limit Access to Resource Over Network is an official MITRE ATT&CK mitigation. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.
Technical view
Security teams should validate M1035: Limit Access to Resource Over Network by reviewing the official ATT&CK relationships, mapped tactics (the mapped ATT&CK tactic context), supported platforms (the platforms named in the official object), and available local telemetry before making detection or mitigation decisions.
Likely telemetry
- Official ATT&CK relationships and object metadata
Detection direction
- Validate whether M1035: Limit Access to Resource Over Network appears in your detection coverage and tabletop scenarios.
- Use the object to align executive risk language with SOC, incident response, and detection engineering work.
- Do not treat ATT&CK relationship context as attribution without corroborating evidence.
Mitigation priorities
- Map the object to existing controls and identify missing telemetry or response ownership.
- Prioritize mitigations that reduce exposure on the listed platforms and tactics.
- Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits
Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.
This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.
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.CitationDocker Daemon Socket Protect |
| 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.CitationSygnia ESXi Ransomware 2024 |
| Enterprise | T1200 | Hardware Additions | Establish network access control policies, such as using device certificates and the 802.1x standard. CitationWikipedia 802.1x 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.CitationDocker Daemon Socket ProtectCitationKubernetes API Control Access 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.CitationKubernetes Cloud Native Security Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.CitationMicrosoft AKS Azure AD 2023 |
| 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.CitationDocker Daemon Socket ProtectCitationKubernetes API Control Access 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.CitationKubernetes Cloud Native Security Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.CitationMicrosoft AKS Azure AD 2023 |
| 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.CitationTechNet RDP Gateway |
| 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.CitationDocker Daemon Socket ProtectCitationKubernetes API Control Access 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.CitationKubernetes Cloud Native Security Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.CitationMicrosoft AKS Azure AD 2023 |
| 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.CitationDocker Daemon Socket ProtectCitationKubernetes API Control Access 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.CitationKubernetes Cloud Native Security Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.CitationMicrosoft AKS Azure AD 2023 |
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(2)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.2 | 1.1 | Current bundle | 4e83218b110c… | ||
| 19.1 | 1.1 | Older 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]mitre-attackM1035Open 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.