{
	"id": "d193bf70-780c-4c08-a4ca-532c8415f771",
	"created_at": "2026-04-06T00:09:00.723593Z",
	"updated_at": "2026-04-10T13:12:58.435556Z",
	"deleted_at": null,
	"sha1_hash": "8f81bb920cb5d2c963e2f08b5cd1cbdac78ca5ad",
	"title": "Developer-targeting campaign using malicious Next.js repositories | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1547970,
	"plain_text": "Developer-targeting campaign using malicious Next.js repositories |\r\nMicrosoft Security Blog\r\nBy Microsoft Defender Experts, Microsoft Defender Security Research Team\r\nPublished: 2026-02-24 · Archived: 2026-04-02 10:56:27 UTC\r\nMicrosoft Defender Experts identified a coordinated developer-targeting campaign delivered through malicious repositories\r\ndisguised as legitimate Next.js projects and technical assessment materials. Telemetry collected during this investigation\r\nindicates the activity aligns with a broader cluster of threats that use job-themed lures to blend into routine developer\r\nworkflows and increase the likelihood of code execution.\r\nDuring initial incident analysis, Defender telemetry surfaced a limited set of malicious repositories directly involved in\r\nobserved compromises. Further investigation expanded the scope by reviewing repository contents, naming conventions,\r\nand shared coding patterns. These artifacts were cross-referenced against publicly available code-hosting platforms. This\r\nprocess uncovered additional related repositories that were not directly referenced in observed logs but exhibited the same\r\nexecution mechanisms, loader logic, and staging infrastructure.\r\nAcross these repositories, the campaign uses multiple entry points that converge on the same outcome: runtime retrieval and\r\nlocal execution of attacker-controlled JavaScript that transitions into staged command-and-control. An initial lightweight\r\nregistration stage establishes host identity and can deliver bootstrap code before pivoting to a separate controller that\r\nprovides persistent tasking and in-memory execution. This design supports operator-driven discovery, follow-on payload\r\ndelivery, and staged data exfiltration.\r\nInitial discovery and scope expansion\r\nThe investigation began with analysis of suspicious outbound connections to attacker-controlled command-and-control (C2)\r\ninfrastructure. Defender telemetry showed Node.js processes repeatedly communicating with related C2 IP addresses,\r\nprompting deeper review of the associated execution chains.\r\nBy correlating network activity with process telemetry, analysts traced the Node.js execution back to malicious repositories\r\nthat served as the initial delivery mechanism. This analysis identified a Bitbucket-hosted repository presented as a\r\nrecruiting-themed technical assessment, along with a related repository using the Cryptan-Platform-MVP1 naming\r\nconvention.\r\nFrom these findings, analysts expanded the scope by pivoting on shared code structure, loader logic, and repository naming\r\npatterns. Multiple repositories followed repeatable naming conventions and project “family” patterns, enabling targeted\r\nsearches for additional related repositories that were not directly referenced in observed telemetry but exhibited the same\r\nexecution and staging behavior.\r\nPivot signal   What we looked for  Why it mattered  \r\nRepo family\r\nnaming convention  \r\nCryptan, JP-soccer, RoyalJapan, SettleMint  Helped identify additional repos likely\r\ncreated as part of the same seeding effort  \r\nVariant naming  \r\nv1, master, demo, platform,\r\nserver  \r\nHelped find near-duplicate variants that\r\nincreased execution likelihood  \r\nStructural reuse  \r\nSimilar file placement and loader\r\nstructure across repos  \r\nConfirmed newly found repos were\r\nfunctionally related, not just similarly\r\nnamed  \r\nFigure 1. Repository naming patterns and shared structure used to pivot from initial telemetry to additional related\r\nrepositories \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 1 of 12\n\nAnalysis of the identified repositories revealed three recurring execution paths designed to trigger during normal developer\r\nactivity. While each path is activated by a different action, all ultimately converge on the same behavior: runtime retrieval\r\nand in‑memory execution of attacker‑controlled JavaScript. \r\nPath 1: Visual Studio Code workspace execution\r\nSeveral repositories abuse Visual Studio Code workspace automation to trigger execution as soon as a developer opens (and\r\ntrusts) the project. When present, .vscode/tasks.json is configured with runOn: “folderOpen”, causing a task to\r\nrun immediately on folder open. In parallel, some variants include a dictionary-based fallback that contains obfuscated\r\nJavaScript processed during workspace initialization, providing redundancy if task execution is restricted. In both cases, the\r\nexecution chain follows a fetch-and-execute pattern that retrieves a JavaScript loader from Vercel and executes it directly\r\nusing Node.js.\r\nFigure 2. Telemetry showing a VS Code–adjacent Node script (.vscode/env-setup.js) initiating outbound access to\r\na Vercel staging endpoint (price-oracle-v2.vercel[.]app). \r\nAfter execution, the script begins beaconing to attacker-controlled infrastructure. \r\nPath 2: Build‑time execution during application development \r\nThe second execution path is triggered when the developer manually runs the application, such as with npm run dev or by\r\nstarting the server directly. In these variants, malicious logic is embedded in application assets that appear legitimate but\r\nare trojanized to act as loaders. Common examples include modified JavaScript libraries, such as jquery.min.js,\r\nwhich contain obfuscated code rather than standard library functionality. \r\nWhen the development server starts, the trojanized asset decodes a base64‑encoded URL and retrieves a JavaScript loader\r\nhosted on Vercel. The retrieved payload is then executed in memory by Node.js, resulting in the same backdoor\r\nbehavior observed in other execution paths. This mechanism provides redundancy, ensuring execution even when\r\neditor‑based automation is not triggered. \r\nTelemetry shows development server execution immediately followed by outbound connections to Vercel staging\r\ninfrastructure: \r\nFigure 3. Telemetry showing node server/server.js reaching out to a Vercel-hosted staging endpoint (price-oracle-v2.vercel[.]app). \r\nThe Vercel request consistently precedes persistent callbacks to attacker‑controlled C2 servers over HTTP on port 300.  \r\nPath 3: Server startup execution via env exfiltration and dynamic RCE \r\nThe third execution path activates when the developer starts the application backend. In these variants, malicious loader\r\nlogic is embedded in backend modules or routes that execute during server initialization or module import (often at require-time). Repositories commonly include a .env value containing a base64‑encoded endpoint (for example, AUTH_API=\r\n\u003cbase64\u003e), and a corresponding backend route file (such as server/routes/api/auth.js) that implements the loader. \r\nOn startup, the loader decodes the endpoint, transmits the process environment (process.env) to the attacker-controlled\r\nserver, and then executes JavaScript returned in the response using dynamic compilation (for example,\r\nnew Function(“require”, response.data)(require)). This results in in‑memory remote code execution within the Node.js\r\nserver process. \r\n1\r\n2\r\n3\r\n4\r\n```\r\nServer start / module import\r\n→ decode AUTH_API (base64)\r\n→ POST process.env to attacker endpoint\r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 2 of 12\n\n5\r\n6\r\n7\r\n→ receive JavaScript source\r\n→ execute via new Function(...)(require)\r\n```\r\nFigure 4. Backend server startup path where a module import decodes a base64 endpoint, exfiltrates environment variables,\r\nand executes server‑supplied JavaScript via dynamic compilation. \r\nThis mechanism can expose sensitive configuration (cloud keys, database credentials, API tokens) and enables follow-on\r\ntasking even in environments where editor-based automation or dev-server asset execution is not triggered. \r\nStage 1 C2 beacon and registration \r\nRegardless of the initial execution path, whether opening the project in Visual Studio Code, running the development server,\r\nor starting the application backend, all three mechanisms lead to the same Stage 1 payload. Stage 1 functions as a\r\nlightweight registrar and bootstrap channel.\r\nAfter being retrieved from staging infrastructure, the script profiles the host and repeatedly polls a registration endpoint at a\r\nfixed cadence. The server response can supply a durable identifier, instanceId, that is reused across subsequent polls to\r\ncorrelate activity. Under specific responses, the client also executes server-provided JavaScript in memory using dynamic\r\ncompilation, new Function(), enabling on-demand bootstrap without writing additional payloads to disk. \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 3 of 12\n\nFigure 5. Stage 1 registrar payload retrieved at runtime and executed by Node.js.\r\nFigure 6. Initial Stage 1 registration with instanceId=0, followed by subsequent polling using a\r\ndurable instanceId. \r\nStage 2 C2 controller and tasking loader \r\nStage 2 upgrades the initial foothold into a persistent, operator-controlled tasking client. Unlike Stage 1, Stage 2\r\ncommunicates with a separate C2 IP and API set that is provided by the Stage 1 bootstrap. The payload commonly runs as\r\nan inline script executed via node -e, then remains active as a long-lived control loop. \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 4 of 12\n\nFigure 7. Stage 2 telemetry showing command polling and operational reporting to the C2 via\r\n/api/handleErrors and /api/reportErrors.\r\nStage 2 polls a tasking endpoint and receives a messages[] array of JavaScript tasks. The controller maintains session state\r\nacross rounds, can rotate identifiers during tasking, and can honor a kill switch when instructed. \r\nFigure 8. Stage 2 polling loop illustrating the messages[] task format, identity updates, and kill-switch\r\nhandling.\r\nAfter receiving tasks, the controller executes them in memory using a separate Node interpreter, which helps\r\nreduce additional on-disk artifacts. \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 5 of 12\n\nFigure 9. Stage 2 executes tasks by piping server-supplied JavaScript into Node via STDIN. \r\nThe controller maintains stability and session continuity, posts error telemetry to a reporting endpoint, and includes retry\r\nlogic for resilience. It also tracks spawned processes and can stop managed activity and exit cleanly when instructed. \r\nBeyond on-demand code execution, Stage 2 supports operator-driven discovery and exfiltration. Observed operations\r\ninclude directory browsing through paired enumeration endpoints: \r\nFigure 10. Stage 2 directory browsing observed in telemetry using paired enumeration endpoints\r\n(/api/hsocketNext and /api/hsocketResult). \r\n Staged upload workflow (upload, uploadsecond, uploadend) used to transfer collected files: \r\nFigure 11. Stage 2 staged upload workflow observed in telemetry using /upload, /uploadsecond, and\r\n/uploadend to transfer collected files. \r\nSummary\r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 6 of 12\n\nThis developer‑targeting campaign shows how a recruiting‑themed “interview project” can quickly become a reliable path to\r\nremote code execution by blending into routine developer workflows such as opening a repository, running a development\r\nserver, or starting a backend. The objective is to gain execution on developer systems that often contain high‑value assets\r\nsuch as source code, environment secrets, and access to build or cloud resources.\r\nWhen untrusted assessment projects are run on corporate devices, the resulting compromise can expand beyond a single\r\nendpoint. The key takeaway is that defenders should treat developer workflows as a primary attack surface and prioritize\r\nvisibility into unusual Node execution, unexpected outbound connections, and follow‑on discovery or upload behavior\r\noriginating from development machines \r\nCyber kill chain model \r\nFigure 12. Attack chain overview.\r\nMitigation and protection guidance  \r\nWhat to do now if you’re affected  \r\nIf a developer endpoint is suspected of running this repository chain, the immediate priority is containment and\r\nscoping. Use endpoint telemetry to identify the initiating process tree, confirm repeated short-interval polling to\r\nsuspicious endpoints, and pivot across the fleet to locate similar activity using Advanced Hunting tables such as\r\nDeviceNetworkEvents or DeviceProcessEvents.\r\nBecause post-execution behavior includes credential and session theft patterns, response should include identity risk\r\ntriage and session remediation in addition to endpoint containment. Microsoft Entra ID Protection provides a\r\nstructured approach to investigate risky sign-ins and risky users and to take remediation actions when compromise is\r\nsuspected. \r\nIf there is concern that stolen sessions or tokens could be used to access SaaS applications, apply controls that reduce\r\ndata movement while the investigation proceeds. Microsoft Defender for Cloud Apps Conditional Access app\r\ncontrol can monitor and control browser sessions in real time, and session policies can restrict high-risk actions to\r\nreduce exfiltration opportunities during containment. \r\nDefending against the threat or attack being discussed  \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 7 of 12\n\nHarden developer workflow trust boundaries. Visual Studio Code Workspace Trust and Restricted Mode are designed\r\nto prevent automatic code execution in untrusted folders by disabling or limiting tasks, debugging, workspace\r\nsettings, and extensions until the workspace is explicitly trusted. Organizations should use these controls as the\r\ndefault posture for repositories acquired from unknown sources and establish policy to review workspace automation\r\nfiles before trust is granted.  \r\nReduce build time and script execution attack surface on Windows endpoints. Attack surface reduction rules in\r\nMicrosoft Defender for Endpoint can constrain risky behaviors frequently abused in this campaign class, such as\r\nrunning obfuscated scripts or launching suspicious scripts that download or run additional content. Microsoft\r\nprovides deployment guidance and a phased approach for planning, testing in audit mode, and enforcing rules at\r\nscale.  \r\nStrengthen prevention on Windows with cloud delivered protection and reputation controls. Microsoft Defender\r\nAntivirus cloud protection provides rapid identification of new and emerging threats using cloud-based intelligence\r\nand is recommended to remain enabled. Microsoft Defender SmartScreen provides reputation-based protection\r\nagainst malicious sites and unsafe downloads and can help reduce exposure to attacker infrastructure and socially\r\nengineered downloads.  \r\nProtect identity and reduce the impact of token theft. Since developer systems often hold access to cloud resources,\r\nenforce strong authentication and conditional access, monitor for risky sign ins, and operationalize investigation\r\nplaybooks when risk is detected. Microsoft Entra ID Protection provides guidance for investigating risky users and\r\nsign ins and integrating results into SIEM workflows.  \r\nControl SaaS access and data exfiltration paths. Microsoft Defender for Cloud Apps Conditional Access app control\r\nsupports access and session policies that can monitor sessions and restrict risky actions in real time, which is valuable\r\nwhen an attacker attempts to use stolen tokens or browser sessions to access cloud apps and move data. These\r\ncontrols can complement endpoint controls by reducing exfiltration opportunities at the cloud application\r\nlayer. [learn.microsoft.com], [learn.microsoft.com] \r\nCentralize monitoring and hunting in Microsoft Sentinel. For organizations using Microsoft Sentinel, hunting queries\r\nand analytics rules can be built around the observable behaviors described in this blog, including\r\nNode.js initiating repeated outbound connections, HTTP based polling to attacker endpoints, and staged upload\r\npatterns. Microsoft provides guidance for creating and publishing hunting queries in Sentinel, which can then be\r\noperationalized into detections.  \r\nOperational best practices for long term resilience. Maintain strict credential hygiene by minimizing secrets stored on\r\ndeveloper endpoints, prefer short lived tokens, and separate production credentials from development workstations.\r\nApply least privilege to developer accounts and build identities, and segment build infrastructure where feasible.\r\nCombine these practices with the controls above to reduce the likelihood that a single malicious repository can\r\nbecome a pathway into source code, secrets, or deployment systems. \r\nMicrosoft Defender XDR detections   \r\nMicrosoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR\r\ncoordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated\r\nprotection against attacks like the threat discussed in this blog.  \r\nCustomers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and\r\nrespond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.  \r\nTactic    Observed activity    Microsoft Defender coverage   \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 8 of 12\n\nInitial access \r\n– Developer receives recruiting-themed\r\n“assessment” repo and interacts with it as a normal\r\nproject \r\n– Activity blends into routine developer\r\nworkflows \r\nMicrosoft Defender for Cloud\r\nApps – anomaly detection alerts\r\nand investigation guidance for\r\nsuspicious activity patterns  \r\nExecution \r\n– VS Code workspace automation triggers\r\nexecution on folder open (for\r\nexample .vscode/tasks.json behavior). \r\n– Dev server run triggers a trojanized asset to\r\nretrieve a remote loader. \r\n– Backend startup/module import triggers\r\nenvironment access plus dynamic execution\r\npatterns. – Obfuscated or dynamically constructed\r\nscript execution (base64 decode and runtime\r\nexecution patterns) \r\nMicrosoft Defender for\r\nEndpoint – Behavioral blocking\r\nand containment alerts based on\r\nsuspicious behaviors and process\r\ntrees (designed for fileless and\r\nliving-off-the-land activity)  \r\nMicrosoft Defender for\r\nEndpoint – Attack surface\r\nreduction rule alerts, including\r\n“Block execution of potentially\r\nobfuscated scripts”   \r\nCommand\r\nand control\r\n(C2) \r\n– Stage 1 registration beacons with host profiling\r\nand durable identifier reuse \r\n– Stage 2 session-based tasking and reporting \r\nMicrosoft Defender for\r\nEndpoint – IP/URL/Domain\r\nindicators (IoCs) for detection\r\nand optional blocking of known\r\nmalicious infrastructure  \r\nDiscovery \u0026\r\nCollection  \r\n– Operator-driven directory browsing and host\r\nprofiling behaviors consistent with interactive\r\nrecon \r\nMicrosoft Defender for\r\nEndpoint – Behavioral blocking\r\nand containment\r\ninvestigation/alerting based on\r\nsuspicious behaviors correlated\r\nacross the device timeline  \r\nCollection  \r\n– Targeted access to developer-relevant artifacts\r\nsuch as environment files and documents \r\n– Follow-on selection of files for collection based\r\non operator tasking \r\nMicrosoft Defender for\r\nEndpoint – sensitivity labels and\r\ninvestigation workflows to\r\nprioritize incidents involving\r\nsensitive data on devices  \r\nExfiltration \r\n– Multi-step upload workflow consistent with\r\nstaged transfers and explicit file targeting  \r\nMicrosoft Defender for Cloud\r\nApps – data protection and file\r\npolicies to monitor and apply\r\ngovernance actions for data\r\nmovement in supported cloud\r\nservices  \r\nMicrosoft Defender XDR threat analytics  \r\nMicrosoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat\r\nIntelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal\r\nto get more information about this threat actor.  \r\nHunting queries   \r\nNode.js fetching remote JavaScript from untrusted PaaS domains (C2 stage 1/2) \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 9 of 12\n\n1\r\n2\r\n3\r\n4\r\nDeviceNetworkEvents\r\n| where InitiatingProcessFileName in~ (\"node\",\"node.exe\")\r\n| where RemoteUrl has_any (\"vercel.app\", \"api-web3-auth\", \"oracle-v1-beta\")\r\n| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl\r\nDetection of next.config.js dynamic loader behavior (readFile → eval) \r\n1\r\n2\r\n3\r\n4\r\n5\r\nDeviceProcessEvents\r\n| where FileName in~ (\"node\",\"node.exe\")\r\n| where ProcessCommandLine has_any (\"next dev\",\"next build\")\r\n| where ProcessCommandLine has_any (\"eval\", \"new Function\", \"readFile\")\r\n| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessCommandLine\r\nRepeated shortinterval beaconing to attacker C2 (/api/errorMessage, /api/handleErrors) \r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\nDeviceNetworkEvents\r\n| where InitiatingProcessFileName in~ (\"node\",\"node.exe\")\r\n| where RemoteUrl has_any (\"/api/errorMessage\", \"/api/handleErrors\")\r\n| summarize BeaconCount = count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp)\r\n by DeviceName, InitiatingProcessCommandLine, RemoteUrl\r\n| where BeaconCount \u003e 10\r\nDetection of detached child Node interpreters (node – from parent Node) \r\n1\r\n2\r\n3\r\n4\r\nDeviceProcessEvents\r\n| where InitiatingProcessFileName in~ (\"node\",\"node.exe\")\r\n| where ProcessCommandLine endswith \"-\"\r\n| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine\r\nDirectory enumeration and exfil behavior\r\n1\r\n2\r\n3\r\nDeviceNetworkEvents\r\n| where RemoteUrl has_any (\"/hsocketNext\", \"/hsocketResult\", \"/upload\", \"/uploadsecond\",\r\n\"/uploadend\")\r\n| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessCommandLine\r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 10 of 12\n\nSuspicious access to sensitive files on developer machines \r\n1\r\n2\r\n3\r\n4\r\n5\r\nDeviceFileEvents\r\n| where Timestamp \u003e ago(14d)\r\n| where FileName has_any (\".env\", \".env.local\", \"Cookies\", \"Login Data\", \"History\")\r\n| where InitiatingProcessFileName in~ (\"node\",\"node.exe\",\"Code.exe\",\"chrome.exe\")\r\n| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessCommandLine\r\nIndicators of compromise  \r\nIndicator   Type   Description  \r\napi-web3-auth[.]vercel[.]app \r\n• oracle-v1-beta[.]vercel[.]app \r\n• monobyte-code[.]vercel[.]app \r\n• ip-checking-notification-kgm[.]vercel[.]app \r\n• vscodesettingtask[.]vercel[.]app \r\n• price-oracle-v2[.]vercel[.]app \r\n• coredeal2[.]vercel[.]app \r\n• ip-check-notification-03[.]vercel[.]app \r\n• ip-check-wh[.]vercel[.]app \r\n• ip-check-notification-rkb[.]vercel[.]app \r\n• ip-check-notification-firebase[.]vercel[.]app \r\n• ip-checking-notification-firebase111[.]vercel[.]app \r\n• ip-check-notification-firebase03[.]vercel[.]app  \r\nDomain \r\nVercelhosted delivery and staging domains\r\nreferenced across examined repositories for l\r\ndelivery, VS Code task staging, buildtime loa\r\nand backend environment exfiltration endpoi\r\n • 87[.]236[.]177[.]9 \r\n• 147[.]124[.]202[.]208 \r\n• 163[.]245[.]194[.]216 \r\n• 66[.]235[.]168[.]136  \r\nIP\r\naddresses  \r\nCommandandcontrol infrastructure observed\r\nStage 1 registration, Stage 2 tasking, discove\r\nstaged exfiltration activity.  \r\n• hxxp[://]api-web3-auth[.]vercel[.]app/api/auth \r\n• hxxps[://]oracle-v1-beta[.]vercel[.]app/api/getMoralisData \r\n• hxxps[://]coredeal2[.]vercel[.]app/api/auth \r\n• hxxps[://]ip-check-notification-03[.]vercel[.]app/api \r\n• hxxps[://]ip-check-wh[.]vercel[.]app/api \r\n• hxxps[://]ip-check-notification-rkb[.]vercel[.]app/api \r\n• hxxps[://]ip-check-notification-firebase[.]vercel[.]app/api \r\n• hxxps[://]ip-checking-notification-firebase111[.]vercel[.]app/api \r\n• hxxps[://]ip-check-notification-firebase03[.]vercel[.]app/api \r\n• hxxps[://]vscodesettingtask[.]vercel[.]app/api/settings/XXXXX \r\n• hxxps[://]price-oracle-v2[.]vercel[.]app \r\n • hxxp[://]87[.]236[.]177[.]9:3000/api/errorMessage \r\n• hxxp[://]87[.]236[.]177[.]9:3000/api/handleErrors \r\n• hxxp[://]87[.]236[.]177[.]9:3000/api/reportErrors \r\n• hxxp[://]147[.]124[.]202[.]208:3000/api/reportErrors \r\n• hxxp[://]87[.]236[.]177[.]9:3000/api/hsocketNext \r\n• hxxp[://]87[.]236[.]177[.]9:3000/api/hsocketResult \r\nURL  Consolidated URLs across delivery/staging,\r\nregistration and tasking, reporting, discovery\r\nstaged uploads. Includes the public IP lookup\r\nduring host profiling. \r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 11 of 12\n\n• hxxp[://]87[.]236[.]177[.]9:3000/upload \r\n• hxxp[://]87[.]236[.]177[.]9:3000/uploadsecond \r\n• hxxp[://]87[.]236[.]177[.]9:3000/uploadend \r\n• hxxps[://]api[.]ipify[.]org/?format=json  \r\n• next[.]config[.]js \r\n• tasks[.]json \r\n• jquery[.]min[.]js \r\n• auth[.]js \r\n• collection[.]js \r\nFilename  \r\nRepository artifacts used as execution entry p\r\nand loader components across IDE, build-tim\r\nbackend execution paths.  \r\n• .vscode/tasks[.]json \r\n• scripts/jquery[.]min[.]js \r\n• public/assets/js/jquery[.]min[.]js \r\n• frontend/next[.]config[.]js \r\n• server/routes/api/auth[.]js \r\n• server/controllers/collection[.]js \r\n• .env  \r\nFilepath  \r\nOn-disk locations observed across examined\r\nrepositories where malicious loaders, executi\r\ntriggers, and environment exfiltration logic r\r\nReferences    \r\nThreat Actors Expand Abuse of Microsoft Visual Studio Code \r\nNorth Korea-Linked Hackers Target Developers via Malicious VS Code Projects \r\nNew DPRK Malware Uses Microsoft VSCode Dictionary Files | OpenSource Malware Blog \r\nThis research is provided by Microsoft Defender Security Research with contributions from Colin Milligan.\r\nLearn more   \r\nReview our documentation to learn more about our real-time protection capabilities and see how to enable them within\r\nyour organization.   \r\nExplore how to build and customize agents with Copilot Studio Agent Builder \r\nMicrosoft 365 Copilot AI security documentation \r\nHow Microsoft discovers and mitigates evolving attacks against AI guardrails \r\nLearn more about securing Copilot Studio agents with Microsoft Defender  \r\nLearn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps |\r\nMicrosoft Learn   \r\nSource: https://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nhttps://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2026/02/24/c2-developer-targeting-campaign/"
	],
	"report_names": [
		"c2-developer-targeting-campaign"
	],
	"threat_actors": [],
	"ts_created_at": 1775434140,
	"ts_updated_at": 1775826778,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8f81bb920cb5d2c963e2f08b5cd1cbdac78ca5ad.pdf",
		"text": "https://archive.orkl.eu/8f81bb920cb5d2c963e2f08b5cd1cbdac78ca5ad.txt",
		"img": "https://archive.orkl.eu/8f81bb920cb5d2c963e2f08b5cd1cbdac78ca5ad.jpg"
	}
}