Recently active topics

name: Axios Supply Chain Node Spawning curl Download of Python Script to tmp Analyticcategory: 'Execution'threatname: 'Command and Scripting Interpreter: Python'functionality: 'Endpoint Management Systems'description: |  Detects Node.js or npm processes spawning a shell that uses curl to download a Python  script to /tmp and execute it via nohup, consistent with the Linux payload delivery in  the axios supply chain compromise. The malicious setup.js dropper from plain-crypto-js@4.2.1  executes a single shell command: curl downloads the Python RAT (/tmp/ld.py) from the C2  (sfrclak[.]com:8000/6202033) and nohup executes it in the background. The Python RAT  uses only standard library modules, beacons every 60 seconds, supports arbitrary command  execution and binary injection to /tmp/.<hidden>, and reads system data from /proc/ and  /sys/class/dmi/id/. Notably, it does NOT establish persistence — a reboot clears it —  suggesting the attacker's primary targets on Linux are ephemera

name: Axios Supply Chain Anomalous IE8 User Agent with npm Registry POST Body Mimicry Analyticcategory: 'Command and Control'threatname: 'Application Layer Protocol: Web Protocols'functionality: 'Web Proxy'description: |  Detects the C2 beacon pattern used across all three platform variants (macOS, Windows, Linux)  of the axios supply chain RAT. All variants share an identical and highly anomalous User-Agent  string mimicking Internet Explorer 8 on Windows XP (mozilla/4.0 compatible; msie 8.0;  windows nt 5.1; trident/4.0) — a combination effectively extinct in 2026. POST request bodies  are designed to blend with npm registry traffic by prefixing packages.npm.org/product0|1|2,  however npm.org is not the npm registry; it belongs to the National Pastoral Musicians  organization. The C2 endpoint sfrclak[.]com listens on port 8000 (non-standard) and routes  platform-specific payloads based on the product suffix. The 60-second beacon interval and  Base64-encoded JSON body structure are co

name: Axios Supply Chain Renamed PowerShell Executing from ProgramData Analyticcategory: 'Defense Evasion'threatname: 'Masquerading: Rename System Utilities'functionality: 'Endpoint Management Systems'description: |  Detects a Windows Terminal process name (wt.exe) executing from %PROGRAMDATA% with  PowerShell-style arguments, consistent with the axios supply chain RAT delivery chain.  The malicious VBScript dropper copies powershell.exe to C:\ProgramData\wt.exe before  executing the stage-2 RAT. wt.exe is the legitimate filename for Windows Terminal  (WindowsTerminal.exe), making this an intentional naming collision to bypass  process-name-based EDR heuristics. The renamed binary is invoked with -w hidden and  -ep bypass to suppress the window and circumvent execution policy. PowerShell executing  from ProgramData is anomalous under any circumstances; PowerShell masquerading as  Windows Terminal is a strong indicator of compromise.reference:  - https://www.huntress.com/blog/supply-cha

name: Axios Supply Chain - npm Lifecycle Hook Spawning VBScript Dropper Analyticcategory: 'Execution'threatname: 'Command and Scripting Interpreter: Visual Basic'functionality: 'Endpoint Management Systems'description: |  Detects npm or Node.js processes spawning cscript.exe or wscript.exe to execute a  VBScript file from a temporary directory, consistent with the malicious postinstall  lifecycle hook in plain-crypto-js@4.2.1 — the phantom dependency injected into the  backdoored axios@1.14.1 and axios@0.30.4 packages. The dropper (setup.js) writes a  hidden-window VBScript to %TEMP% that copies powershell.exe to %PROGRAMDATA%\wt.exe  and fetches the stage-2 PowerShell RAT from the C2 at sfrclak[.]com:8000. The VBScript  self-deletes after execution to reduce forensic artifacts. Any npm install process  that spawns a VBScript interpreter against a temp-resident .vbs file should be considered  highly suspicious and is not consistent with legitimate package installation behavior.referenc

