Trusted Updates Turned Weaponized: Snap Store Publisher Hijacking Leads to Silent Crypto Theft on Linux

Aegiron 9 mins0

Executive Summary

This incident describes a supply-chain attack targeting Linux users through the Snap application ecosystem operated by Canonical. Attackers hijacked legitimate Snap Store publisher accounts by taking control of expired domains and email infrastructure previously owned by trusted developers. Using that access, they pushed malicious updates to existing Snap packages, primarily targeting cryptocurrency wallet users.

No software vulnerability, exploit, or malware dropper was required. The attack relied entirely on trust abuse, account takeover, and legitimate update mechanisms. Once installed, the malicious applications harvested cryptocurrency wallet recovery phrases, resulting in irreversible financial theft.

What Happened

Trusted Snap Store applications, some of which had been legitimate for years, were silently transformed into malware through official updates. Users received these updates automatically or manually, with no warnings, because the updates were cryptographically signed and distributed through the official Snap Store.

The compromise did not involve breaching Snap Store infrastructure. Instead, attackers waited for developers to abandon projects and allow their domains to expire. Once those domains were reclaimed by attackers, they were used to reset publisher credentials and fully take over Snapcraft developer accounts.

How the Attack Happened (Full Kill Chain)

1. Abandoned Developer Assets

Several Snap Store publishers:

  • Became inactive
  • Stopped maintaining their applications
  • Failed to renew domain registrations
  • Continued to have Snapcraft accounts tied to email addresses on those domains

Although development ceased, the applications remained live and installable.

2. Domain Takeover – Initial Access Vector

When the domains expired:

  • Attackers registered the same domains
  • Configured DNS and mail servers
  • Gained control of all email sent to those domains

This granted attackers the ability to impersonate the original developers.

This was the initial access vector.

3. Snapcraft Account Takeover

With email access, attackers:

  • Triggered password resets on Snapcraft accounts
  • Received recovery and verification emails
  • Took full control of publisher identities

There was no additional identity verification or domain ownership validation to prevent this.

This was not an exploited vulnerability, but a weakness in account lifecycle and recovery design.

4. Malicious Update Deployment

After account takeover:

  • Attackers uploaded new versions of existing Snap packages
  • Version numbers appeared normal
  • Package names and publishers remained unchanged
  • No suspicious permissions were introduced

Because these were updates, not new packages:

  • Users trusted them
  • Auto-updates installed them silently on many systems

5. Payload Execution and Behavior

The malicious Snap applications were designed to harvest cryptocurrency credentials, not to disrupt systems.

Once executed, the malware:

  1. Presented a legitimate-looking wallet interface
  2. Prompted users to:
    • Restore a wallet
    • Re-enter recovery phrases
    • Verify seed phrases after an update
  3. Captured:
    • Wallet seed phrases (12 or 24 words)
    • Wallet metadata
    • Host and OS information
  4. Exfiltrated the data to attacker-controlled servers over HTTPS

The malware avoided aggressive behavior to remain undetected.

Payload Details

Malware Type

  • Cryptocurrency credential harvester
  • Seed phrase stealer
  • User-input exfiltration malware

Execution Context

  • Runs inside Snap sandbox
  • No sandbox escape
  • No kernel interaction
  • No privilege escalation

Data Targeted

  • Wallet recovery phrases
  • Wallet identifiers
  • Hostname and OS version
  • Locale and timestamps

Exfiltration Method

  • HTTPS POST requests
  • Domains controlled by attackers
  • Delayed transmission to avoid detection

Impacted Systems and Scope

Platforms Affected

  • Linux desktop systems
  • Systems using Snap packages
  • Systems with automatic updates enabled

Users Affected

  • Cryptocurrency wallet users
  • Users trusting long-standing Snap applications
  • Primarily individual desktop users

Impact Severity

  • Complete loss of cryptocurrency funds
  • No recovery possible once seed phrases are stolen
  • Financial impact only, not system destruction

What Was Not Exploited

  • No Linux kernel vulnerability
  • No Snap sandbox escape
  • No cryptographic failure
  • No privilege escalation
  • No malware loader or exploit chain

This attack succeeded purely by abusing trust and identity.

Root Cause Analysis

The breach occurred due to a combination of:

  • Expired developer domains
  • Email-based account recovery
  • Long-lived publisher trust
  • Lack of dormant account review
  • Automatic update mechanisms

Each factor alone is common. Combined, they enabled a full supply-chain compromise.

Indicators of Compromise (IOCs)

Confirmed Malicious / Hijacked Domains

These domains were taken over after expiration and used in the attack:

storewise[.]tech
vagueentertainment[.]com

DNS / Network IOCs

*.storewise[.]tech
*.vagueentertainment[.]com

Any DNS resolution or outbound traffic to these domains should be treated as malicious.

Behavioral Host IOCs

  • Wallet applications requesting seed phrases unexpectedly
  • Wallets asking for recovery phrases after updates
  • Snap applications making outbound HTTPS connections to non-wallet domains
  • Updates originating from publishers with newly registered domains

Detection Rules

Network Detection (Suricata Example)

alert http any any -> any any (
    msg:"Snap Store Hijack – Crypto Wallet Exfiltration";
    http.host; content:"storewise.tech"; nocase;
    sid:900001; rev:1;
)

alert http any any -> any any (
    msg:"Snap Store Hijack – Crypto Wallet Exfiltration";
    http.host; content:"vagueentertainment.com"; nocase;
    sid:900002; rev:1;
)

SIEM – DNS Monitoring Rule

Trigger alerts for any DNS queries to known hijacked domains:

query IN ("storewise.tech", "vagueentertainment.com")

SIEM – Suspicious Snap Update Rule

Flag Snap updates when:

  • Publisher email domain is newly registered
  • Publisher domain age is less than 90 days
  • Domain ownership recently changed

EDR Behavioral Detection

Alert when a Snap process:

  • Captures user input
  • Immediately initiates outbound HTTPS traffic
  • Communicates with domains unrelated to the official application vendor

Anti-Malware Considerations

Traditional antivirus solutions failed because:

  • No known signatures existed
  • Packages were legitimately signed
  • No exploit behavior occurred

Effective detection relies on:

  • Behavioral analysis
  • Domain reputation checks
  • Network traffic monitoring
  • Application integrity validation

Why This Attack Is Dangerous

  • Uses trusted infrastructure
  • Requires no user mistake beyond normal usage
  • Scales silently
  • Causes irreversible damage
  • Bypasses traditional security controls

This attack demonstrates that application store trust is not permanent and decays when accounts and infrastructure are abandoned.

Final Takeaway

This incident represents a modern supply-chain attack where attackers did not break security controls but waited for them to weaken over time.

The attackers exploited:

  • Human neglect
  • Infrastructure abandonment
  • Automated trust

Once triggered, the impact was immediate and permanent for victims.

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.