GitHub projects: prove the boundary between opening and execution
A code project can carry instructions outside the files a team usually reviews. This analysis of Doctor Web’s research proposes evidence separating acquisition, opening and authorized execution.
Czytaj po portugalskuBy Pentesty
The research describes different activation paths
In research published on November 5, Doctor Web described malicious GitHub projects targeting cryptocurrency users and security professionals. Its analysis found content in Visual Studio project .suo and .csproj files, alongside Python and Go code with instructions concealed among whitespace. The account identifies a PreBuildEvent routine that executed code before compilation and PowerShell content in .suo files.
These findings do not establish that cloning any repository or opening any solution executes the same chain. Activation depends on the project, the action taken and the IDE behavior or configuration in use. Doctor Web also describes an Electron loader with remote access, wallet address substitution and data theft capabilities. These are findings attributed to the vendor, not a new universal GitHub vulnerability.
Define what each stage may do
Before accepting an external project, separate acquiring files, inspecting content, opening it in the IDE, restoring dependencies, building and debugging. For each stage, record who authorizes additional processes, network access and credential use. A trust choice in the interface needs to correspond to a known policy rather than implicitly authorize every future task.
Include configuration files, build tasks and actions offered by extensions in the review scope. Record the source and exact revision received, together with the IDE version and policies applied. This makes it possible to discuss an observed sequence without attributing one configuration’s behavior to every developer.
Build harmless evidence for each transition
On an isolated laboratory machine, use a project created by your own team, containing no code from the malicious samples. A benign task can simply produce an agreed local marker. Compare inspection, opening and building under the approved configurations. Record whether the marker appeared, which process produced it and which preceding action was observed, without treating similar timestamps as sufficient proof.
Define permitted and denied cases before testing. Evidence should connect the project revision, synthetic identity, trust configuration, task and process started. If a stage requests consent, retain the decision and its actual effect. A screen without a warning does not prove execution was absent; the conclusion needs to account for available records and state any gaps.
Investigate changes beyond the downloaded file
If execution is suspected, stop using the workstation according to the response plan and preserve evidence before making further changes. Doctor Web’s research describes interference with protections and recovery mechanisms. Assessment should therefore compare machine policies, access and state with a trusted reference, without concluding that removing the project ended the incident.
Inventory credentials that could have been available during the investigated interval and assign owners for containment and recovery. Distinguish possible access, observed reading and proven use. Our Claude Code permission and file analysis complements the review of local secret copies without replacing investigation of processes and sessions.
Accept the workflow with a verifiable boundary
Approval should identify which operations an external project may execute, what authority it receives and who decides exceptions. Retain benign cases, results, versions and gaps so the assessment can be repeated after IDE, extension or policy changes. The goal is to make the transition from reading to execution demonstrable in the organization’s environment, with defined scope and evidence another owner can review.
Include an exception case in that approval: a specialist temporarily authorized to build an external tool. Record which identity grants the permission, when it expires and whether a later project revision must return for review before the task can run again.
Frequently asked questions
Does cloning a repository prove the malware executed?
No. The activation action and observed processes need to be identified. The research describes particular projects and paths, not universal execution on every clone.
Are .suo and .csproj files always malicious?
No. The account found malicious content in specific projects. Assessment should consider origin, content, tasks and behavior under the configuration being examined.
Does the laboratory need to use the reported samples?
No. The proposed tests use your own project with harmless markers and synthetic identities, without reproducing the malicious chain.
Does deleting the repository complete recovery?
That does not establish the state of the workstation, sessions or policies. The decision depends on what executed, the authority available and recovery evidence.
Sources and references
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.