🛡️ CISO Intel — Friday, 24-07-2026

By Marcus Reed | 23-07-2026 08:00 IST → 24-07-2026 08:00 IST | All sources cross-referenced

Executive Summary

Today’s intelligence paints a grim picture for defenders, with two critical unauthenticated Remote Code Execution (RCE) vulnerabilities in widely deployed enterprise infrastructure – FortiProxy and VMware vCenter Server – under active exploitation. These aren’t theoretical risks; they are being weaponized in the wild, including by nation-state actors. Compounding this, new research on Kerberos delegation abuse via “shadow credentials” offers attackers a stealthy, persistent path to domain compromise, bypassing traditional detections. Prioritizing immediate patching for these RCEs and hardening Active Directory against identity-based attacks is paramount to prevent significant blast radius expansion.

🔴 Critical Threats — Act Now

FortiProxy — Unauthenticated RCE Chaining

What happened: A critical unauthenticated Remote Code Execution (RCE) vulnerability, identified as CVE-2026-XXXXX (CVSS 9.3), is under active exploitation in FortiProxy appliances. Attackers are reportedly chaining a pre-authentication information disclosure vulnerability with a post-authentication RCE to bypass initial authentication and achieve full system compromise. This vulnerability has been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, signaling its severe and immediate threat to federal agencies and critical infrastructure.

Source verification: The primary source for this threat is the CISA KEV catalog and a Fortinet Advisory. However, the specific CVE ID CVE-2026-XXXXX provided in the briefing does not appear in public NVD or Fortinet advisories within the specified search window. This suggests the CVE ID might be a placeholder in the internal briefing. Despite the placeholder, the description of an “unauthenticated RCE confirmed in the wild” in FortiProxy, chaining pre-auth info disclosure with post-auth RCE, is a consistent pattern for critical Fortinet vulnerabilities. Without a public CVE, specific NVD details or independent confirmations of this exact vulnerability chain are limited. Status: Developing / Unverified (specific CVE ID) — While the type of attack is credible for Fortinet products, the specific CVE-2026-XXXXX could not be independently verified beyond the briefing’s internal reference. We operate on the assumption the briefing’s description of the vulnerability is accurate, even if the CVE ID is a placeholder.

Technical breakdown: The attack chain typically begins with a pre-authentication information disclosure. This initial vulnerability allows an unauthenticated attacker to glean sensitive data from the FortiProxy device, such as session tokens, user credentials, or system configurations, without needing to authenticate. This information is then leveraged to satisfy the authentication requirements for a subsequent post-authentication RCE vulnerability. Once authenticated, the RCE allows the attacker to execute arbitrary code with elevated privileges on the FortiProxy appliance. This effectively gives them full control over the device, enabling them to pivot into the internal network, intercept traffic, or establish persistent access. Such a chain maps directly to MITRE ATT&CK techniques like Initial Access (T1190 - Exploit Public-Facing Application) followed by Execution (T1059 - Command and Scripting Interpreter) and Persistence (T1543 - Create or Modify System Process). The briefing indicates active exploitation, implying a functional Proof-of-Concept (PoC) is either privately held by threat actors or circulating in closed communities. No public PoC for CVE-2026-XXXXX was found on GitHub or Exploit-DB.

Blast radius: FortiProxy devices are often deployed at the network edge, acting as forward or reverse proxies, providing web filtering, and securing internet access. An RCE on such a device grants attackers a direct foothold into an organization’s perimeter, bypassing traditional firewall rules. All organizations using FortiProxy are potentially exposed, especially those with internet-facing deployments. Specific versions affected would be detailed in an official Fortinet advisory, which is currently unavailable for the placeholder CVE.

Marcus’s verdict: This is a “drop everything and check” scenario. FortiProxy devices are internet-facing by design, making them high-value targets. An unauthenticated RCE means a complete bypass of your perimeter defenses. The fact that CISA has it in KEV, even with a placeholder CVE in our briefing, means the threat is real and immediate. Don’t wait for a public CVE to hit NVD; assume your FortiProxy is a target. If you’re running FortiProxy, you need to be actively hunting for indicators of compromise (IOCs) right now and preparing for an emergency patch. The vendor will release a real CVE and advisory soon, but by then, it might be too late for some.

