← Back to Cybersecurity News Center
Severity
CRITICAL
CVSS
9.5
Priority
0.906
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Threat actor TeamPCP compromised the official Telnyx Python SDK on PyPI, publishing malicious versions 4.87.1 and 4.87.2 that steal SSH keys, cloud credentials, and Kubernetes secrets from any environment that installed them. Any organization using the Telnyx Python SDK in development pipelines, CI/CD systems, or production infrastructure may have had credentials silently exfiltrated. The Telnyx SDK is widely used in the Python developer community, making the potential scope significant, and because the malware conceals its payload inside audio files, standard file-scanning tools likely missed it.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
CRITICAL
Critical severity — immediate action required
Actor Attribution
HIGH
TeamPCP
TTP Sophistication
HIGH
10 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Telnyx Python SDK (PyPI versions 4.87.1 and 4.87.2); Python environments on Linux, macOS, and Windows; Kubernetes clusters
Are You Exposed?
⚠
Your industry is targeted by TeamPCP → Heightened risk
⚠
You use products/services from Telnyx Python SDK (PyPI versions 4.87.1 and 4.87.2); Python environments on Linux → Assess exposure
⚠
10 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Business Context
Any organization whose developers or CI/CD pipelines installed the compromised Telnyx SDK versions may have had cloud access credentials, SSH keys, and Kubernetes secrets silently stolen — giving attackers direct access to production infrastructure, data stores, and cloud accounts. A successful credential theft from a CI/CD environment can escalate quickly to a full cloud account takeover, enabling data exfiltration, ransomware deployment, or persistent access that persists well after the malicious package is removed. Regulatory exposure is real for any organization subject to SOC 2, ISO 27001, or cloud security frameworks, as unauthorized credential access and potential data exfiltration typically trigger breach notification and audit obligations.
You Are Affected If
Your Python environments, CI/CD pipelines, or container images installed telnyx==4.87.1 or telnyx==4.87.2 from PyPI
Cloud provider credentials (AWS, GCP, Azure) or SSH private keys were accessible in environments where the compromised package was imported
Kubernetes clusters were accessible from environments where the compromised package was installed (kubeconfig or service account tokens present)
Developer workstations running Linux, macOS, or Windows that use the Telnyx Python SDK installed the affected versions
You have not yet audited lock files and container image manifests across all repositories for the malicious version strings
Board Talking Points
A trusted software component used by over 740,000 developers monthly was secretly replaced with a version that steals cloud and system passwords — any team that installed it may have handed attackers the keys to our infrastructure.
We are conducting an immediate audit of all systems that may have installed the affected versions and rotating any credentials that could have been exposed — this work should be complete within 24-48 hours.
If we do not act now, attackers who already collected credentials could use them to access cloud environments, steal data, or deploy ransomware, turning a software library issue into a full breach.
FedRAMP / FISMA — Organizations operating under FedRAMP or FISMA authorization are required to implement supply chain risk management under NIST SP 800-161. This incident (compromised third-party PyPI package delivering credential-stealing malware) is a textbook supply chain attack. Affected federal systems or FedRAMP-authorized cloud services must assess whether this constitutes a reportable incident and notify the authorizing official. NIST SP 800-161 is not represented in the current KB control set — reference it separately.
CISA Binding Operational Directive — Federal civilian executive branch (FCEB) agencies using the Telnyx SDK in internet-facing or internal systems should assess whether this incident triggers reporting obligations under applicable CISA directives governing software supply chain security and incident notification.
Technical Analysis
TeamPCP, a supply chain threat actor previously tied to the LiteLLM PyPI compromise, injected malicious code into Telnyx Python SDK versions 4.87.1 and 4.87.2 on PyPI.
The payload is steganographically embedded within WAV audio files (MITRE T1027.003 , Steganography), bypassing signature-based detection that inspects Python source files or binaries directly.
Upon package import, the malware executes automatically (T1059.006 , Python) and harvests: SSH private keys (T1552.004 ), cloud provider authentication tokens for AWS, GCP, and Azure (T1528 , Steal Application Access Token), cryptocurrency wallet data, and Kubernetes cluster secrets (T1613 , Container and Resource Discovery).
Exfiltration occurs over a command-and-control channel (T1041 , Exfiltration Over C2 Channel). Persistence mechanisms consistent with T1543.001 have been observed. The attack targets Linux, macOS, and Windows Python environments, as well as Kubernetes clusters. Relevant CWEs: CWE-506 (Embedded Malicious Code), CWE-494 (Download of Code Without Integrity Check), CWE-522 (Insufficiently Protected Credentials), CWE-312 (Cleartext Storage of Sensitive Information). No CVE has been assigned. Telnyx has confirmed the compromise via official security notice and GitHub issue #235. Safe versions are those predating 4.87.1 or postdating 4.87.2, verify against Telnyx's official advisory before upgrading. Technical claims are corroborated across T1 and T2 sources: SANS ISC Diary (T1), Telnyx official notice (vendor-official), GitHub issue (official repository), and security publications including BleepingComputer and OX Security.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to CISO, legal counsel, and external IR retainer if CloudTrail, GCP Audit Logs, or Kubernetes audit logs confirm any API calls, resource access, or cluster activity using credentials that were present in an environment where telnyx 4.87.1 or 4.87.2 was installed — confirmed credential use post-compromise triggers breach notification assessment under applicable regulations (GDPR Article 33, US state breach notification statutes, HIPAA §164.412 if PHI was accessible to the compromised environment).
1
Step 1: Containment — Identify every environment, CI/CD pipeline, container image, and developer workstation where telnyx==4.87.1 or telnyx==4.87.2 was installed. Run 'pip show telnyx' or 'pip list' across all Python environments. Cross-reference results against your software inventory to confirm scope. Isolate affected systems from the network immediately. (Cite: CIS 2.1 — Establish and Maintain a Software Inventory / CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / D3-ODM — Operational Dependency Mapping)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST CM-7 (Least Functionality)
CIS 1.1 (Establish and Maintain Detailed Enterprise Asset Inventory)
CIS 2.1 (Establish and Maintain a Software Inventory)
Compensating Control
Run the following one-liner across all reachable hosts via Ansible, SSH loop, or manual execution: `python3 -c "import pkg_resources; v=pkg_resources.get_distribution('telnyx').version; print(f'{v}') if v in ['4.87.1','4.87.2'] else None" 2>/dev/null`. For container images, enumerate with `docker images --format '{{.Repository}}:{{.Tag}}'` and inspect each with `docker run --rm <image> pip show telnyx`. For Kubernetes, use `kubectl get pods -A -o json | jq '.items[].spec.containers[].image'` to enumerate all running images, then `docker inspect` or `crane config` to check installed packages. A 2-person team can script this as a parallel SSH job using `pssh` or `pdsh` against the full host inventory.
Preserve Evidence
Before isolating, capture a full snapshot of the affected Python environment: `pip freeze > /tmp/pip_freeze_$(hostname)_$(date +%s).txt`. Capture running process tree (`ps auxf` on Linux/macOS, `Get-Process` on Windows) to document any Python processes active at time of discovery — TeamPCP's payload executes at import time, so a running Python process importing telnyx may indicate live exfiltration in progress. Preserve `/proc/<pid>/net/tcp` and `/proc/<pid>/net/tcp6` on Linux for any Python PIDs to capture open socket state before network isolation. On Kubernetes, capture `kubectl describe pod <pod>` and `kubectl get events` output before terminating pods.
2
Step 2: Detection — Search package manager logs, CI/CD build logs, and container image manifests for 'telnyx==4.87.1' or 'telnyx==4.87.2'. Inspect requirements.txt, pyproject.toml, Pipfile.lock, and Poetry lock files across all repositories. Audit build pipeline logs using AU-2 event logging to identify when and where the malicious package was installed. Query SIEM for DNS lookups or HTTP connections from Python interpreter processes to unknown external hosts at import time. Look for WAV files under site-packages/telnyx — their presence is a strong indicator of compromise; apply D3-FMBV file magic byte verification to confirm file type mismatches. Monitor for unauthorized reads of ~/.ssh/, ~/.aws/credentials, ~/.config/gcloud/, ~/.azure/, and kubeconfig paths using D3-SFA system file analysis. (Cite: NIST AU-2 — Event Logging / NIST AU-6 — Audit Record Review, Analysis, And Reporting / CIS 8.2 — Collect Audit Logs / D3-SFA — System File Analysis / D3-FMBV — File Magic Byte Verification)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST SI-4 (System Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-12 (Audit Record Generation)
CIS 8.2 (Collect Audit Logs)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
For WAV-based steganographic payload discovery, locate the telnyx site-packages directory with `python3 -c "import telnyx; import os; print(os.path.dirname(telnyx.__file__))"` then run `find <path> -name '*.wav' -o -name '*.png' -o -name '*.jpg'` — presence of any binary media files in a pure-Python SDK package directory is anomalous and warrants immediate analysis. Extract and inspect with `strings <file.wav>` or `binwalk <file.wav>` (install via `apt install binwalk`) to reveal embedded payloads. For network detection without a SIEM, enable Sysmon (Windows) with EventID 3 (Network Connection) filtered on `python.exe` or `python3` as the initiating process, or use `auditd` on Linux with a rule: `-a always,exit -F arch=b64 -S connect -F exe=/usr/bin/python3 -k telnyx_net`. On macOS, use `sudo fs_usage python3 | grep -E 'connect|send'`. For CI/CD log grep: `grep -rE 'telnyx==(4\.87\.1|4\.87\.2)' --include='*.txt' --include='*.toml' --include='*.lock' .` across all cloned repos.
Preserve Evidence
Preserve the intact malicious package directory at `$(python3 -c 'import site; print(site.getsitepackages()[0])')/telnyx/` as a forensic image before uninstalling — this is the primary artifact containing the steganographic WAV file and obfuscated loader code. Capture a hash of all files: `find <telnyx_path> -type f -exec sha256sum {} \; > telnyx_package_hashes.txt`. Extract outbound network connection history from: `/var/log/syslog` or `journalctl -u <service>` for Linux daemons running the SDK, GitHub Actions/GitLab CI job logs for any `pip install` steps, and AWS CloudTrail `CreateNetworkInterface` or `RunInstances` events if the package executed in Lambda or EC2. On Kubernetes, collect `kubectl logs <pod> --previous` for any pods that ran the affected image.
3
Step 3: Eradication — Uninstall the malicious package immediately: 'pip uninstall telnyx'. Do not upgrade in place — consult Telnyx's official security advisory to confirm the safe version hash before reinstalling. Rebuild all container images that included affected versions from a verified clean base. Rotate all credentials that were accessible in affected environments: SSH private keys, AWS/GCP/Azure IAM tokens, Kubernetes service account tokens and kubeconfig files, and cryptocurrency wallet keys. Apply D3-CRO credential rotation to all exposed secrets. Restrict access to credential paths using AC-6 least privilege so only authorized processes can read SSH and cloud credential files going forward. (Cite: NIST AC-6 — Least Privilege / CIS 5.1 — Establish and Maintain an Inventory of Accounts / CIS 6.2 — Establish an Access Revoking Process / D3-CRO — Credential Rotation / D3-CH — Credential Hardening)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST SI-2 (Flaw Remediation)
NIST IA-5 (Authenticator Management)
NIST CM-2 (Baseline Configuration)
CIS 7.3 (Perform Automated Operating System Patch Management)
CIS 7.4 (Perform Automated Application Patch Management)
CIS 5.2 (Use Unique Passwords)
Compensating Control
After uninstalling, verify removal and re-install a known-good version with hash verification: `pip uninstall -y telnyx && pip install telnyx==<safe_version> --require-hashes --hash=sha256:<hash_from_telnyx_advisory>`. Obtain the correct hash from Telnyx's official advisory or by cross-referencing PyPI's JSON API: `curl -s https://pypi.org/pypi/telnyx/<safe_version>/json | python3 -m json.tool | grep sha256`. For SSH key rotation on Linux: `find ~/.ssh /home/*/.ssh /root/.ssh -name 'id_*' -not -name '*.pub' 2>/dev/null` to enumerate all private keys that were accessible in the compromised environment. For AWS, enumerate exposed keys with `aws iam list-access-keys --user-name <user>` and rotate via `aws iam create-access-key` followed by `aws iam delete-access-key`. For Kubernetes, rotate service account tokens: `kubectl delete secret <sa-token-secret> -n <namespace>` to force regeneration. Document every rotated credential with timestamp for audit trail.
Preserve Evidence
Before uninstalling, forensically preserve the malicious package: `cp -r $(python3 -c 'import site; print(site.getsitepackages()[0])')/telnyx /tmp/forensic_telnyx_$(date +%s)` and generate a manifest: `find /tmp/forensic_telnyx_* -type f -exec sha256sum {} \;`. Capture the pip install log that originally pulled the malicious version from `~/.pip/pip.log` or `$(pip config get global.log)` if configured. Preserve any `.pyc` compiled cache files under `__pycache__` within the telnyx package directory — these may contain deobfuscated bytecode of the steganographic loader recoverable via `uncompyle6` or `decompile3`. On CI/CD systems (GitHub Actions, Jenkins, GitLab CI), download and archive the full build log artifact for the job that performed the `pip install telnyx` step before log retention expires.
4
Step 4: Recovery — After credential rotation, audit cloud provider access logs (AWS CloudTrail, GCP Audit Logs, Azure Monitor) and Kubernetes audit logs for unauthorized API calls or resource access that occurred post-compromise. Use AU-6 audit record review to correlate log timestamps against the known installation window of the malicious versions. Verify that CI/CD pipelines were rebuilt from clean images. Confirm the reinstalled telnyx package hash matches Telnyx's advisory-published known-good value before returning systems to production. Enforce MFA on all administrative and cloud provider accounts to reduce re-exploitation risk. (Cite: NIST AU-6 — Audit Record Review, Analysis, And Reporting / NIST AU-11 — Audit Record Retention / NIST AU-3 — Content Of Audit Records / CIS 6.3 — Require MFA for Externally-Exposed Applications / CIS 6.5 — Require MFA for Administrative Access / D3-MFA — Multi-factor Authentication)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-11 (Audit Record Retention)
NIST CP-10 (System Recovery and Reconstitution)
CIS 8.2 (Collect Audit Logs)
Compensating Control
For AWS CloudTrail analysis without a SIEM, use CloudTrail Lake or the following CLI query scoped to the compromise window: `aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=<rotated_iam_user> --start-time <install_date> --end-time <rotation_date>`. Focus on `AssumeRole`, `GetSecretValue`, `DescribeInstances`, `CreateUser`, and `PutBucketPolicy` event names — these represent post-compromise lateral movement and persistence actions TeamPCP's stolen credentials would enable. For Kubernetes audit log review without a SIEM, use: `kubectl get events -A --field-selector reason=Forbidden` and parse the API server audit log at `/var/log/kubernetes/audit.log` with `jq` filtering on `verb: ["create","delete","patch"]` and `user.username` values that do not match known service accounts. For package hash verification: `pip show telnyx | grep -i location` then `sha256sum $(pip show telnyx | grep Location | awk '{print $2}')/telnyx-*.dist-info/RECORD`.
Preserve Evidence
Collect and preserve cloud provider audit logs covering the full window from the PyPI publication date of 4.87.1 through credential rotation completion — this is the definitive exfiltration and unauthorized access window for this TeamPCP campaign. For AWS: export CloudTrail logs from S3 to local storage with `aws s3 sync s3://<cloudtrail-bucket>/<prefix>/<account-id>/CloudTrail/ ./cloudtrail_forensic/`. For Kubernetes: export audit logs from the API server and any managed Kubernetes audit logging service (e.g., GKE Audit Logs, EKS CloudTrail integration). Preserve the `~/.kube/config` file from any affected developer workstation as evidence of which clusters were accessible to the stolen kubeconfig — TeamPCP's credential theft specifically targeted kubeconfig files, and the cluster endpoints listed there define the full blast radius.
5
Step 5: Post-Incident — Enforce hash-pinning or digest-pinning for all PyPI dependencies in requirements files and lock files; add version integrity checks to CI/CD pipelines per CIS 4.6. Implement a private package mirror or artifact proxy (e.g., Artifactory, AWS CodeArtifact) with allowlisting to control which external packages enter your build environment — this is a supply chain control gap aligned with CIS 2.3. Add automated scanning for non-source file types (WAV, audio) embedded in Python packages using D3-FMBV and D3-SFA. Apply D3-SICA to analyze package init and import configurations for unauthorized startup code. Establish or update your vulnerability management process per CIS 7.1 to include PyPI supply chain monitoring. Brief the development team on TeamPCP's pattern of targeting widely used Python SDKs. Note: NIST SP 800-161 (Supply Chain Risk Management) is directly applicable to this incident but is not represented in the current KB control set — organizations subject to federal requirements should reference 800-161 separately. (Cite: CIS 2.3 — Address Unauthorized Software / CIS 4.6 — Securely Manage Enterprise Assets and Software / CIS 7.1 — Establish and Maintain a Vulnerability Management Process / CIS 7.2 — Establish and Maintain a Remediation Process / D3-FMBV — File Magic Byte Verification / D3-SFA — System File Analysis / D3-SICA — System Init Config Analysis)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST SI-2 (Flaw Remediation)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST SA-12 (Supply Chain Protection)
NIST IR-8 (Incident Response Plan)
CIS 2.1 (Establish and Maintain a Software Inventory)
CIS 2.2 (Ensure Authorized Software is Currently Supported)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Implement pip hash-pinning immediately using `pip-compile --generate-hashes` from the `pip-tools` package to regenerate all `requirements.txt` files with per-package SHA-256 digests — this is free and directly mitigates the mechanism TeamPCP used (unsigned PyPI package replacement). For steganographic payload detection in CI/CD pipelines without commercial tooling, write a YARA rule targeting binary media file types (WAV, PNG, JPEG) present in installed Python package directories and run it as a pipeline step: `yara -r media_in_packages.yar $(python3 -c 'import site; print(site.getsitepackages()[0])')`. Use `truffleHog` (free, open source) to scan all repositories and CI/CD environment variables for newly committed secrets that may have been exfiltrated and reused by TeamPCP. Add an `osquery` scheduled query to all developer workstations: `SELECT name, version, location FROM python_packages WHERE name='telnyx'` with alerting on version values matching 4.87.1 or 4.87.2. For the development team brief, reference TeamPCP's confirmed prior campaigns targeting PyPI-distributed Python SDKs to establish the pattern of targeting transitive dependencies in developer toolchains.
Preserve Evidence
Produce a post-incident artifact package containing: (1) the forensically preserved malicious telnyx package directory with all file hashes, (2) the full timeline of installation events across all affected environments reconstructed from pip logs and CI/CD build logs, (3) the complete list of credentials confirmed in-scope for rotation with rotation timestamps, and (4) cloud provider audit log exports covering the compromise window. This package supports both internal lessons-learned and any required regulatory breach notification documentation. Preserve all evidence for a minimum of 12 months per NIST AU-11 (Audit Record Retention) requirements, or longer if regulatory obligations (SOC 2, PCI-DSS, HIPAA) apply to the affected environments.
Recovery Guidance
After credential rotation and pipeline rebuild, maintain enhanced monitoring of all cloud provider accounts and Kubernetes clusters for a minimum of 30 days — TeamPCP's operational pattern of targeting developer environments and CI/CD pipelines means stolen credentials may be staged for delayed use rather than immediate exploitation. Verify integrity of any infrastructure-as-code (Terraform, Pulumi, Helm charts) stored in repositories accessible from compromised developer workstations, as these may have been exfiltrated and could be used to reconstruct environment topology for follow-on attacks. Confirm that all reinstalled telnyx package hashes are pinned in requirements files and that CI/CD pipeline jobs fail hard on hash mismatch before returning any affected pipeline to active use.
Key Forensic Artifacts
Malicious telnyx package directory at $(python3 -c 'import site; print(site.getsitepackages()[0])')/telnyx/ — contains the steganographic WAV file(s) embedding the credential-stealing payload; must be preserved before uninstall as it is the primary malware artifact for this TeamPCP campaign
pip install logs and CI/CD build logs containing 'telnyx==4.87.1' or 'telnyx==4.87.2' install events — establish the precise timestamp and environment scope of initial compromise, required to bound the credential exfiltration window
Outbound network connection records from Python interpreter processes (auditd SYSCALL connect records on Linux, Sysmon EventID 3 on Windows, macOS unified log network events) capturing the C2 or exfiltration endpoint contacted by the steganographic payload at import time
Cloud provider credential usage logs (AWS CloudTrail, GCP Audit Logs, Azure Monitor Activity Log) scoped from telnyx install timestamp through credential rotation — documents whether TeamPCP operationalized any stolen AWS/GCP/Azure tokens before rotation
Kubernetes API server audit log and kubeconfig files from affected developer workstations — establishes which cluster endpoints and namespaces were accessible via stolen kubeconfig credentials, defining the full Kubernetes blast radius of this TeamPCP intrusion
Detection Guidance
Primary detection — Query all Python environment package lists for telnyx==4.87.1 or telnyx==4.87.2 using 'pip list --format=freeze | grep telnyx'.
Scan lock files (requirements.txt, Pipfile.lock, poetry.lock, pip-compile output) across all repositories for these pinned versions.
Search CI/CD build logs for installation of either version.
This inventory sweep is grounded in CIS 2.1 (Establish and Maintain a Software Inventory) and CIS 8.2 (Collect Audit Logs), which require logging to be enabled across enterprise assets so these build-time events are recoverable. File-based detection — Inspect the telnyx package directory under site-packages for WAV or audio files. Legitimate SDK packages do not contain audio files. Apply D3-FMBV (File Magic Byte Verification) to confirm actual file type against declared extension — the steganographic payload (MITRE T1027.003 ) may use audio file headers to evade extension-based checks. Use D3-SFA (System File Analysis) to continuously monitor package directories for unexpected file additions or modifications. Behavioral detection — Alert on unauthorized reads of ~/.ssh/ directories, cloud credential files (~/.aws/credentials, ~/.config/gcloud/, ~/.azure/), and kubeconfig files by Python interpreter processes. D3-SFA covers this monitoring pattern directly. Map these file access events to AU-2 (Event Logging) — confirm that file access auditing is enabled for credential paths on all systems where Python runs. Network-based detection — Alert on outbound connections from Python interpreter processes (python, python3) to external IP addresses not associated with Telnyx's legitimate API endpoints, particularly at application import time rather than during active API calls (MITRE T1041 — Exfiltration Over C2 Channel). Route outbound Python process traffic through a proxy covered by D3-PBWSAM (Proxy-based Web Server Access Mediation) or enforce endpoint-level controls per D3-EBWSAM (Endpoint-based Web Server Access Mediation) to detect and block unauthorized exfiltration destinations. Corroborate network indicators with AU-6 (Audit Record Review, Analysis, And Reporting) by reviewing SIEM logs for DNS lookups and HTTP connections originating from Python processes during the affected installation window. Use AU-3 (Content Of Audit Records) to verify that log records capture process name, user context, destination IP, and timestamp — records missing these fields cannot support attribution. Account-level detection — After credential rotation, use D3-LAM (Local Account Monitoring) to detect unauthorized local account activity that may indicate the attacker established persistence (MITRE T1543.001 ) before the malicious package was removed. Review AC-2 (Account Management) records to identify any accounts created or modified in affected environments during the compromise window. Kubernetes-specific — Review Kubernetes audit logs for unauthorized API calls, pod creation, or secret access (MITRE T1613 , T1610 ). Correlate Kubernetes service account token usage against the known compromise window using AU-11 (Audit Record Retention) — ensure retention policy covers sufficient lookback to reconstruct the full incident timeline.
Indicators of Compromise (4)
Export as
Splunk SPL
KQL
Elastic
Copy All (4)
2 hashs
2 urls
Type Value Enrichment Context Conf.
# HASH
telnyx==4.87.1 (PyPI)
VT
MB
Malicious PyPI package version — treat any installation as compromised; obtain specific file hashes from Telnyx's official security notice and OX Security blog
HIGH
# HASH
telnyx==4.87.2 (PyPI)
VT
MB
Malicious PyPI package version — treat any installation as compromised; obtain specific file hashes from Telnyx's official security notice and OX Security blog
HIGH
🔗 URL
https://github.com/team-telnyx/telnyx-python/issues/235
VT
US
Telnyx GitHub issue confirming compromise — review for any additional IOCs published by the community
HIGH
🔗 URL
https://isc.sans.edu/diary/32838
VT
US
SANS ISC Diary entry 32838 — TeamPCP Supply Chain Campaign Update 002; may contain network IOCs not included in this item
HIGH
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
IOC Detection Queries (2)
1 URL indicator(s).
KQL Query Preview
Read-only — detection query only
// Threat: TeamPCP Supply Chain Attack: Malicious Telnyx PyPI SDK Versions Deliver Steganog
let malicious_urls = dynamic(["https://isc.sans.edu/diary/32838"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (malicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Malicious URLs hosted on legitimate platforms. The domain is safe — the specific URL path is the indicator.
KQL Query Preview
Read-only — detection query only
// Threat: TeamPCP Supply Chain Attack: Malicious Telnyx PyPI SDK Versions Deliver Steganog
// Specific malicious URLs on shared platforms
let suspicious_urls = dynamic(["https://github.com/team-telnyx/telnyx-python/issues/235"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (suspicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (2)
Sentinel rule: Suspicious PowerShell command line
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-nop", "bypass", "hidden", "downloadstring", "invoke-expression", "iex", "frombase64", "new-object net.webclient")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
Sentinel rule: Encoded command execution
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine matches regex @"[A-Za-z0-9+/]{50,}={0,2}"
or ProcessCommandLine has_any ("-enc ", "-encodedcommand", "frombase64string", "certutil -decode")
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "certutil.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName
| sort by Timestamp desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1195.002
T1041
T1543.001
T1552.001
T1528
T1610
+4
CM-7
SA-9
SR-3
SI-7
CA-7
SC-7
+4
A04:2021
A07:2021
A08:2021
164.308(a)(5)(ii)(D)
164.312(d)
MITRE ATT&CK Mapping
T1195.002
Compromise Software Supply Chain
initial-access
T1041
Exfiltration Over C2 Channel
exfiltration
T1552.001
Credentials In Files
credential-access
T1528
Steal Application Access Token
credential-access
T1610
Deploy Container
defense-evasion
T1613
Container and Resource Discovery
discovery
Guidance Disclaimer
