Trend Micro Apex One command-injection flaws actively exploited to gain console control
Summary: Threat actors are actively exploiting critical command-injection vulnerabilities in Trend Micro Apex One and Apex One as a Service management consoles to obtain remote code execution, pivot into enterprise networks, and deploy post-exploitation tooling. The issues, tracked as CVE-2025-54948 and CVE-2025-54987, enable unauthenticated or low-authenticated attackers to inject system commands through web endpoints in the console, with exploitation observed in the wild since early August 2025. Emergency patches and compensating controls are available.
Vulnerabilities and impacted components
Trend Micro disclosed two command-injection flaws affecting the Apex One Management Console, the central on-prem and SaaS component used to manage endpoint agents and security policies. Command injection allows attackers to run arbitrary OS commands under the console service account, which typically has elevated privileges on the server hosting the console. The affected endpoints are web-exposed console routes that insufficiently sanitize user-controlled parameters.
Attack surface and exploitation mechanics
Attackers target Internet-facing or internally reachable management consoles by sending crafted HTTP requests that embed shell metacharacters or chained payloads in parameters processed by backend scripts. Because console tasks often invoke system utilities for agent orchestration, weak input validation can allow direct shell invocation. Successful exploitation yields system-level command execution on the console host. In observed incidents, adversaries leveraged initial code execution to drop lightweight backdoors, perform credential dumping, and stage lateral movement to Windows domain controllers.
Observed TTPs and post-exploitation
Intrusions tied to these CVEs show rapid deployment of webshells and native LOLBINs to minimize detection. Common steps include enumerating installed security tools, disabling or tampering with EDR processes where possible, and using WMI and PsExec-style techniques to propagate. Operators have harvested cached domain credentials from LSASS, queried Active Directory for high-value targets, and exfiltrated configuration databases from the console to identify enrolled endpoints. In several cases, attackers scheduled persistence via Task Scheduler and abused service recovery actions to respawn implants.
Detection and forensic indicators
Indicators include anomalous POST requests to console administrative endpoints containing suspicious special characters, spikes in 500-series HTTP responses followed by process spawns (cmd.exe, powershell.exe) under the console service identity, and unusual outbound connections from the console host to previously unseen internal subnets. Process command lines with base64-encoded payloads, curl/certutil usage, and short-lived archive creation in temp directories are common. Reviewing IIS or reverse-proxy logs, Windows Security logs (4688 process creation, 4624 logons), and Sysmon events on the console host is recommended.
Mitigations and patching guidance
Apply Trend Micro’s emergency updates for both on-prem and SaaS consoles. If immediate patching is not possible, restrict network access to the console via VPN and IP allowlists, enforce MFA for administrative logins, and place the console behind an authenticated reverse proxy with strict WAF rules that block command-injection patterns. Disable direct Internet exposure. Monitor for new or modified tasks, services, and unusual child processes of the console service. Rotate privileged credentials and validate domain controller integrity if compromise is suspected.
Risk assessment and exposure management
Because the management console is a centralized control plane with high trust, compromise can undermine endpoint security at scale. Organizations should treat confirmed exploitation as a probable enterprise compromise, conduct full-scope incident response, and consider golden ticket or DCSync checks if domain admin credentials were at risk. Implement continuous scanning for management-plane exposures and adopt change-control monitoring on security infrastructure hosts to detect unauthorized configuration drift.
ECScape: Privilege escalation in Amazon ECS on EC2 via ACS WebSocket and IMDS credential theft
Summary: New research presented at Black Hat USA 2025 details ECScape, a technique that lets a low-privilege container task in Amazon ECS on EC2 escalate privileges by abusing the undocumented Agent Communication Service (ACS) WebSocket channel and the EC2 Instance Metadata Service to obtain IAM credentials from colocated tasks. The issue impacts ECS deployments on EC2-backed clusters where tasks share instances, not Fargate.
Root cause and threat model
In ECS on EC2, the container agent communicates with the control plane over ACS, a long-lived WebSocket used for task lifecycle events. In certain configurations, insufficient task isolation and metadata access controls allow an attacker within a container to interact with agent-managed channels or retrieve credentials intended for another task on the same instance. The core weakness stems from relying on instance-scoped trust and permissive access to IMDSv2 paths when multiple tasks are colocated.
Exploitation path
An attacker with code execution in a low-privilege task probes the local environment for ECS-specific sockets or endpoints and enumerates task metadata. By leveraging ACS message handling or misconfigurations exposing task credentials, the attacker can obtain temporary IAM role credentials issued to a different, more privileged task. With those credentials, they invoke AWS APIs to exfiltrate data from S3, enumerate secrets in Secrets Manager, or modify ECS task definitions and services.
Affected environments
Clusters running multiple tasks per EC2 host, especially where tasks have heterogeneous IAM roles, are most at risk. Workloads using host networking, shared PID or IPC namespaces, or permissive docker.sock access exacerbate exposure. Environments not enforcing IMDS hop limits or that permit IMDSv2 tokens to be re-used across tasks also increase the likelihood of cross-task credential leakage.
Mitigations and hardening
Prefer Fargate for multi-tenant workloads to achieve stronger task isolation. On EC2-backed ECS, enforce strict task-level isolation: disable host networking when not required, avoid sharing the docker socket, and ensure each task has only the minimum IAM role needed. Lock down IMDS with hop limit settings and IMDSv2 enforcement, and use network policies to prevent lateral access to agent endpoints. Consider dedicated EC2 instances per trust boundary or use placement constraints to avoid mixing privilege levels on the same host.
Detection strategies
Monitor for anomalous AssumeRole, ListSecrets, and PutTaskDefinition API calls initiated from unexpected task roles. Baseline normal ECS agent communications and alert on attempts to open unrecognized local sockets or unauthorized metadata queries. Collect and analyze container egress logs for suspicious AWS API usage patterns that don’t align with the task’s intended function.
Programmatic controls
Adopt service control policies that restrict high-risk AWS API actions from container roles, and use session tags or external IDs to bind credentials to specific workloads. Implement per-task egress control and TLS inspection to detect unusual calls to AWS endpoints. Rotate IAM roles frequently and use short credential lifetimes where possible to reduce the window for abuse.
AgentFlayer: Zero- and one-click prompt-injection chains steal credentials from AI agents
Summary: Researchers disclosed AgentFlayer, a set of prompt-injection techniques that compromise popular AI agents and developer copilots, enabling silent credential harvesting, document exfiltration, and conversation leakage. The attacks exploit agent tool-use flows and insecure connector permissions, requiring zero or minimal user interaction when agents automatically follow embedded instructions from content sources or plugins.
Attack design and vectors
AgentFlayer embeds adversarial instructions in files, webpages, or code snippets that agents ingest. When agents with tool-use capabilities encounter the payload, they execute actions such as exporting OAuth tokens, retrieving internal documents from connected SaaS apps, or sending conversation context to attacker-controlled endpoints. One-click variants trigger when a user previews or imports poisoned content; zero-click variants occur in autonomous or scheduled agent runs that routinely crawl resources.
Abuse of connectors and permissions
The most damaging cases involve overprivileged connectors to systems like Git, Google Drive, Slack, Jira, and internal wikis. Agents granted broad read/write scopes can be coerced into exfiltrating repositories, moving files, or modifying tickets. Weak output filtering and lack of egress controls allow the agent to transmit secrets and internal data without tripping DLP policies designed for human-initiated exfiltration.
Targets and impacted platforms
Demonstrations included multi-agent developer environments, enterprise chat assistants, and workflow orchestrators. Attacks successfully extracted API keys from environment variables, leaked embeddings that contain sensitive summaries, and coerced agents to reveal prior conversation history. The portability of the injections means any agent that renders or processes untrusted content is a potential target.
Mitigations for AI agent ecosystems
Constrain connector scopes to least privilege, enforce human-in-the-loop approvals for actions with exfiltration potential, and implement domain-allowlists for agent browsing. Add egress filtering from agent runtimes to block unsanctioned destinations and validate that tool outputs are not blindly fed back into prompts. Use content sanitization and markup stripping for external inputs, and scan retrieved content for adversarial patterns before execution.
Detection and governance
Instrument agent frameworks to log tool invocations, data flows, and outbound requests with correlation to originating content. Set up guardrails that reject instructions to expose secrets, upload data externally, or alter access controls. Regularly test agents with red-team prompt-injection suites and maintain an SBOM-like inventory for agent tools and connectors, including their permissions and data-access footprints.
Bouygues Telecom breach exposes IBANs and contract data for 6.4 million customers
Summary: Bouygues Telecom confirmed that attackers accessed contact details, contract information, and IBANs for 6.4 million customers. While passwords and card numbers were not stolen, exposure of bank identifiers raises risks of targeted fraud, social engineering, and invoice redirection attacks. Regulatory notification and customer communication are underway.
Nature of exposed data and fraud risks
The dataset includes names, email addresses, phone numbers, customer identifiers, service contracts, and IBANs. Although IBAN alone does not authorize direct debits without additional controls, criminals can craft convincing phishing lures, set up mandate fraud attempts, and manipulate invoice payment workflows by spoofing carrier communications. Enterprises with corporate lines are at heightened risk of BEC-style supplier fraud.
Intrusion vector and scope
The company reported unauthorized access affecting a large subset of its consumer base. The attack likely targeted customer management or billing systems that store banking details to support SEPA direct debit. No evidence indicates compromise of authentication secrets, but contact data breadth enables high-fidelity impersonation campaigns tailored to carrier services, plan renewals, or device financing.
Customer protections and carrier response
Carrier guidance includes heightened monitoring for suspicious debit mandates, verifying any requested changes to payment details via known channels, and ignoring unsolicited links in emails or SMS. The operator is coordinating with regulators and financial partners to detect fraudulent SEPA attempts. Impacted customers should enable strong email account protections and consider aliasing for carrier communications to make phishing less effective.
Enterprise and supply-chain considerations
Organizations using Bouygues corporate services should validate supplier bank detail changes through out-of-band verification and update BEC playbooks to account for telecom-themed lures. Security teams should tune mail gateways for carrier-branded phishing kits and monitor for newly registered lookalike domains. Financial controllers should require dual approval for vendor bank changes and confirm via verified contacts.
US Judiciary case filing systems breach raises concerns over sealed records and informant exposure
Summary: The US federal judiciary’s electronic filing systems, including PACER and CM/ECF, were reportedly breached, potentially exposing sealed filings and identities of confidential informants. The sophistication of the intrusion suggests a well-resourced adversary, with investigators probing scope, data accessed, and potential national security implications.
Systems and data at risk
PACER provides public access to federal court records, while CM/ECF manages electronic case filing and sealed documents. A compromise of backend systems could reveal metadata and contents of sealed indictments, cooperation agreements, and ongoing investigative materials. Exposure could endanger individuals, compromise prosecutions, and inform counterintelligence targeting.
Potential threat actors and objectives
Given the sensitivity of sealed records, a state-sponsored operation is plausible, seeking intelligence on investigations, law-enforcement techniques, and witness identities. Criminal groups could monetize access by extorting high-profile defendants or manipulating legal proceedings; however, sustained stealth and data selection align more closely with espionage tradecraft.
Immediate mitigations and legal safeguards
Court IT administrators are expected to rotate credentials, segment access to sealed repositories, and conduct log forensics across PACER, CM/ECF, and associated identity providers. Judges and clerks may temporarily tighten sealing procedures and favor offline handling for the most sensitive filings. Law enforcement will likely initiate witness-protection assessments and adjust charging strategies where exposure risk is high.
Operational and policy implications
The incident underscores the need for zero-trust segmentation in justice systems, rigorous auditing of privileged access, and stronger encryption and compartmentalization for sealed materials. Longer term, modernization efforts may prioritize out-of-band delivery for ultra-sensitive documents and adopt hardware-backed attestation for systems handling sealed records.
Ransomware operators weaponize potential SonicWall zero-day amid Akira surge
Summary: Multiple security researchers report a surge in Akira ransomware intrusions linked to exploitation of a potential SonicWall firewall zero-day. Attackers are gaining initial access via edge devices, then using living-off-the-land techniques to move laterally and encrypt workloads. SonicWall is investigating while defenders harden perimeter gear and monitor for anomalous VPN and management-plane activity.
Edge device exposure and exploitation flow
Adversaries target Internet-exposed firewall management interfaces and VPN services to obtain code execution or authentication bypass. Compromise of perimeter devices provides a launchpad to enumerate internal networks, harvest credentials from VPN appliances, and deploy C2 beacons. Once inside, actors use native tools for reconnaissance and stage encryption payloads with domain-wide impact.
Indicators and containment
Watch for unusual configuration changes on SonicWall devices, unexpected administrator logins from foreign ASN ranges, and spikes in SSL VPN session creation outside business hours. Network telemetry may show lateral connections from firewall subnets to high-value servers. Immediate steps include disabling unused management exposure, enforcing MFA for all admin access, and applying interim hardening guidance from the vendor.
Resilience and recovery practices
Maintain offline, immutable backups and test bare-metal restore procedures. Segment OT and critical business networks so firewall compromise does not equate to enterprise compromise. Implement rapid credential rotation following edge-device incidents, including service accounts, and validate GPO integrity before resuming operations.
Allianz Life breach tied to supply-chain compromise amplifies insurance-sector targeting
Summary: Allianz Life disclosed a significant data breach stemming from a third-party supply-chain intrusion, aligning with a broader wave of social-engineering and vendor compromises impacting insurers. Exposed data may include customer PII linked to policy servicing, escalating fraud and regulatory risks across the sector.
Supply-chain attack dynamics
Attackers increasingly compromise vendors with broad access to insurance back-office systems, leveraging stolen credentials and OAuth grants to infiltrate carriers. Access enables data scraping across policy administration and claims portals, followed by selective exfiltration to avoid detection. The Allianz incident reflects the fragility of federated identity and delegated access in complex partner ecosystems.
Fraud and compliance impact
Leaked datasets can fuel synthetic identity schemes, claim redirection, and targeted phishing against policyholders and agents. Carriers face notification duties, potential regulatory fines, and heightened scrutiny of third-party risk management. Forensic scope must include vendor logs, SSO audit trails, and API access histories to reconstruct data flows.
Defensive measures
Insurers should enforce zero-trust access for vendors, limit API scopes with conditional access, and require hardware-backed phishing-resistant MFA. Continuous validation of OAuth app provenance and automated anomaly detection on data export patterns are critical. Contractual clauses should mandate rapid telemetry sharing and incident drill participation from critical suppliers.
Fake Microsoft OAuth apps proliferate to hijack Microsoft 365 accounts via MFA-bypassing consent
Summary: Adversaries are deploying fake OAuth applications that mimic brands like RingCentral and SharePoint to phish Microsoft 365 users for consent grants, sidestepping traditional MFA. Once authorized, the rogue apps harvest mail, files, and chat data, and can establish persistence by creating inbox rules and new OAuth secrets.
Tactics and tooling
Campaigns rely on well-crafted emails driving users to legitimate Microsoft consent screens that request overbroad Graph API scopes. The technique abuses trust in Microsoft’s OAuth flow rather than stealing passwords. Some operators use “Tycoon” style toolkits to mass-generate tenant-specific apps and rotate infrastructure, increasing campaign resilience.
Detection and response
Security teams should audit enterprise applications for recently consented apps, flag risky Graph scopes (Mail.ReadWrite, Files.ReadWrite.All, offline_access), and revoke tokens and certificates associated with suspicious apps. Conditional access can require admin consent for high-privilege scopes and block user consent for unverified publishers. Monitor sign-in logs for app-only access and anomalous Graph activity such as mass message reads or file downloads.
Preventive controls
Enable publisher verification policies, enforce admin consent workflows, and use consent fatigue training for users. Integrate SIEM detections for OAuth app creation, credential secret addition, and permission elevation events. Apply DLP and egress controls to constrain data accessible via app-only tokens.