AzureCdnInfo.edrtester — a VS Code extension that beacons out with host recon behind HTTP Host-header domain fronting
A Visual Studio Code Marketplace extension (AzureCdnInfo.edrtester 1.0.4) that, on activation, fingerprints the machine and its Windows domain, then beacons to an attacker endpoint every 150 seconds — reaching one host on the wire while presenting a spoofed Host: header for another (HTTP domain fronting, not SNI). A reverse shell and an AES-decrypt routine are bundled but the reverse shell is dormant in this build.
AzureCdnInfo.edrtester presents as an EDR/telemetry test utility. In practice its activation path loads a payload module (edrdrill.js) that performs host reconnaissance and opens an outbound beacon — the behaviour of a lightweight backdoor implant, not a test tool.
The publisher id itself (AzureCdnInfo) and the spoofed Host: value are chosen to read like benign Azure/CDN infrastructure — social-engineering the network reviewer, not just the marketplace reviewer.
Activation. extension.js is the VS Code entrypoint (activate()); it loads edrdrill.js, which calls setUpBeaconing() immediately and then on a setInterval every 150 seconds.
Recon. It collects hostname, current working directory and local IP, and resolves the Windows domain controller / PDC via DNS SRV and reverse lookups (ext.dns.js: queryDC() / queryPDC()). Command helpers for systeminfo, tasklist, netstat, ipconfig, wmic and net localgroup are present.
Beacon + domain fronting. The beacon is an http.request to xeroshoes[.]com:80 on path /bcon/, but it sets Host: officeupdate.southeast.cloudapp.azure-cdn[.]info and a decoy browser User-Agent — so the TCP peer and the advertised host differ (HTTP Host-header fronting, not SNI).
Present but dormant. A reverse-shell function (phone_home()) and an AES-decrypt routine are bundled. In this build phone_home() is not dispatched (no command handler wires it up), and a second endpoint goofy.japaneast.cloudapp.azure[.]com is commented out — so the active scope is recon + beaconing. The dormant capability is why the verdict is Critical, not Medium: arming remote command execution is a one-line change.
AzureCdnInfo.edrtester 1.0.4 pulled from the VS Code Marketplace feed by codelake collection.xeroshoes[.]com:80, path /bcon/Host: header (domain fronting): officeupdate.southeast.cloudapp.azure-cdn[.]infogoofy.japaneast.cloudapp.azure[.]comextension/edrdrill.js sha256 eebb86f9d25df589229ce17cb2ee98c3b37f79739f4abb608171ed64977cbb77extension/extension.js sha256 0615802ff0a30b46b159a064bd63ae7a58bab0097c215bce608f4c67306bfeafextension/ext.dns.js sha256 acd8833a51e369f4d5638191322bd14196d6960dd70b3b5142d91d8daf92cec5extension/ext.logging.js sha256 28d6e35c0c6dbbb149a8f15f01dc278b76c40eb72dfb20472d6bb367c41d3e39d4101a5bc86747f499ef347548e92eb3e1b09ce6acaf34bd1ee07f66400b18afVerified scope: on-activation host recon + a 150 s HTTP beacon behind Host-header domain fronting. The bundled reverse shell is not wired to a dispatcher in build 1.0.4 — present but dormant — which is exactly why this is Critical: arming it is trivial.
Analysis was static (code + dataflow) on the inert VSIX; no installation, execution, or live callback was performed.