A stolen core, a stolen cookie, a stolen SYSTEM token: three routes to one corrupted number

ActiveState's webinar pitch starts from a premise worth granting: AI coding tools have become a rapidly growing source of unvetted open source in production, and security and engineering teams are inheriting packages they did not approve, vulnerabilities they do not know how to prioritise, and exposure they cannot control ^[1]. The vendor says it surveyed 300 security and engineering leaders across technology, financial services, healthcare, manufacturing and government, and that the research quantifies the acceleration of remediation backlogs and maps it to liability and business outcomes ^[2][3].

Grant that and a second problem follows that the pitch does not touch. Whatever governance you write about that code, you will enforce it using measurements produced by the machine under review, delivered through an identity that three well-documented compromises collapse. Worth noting before going further: the promotional page asserts quantification and publishes no figure other than the sample size of 300 ^[5].

The number is a self-report

Take the most ordinary piece of infrastructure telemetry on Linux. /proc/stat reports kernel and system statistics in units of USER_HZ, which is one hundredth of a second on most architectures, and the manual page tells you to call sysconf(_SC_CLK_TCK) rather than assume it, because the contents vary with architecture ^[33]. The cpu line carries ten fields in a fixed order: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice ^[34].

Two of those fields are interesting for reasons that have nothing to do with attackers. iowait, present since Linux 2.5.41, is documented as not reliable, and the manual gives three reasons: the CPU does not actually wait for I/O, on a multi-core system the waiting task is running on no CPU at all so per-CPU iowait is hard to calculate, and the value may decrease under certain conditions ^[35]. steal, since Linux 2.6.11, is defined as the time spent in other operating systems when running in a virtualized environment, while guest, since 2.6.24, is time spent running a virtual CPU for guest operating systems under the kernel's control ^[36]. So the canonical signal for "a neighbour took my CPU" is produced by the kernel that was not running when the CPU was taken.

The example line in the manual page is worth reading positionally rather than as decoration. It is `cpu 10132153 290696 3084719 46828483 16683 0 25195 0 175628 0` ^[37], which maps to idle 46,828,483 ticks, iowait 16,683, steal 0 and guest 175,628 ^[39]. The ten fields sum to 60,553,557 ticks, about 605,536 seconds at 100 Hz, of which idle is 77.3 per cent and the field the kernel explicitly disclaims is 0.028 per cent ^[40]. Under the documented definitions, steal at zero with guest non-zero is the shape of a host running guests, not a guest being charged for a neighbour ^[36][39]. The same file, same field order, means different things depending on which side of the virtualization boundary you are standing on, and the file cannot tell you which side that is.

The rest of /proc/stat is the same kind of artefact: context switches, boot time in seconds since the Epoch, forks since boot, processes runnable and blocked, interrupt and softirq totals ^[38]. Restart detection, churn detection and saturation dashboards all read out of a surface the machine writes about itself.

The collector is a bearer token

Now the path the number travels. OWASP's description of session hijacking is a description of how web identity actually works: because HTTP communication uses many different TCP connections, the server needs a method to recognise every user's connections, and the most useful method depends on a token sent to the client browser after successful authentication ^[15]. That token can live in the URL, in a request header as a cookie, in other parts of the header, or in the body of the request ^[16].

The attack is to steal or predict a valid token and gain unauthorized access, and OWASP's list of common routes is short: predictable tokens, session sniffing, client-side attacks such as cross-site scripting, malicious JavaScript and trojans, man-in-the-middle, and man-in-the-browser ^[17]. The demonstration is three lines of JavaScript that display the current cookie, with the note that the same technique can be used to send the cookie to the attacker instead ^[18].

Two of those five routes require nothing from the measured host at all. Prediction and sniffing operate entirely on the token, which means the integrity of every number in the console is downstream of a string whose only property is that the server recognises it. Man-in-the-browser sits at the other end, in the place where the number is finally rendered for a human. Whoever holds the token is the analyst, and the substrate has no way to tell the difference. It is also worth saying plainly that OWASP's own page for this attack class carries a notice that its content was programmatically ported from a previous wiki page and that there is still some work to be done ^[19].

The agent is the machine

The third compromise hits both halves at once, which is why it deserves the most space. Microsoft's documentation describes LocalSystem as a predefined local account used by the service control manager that has extensive privileges on the local computer and acts as the computer on the network, with a token that includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs, and no password ^[26]. It is not recognised by the security subsystem, so you cannot resolve its name through LookupAccountName, and any password you pass to CreateService or ChangeServiceConfig is ignored ^[27]. A LocalSystem service inherits the SCM's security context, is associated with no logged-on user, maps HKEY_CURRENT_USER to the default user, can open HKEY_LOCAL_MACHINE\SECURITY, and presents the computer's credentials to remote servers ^[28].