name: Masqueraded MSBuild Execution from Windows Startup Folder Analyticsignatureid: TELNYX2category: 'Persistence'threatname: 'Boot or Logon Autostart Execution: Startup Folder'functionality: 'Endpoint Management Systems'description: |  Detects execution of msbuild.exe from the Windows Startup folder, which is a persistence mechanism  used by the TeamPCP Telnyx supply chain malware. The legitimate Microsoft Build Engine (msbuild.exe)  resides in C:\Windows\Microsoft.NET\ and is never present in user Startup directories. The TeamPCP  malware extracts a PE binary from WAV audio steganography (hangup.wav) and writes it to  %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe to achieve persistence across  reboots. The dropped binary is a MinGW-compiled x86_64 PE that performs process hollowing into  dllhost.exe. This rule also detects the companion lock file (msbuild.exe.lock) which the malware  creates with the hidden attribute to implement a 12-hour re-download cooldown.

name: TeamPCP Archived Credential Exfiltration via HTTP POST Analyticsignatureid: PXY-TELNYX1category: 'Exfiltration'threatname: 'Exfiltration Over C2 Channel'functionality: 'Web Proxy'description: |Detects HTTP POST requests containing the X-Filename header value "tpcp.tar.gz", which is the consistent exfiltration signature used by TeamPCP across both the LiteLLM and Telnyx supply chain compromises. After harvesting credentials (SSH keys, cloud credentials, .env files, shell histories, cryptocurrency wallets, and Kubernetes tokens), the malware encrypts the collected data with AES-256-CBC, wraps the session key with RSA-4096, bundles both into a gzipped tarball named tpcp.tar.gz, and exfiltrates via HTTP POST with Content-Type: application/octet-stream and header X-Filename: tpcp.tar.gz. Independent validation on March 30, 2026 confirmed the exfiltration endpoint at 83.142.209.203:8080 remains active and accepting POST data even though payload delivery (GET) endpoints have been disabl

Campaign: TeamPCP — Telnyx PyPI Supply Chain CompromiseSamples: hangup.wav (Windows steganographic carrier), linux_payload.py (decoded _p credential harvester)What Happened...On March 27, 2026, the threat actor group TeamPCP published two trojanized versions (4.87.1 and 4.87.2) of the official Telnyx Python SDK to PyPI. This was the latest link in a credential-chaining supply chain campaign that began on March 19 with the compromise of Aqua Security's Trivy, subsequently spreading to Checkmarx GitHub Actions, LiteLLM, and now Telnyx. The campaign's defining innovation is the use of WAV audio steganography to deliver second-stage payloads, concealing executable binaries inside valid audio containers to evade network inspection and endpoint detection.This breakdown provides a deep technical analysis of both platform-specific attack paths in the Telnyx compromise. For Windows, we dissect hangup.wav, the steganographic carrier downloaded from the TeamPCP command-and-control infrastructure,

Audience: Security Analysts, SOC Leads, Architects, MSSPsProduct Module: Threat Analytics / Detection EngineeringLast Updated: March 23, 2026KB ID: KB-20260323-sta-previewTags: Securonix, Threat Analytics, SIEM, Microsoft Sentinel, Risk Scoring, Detection Engineering, SOC, Security Analytics  Problem As security environments grow in scale and complexity, analysts are often overwhelmed by high volumes of alerts with limited context. Traditional SIEM workflows can make it difficult to connect related events across datasets, leading to alert fatigue and slower investigations.  Objective Provide an early preview of Securonix Threat Analytics (STA) and how it enhances existing SIEM platforms by improving detection quality, prioritization, and investigation workflows.  Overview Securonix Threat Analytics (STA) is an advanced analytics layer that operates on top of your existing SIEM and telemetry platforms (such as Microsoft Sentinel). Rather than replacing your current data infrastructure,

