Initial access and foothold boundaries¶

Initial access shapes everything that follows, whether it arrives through a phished workstation, a jump host bridging two networks, an API key committed to a repository, or a self-registered application account. The nature of that first foothold sets the terms for all subsequent activity.

Categories of initial access¶

A compromised workstation carries the user’s technical identity and whatever network access the organisation has extended to it. In a flat network, that can mean broad visibility across the estate; in a segmented environment, it might offer little more than an email client, two file shares, and a long walk. Crucially, a workstation also holds user habits that rarely show up in technical inventories: the four servers touched daily, a profile script with embedded credentials, or a browser password vault that stays unlocked as long as the user is logged on.

A jump host positioned at the boundary between an office network and a process network offers a much narrower, specific utility. It often holds two network interfaces and a route that exists nowhere else, which is its entire reason for being. At the same time, it is usually the most heavily watched host in either network, frequently fitted with session recording software. Its primary value is topological rather than local.

A leaked API key or build token grants authority without requiring a host compromise. No active exploitation is needed to use it, and because it belongs to an automated service rather than a human, its activity is often watched by nothing at all. Against that, tokens are frequently temporary and can expire within the hour.

A low-privilege application login carries minimal initial authority but yields valuable internal visibility. Sitting inside a tenant environment reveals how requests are structured and exposes internal detail through unexpected error responses, such as a 403 forbidden response where a 404 was expected, or object identifiers that increment sequentially.

Defining foothold limits¶

Every foothold has strict boundaries, and defining those limits early is far cheaper than discovering them during an operation. An identity-based foothold reaches only as far as that identity is honoured. A network-based foothold stops at the firewall that justifies the segment. A token might reach a single API and expire within the hour. A foothold on a controller network might offer broad physical reach, yet be unable to touch anything without triggering an alert inside a single scan cycle.

Some footholds offer no path forward at all. A device on a guest wireless network with client isolation enabled, or a login on an isolated tenant, is unlikely to lead anywhere. What such a position is still good for is covered in what a position can reach.