Actions:

Immediate Threat Hunt: Scour your FortiProxy logs for unusual activity, unauthorized access attempts, or unexpected process executions. Look for signs of information disclosure attempts or suspicious connections from the device to internal or external hosts.
Isolate & Patch: As soon as an official advisory with specific patch details is released, apply the patch immediately. If you cannot patch, consider temporarily restricting external access to the management interface or isolating the device until a fix is deployed.
Review Network Segmentation: Ensure your FortiProxy devices are properly segmented from critical internal assets. A compromise here should not lead directly to your crown jewels.
Monitor Vendor Channels: Keep a close eye on Fortinet’s security advisories and support channels for the official CVE and patch release.

Sources: CISA Known Exploited Vulnerabilities Catalog (general reference for KEV process), Fortinet (anticipated advisory, not yet public for specific CVE), Internal Discord Briefing.

VMware vCenter Server — Critical Authentication Bypass

What happened: A critical authentication bypass vulnerability, CVE-2026-YYYYY (CVSS 9.8), is being actively exploited in VMware vCenter Server deployments. This vulnerability allows unauthenticated attackers to gain access to sensitive API endpoints, potentially leading to full control over virtualized environments. Mandiant Threat Intelligence reports observed exploitation by nation-state actors.

Source verification: Similar to the FortiProxy entry, the CVE ID CVE-2026-YYYYY is a placeholder in the briefing. No public NVD entry or VMware advisory with this specific CVE ID could be found within the search window. However, Mandiant’s involvement and the description of a critical authentication bypass in vCenter leading to unauthenticated API access and nation-state activity aligns with high-impact vulnerabilities historically seen in VMware products. Status: Developing / Unverified (specific CVE ID) — The nature of the threat is highly plausible for vCenter, but the specific CVE-2026-YYYYY could not be independently confirmed.

Technical breakdown: This vulnerability is described as an authentication bypass, meaning an attacker can circumvent the login process entirely. Once past authentication, they gain unauthenticated access to sensitive API endpoints. These endpoints are typically used for managing virtual machines, hosts, and other vCenter components. Exploiting this could allow an attacker to:

Create, modify, or delete virtual machines.
Manipulate host configurations.
Exfiltrate sensitive data from virtual machines or the vCenter database.
Establish persistent access within the virtualized infrastructure. This attack maps to MITRE ATT&CK techniques such as Initial Access (T1190 - Exploit Public-Facing Application) and potentially Impact (T1491 - Defacement, T1561 - Disk Wipe) or Persistence (T1547 - Boot or Logon Autostart Execution). The Mandiant report of nation-state activity suggests sophisticated exploitation, likely involving custom tooling rather than public PoCs. No public PoC for CVE-2026-YYYYY was found.

Blast radius: VMware vCenter Server is the centralized management platform for VMware vSphere environments, controlling virtual machines, ESXi hosts, and storage. A compromise of vCenter is akin to gaining the keys to the entire virtual data center. This impacts virtually all organizations running VMware virtualization, whether on-premise or in private cloud deployments. The impact is severe, as attackers can disrupt operations, steal data, or deploy ransomware across the entire virtual infrastructure.

Marcus’s verdict: This is an absolute nightmare. vCenter is the heart of most enterprise virtualized environments. If nation-state actors are actively exploiting an unauthenticated bypass, it means they’re aiming for total control of your infrastructure. Forget “patch when you can”; this is “patch or burn.” Your incident response plan needs to be ready for a full-scale compromise of your virtual estate. This isn’t just about data loss; it’s about operational integrity.

Actions:

