The Deep Purple Sec – March 2026

📝 Pattern Detection and Correlation in JSON Logs

RSigma is a Rust-based command-line tool for testing purposes Sigma detection rules against JSON log streams, such as CloudTrail, Okta audit events or incident exports, without the need for a SIEM. It processes Sigma’s YAML rules (over 3,800 community-contributed detections for Windows, Linux, cloud and network threats) through fast pattern checkers, enabling real-time pattern detection, including single-event matches (e.g., whoami execution) and cross-event correlations (e.g., brute-force login attempts). Its architecture includes a parse (PEG grammar), evaluation engine (fast matching with no extra memory), correlation engine (8 Sigma-specified types with sliding windows), and linter (65 validation rules), delivering high throughput and Language Server Protocol (LSP) support for rule authoring.

Defensive teams can pipe logs via CLI commands, apply field-mapping pipelines (e.g., alignment of the ECS with the Windows Security log), and chain correlations for detecting multi-stage attacks. The tool’s memory-efficient state management, auto-fix linting, and deletion mechanisms reduce false positives. With an open-source MIT licence and crates.io availability, RSigma enables fast, scalable and affordable log analysis using Sigma’s tried-and-tested rules.

📌 Source: https://mostafa.dev/pattern-detection-and-correlation-in-json-logs-fab16334e4ee

📝 Detection Pipeline Maturity Model

A strong detection pipeline must strike a balance between accurate alerts and smooth operations, ensuring that important signals stand out whilst supporting both custom analytics and closed-source security tools (e.g., CrowdStrike, SentinelOne, AWS GuardDuty). The pipeline relies on two core data sources: security tools (rules set by suppliers or your own) and telemetry (data from endpoints, networks, cloud trails and more), both of which require normalisation and enrichment to ensure effective correlation. Maturity progresses through five levels: None (manual work, minor errors, switching between tools), Basic (centralised case management with some automation), Standard+ (all data via an analytics platform with a risk engine to rank alerts), Advanced (custom, accurate rules tested using simulated attacks), and Leading (detections based on data science and deception techniques). Organisations should rely less on unproven closed-source rules, adjust alert thresholds for noisy signals, and check regularly that the detection system is working by searching for threats and adjusting settings, ensuring clear, useful and robust monitoring wherever you operate.

📌 Source: https://detect.fyi/detection-pipeline-maturity-model-076984779651

📝 Stop Enabling Every AWS Security Service

Securing AWS environments requires a step-by-step approach: identify critical threats by planning for potential issues, understand how your team operates (IAM practices, resource creation), and safeguard sensitive data and systems that could cause major problems if they fail. Check for duplication between native AWS tools and third-party platforms to avoid redundant alerts.

Compare cost-benefit ratios and use custom automations (Lambda + EventBridge) to control costs. Consolidate identity management via AWS SSO (IAM Identity Centre) and automate monitoring tasks to ensure consistency. A step-by-step, automated and financially sustainable architecture enables operations to be carried out with confidence.

📌 Source: https://aws.plainenglish.io/stop-enabling-every-aws-security-service-fb171635a25c

📝 Help on the line: How a Microsoft Teams support call led to a security breach

A Microsoft DART investigation uncovered a complex attack that began with identity-first intrusion using Microsoft Teams voice phishing (vishing), . Attackers posed as IT support staff and tricked employees into granting remote access using Quick Assist. After two failed attempts, they tricked a third person and used that access to redirect them to a fake login page and install a malicious MSI package which secretly loaded a DLL to control the computer (C2). Subsequent attacks expanded their access by using encrypted loaders, living-off-the-land binaries (LOLBins), , and proxy-based C2, to steal login details and take over user sessions without being detected.

To guard against this, defenders should restrict teamwork in Teams by only allowing trusted domains and disable or restrict remote access tools such as Quick Assist, unless the business really needs them. To detect attacks, focus on unusual use of Quick Assist, unexpected MSI programmes running, , and connections to unknown websites after Teams calls. Security teams should also watch out for secret DLLs being loaded and proxy-based traffic control, and train users to spot rushed moves that put them under pressure and check support requests by contacting IT via a different channel.

📌 Source: https://www.microsoft.com/en-us/security/blog/2026/03/16/help-on-the-line-how-a-microsoft-teams-support-call-led-to-compromise

📝 Torg Grabber: Anatomy of a New Credential Stealer

The newly identified Torg Grabber is a credential stealer that uses ChaCha20 encryption, HMAC-SHA256 authentication and a modular REST API design. It has switched from stealing data via Telegram using a custom TCP protocol to HTTPS. It includes a 20 KB reflective DLL to get round Chrome’s Application Bound Encryption (ABE).

Security teams should be on the lookout for use of environment variables (GRABBER_*), PowerShell BITS transfers, and TCP traffic on port 50443. Update detection rules for ChaCha20-encrypted HTTPS traffic to track C2 domains. Use behavioural analysis and memory forensics to detect direct NT system calls and reflective loading. Limit PowerShell execution, block known attacker C2 IP addresses (e.g., 84.200.125.231), and use YARA rules for operator tags and ABE bypass DLL artefacts.

📌 Source: https://www.gendigital.com/blog/insights/research/torg-grabber-credential-stealer-analysis

📝 How a Compromised Security Scanner Became the Key to Backdooring LiteLLM

Attackers compromised LiteLLM (versions 1.82.7 and 1.82.8) on 24 March 2026. The group TeamPCP carried out a supply chain attack by tampering with a Trivy security scanner in LiteLLM’s CI/CD pipeline to steal PyPI credentials. The attack delivered malware in two ways: by injecting code directly into proxy_server.py (1.82.7) and via a .pth file (1.82.8) that runs when Python starts up. The attack had three steps: stealing credentials (cloud, Kubernetes and cryptographic secrets), and sending them in encrypted form to models.litellm.cloud, and installing a backdoor using a systemd a service that checks checkmarx.zone for more payloads. The attack used MITRE ATT&CK techniques T1546.018 (Python Startup Hooks), T1003 (Credential Dumping) and T1610 (Deploy Container), with Kubernetes deployed across alpine:latest named pods node-setup-*.

Defenders should check the systems straight away for signs of compromise, including the .pth file, sysmon.py backdoor, or tpcp.tar.gz archives, and rotate all credentials, particularly cloud, SSH and Kubernetes tokens. To prevent reinfection, Update LiteLLM to version ≤1.82.6, check CI/CD pipelines for unlocked dependencies, and monitor for suspicious pods or network traffic to domains controlled by attackers. This incident highlights the risk of .pth-based persistence and the need for real-time integrity checks that go beyond hash verification, as the malicious packages passed all standard PyPI checks.

📌 Source: https://snyk.io/fr/blog/poisoned-security-scanner-backdooring-litellm