Episode 64 — Detect lateral movement by monitoring network flows, service calls, and unusual access paths
Lateral movement is where an incident stops being a single-system problem and becomes a business problem, because it is the attacker’s method for expanding reach, finding higher value targets, and building resilience against containment. In this episode, we start with the simple idea that initial access is rarely the end of the story, especially in cloud and hybrid environments where workloads are interconnected and permissions can be chained. Once an attacker has a foothold, they explore what else is reachable, what else trusts the compromised asset, and what else can be accessed with the same identity or with harvested credentials. The defender’s job is to notice the expansion early, when movement is still exploratory and before it becomes a coordinated sweep through sensitive systems. That requires monitoring the signals that show internal motion, not just external entry, and doing it in a way that supports fast triage.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
Lateral movement is best defined in operational terms so detection logic stays grounded. It is the act of moving between systems, services, or trust boundaries to gain additional access beyond the initial foothold. That movement can be network-based, such as connecting from one workload to another over internal ports, or identity-based, such as reusing credentials to authenticate to a different service. It can be tool-driven, where an attacker uses remote execution mechanisms, or it can be native, where they rely on built-in service-to-service trust and administrative APIs. What matters is not the specific technique, but the outcome: the attacker is widening control, discovering new targets, and positioning themselves for privilege escalation or data access. When you define lateral movement this way, the detection problem becomes a search for new relationships and new paths that should not exist, especially when they appear abruptly.
Network flow monitoring is one of the most direct ways to see lateral movement because it captures the communication graph as it actually happens. Watching flows for new internal connections means paying attention to a source that suddenly begins talking to destinations it has never contacted before, or begins using ports and protocols that do not fit its role. Scanning is often visible as one source probing many destinations, many ports, or both in a short time window, especially when the results are mostly denied or mostly short-lived. Even when the attacker is careful, the act of exploration tends to generate new connection attempts, and those attempts can stand out against steady-state service communication. Flow data is especially valuable when it is enriched with asset identity, environment, and tier context so you can quickly judge whether the connection should exist. Without that context, flow logs can become a large pile of numbers, but with it, they become a map of who is reaching into places they do not belong.
Service call monitoring adds a second lens that is often more precise than raw flows because it reflects application-level intent. Watching service calls for new dependencies means noticing when a service starts calling another service it has not depended on historically, or starts reaching across tiers in ways that violate design. Unexpected A P I usage is a common symptom of compromise because attackers often use administrative or introspection endpoints, or they call functions that are rarely used during normal operations. This category also includes changes in call patterns, such as a sudden increase in error responses, calls made with unusual parameters, or calls that occur at unusual rates and times. In cloud-native environments, service-to-service behavior is a primary pathway for lateral movement, because once the attacker gains a foothold in one workload, service calls can become their quiet vehicle for exploration and privilege expansion. Service call signals also help reduce false positives because they can distinguish a benign new network connection from an actual attempt to use a sensitive interface.
Authentication events are the third critical source because many lateral movement techniques rely on re-authentication, role assumptions, or token reuse between services. Watching authentication events for new role assumptions between services means tracking when a workload begins to assume roles it never assumed before, when a service identity begins accessing resources outside its normal scope, or when role chaining appears in unusual sequences. In many environments, service identities are designed to have stable, minimal permissions, so abrupt changes in role usage patterns are meaningful. Even if the network path exists, identity should still be a gate, and changes in identity behavior can reveal that the attacker is using the compromised asset to request broader access. Authentication telemetry also helps you connect movement across layers: a new internal connection in flow data becomes more suspicious when it lines up with a new role assumption or a new token issuance event. That cross-correlation is often where high-confidence detection comes from.
Baselining is what turns these telemetry sources into useful detection rather than constant noise. You want to baseline normal east-west patterns per environment and tier, because what is normal in one place can be abnormal in another. A development environment may have broader connectivity and more frequent change, while a production environment should have tighter, more stable communication graphs. A web tier should generally talk to specific application services and upstream dependencies, not to arbitrary internal hosts, and a database tier should have even tighter inbound expectations. Baselining should capture which sources talk to which destinations, what ports and protocols are used, and what authentication patterns support those connections. The baseline is not a permanent rule, because systems evolve, but it gives you a reference point so you can spot new paths quickly. When you baseline by environment and tier, you reduce false positives and increase the chance that a real pivot stands out.
A practical way to build competence is to practice spotting lateral movement using one flow clue and one login clue, because it encourages responders to form a narrative rather than treat data sources in isolation. The flow clue might be a workload that suddenly initiates connections to multiple internal destinations, or a web server that starts talking directly to a database management port it never used before. The login clue might be a new role assumption by that same workload identity, a token issuance event that expands scope, or a set of authentication failures followed by success against a new internal service. When you put the clues together, you can ask the right questions: is this a legitimate deployment change, a misconfiguration, or an attacker exploring? The goal of the exercise is not to catch every possible movement technique, but to build the reflex of linking network behavior to identity behavior. That reflex is what makes lateral movement detection fast enough to matter.
One of the most damaging pitfalls in real programs is missing internal movement because only perimeter logs exist. Perimeter logs are valuable for understanding internet-facing threats, but they are often blind to east-west movement where the attacker does most of the work after entry. In cloud environments, internal movement can be fast and quiet, and if you do not collect flow visibility and service call visibility inside the environment, you will discover lateral movement only when the impact shows up. That might be a data exfiltration alert, a service outage, or an integrity incident, and by then the attacker may have already established multiple footholds. The pitfall is often organizational rather than technical: teams invest heavily in the edge and assume the internal space is safe because it is not public. Attackers do not share that assumption, and modern incidents regularly prove that internal visibility is not optional.
A quick win that improves internal visibility rapidly is enabling flow logs and centralizing them for analysis. Flow logs are not a complete solution, but they provide immediate evidence of how systems communicate and they enable broad detection patterns like scanning, new internal connections, and tier boundary violations. Centralizing them matters because lateral movement often spans multiple subnets, multiple projects, or multiple accounts, and local log storage fragments the story. When flow logs are centralized, you can correlate across sources, enrich with asset inventory, and build detection logic that sees the environment as a connected system. Centralization also improves incident response because responders can query traffic patterns without relying on one team’s local access to one segment. The operational payoff is speed: faster triage, faster scoping, and faster containment decisions.
To make the pivot risk tangible, consider the classic scenario of an attacker moving from a web server to a database tier. The web server is often the initial foothold because it faces external traffic and must accept untrusted inputs, and once compromised, it becomes an internal launch point. The attacker then tests what the web server can reach, probing for database endpoints, cache layers, internal admin interfaces, and metadata services. If they find a database path, they might attempt direct queries using harvested credentials, exploit a misconfigured trust relationship, or use the web server’s service identity to access secrets that unlock database access. On the network side, you would see new internal connections from the web server into the database segment, often to ports that are not part of normal application connectivity. On the identity side, you might see new role assumptions, new token requests, or access to secret stores that precede database authentication. The combination of network and identity clues is what reveals the pivot early.
A particularly high-signal category of detection is alerting on new paths into management networks and sensitive segments. Management networks are high leverage because they contain control surfaces, and sensitive segments are high leverage because they contain regulated data, privileged services, or core business systems. New paths can appear as new routing, new security group rules, or simply new traffic that indicates a path already existed but was never used before. Either case is worth attention because management access and sensitive access should be tightly controlled and relatively stable over time. If a workload that never had any reason to contact management interfaces suddenly does so, you should assume compromise until proven otherwise. Similarly, if a general-purpose workload begins reaching into a restricted data segment, that violates the principle of least privilege at the network layer and often indicates lateral movement or misconfiguration. High-value segment alerts are effective because they focus attention where the risk is concentrated.
A memory anchor that fits lateral movement is footsteps moving deeper into the building. The initial breach is the front door being opened, but lateral movement is the sound of someone walking through hallways, trying doors, and heading toward rooms they should never enter. Footsteps are not always loud, but they create patterns: new paths, repeated attempts, and movement toward higher-value areas. Network flows represent the footsteps in terms of connectivity, service calls represent the intent and the doors being tried, and authentication events represent the keys being tested or copied. When you think in footsteps, you naturally prioritize detection near sensitive rooms, like management networks and high-value data segments, and you become less distracted by noise in low-value corridors. The anchor also reinforces that the real problem is not just that someone got in, but that they are moving with purpose.
Before closing, it helps to stitch the detection model into a coherent mental checklist that stays usable during real triage. Lateral movement is movement between systems to gain access, and it tends to show up as new internal connections, new service dependencies, and new authentication patterns. Flow logs show connectivity changes and scanning, service telemetry shows new or unexpected A P I usage, and authentication logs show role assumptions and token behaviors that enable access across services. Baselining per environment and tier reduces false positives and makes new paths stand out quickly. The pivot scenario from web to database illustrates how network and identity clues reinforce each other, and the most urgent alerts often involve new access into management networks or sensitive segments. When these sources are combined and framed as a movement story, defenders can spot expansion early and interrupt it before it becomes widespread.
To conclude, identify your most dangerous internal movement paths today, focusing on where a compromise would expand into management access or sensitive data access. Think in terms of plausible pivots, such as internet-facing workloads reaching privileged segments, shared services acting as bridges between environments, or service identities that can assume broader roles than intended. For each high-risk path, ensure you have at least one flow-based signal, one service-behavior signal, and one authentication signal that could reveal movement along that path. The objective is not perfection, but coverage of the routes an attacker would most likely use to turn one foothold into many. When you know your dangerous paths and you monitor for the first footsteps along them, lateral movement becomes something you can detect and contain early rather than something you discover after the damage is done.