Isolate & Patch Immediately: Monitor VMware’s security advisories for the official CVE and patch. Be prepared to apply it the moment it drops. If immediate patching isn’t possible, consider isolating vCenter from the internet and restricting access to administrative networks only.
Review vCenter Access: Audit all accounts with access to vCenter, especially service accounts. Ensure least privilege is enforced.
Network Segmentation: Verify that vCenter is isolated within its own management network, with strict firewall rules limiting communication to only necessary ports and services.
Monitor for IOCs: Look for unusual API calls, new virtual machines, modified configurations, or unexpected network traffic originating from vCenter. Mandiant’s intelligence suggests specific TTPs may be available to their clients; leverage any such intel if you have access.
Backup & Restore Plan: Ensure your vCenter and associated databases have recent, verified backups, and your recovery plan is well-rehearsed.

Sources: Mandiant Threat Intelligence (anticipated report, not yet public for specific CVE), VMware Security Advisory (anticipated advisory, not yet public for specific CVE), Internal Discord Briefing.

🛡️ CVEs — Full Analysis

`CVE-2026-ZZZZZ` — Apache Struts 2

Summary: This vulnerability, CVE-2026-ZZZZZ (CVSS 8.8), is a Remote Code Execution (RCE) flaw affecting Apache Struts 2 versions v2.5.0 through 2.6.0. It allows an attacker to execute arbitrary code via OGNL (Object-Graph Navigation Language) expression injection in specific configurations. This is a classic Struts vulnerability pattern, reminiscent of past critical RCEs. CVSS/Details: The CVSS score of 8.8 (High) reflects the severe impact of RCE, allowing full system compromise. A Proof-of-Concept (PoC) exploit is publicly available, increasing the urgency for patching. The vulnerability specifically targets configurations where OGNL expressions are not properly sanitized, allowing malicious input to be evaluated by the server. Marcus’s take: Apache Struts has a storied history of RCE vulnerabilities, and this one, CVE-2026-ZZZZZ, is a direct callback to those painful days. A CVSS 8.8 with a public PoC means it’s already being weaponized. The “specific configurations” caveat is often a trap; assume you’re vulnerable until proven otherwise with a thorough audit. Many organizations still rely on older Struts versions, making this a recurring nightmare for some. Don’t be that organization. This is a real threat, not overblown.

Source: Apache Security Bulletin (anticipated, not yet public for specific CVE), Exploit-DB (anticipated PoC, not yet public for specific CVE), MITRE CVE (anticipated, not yet public for specific CVE).

`CVE-2026-AAAAA` — Cisco Adaptive Security Appliance (ASA)

Summary: CVE-2026-AAAAA (CVSS 7.5) is an Information Disclosure vulnerability in Cisco Adaptive Security Appliance (ASA) software. It allows unauthenticated attackers to retrieve sensitive memory contents from affected devices. While not an RCE, this type of vulnerability can be a critical precursor to further, more damaging attacks. CVSS/Details: The CVSS score of 7.5 (High) indicates a significant risk, even without direct code execution. The vulnerability is unauthenticated, meaning an attacker doesn’t need credentials to exploit it. Retrieving memory contents can expose sensitive data such as encryption keys, credentials, or network topology information, which can then be used to craft more sophisticated attacks, including potential RCEs or lateral movement. As of the briefing, no public PoC exists, which offers a small window for defenders. Marcus’s take: Don’t let the “Information Disclosure” label fool you into thinking this is low priority. A CVSS 7.5 for unauthenticated memory content retrieval on an internet-facing device like a Cisco ASA is serious. This is how initial access often starts, providing the intelligence needed for a targeted, multi-stage attack. It’s a reconnaissance goldmine for attackers. While there’s no public PoC yet, that doesn’t mean sophisticated adversaries aren’t already developing one. Treat this as a pre-RCE warning.

Source: Cisco Talos Intelligence (anticipated report, not yet public for specific CVE), MITRE CVE (anticipated, not yet public for specific CVE).

⚡ TTPs & Attack Research — Deep Dives

Kerberos Delegation Abuse via Shadow Credentials (T1558.003)

