# Supply Chain npm Install Context Credential Egress (@edge-sky/dsh-oauth-adapter)

- **Severity:** High
- **Signature ID:** `7f3c1d2e-8b64-4a19-9c07-5e2ad84b1f36`

## Summary

This rule flags a specific attack pattern seen with the package @edge-sky/dsh-oauth-adapter: during package installation, a script reads OAuth or cloud credential files it has no legitimate reason to touch, then sends an outbound network request. It also flags any session where the package name itself shows up in commands or URLs.

## How the attack works

An attacker publishes or compromises a package (here, @edge-sky/dsh-oauth-adapter) whose install or lifecycle scripts run automatically when someone runs npm/npx/yarn/pnpm/bun/node-gyp. In the same session, after that install step starts, a non-npm credential store (OAuth tokens, cloud credentials, etc., but not the routine ~/.npmrc) gets read. Shortly afterward, still within the same session and within a 15-minute window, an outbound HTTP request goes out from a process descended from that install. The rule reconstructs this whole chain by tracing process ancestry and timing, since it cannot directly observe package installs or credential theft as native events.

## Why it matters

If this pattern is real and malicious, an organization's cloud or OAuth credentials can be silently exfiltrated the moment a developer or CI system installs a trojanized package, leading to account or infrastructure compromise.

## What you can do

- Restrict which credential files and directories install/build scripts can access, separating build environments from production credentials where possible.
- Audit any environment that has installed @edge-sky/dsh-oauth-adapter for unexpected reads of credential files (AWS, GCP, Kubernetes configs, OAuth tokens) around install time.
- Review preinstall/postinstall lifecycle scripts in dependencies before allowing them in CI or developer machines.
- When this fires, check what binary read the credential file and where the network request went before treating it as an incident 	h flhits this pattern.

## Known benign look-alikes

- Repositories whose install lifecycle legitimately authenticates to a private registry or artifact store by reading a cloud credential file (for example a CodeArtifact or GCP Artifact Registry login helper invoked from a preinstall script) and then fetching tarballs - the ordered install -> secret-read -> egress chain will match. Confirm the reading binary and the destination before escalating.
- CI runners executing 'npm ci' inside an agent session where a build step assumes an IAM role from ~/.aws/credentials or reads ~/.kube/config before calling an API.
- Security researchers or SOC engineers deliberately installing @edge-sky/dsh-oauth-adapter in a sandbox for payload analysis - the IoC track fires by design.
- Long-lived monorepo dev loops ('pnpm exec', 'yarn dlx') where a package-manager ancestor stays in the lineage and an unrelated tool in the same shell session reads a credential store within the 15-minute window.
- Hosts where the shell ancestor was never ingested - lineage is short and the reason string is marked attribution=degraded; the install anchor is still required, but the owning session shown in the chain may be truncated.

## References

- https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/
- https://attack.mitre.org/techniques/T1195/001/
- https://attack.mitre.org/techniques/T1552/001/

---
Source: https://www.netzilo.com/threats/npm-oauth-adapter-credential-egress