Nora
Blake

Operation Navy Ghost: Malicious PyPI Packages Backdoor Telegram Bot Servers

Nora Blake

Jul 1, 2026

5 min read

Operation Navy Ghost Malicious PyPI Packages Backdoor Telegram Bot Server

TL; DR

Operation Navy Ghost is a software supply-chain campaign that targeted Python developers building Telegram bots. Attackers published trojanized forks of the legitimate Pyrogram library on the Python Package Index (PyPI), embedding a hidden backdoor capable of executing Python code or shell commands on infected servers after the bot launched. Organizations using the affected packages should remove them, rotate credentials, revoke Telegram bot tokens, and review systems for signs of compromise. The campaign reinforces why dependency security, endpoint visibility, and strong device management practices remain essential for enterprise development environments.

Introduction

A newly disclosed software supply chain campaign has highlighted how a seemingly legitimate Python dependency can provide attackers with remote control over servers running Telegram bots. Dubbed Operation Navy Ghost, the campaign involved malicious PyPI packages masquerading as forks of the popular Pyrogram framework.

Once installed, the modified packages reportedly registered hidden Telegram command handlers capable of executing attacker-supplied Python code or shell commands on infected systems.

Rather than targeting Telegram itself, the attackers abused the trust developers place in public package repositories. The incident shows how third-party dependencies can become an attack vector capable of reaching production infrastructure through routine software development workflows.

Secure Your Endpoints with Hexnode

How the Operation Navy Ghost Attack Worked

The campaign, reportedly active since November 2025, involved at least eight malicious packages uploaded to PyPI as modified versions of the legitimate Pyrogram framework.

The trojanized packages preserved Pyrogram’s expected functionality while introducing additional malicious code inside a helper module named secret.py.

When an affected Telegram bot started, the malware reportedly:

  • Registered hidden Telegram command handlers
  • Accepted commands from attacker-controlled Telegram accounts
  • Executed arbitrary Python code
  • Executed shell commands on the host
  • Returned command output through Telegram
  • Read files accessible to the compromised application
  • Suppressed errors and logging to reduce visibility

Because the malware retained the expected behavior of the legitimate library, developers may not have noticed any operational issues after installation. This combination of normal application functionality and concealed backdoor logic is characteristic of modern software supply-chain attacks, where malicious code is designed to blend into trusted development workflows.

What Is Confirmed and What Remains Unclear

The published analysis confirms that the affected packages contained embedded backdoor functionality capable of providing remote command execution through Telegram-based command handlers.

It also confirms that the campaign specifically targeted developers using Pyrogram-based Telegram applications.

However, several important questions remain unanswered publicly:

  • The campaign has not been attributed to a known named threat group.
  • No victim organizations have been identified.
  • The number of compromised environments has not been disclosed.
  • Public reporting has not confirmed credential theft, data theft from named victim organizations, or follow-on intrusions resulting from the campaign, although the malware reportedly included data exfiltration capabilities.

Although the malware was capable of executing commands and accessing files available to the compromised application, organizations should avoid assuming every installation resulted in a successful compromise without further investigation.

Why Operation Navy Ghost Matters for Enterprises

Although the campaign specifically targeted Python developers building Telegram bots, the broader implications extend well beyond developer workstations.

Production bot applications often operate with access to valuable enterprise resources, including:

  • Environment variables
  • API keys
  • Cloud credentials
  • Internal databases
  • Customer messaging data
  • Business automation workflows

If a compromised application runs with access to these resources, attackers may be able to leverage the application’s existing permissions to expand their access. The privileges granted to the affected service determine the potential impact, and public reporting has not universally confirmed that impact across this campaign.

The incident demonstrates why organizations should treat dependency security as a core component of enterprise security. Malicious packages that preserve expected functionality can evade casual inspection, allowing compromised software to move from development into production unless organizations maintain strong software governance and endpoint visibility.

Recommended Mitigations

Organizations that suspect they may have installed one of the affected packages should prioritize containment and validation.

Recommended actions include:

  • Remove the malicious packages from development and production environments.
  • Revoke and regenerate Telegram bot tokens.
  • Rotate credentials that may have been accessible from affected systems.
  • Review endpoint telemetry and application logs for unexpected Python or shell activity.
  • Validate third-party software dependencies before deployment.
  • Maintain an inventory of packages used across production workloads.
  • Review developer workstations and internal package repositories for cached copies of the affected packages.

These measures can help reduce the likelihood that compromised dependencies remain active after package removal and support a more effective incident response.

How Hexnode Can Help

Responding to software supply-chain incidents requires visibility into affected endpoints, the ability to investigate suspicious activity, and consistent enforcement of endpoint policies.

Hexnode UEM can help organizations strengthen developer endpoint hygiene by:

  • Enforcing operating system update policies
  • Managing approved applications
  • Supporting managed application deployment
  • Applying device compliance policies
  • Restricting unauthorized software where appropriate

If suspicious activity is identified on managed endpoints, Hexnode XDR can support endpoint investigation and response by helping security teams:

  • Review historical endpoint activity
  • Investigate suspicious endpoint behavior using endpoint telemetry
  • Isolate affected devices from the network
  • Terminate suspicious processes as part of incident response

Introduction to Hexnode XDR
Featured resource

Introduction to Hexnode XDR

Learn how Hexnode XDR helps security teams investigate suspicious endpoint activity and respond to threats more effectively.

Download the Presentation

Organizations using Hexnode IdP can further strengthen access controls through multi-factor authentication (MFA), role-based access control (RBAC), Microsoft Entra ID integration, and device compliance checks.

While these capabilities do not prevent software supply-chain attacks, they can improve endpoint visibility, support investigations, and help organizations respond to suspicious activity across managed environments.

Key Takeaways from Operation Navy Ghost

Operation Navy Ghost highlights how software supply-chain attacks can abuse developer dependencies instead of directly targeting enterprise infrastructure.

Organizations building applications on open-source ecosystems should make dependency governance a core security control. They should pair it with endpoint visibility, credential hygiene, and incident response. Organizations should verify third-party packages before deployment. They should also maintain endpoint visibility and respond quickly to suspicious activity. These practices can help reduce the operational impact of compromised dependencies.

While investigators continue to analyze this campaign, organizations should continuously validate software trust throughout the development lifecycle instead of assuming it at installation.

Share

Nora Blake

I write at the intersection of technology, process, and people, focusing on explaining complex products with clarity. I break down tools, systems, and workflows without any noise, jargon, or the hype.