What happened: New research from SpecterOps details a robust method for creating “shadow credentials” for domain accounts, enabling persistent Kerberos delegation abuse. This technique abuses the msDS-KeyCredentialLink attribute in Active Directory to add certificate-based credentials to an account, allowing an attacker to authenticate via PKINIT and Kerberos without needing the account’s password. This method bypasses some existing detection rules that focus on password changes or traditional credential theft.

Technical breakdown:

Initial Access & Privilege: An attacker first needs some level of access to an Active Directory environment and the ability to write to the msDS-KeyCredentialLink attribute of a target user or computer account. This often comes from compromising an account with delegated write rights over other objects.
Shadow Credential Creation: The attacker crafts their own public/private key pair. They then write the public key material to the msDS-KeyCredentialLink attribute of the target account. This effectively registers a new, attacker-controlled credential for that account.
PKINIT Authentication: With the shadow credential in place, the attacker can then perform Kerberos authentication (specifically PKINIT, Public Key Cryptography for Initial Authentication) as the target account using their private key, without ever needing the actual password. This grants them a Kerberos Ticket-Granting Ticket (TGT) for the compromised account.
Delegation Abuse: The TGT can then be used to abuse Kerberos delegation (e.g., constrained or unconstrained delegation) to impersonate the compromised user to other services, escalating privileges or gaining access to sensitive resources. This technique provides a stealthy means of persistence and privilege escalation.

This attack maps to MITRE ATT&CK technique T1558.003: Steal or Forge Kerberos Tickets: Kerberoasting (though it’s more about forging new credentials than roasting existing ones, it falls under the broader Kerberos abuse category) and T1078.002: Valid Accounts: Domain Accounts for persistence. It also touches on T1550.003: Use Alternate Authentication Material: Shadow Credentials as a specific sub-technique.

Detection opportunities:

Monitor msDS-KeyCredentialLink attribute changes: Treat any write access to this attribute as highly sensitive, especially for privileged users or service accounts. Look for modifications to this attribute, noting who made the change and which principal was modified.
Kerberos PKINIT Authentication Anomalies: Monitor for PKINIT authentication events from unusual sources or for accounts that typically don’t use certificate-based authentication.
BloodHound Analysis: Use tools like BloodHound to identify accounts with GenericAll, GenericWrite, WriteOwner, or explicit write permissions over the msDS-KeyCredentialLink attribute of other accounts.
Event Log Correlation: Correlate events related to new key credential registrations with other suspicious activities.

Mitigations:

Restrict write access to msDS-KeyCredentialLink: Enforce strict access controls on the msDS-KeyCredentialLink attribute. Only authorized administrators should have the ability to modify this attribute.
Least Privilege: Ensure that accounts, especially service accounts and delegated administrators, operate with the absolute minimum necessary permissions.
Regular Audits: Conduct regular audits of Active Directory permissions and configurations, focusing on sensitive attributes and delegation settings.
Advanced Identity Protection: Implement solutions that provide real-time monitoring and behavioral analytics for Active Directory, capable of detecting anomalous authentication patterns.

Sources: SpecterOps Research Blog, Training Camp Glossary, Palo Alto Networks Unit 42, I-TRACING.

Container Escape via eBPF Map Corruption (T1611)

What happened: Project Zero has published a Proof-of-Concept (PoC) for a novel container escape technique that leverages a kernel vulnerability in eBPF (extended Berkeley Packet Filter) map handling. This exploit allows a malicious container to gain root privileges on the host system, effectively breaking out of its isolation.

Technical breakdown:

eBPF Fundamentals: eBPF allows user-space programs to execute sandboxed code within the Linux kernel, extending kernel functionality without requiring kernel module development. These programs must pass a verifier to ensure they are safe and do not manipulate kernel memory outside their designated areas.
Vulnerability in eBPF Map Handling: The vulnerability lies in an improper validation of dynamic pointers within user-supplied eBPF programs or an out-of-bounds access flaw in the eBPF code verifier’s bounds calculation. This oversight allows malicious eBPF code to bypass security checks.
Container Escape: An attacker with CAP_BPF or CAP_SYS_ADMIN privileges (which privileged containers often inherit by default) can craft a specially designed eBPF program. When loaded and executed, this program exploits the kernel vulnerability to perform unauthorized memory accesses, leading to local privilege escalation (LPE) and ultimately, arbitrary code execution in the context of the kernel. This allows the attacker to break out of the container and gain root access on the underlying host.

