When attackers can use RPC to create services without SMB, blocking file-transfer paths alone is no longer enough. They may still establish execution, start a remote service, and move laterally through management interfaces that defenders overlook. This creates a blind spot in environments that equate port 445 blocking with safety and do not monitor port 135 and service-control activity closely.
Why RPC service creation still works when SMB is blocked
RPC-based service creation matters because the attacker does not need file-copy access over SMB to get code running. If they can reach the service-control path, they can create or start a service remotely, then use that service as the execution point for lateral movement. The security question is therefore about management-plane exposure, not just file-transfer exposure.
That is why environments that only treat TCP 445 as the indicator of lateral-movement risk are incomplete. RPC over TCP 135, plus the related service-control interfaces, can preserve remote execution capability even when SMB is unavailable. For teams studying real-world abuse paths, the broader attack patterns documented in The 52 NHI breaches Report are useful because lateral movement often follows the same trust and privilege failure, even when the transport differs.
What defenders miss when they equate port 445 with safety
The key blind spot is assuming that blocking one protocol blocks the action. Service creation is a management operation, so the attacker is abusing control channels rather than conventional file delivery. If defenders are not watching service-control events, remote procedure activity, or host management logs, they may miss the moment an endpoint becomes an execution foothold.
That oversight is especially dangerous when the network design allows administrative reachability but the monitoring model only keys on obvious payload transfer. The practical consequence is that an environment can look “closed” from a file-sharing perspective while remaining open to remote service manipulation. If you are mapping this to broader hardening guidance, CISA cyber threat advisories are a useful reminder that adversaries commonly pivot through legitimate administrative interfaces after initial access.
In identity terms, the enabling condition is not SMB itself but the privilege to invoke service-management operations on the target. That makes the access path more important than the transport protocol. The most relevant control objective is to reduce who can administer services, and to make service creation visible when it does occur. For a control-model lens, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the clearest reference point for access control, audit, and configuration discipline around these actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1569.002 — Service Execution: System Services | Covers remote service creation and execution via service-control interfaces. |
| T1021 — Remote Services | RPC-based lateral movement uses remote administrative services rather than SMB file transfer. | |
| Recommendation — Map service-creation activity to T1569.002 and alert on remote service install/start events. Monitor remote administration channels and constrain which hosts can use them. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Detects service-control abuse and management-plane activity that SMB-only monitoring misses. |
| PR.AC — Access Control | Remote service creation is an access-control problem, not only a transport problem. | |
| Recommendation — Extend monitoring to RPC and service-control logs so remote execution is visible. Limit who can administer services and validate those permissions continuously. | ||
| CIS Controls v8 | CIS 6 — Access Control Management | Service creation depends on administrative access and privilege boundaries. |
| CIS 8 — Audit Log Management | Service creation and remote administration need auditable telemetry for detection. | |
| Recommendation — Restrict service-management rights to approved admins and review them routinely. Collect and review service-creation and start events from endpoints and management tooling. | ||
Practitioner Guidance
What to prioritize: Treat RPC-based service creation as a remote-execution path, not a networking oddity. The first question is whether the target can be reached on the service-control plane and whether those actions are logged with enough detail to attribute who created, started, or modified the service.
What to verify: Confirm that your detection logic covers service creation, service start, and remote administration activity, not just SMB use. The common mistake is to build a rule set around blocked file shares and assume lateral movement has been materially reduced when the remote management surface is still available.
Practitioner takeaway: If an attacker can touch the service-control interface, SMB blocking only narrows one route, it does not remove the execution path. The operational decision is to monitor the management plane with the same seriousness as the data plane.
Related resources from NHI Mgmt Group
- What happens when attackers use compromised credentials to target municipal databases without strong segmentation or monitoring?
- What happens when security teams investigate cloud threats without understanding how attackers use compromised identities?
- What happens when attackers use AWS Systems Manager without tight access controls?
- What happens when attackers use stolen admin credentials against on-prem servers without MFA?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