Here’s what happened...While browsing a legitimate Formula 1 news site, a programmatic ad creative hijacks your browser session and redirects to a sophisticated social engineering operation impersonating McAfee. The attack chain traversed multiple supply-side platforms (SSPs), a demand-side platform (DSP), and Cloudflare infrastructure before landing on a multi-step scam funnel that used fake virus scans, fabricated threat alerts, an alarm sound, a fake "AI assistant" chat, and an urgency countdown timer — all to drive the victim into purchasing a real McAfee antivirus subscription through a fraudulent affiliate link.This post documents the complete kill chain from initial ad impression to final monetization endpoint, including extracted IOCs, infrastructure analysis, and the social engineering techniques employed.The Initial RedirectThe attack began on racingnews365.com, a well-known F1 racing news site. While browsing on a mobile device, Azerion's ad loader served a programmatic disp

 On March 11, 2026, the Iran-linked hacktivist group Handala (a.k.a. Handala Hack Team / Void Manticore) executed a destructive wiper attack against Stryker Corporation, wiping devices and servers across the $25 billion medical technology company's global enterprise and idling approximately 56,000 employees in 61+ countries. This is the first confirmed major cyber disruption of a U.S. corporation since joint U.S.-Israeli military strikes on Iran commenced on February 28, 2026 (Operations "Epic Fury" and "Roaring Lion"). The attackers compromised administrator accounts and weaponized Microsoft Intune, Stryker's cloud-based mobile device management (MDM) platform, to issue remote wipe commands to all connected devices — a "living off the land" technique that turned Stryker's own IT management infrastructure against itself. The attack is assessed as retaliatory, timed 11 days after kinetic strikes began, and targeted Stryker specifically for its 2019 acquisition of Israeli company OrthoSp

Audience: Securonix Administrators, Identity Administrators, MSSPs Product Module: Administration → Settings → SAML Settings Last Updated: February 27, 2026 KB ID: KB-20260227-uds-sso-login-failuresTags: SAML, SSO, Azure AD, Okta, Authentication, Redirect Loop, Certificate Expired, Invalid Audience, Role Mapping Table of ContentsProblem  Objective  Step-by-Step Solution  Step 1 – Perform a 60-Second Configuration Validation (Always Do This First)  Step 2 – Validate Metadata and URL Alignment Step 3 – Validate the Signing Certificate Step 4 – Validate Time Synchronization (Clock Skew) Step 5 – Validate User Assignment and Role Mapping Step 6 – Validate Local Login (Isolation Test) Final Notes When to Contact Support Verification Checklist Need Additional Help?Problem   Users are unable to log in to UDS using SAML SSO. Common symptoms include:  Redirect loop after login  “Invalid SAML response”  “Invalid audience”  “Signature validation failed”  Azure error AADSTS700016 (applica

Audience: Securonix Administrators, MSSPs, Security Operations Leaders Product Module: Menu → Main → Manage License  or  Menu → Administration → Settings → Manage License Last Updated: March 10, 2026 KB ID: KB-20260227-uds-licensing-overviewTags: UDS Licensing, Manage License, License Expiry, SOAR, Entitlements, Grace Period, Add-ons, Feature Availability Table of ContentsProblem  Objective  Step-Based Troubleshooting Workflow (Start Here)  Step 1 – Check for Expiry Banner  Step 2 – Blue or Yellow Expiry Banner (Pre-Expiry Warning)  Step 3 – Red Banner or License Expired  Step 4 – No Expiry Banner, but Feature Missing  Step 5 – Feature Not Listed in License  How UDS Licensing Works (Reference)  ⚠️ Important Note on Banner Accuracy  ✅ Verification Checklist  When to Contact Support Immediately  Need Additional Help? Problem  Administrators may encounter licensing-related scenarios such as:  Expiry warning banners in the UI  License marked as expired  Login blocked due to license

 Audience: Admins, Analysts, MSSPsProduct Module: Integrations (ThreatQ Platform)Last Updated: March 2, 2026KB ID: KB-20260227-threatq-integration-syncTags: ThreatQ, Integrations, TAXII, CDF, Exports, SSL, API Key, Data Retention, Job Management, TroubleshootingTable of Contents Problem Objective Step-by-Step Solution Step 1 – Confirm the Integration Is Running Step 2 – Review the Most Recent Run (Activity Log) Step 3 – Validate Credentials (Authentication Errors) Step 4 – Validate SSL / Certificate Settings Step 5 – Validate Endpoint & Network Connectivity Step 6 – If Sync Succeeds but No Data Moves Step 7 – Review Job Management Step 8 – Check Retention & Expiration Policies Step 9 – Review Feed Health Notifications Step 10 – When to Escalate Verification Checklist Call to Action  Problem ThreatQ integrations (CDF feeds, TAXII feeds, Operations, and Exports) may fail to sync, ingest, or send data.Common symptoms include:Integration runs but no data appears Authenti