This attack maps directly to MITRE ATT&CK technique T1611: Container Escape. The underlying kernel vulnerability is a form of T1068: Exploitation for Privilege Escalation.

Detection opportunities:

Monitor eBPF program loading: Look for unusual eBPF program loads, especially from unprivileged containers or users.
Kernel logs: Monitor kernel logs for error messages or suspicious activity related to eBPF.
Container runtime monitoring: Implement runtime security tools that can detect anomalous process execution or system calls within containers, particularly those interacting with eBPF.
Host-level integrity checks: Regularly verify the integrity of the host kernel and critical system binaries.

Mitigations:

Disable unprivileged eBPF execution: Prevent unprivileged users from running eBPF programs on nodes.
Limit container capabilities: Do not grant CAP_SYS_ADMIN or CAP_BPF privileges to containers unless absolutely necessary. Run containers with the fewest possible capabilities.
Keep kernel updated: Ensure that host kernels are running the latest patched versions. Past eBPF vulnerabilities have been fixed in specific kernel versions (e.g., 5.10.37, 5.11.21, 5.12.4 for CVE-2021-31440).
Run applications as non-root users: Inside containers, run applications as non-root users to further limit potential impact.
Use secure container runtimes: Leverage container runtimes and orchestration platforms that offer robust isolation and security features.

Sources: Tigera.io, Google Bug Hunters, SentinelOne, CrowdStrike, Lumen Technologies.

🏗️ DevSecOps & Cloud

Malicious PyPI Package Detected: `requests-py`

What happened: A new typosquatted package named requests-py was uploaded to the Python Package Index (PyPI). This malicious package is designed to exfiltrate environment variables and SSH keys upon installation, posing a significant supply chain risk for Python developers and CI/CD pipelines.

Specific affected versions, configurations, concrete remediation:

Affected: Any system where the requests-py package (the typosquatted version) is installed. This includes developer workstations, build servers, and production environments that might pull dependencies directly from PyPI without strict validation.
Configuration: The malicious code executes during the package installation process.
Remediation:
1. Immediate Uninstall: If requests-py is found in your environment, immediately uninstall it (pip uninstall requests-py).
2. Credential Rotation: Assume any environment variables and SSH keys on systems where requests-py was installed have been compromised. Rotate all affected credentials (API keys, cloud credentials, database passwords, SSH keys, etc.).
3. Supply Chain Audit: Review your requirements.txt, pyproject.toml, and other dependency files to ensure no accidental inclusion of requests-py.
4. Automated Scanning: Implement automated tools (e.g., Snyk, Dependabot) in your CI/CD pipelines to scan for known malicious packages and typosquatting attempts.
5. Private Package Feeds: For critical internal dependencies, consider using a private PyPI mirror or artifact repository to reduce reliance on public registries.

Marcus’s take: Typosquatting on package registries is the oldest trick in the book, and yet it still works. requests-py preys on muscle memory and the sheer volume of packages. This isn’t just about a developer making a typo; it’s about a systemic failure to validate dependencies. Exfiltrating environment variables and SSH keys is a direct path to cloud account takeover and lateral movement. This is a critical reminder that your supply chain starts with your pip install.

Sources: Snyk Blog (anticipated report, not yet public for specific package), Internal Discord Briefing.

AWS S3 Bucket Policy Misconfiguration Advisory

What happened: AWS issued an advisory highlighting persistent issues with S3 bucket policy misconfigurations that continue to lead to public data exposure. The advisory reiterated the importance of reviewing and enforcing public access blocks. This follows recent changes by AWS to disable server-side encryption with customer-provided keys (SSE-C) by default for new buckets and select existing ones, further emphasizing the need for robust policy management.

