skip to content

Running in Another Process

1 roadmap4 questions

Code placed inside a running process inherits its token, its privileges and the destinations that are ordinary for it - and its lifetime and crashes too. Interviewers probe what is really gained.

on this pageshow

explore

questions

4

Why does an operator already running as a user inject into that user's browser instead of opening its own connection?

level: juniorimportance: must knowfreq 70%

answer

  1. your own process has no reason online
  2. whose identity rides the packets
  3. the one process allowed to reach anywhere
  4. blend into browsing, don't tunnel
  5. borrow the token and the egress path

basics

~20 s

The operator's own process has no business reaching the internet, and its traffic carries no user identity. Running inside the user's browser borrows that person's session, proxy settings and usual destinations, so the outbound traffic looks like their ordinary browsing rather than a strange new program phoning out.

solid answer

~40 s

Code the operator already runs can open a socket, but its traffic stands out: an unusual image, an odd parent, and a connection to a host that program has no reason to reach. The browser is the one process expected to reach arbitrary internet hosts, and it already carries the logged-on user's authenticated sessions and proxy configuration. By executing inside it, the operator's requests inherit the user's identity and the browser's permitted egress path, so they blend into that person's real browsing. A patient operator who wants no revenue, only presence, cares about exactly this: the traffic must be the user's own, from the user's own process, at the user's own tempo.

go deeper

for a junior

Be able to say plainly what running inside the browser buys: the user's identity on outbound traffic and a route the environment already allows, so it looks like normal browsing.

for a middle

Explain why the operator's own process stands out on the network and why the browser is uniquely well-placed — expected to reach anywhere, already carrying sessions and proxy config.

for a senior

Discuss how a patient operator uses this to match a target user's identity, destinations and tempo, and why a shared multi-session host multiplies the available cover.

for a principal

Frame the tradeoff a platform owner faces: outbound identity based on the host process is not trustworthy, because a user's own code can wear the user's own browser. That reshapes where you place trust.

## The problem the operator has Getting code to run on a host is only half the job; that code usually needs to reach the operator's infrastructure. A freshly launched program that makes outbound connections is conspicuous in three ways at once: 1. it is an image nobody expects to be online, 2. it was started by an unusual parent, 3. and it is talking to a destination that program has no legitimate reason to contact. None of that is about hiding a file — it is about how the *traffic* looks. ## Why the browser specifically On a normal desktop, exactly one class of process is expected to reach arbitrary hosts on the internet: the **web browser**. - It already holds the user's **authenticated sessions** (cookies, tokens). - It is configured with the organisation's **proxy**. - It routinely establishes encrypted connections to sites the user visits. If the operator's code executes *inside* that process, its outbound requests inherit all of that for free: - the user's identity is on the wire, - the egress path is one the environment already permits, - and the destination sits among the many the user reaches anyway. ## What 'inherit the token and destinations' means A running process carries an **access token** that names the user and their rights, and it carries the network context the user configured. Code injected into the browser runs under that same token and uses that same context. It does not become a different, more powerful user — it becomes *this* user, on *this* egress path. That is the entire point: **identity plus a plausible outbound route**. ## The multi-session angle On a shared **terminal-server or virtual-desktop host**, dozens of people are logged on at once, each with their own browser holding their own sessions and proxy configuration. An operator on such a host can choose whose identity and whose destinations to wear by choosing whose browser to run inside — a rich menu of ready-made cover. ## What this is NOT Two misreadings are common: 1. First, that the goal is to steal the browser's **saved passwords** — that is a separate harvesting step, not what running-inside buys you here; what you buy is *live* identity on outbound requests and a permitted egress path. 2. Second, that the goal is to **hide a file on disk** — the file may still exist; the technique is about making the *traffic* indistinguishable from real browsing. A patient, well-resourced operator will spend real engineering to get this **blending**, because it is the difference between traffic that looks like a program calling home and traffic that looks like a person browsing the web.

  • Why is a shared multi-session terminal server an especially attractive place to do this?
    Because dozens of users are logged on at once, each with a live browser holding their own authenticated sessions and proxy configuration. The operator can pick whichever user's identity and destinations best fit the traffic they want to blend into, rather than being stuck with one.
  • Does running inside the browser hand the operator the user's stored passwords?
    Not by itself. Executing inside the browser buys live identity on outbound requests and a permitted egress path — it does not read the credential store, which is a separate harvesting step with its own requirements. Conflating the two overstates what this technique alone achieves.

saying these in an interview costs you the question

  • Thinks injecting into the browser is mainly to steal saved passwords
  • Assumes the operator's own process can reach the internet as freely as a browser
  • Believes the goal is hiding the file rather than blending the traffic
  • Says injecting makes the operator a more powerful user

context

resolving links…

open as a page

You're told injecting into a user's browser 'escalated' the operator's privileges. On a shared desktop, is that right?

level: seniorimportance: must knowfreq 60%

basics

~20 s

No. Injecting into a process at the same integrity level escalates nothing — the operator already held that user's rights. It buys the user's identity on outbound traffic, a permitted egress path and a plausible lifetime. Privilege is spent only when the operator crosses into a different user's session.

open as a page

In process hollowing, what must an operator do to a suspended host before the payload can run?

level: middleimportance: should knowfreq 55%

basics

~20 s

Hollowing starts a legitimate process suspended so it never actually runs, unmaps its original image from memory, writes the payload in its place, fixes the payload's relocations to wherever it landed, repoints the primary thread's entry at the payload, then resumes. The process ends up running code it was never loaded with.

open as a page

An operator injects into a user's browser tab to blend traffic; the user closes it. What just happened to their code?

level: seniorimportance: should knowfreq 45%

basics

~20 s

It died with the process. Memory-only injection has no life of its own — when the user closes the browser, the host exits and the payload is gone. To survive, the operator needs a separate trigger that re-injects on each new session, or must accept a longer-lived host that is worse cover.

open as a page