Kaspersky exposes hidden malware on GitHub stealing personal data

Original Article ↗ Hacker News Discussion ↗

Kaspersky, geopolitics, and trust

  • Many argue Kaspersky should be treated as a Russian state actor and thus a threat, with its public research seen partly as PR.
  • Others claim the original bans were driven by geopolitics, especially after Kaspersky exposed NSA “Equation Group” tooling, and note Kaspersky’s moves of infrastructure and code-review centers to Switzerland/EU to signal neutrality.
  • Some insist that regardless of past details, a Russian AV vendor is an unacceptable risk for Western governments in 2025; others counter that all major powers weaponize tech firms.

State actors, surveillance, and double standards

  • Several comments generalize: all serious cybersecurity/AV companies (US, Russian, Chinese, etc.) should be assumed co-optable by their states through secret orders or legal compulsion.
  • Debate over whether US companies (Google, Microsoft, etc.) should also be treated as de facto state actors, especially post‑Snowden and under surveillance laws.
  • Dispute over relative threat levels: some say Russia/China run the “largest attacks in history”; others argue the US-led surveillance apparatus is the most expansive, raising human-rights concerns.
  • Discussion digresses into Ukraine, NATO, and “spheres of influence,” with strongly conflicting narratives about responsibility and motives; consensus is absent.

Jurisdiction-based risk models

  • Some participants choose security tools primarily by jurisdiction, not technical merit, and argue foreign software/hardware is always a potential national-security risk.
  • Others emphasize applying the same standard to all states: if you distrust Russian software because of its government, you should analogously distrust US/5-Eyes vendors.

GitHub malware and open-source trust

  • Multiple commenters note developers routinely git clone && run without inspection, treating GitHub like a safe app store and over-trusting the “open source” label and stars.
  • There is discussion of:
    • Attackers abusing GitHub as a dropper domain, including for game cheats and cracks that bundle credential/cookie stealers.
    • How few stars/forks/issues many malicious repos have, suggesting social signals can help but don’t guarantee safety.
    • Ideas for “risk scores,” endorsement systems, CVE-based reputation, mandatory static analysis, or LLM-based scanning—though feasibility and reliability are questioned.

Sandboxing, OS design, and distributions

  • Several people argue mainstream OSes should enforce stronger sandboxing and permission prompts (per-app directories, explicit access grants) to limit damage from untrusted code.
  • Others point out that optional sandboxes and permission systems exist (on desktop and mobile) but are underused; culture and convenience lead users and developers to bypass them.
  • Some see value in curated distributions (Linux vendors, commercial package ecosystems) that vet and sign software, versus pulling arbitrary GitHub code directly.

Relationship to prior research

  • One commenter links earlier independent research on large-scale GitHub malware campaigns, suggesting overlap in techniques and structures with what Kaspersky reports, though it’s unclear whether this is the same campaign or parallel ones.