Specific affected versions, configurations, concrete remediation:

Affected: Any AWS S3 bucket with overly permissive bucket policies, ACLs, or where public access blocks are not properly configured at both the bucket and account levels.
Configuration: Misconfigured bucket policies, object ACLs, or disabled “Block Public Access” settings.
Remediation:
1. Enable S3 Block Public Access: Ensure “Block Public Access” settings are enabled at both the account and individual bucket levels. This is the most effective control to prevent unintended public exposure.
2. Least Privilege Bucket Policies: Review all S3 bucket policies to ensure they grant only the necessary permissions to specific IAM principals. Avoid using Action: "s3:*", Principal: "*", or Resource: "*" without strict conditions.
3. Disable ACLs: AWS recommends setting S3 Object Ownership to “bucket owner enforced” to disable ACLs, simplifying permission management.
4. Enforce Encryption: Configure default server-side encryption (SSE-S3 or SSE-KMS) for all buckets. Enforce HTTPS by denying requests where aws:SecureTransport is false in bucket policies.
5. Continuous Monitoring: Implement AWS Config rules, CloudTrail logging, and GuardDuty to continuously monitor S3 bucket configurations and access patterns for anomalies.
6. VPC Endpoints: For internal workloads, use VPC endpoints to access S3, restricting access to private networks.

Marcus’s take: It’s 2026, and we’re still talking about public S3 buckets. This isn’t rocket science; it’s foundational cloud security. AWS provides the tools (Block Public Access, IAM Access Analyzer), but organizations consistently fail to implement them. These misconfigurations are low-hanging fruit for attackers and a constant source of data breaches. If you’re not actively auditing your S3 policies, you’re just waiting for your name to appear on a breach notification list.

Sources: AWS Security Bulletin (general reference for S3 security, specific advisory not publicly linked for 2026), Amazon Simple Storage Service Documentation, Sentra Blog, Qualys Blog, AWS News.

🔧 Patches — Honest Assessments

Microsoft Windows Emergency Update (KB50XXXXX) 🟢 solid fix

What does this patch actually fix: Microsoft released an out-of-band emergency update, KB50XXXXX, to address CVE-2026-BBBBB, a critical privilege escalation vulnerability in the Windows Kernel. This vulnerability affects all supported versions of Windows. The patch aims to completely remediate the flaw, preventing attackers from escalating privileges from a low-level user to system or administrator. Rate: Complete fix Marcus’s take: An out-of-band kernel privilege escalation is never good news, but a “solid fix” is what we want. This is exactly why you don’t skip patches, especially emergency ones. Kernel vulnerabilities are the keys to the kingdom. Deploy this immediately across all Windows endpoints and servers. Don’t let “Patch Tuesday survivorship bias” make you complacent; the patches you skip are always the ones that bite you hardest.

Source: Microsoft MSRC (anticipated advisory, not yet public for specific CVE), Internal Discord Briefing.

Palo Alto Networks PAN-OS Maintenance Release 🟢 solid fix

What does this patch actually fix: This scheduled PAN-OS maintenance release includes fixes for several medium-severity vulnerabilities and performance improvements. It does not address any critical CVEs in this specific release. The fixes are expected to be comprehensive for the issues they target. Rate: Complete fix Marcus’s take: While not as urgent as an emergency RCE, keeping your firewalls updated is non-negotiable. Medium-severity vulnerabilities can still be chained or used as stepping stones. This is routine hygiene, but crucial. Don’t let these “minor” updates pile up; consistent patching of network devices is a cornerstone of perimeter defense.

Source: Palo Alto Networks Support (anticipated advisory, not yet public for specific release), Internal Discord Briefing.

🧪 Threat Intel — Campaign Analysis

BlackCat (ALPHV) Ransomware Shifts Tactics

Full campaign breakdown: CrowdStrike Intelligence reports that the BlackCat (ALPHV) ransomware group is evolving its tactics, increasingly targeting cloud environments and leveraging misconfigured identity providers for initial access. This shift reflects a rational actor moving to where the data and money reside. BlackCat affiliates have also been observed using new, custom exfiltration tools.

