How do attackers use calling micro-services directly?

Why direct micro-service calls work as an attack path

Attackers use direct service calls to step around the public-facing layer and interact with internal components that were never meant to be independently trusted from the outside. The technique matters because the service mesh, API gateway, or front end may enforce policy, but the micro-service itself may still accept requests if it only assumes the caller is “internal.”

That breaks the security model whenever trust is tied to network location, shared infrastructure, or a supposedly safe internal address range. It also exposes design gaps where teams secure the entrance to the application but not the east-west paths between services. When this happens, the attacker no longer needs to defeat the full user journey, only the weakest internal endpoint.

For teams mapping the problem to API abuse, the same pattern often appears in broken object and function-level authorisation, plus inventory blind spots around shadow or zombie services. The API Security Guide helps teams reason about those internal endpoints as part of the attack surface, not as hidden implementation detail. API Security Guide

What attackers look for inside the service-to-service layer

Direct micro-service abuse usually starts with discovery. Attackers enumerate endpoints, probe for undocumented routes, look for verbose error messages, and test whether internal services accept requests without a valid identity context. They also look for service-to-service trust that is too broad, such as one workload being able to call every other workload in the environment.

The most useful indicators of weakness are missing mutual authentication, weak token validation, shared secrets reused across services, and authorisation that happens only once at the edge. If a service trusts caller headers, source IPs, or upstream claims without independently validating them, a direct request can often impersonate a legitimate internal caller.

Attackers also target service accounts and machine credentials that can be replayed across environments or reused in multiple integrations. The Service Account Security Guide is useful here because it focuses on the lifecycle and governance issues that let internal credentials become the entry point for direct service abuse. Service Account Security Guide

How defenders reduce the value of direct calls

The right defense is to make each service prove who it is and what it is allowed to do, not just assume a request is safe because it came from inside the network. Mutual authentication is the first line of defense, but it is not enough on its own if authorisation is still missing at the service boundary.

Teams should treat east-west traffic as production traffic with its own control plane, logging, and anomaly detection. That means enforcing per-service access decisions, validating tokens or certificates at the destination service, and watching for unexpected direct requests that bypass the normal application flow.

Where organisations want a broader architecture pattern for this, the Zero Trust model is the clearest external reference point because it formalises “never trust, always verify” for internal traffic as well as external traffic. NIST SP 800-207 Zero Trust Architecture

Risk and Threat Considerations

Direct micro-service calls matter because they turn a single exposed endpoint into a shortcut around layered controls. Once an attacker reaches an internal service that trusts upstream identity too much, they can often move laterally, access data or functions that the front end would normally gate, and persist through whichever service still accepts the stolen or replayed credential.

Failure mechanism: The service accepts requests based on implicit trust, shared credentials, or network location instead of independently verifying caller identity and privilege.

Impact: Attackers can bypass application-layer controls, expand access across internal services, and abuse legitimate service pathways to reduce detection and increase blast radius.

Practitioner Guidance

What to verify: Confirm that every micro-service validates its own caller identity and authorisation, not just the gateway or front end. If a request can succeed with an internal network position alone, the service boundary is not enforcing a real security decision.

What to measure: Track how many services rely on shared secrets, reusable tokens, or caller IP as a trust signal. A shrinking count of implicit-trust dependencies is a better indicator of maturity than gateway-only coverage.

Common mistake: Teams often harden the public API and assume the internal layer is safe by default. In practice, the attacker only needs one service that still accepts unauthorised direct requests or trusts upstream assertions without re-checking them.

Practitioner takeaway: If the internal service can be called directly, it must behave like a security boundary, not like a trusted implementation detail.

Related resources from NHI Mgmt Group

• Calling Micro-Services Directly
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?