Microsoft lists 24 privileges for the account, among them SE_DEBUG_NAME, SE_IMPERSONATE_NAME and SE_TCB_NAME as enabled ^[30]; by count, 11 of the 24 are marked enabled and 13 disabled ^[31]. The same documentation says most services do not need such a high privilege level and points non-interactive services at LocalService or NetworkService instead ^[32]. It also records a boundary thinner than the privilege list suggests: if a LocalSystem service opens a command window and runs a batch file, a user pressing CTRL+C can terminate the batch file and be left with a command window running at LocalSystem permissions ^[29].

Put that against the two things this article is tracking. Debug and impersonate privileges on the local machine mean the code that reads the measurement surface can be rewritten or impersonated; presenting the computer's credentials to remote servers means the report arrives at the collector under an identity the collector has no reason to question. There is no password to rotate, because there is none to begin with ^[26]. Microsoft's other page states the trade-off in one sentence: complete unrestricted access to local resources is the advantage, and the disadvantage, because such a service can do things that would bring the entire system down ^[20].

The multiplier is the shared account. All LocalSystem services on a machine share the computer account of their host server, so adding a computer account to a group permits every LocalSystem service on that computer the access rights of the group, which is why the documentation says computer accounts must not be members of domain administrator groups ^[22]. On a domain controller, a LocalSystem service has unrestricted access to Active Directory Domain Services, so a bug or an attack can damage the entire enterprise network, and Microsoft's instruction is unambiguous: services should never run as LocalSystem on a domain controller ^[21]. On anything that is not a DC, default AD DS ACL protection permits computer accounts only minimal access, which is exactly why Microsoft tells you to test on a member server rather than only on a DC ^[24]. A collector that looks well behaved because it was tested in the wrong place is a governance artefact, not a control.

RATS names the missing role, then stops

The vocabulary for the gap already exists. RFC 9334 sets out the Remote ATtestation procedureS architecture, in which an Attester produces believable information about itself, called Evidence, so that a remote Relying Party can decide whether to treat it as a trustworthy peer, with a Verifier as the third necessary party ^[7]. The Verifier appraises Evidence against appraisal policies and produces Attestation Results that support the Relying Party's decision ^[8]. The document is careful about a distinction operators routinely blur: trust is a choice one makes about another system, while trustworthiness is a quality of that system used in making the choice ^[9].

The important thing about that architecture, for this argument, is what it does not do. It does not eliminate the self-report. The Attester still describes itself, exactly as the guest kernel still describes its own stolen time ^[7][36]. What changes is that someone other than the reporter decides what the report is worth, against a written policy, and the document specifies freshness and trust relationships alongside topological patterns it calls the Passport Model and the Background-Check Model ^[12]. The operational teeth are in the consequences: systems attested and verified to be in a good state can improve overall posture, and systems that cannot be attested and verified can be given reduced access or privileges, taken out of service, or flagged for repair ^[10]. The RFC's own examples are a bank backend refusing to transact with a system not known to be in a good state, and a healthcare system refusing to transmit electronic healthcare records to one ^[11].

The honest limit is in the header. RFC 9334 is Informational, is explicitly not an Internet Standards Track specification, and is deliberately neutral toward processor architectures, the content of Claims, and protocols, with the stated purpose of providing terminology and enabling semantic interoperability across multi-vendor solutions ^[6][13]. It hands you roles and words. It does not hand you a measurement, and it does not tell you which fields of /proc/stat are worth appraising.

There is no head-on contradiction between these sources, but there is a mismatch that neither acknowledges. ActiveState's frame is inventory and remediation backlog: which packages, which vulnerabilities, in what order ^[1][3]. RATS's question is whether the far end is in an intended operating state right now ^[7][10]. A clean, approved package list says nothing about whether the host reporting it was in a good state when it reported, and an attested runtime state says nothing about whether the code running is code anyone approved. ActiveState's own agenda concedes the adjacent point, promising a discussion of which approaches mitigate remediation burden and which might just redistribute it ^[4].

What to watch is whether the numbers acquire owners. The survey's backlog figures are the first: a claim to have quantified acceleration is not a quantity ^[3][5]. The second is an inventory of collectors and agents running under LocalSystem, with the group memberships of the computer accounts they share, since that single fact sets how far one compromise travels ^[22]. The third is whether anyone writes an appraisal policy that names the fields the kernel itself disclaims, rather than charting them ^[35][8]. And the fourth is whether a failed appraisal actually produces one of the three outcomes RFC 9334 lists, or another dashboard tile ^[10].