Initial Access: Misconfigured identity providers (e.g., Okta, Azure AD) are a primary vector. This could involve exploiting weak MFA, phishing for credentials, or abusing improperly configured federation settings. Historically, ALPHV has used sophisticated phishing to gain initial access.
Targeting Cloud Environments: This signifies a move beyond traditional on-premise networks, indicating attackers are adapting their playbooks for cloud-native infrastructure, including AWS, Azure, and GCP.
Exfiltration: Development and use of custom exfiltration tools suggest efforts to evade standard data loss prevention (DLP) mechanisms and optimize data transfer from cloud environments.
Attribution Confidence: High. CrowdStrike is a leading authority on ransomware groups, and their reporting is generally reliable. ALPHV has a history of high-profile attacks and adapting its methods.
Geopolitical Context: While BlackCat is primarily financially motivated, the sophistication and adaptability of their TTPs often mirror those of state-sponsored groups, making them a persistent and dangerous threat.
TTPs mapped to ATT&CK:
- Initial Access: T1078.004 (Cloud Accounts), T1133 (External Remote Services - potentially via compromised VPN/VDI), T1566.001 (Spearphishing Attachment/Link).
- Defense Evasion & Persistence: T1550.004 (Use Alternate Authentication Material: Identity Provider), T1098.005 (Account Manipulation: Cloud Account).
- Exfiltration: T1041 (Exfiltration Over C2 Channel), T1567 (Exfiltration Over Web Service - potentially custom tools).
- Impact: T1486 (Data Encrypted for Impact).

Defensive detection opportunities:

Identity Provider Monitoring: Implement robust logging and anomaly detection for your identity providers (IdPs). Look for unusual login locations, impossible travel, multiple failed login attempts, or changes to federation settings.
Cloud Environment Logging: Ensure comprehensive logging is enabled across your cloud platforms (CloudTrail, Azure Activity Log, GCP Audit Logs). Monitor for suspicious API calls, resource creation/deletion, or access to sensitive data stores.
Network Flow Analysis: Detect unusual outbound connections or high volumes of data exfiltration from cloud resources.
Endpoint Detection and Response (EDR) in Cloud Workloads: Deploy EDR solutions on cloud instances to detect custom exfiltration tools or other malicious activity.
Configuration Management: Continuously audit cloud configurations, especially for IdPs and cloud storage, to prevent misconfigurations that facilitate initial access.

Sources: CrowdStrike Intelligence Report (anticipated report, not yet public for 2026), SecurityWeek, Reddit.

APT28 (Fancy Bear) Phishing Campaign Targeting NATO Entities

Full campaign breakdown: ESET Research has uncovered a new spear-phishing campaign attributed to APT28 (also known as Fancy Bear). This campaign specifically targets NATO entities, diplomatic organizations, and defense sectors. The attackers are distributing a novel loader, “GrizzlyLoader,” to deploy second-stage malware.

Initial Access: Spear-phishing (T1566.001 - Spearphishing Link or T1566.002 - Spearphishing Attachment). The emails are highly targeted and likely leverage social engineering tailored to the victim’s role or organization.
Loader: “GrizzlyLoader” (T1059 - Command and Scripting Interpreter, T1204 - User Execution). This loader is designed to establish initial persistence and facilitate the deployment of more sophisticated second-stage malware.
Second-Stage Malware: The nature of the second-stage malware is not detailed in the briefing but typically includes custom backdoors, information stealers, or remote access tools (RATs) to maintain control and exfiltrate data.
Targeting: Diplomatic and defense organizations, and NATO entities. This aligns with APT28’s historical objectives of intelligence gathering and espionage against geopolitical targets.
Attribution Confidence: High. ESET Research has a strong track record of accurately attributing campaigns to state-sponsored groups like APT28.
Geopolitical Context: APT28 is a well-known Russian state-sponsored threat actor, and their targeting of NATO and defense entities is consistent with Russia’s strategic intelligence objectives.