Analysis Map and Safety Boundary¶

Safety boundary: This workbook performs static analysis of sanitized excerpts, fake fixtures, and derived public metadata. It does not execute attacker code, inspect the analyst's environment, or contact any network.

Question and Method¶

This technical appendix reconstructs how a root dependency install crossed several trust boundaries:

root npm install
  -> prepare lifecycle script
  -> backgrounded Node server
  -> CommonJS import-time side effect
  -> bulk environment POST
  -> returned JavaScript executed with CommonJS access
  -> host-profile beacon attempt
  -> direct-IP connect failure

The notebooks analyze that chain without replaying it. Their governing rule is:

capability != observed execution != proven transmission

Static code can establish capability. Runtime traces can establish execution. Network or server-side evidence is needed to establish completed transmission.

Artifact and Publication Map¶

Layer Artifact Public treatment Reason
npm lifecycle preserved package manifest / sanitized excerpt analyzed directly automatic entrypoint
Node import chain server.js, socket/index.js, controllers/auth.js call graph and reviewed excerpts import-time side effects
environment exfiltration auth controller / redacted schema data-flow model sensitive primitive
stage two hash plus derived feature summary feature extraction only raw payload withheld
C2 path public IOC plus reconstructed runtime error network-path reasoning no live contact

The private evidence set also contains hostile source and raw captures. Those are not notebook dependencies and are intentionally not published.

In [ ]:
layers = [
    {"step": 1, "boundary": "package manager -> shell", "question": "What can install execute?"},
    {"step": 2, "boundary": "entrypoint -> import graph", "question": "What runs before a request?"},
    {"step": 3, "boundary": "process -> environment", "question": "What data is reachable?"},
    {"step": 4, "boundary": "host -> remote response", "question": "What authority does returned data receive?"},
    {"step": 5, "boundary": "stage two -> C2", "question": "Did the connection complete?"},
]
layers

What Is Withheld¶

  • the raw executable stage-two body;
  • raw process-environment captures;
  • credential, token, browser, shell-history, or wallet reports;
  • private filesystem inventories;
  • live endpoint interaction and tasking logic.

This is not loss of analytical rigor. The public substitutes are hashes, lengths, line references, sanitized excerpts, feature presence, and bounded runtime observations. Those are sufficient to teach the reasoning path without redistributing executable hostile content.

In [ ]:
claim_levels = {
    "capability": "The code can perform an action.",
    "observed": "A local artifact shows that the path ran.",
    "likely": "Multiple artifacts support the inference, but one proof source is absent.",
    "proven transmission": "Network or receiver evidence shows data completed the path.",
    "not evidenced": "The available artifacts do not show the behavior.",
}
claim_levels

Analytical Questions Used Throughout¶

Every workbook asks:

  1. What code path is under analysis?
  2. Which artifact supports it?
  3. What did the code do, and what authority did it enable?
  4. What was actually observed?
  5. What was not proven?
  6. Which control could prevent or detect it?
  7. Which additional telemetry would raise confidence?

Strongest supported claim: the install path reached downloaded stage-two execution and a direct-IP connection attempt.

Strongest unsupported claim: that direct-IP tasking completed or that credential or wallet files were stolen.