Tenable Blog

Tenable’s Research Special Operations team focuses on some frequently asked questions about Iranian cyber operations, including the tactics, techniques and procedures employed by Iran-based threat actors.

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding Iranian cyber operations in the wake of the recent conflict and warnings from U.S. government agencies, including the Department of Homeland Security (DHS), about potential retaliatory attacks from cyber actors affiliated with the Iranian government as well as hacktivists.

This FAQ provides a focused analysis of Iranian state-sponsored cyber threats, detailing the types of threats used by Advanced Persistent Threat (APT) groups, tactics, techniques and procedures (TTPs) mapped to the MITRE ATT&CK framework and the specific vulnerabilities they consistently exploit. We also provide guidance about Tenable product coverage you can use to reduce your cyber exposure to these threats.

Has there been an increase in threat activity related to Iran-based threat actors?

While there have been ample warnings from U.S. government agencies about retaliatory attacks, we’re also seeing a slight increase in reported activity by threat actors. Reports have cited that threat actors have begun targeting U.S. finance, defense, and energy sectors. While this activity has been limited to distributed-denial-of-service (DDoS) attacks, there have also been recent reports of an increase in targeted phishing attacks.

Which threat actors are believed to be Iran-based or linked to the Iranian government?

In recent years, several Iran-based groups have been identified by security vendors and U.S. government agencies, including the Cybersecurity and Infrastructure Security Agency (CISA). In some alerts, threat activity has been linked to the Iranian Islamic Revolutionary Guard Corps (IRGC), while other APT groups and hacktivist groups have been identified as having ties to Iran. The table below outlines the groups and known activities linked to them. While this is not an exhaustive list of all known APTs and threat actors known to have previously been attributed to Iran, these groups have been recent subjects of CISA and other U.S. government alerts and have been featured in reports from multiple security vendors.

Pioneer Kitten

Fox Kitten

UNC757

Parisite

RUBIDIUM

Lemon Sandstorm

Br0k3r

xplfinder

APT35

CALANQUE

Charming Kitten

CharmingCypress

ITG18

Mint Sandstorm (formerly Phosphorus)

Newscaster

TA453

Yellow Garuda

Educated Manticore

APT42*

Agent Serpens

UNC788

Social engineering campaigns targeting journalists and internet-facing applications

*APT42 is a subcluster of APT35 and also poses as journalists in order to harvest credentials. Some aliases overlap between these groups.

APT34

OilRig

Helix Kitten

Hazel Sandstorm

Earth Simnavaz

MuddyWater

Earth Vetala

MERCURY

Static Kitten

Seedworm

TEMP.Zagros

Agrius

Pink Sandstorm

Banished Kitten

Dune

What are the vulnerabilities that have been targeted by Iranian threat actors?

The following table contains a list of CVEs that have been known to be exploited by Iran-based threat actors. This list of CVEs covers a wide range of commonly exploited vulnerabilities that have also been abused by a wide variety of threat actors beyond just Iran-based APTs or state-sponsored actors.

*Please note: Tenable’s Vulnerability Priority Rating (VPR) scores are calculated nightly. This blog post was published on June 27 and reflects VPR at that time.

Has Tenable released any product coverage for these vulnerabilities?

The CVEs covered in this blog have product coverage from Tenable. A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages:

• CVE-2017-11774
• CVE-2018-13379
• CVE-2019-0604
• CVE-2019-11510
• CVE-2019-19781
• CVE-2019-5591
• CVE-2020-12812
• CVE-2020-1472
• CVE-2021-31207
• CVE-2021-34473
• CVE-2021-34523
• CVE-2021-44228
• CVE-2021-45046
• CVE-2021-45105
• CVE-2022-1388
• CVE-2022-26134
• CVE-2022-30190
• CVE-2022-42475
• CVE-2022-47966
• CVE-2022-47986
• CVE-2023-27350
• CVE-2023-3519
• CVE-2023-38831
• CVE-2023-46805
• CVE-2023-6448
• CVE-2024-21887
• CVE-2024-24919
• CVE-2024-30088
• CVE-2024-3400

These links will display all available plugins for the listed vulnerabilities, including upcoming plugins in our Plugins Pipeline. In addition to plugin coverage, the tables below highlight additional Tenable product coverage for the MITRE ATT&CK IDs that are known to be associated with Iran-based threat actors.

Tenable attack path techniques

T1069.003_Azure

T1069.003_AWS

T1098.001_Azure

T1098.001_AWS

T1098.003_Azure

T1098.004

T1133_AWS

T1133_Azure

T1133_Windows

T1555.004_Windows

T1555.006

Tenable Identity Exposure Indicators of Exposure and Indicators of Attack

C-PROTECTED-USERS-GROUP-UNUSED

I-ProcessInjectionLsass

C-AAD-PRIV-SYNC

C-AAD-SSO-PASSWORD

C-ADM-ACC-USAGE

C-ADMIN-RESTRICT-AUTH

C-ADMINCOUNT-ACCOUNT-PROPS

C-AUTH-SILO

C-BAD-SUCCESSOR

C-CLEARTEXT-PASSWORD

C-DANG-PRIMGROUPID

C-DANGEROUS-SENSITIVE-PRIVILEGES

C-DC-ACCESS-CONSISTENCY

C-DSHEURISTICS

C-EXCHANGE-MEMBERS

C-KERBEROS-CONFIG-ACCOUNT

C-KRBTGT-PASSWORD

C-MSA-COMPLIANCE

C-NATIVE-ADM-GROUP-MEMBERS

C-PASSWORD-DONT-EXPIRE

C-PASSWORD-HASHES-ANALYSIS

C-PASSWORD-NOT-REQUIRED

C-PASSWORD-POLICY

C-PKI-DANG-ACCESS

C-PRIV-ACCOUNTS-SPN

C-PROP-SET-SANITY

C-REVER-PWD-GPO

C-SERVICE-ACCOUNT

C-SLEEPING-ACCOUNTS

C-USER-PASSWORD

HIGH-NUMBER-OF-ADMINISTRATORS

MISSING-MFA-FOR-NON-PRIVILEGED-ACCOUNT

MISSING-MFA-FOR-PRIVILEGED-ACCOUNT

UNRESTRICTED-GUEST-ACCOUNTS

C-GUEST-ACCOUNT

GUEST-ACCOUNT-WITH-A-PRIVILEGED-ROLE

GUEST-ACCOUNTS-WITH-EQUAL-ACCESS-TO-NORMAL-ACCOUNTS

C-AAD-CONNECT

C-ABNORMAL-ENTRIES-IN-SCHEMA

C-CREDENTIAL-ROAMING

C-DANG-PRIMGROUPID

C-DC-ACCESS-CONSISTENCY

C-EXCHANGE-PERMISSIONS

C-PROP-SET-SANITY

C-SDPROP-CONSISTENCY

C-SENSITIVE-CERTIFICATES-ON-USER

C-SHADOW-CREDENTIALS

CONDITIONAL-ACCESS-POLICY-DISABLES-CONTINUOUS-ACCESS-EVALUATION

ENTRA-SECURITY-DEFAULTS-NOT-ENABLED

LEGACY-AUTHENTICATION-NOT-BLOCKED

MFA-NOT-REQUIRED-FOR-A-PRIVILEGED-ROLE

MFA-NOT-REQUIRED-FOR-RISKY-SIGN-INS

MISSING-MFA-FOR-NON-PRIVILEGED-ACCOUNT

MISSING-MFA-FOR-PRIVILEGED-ACCOUNT

SHOW-ADDITIONAL-CONTEXT-IN-MICROSOFT-AUTHENTICATOR-NOTIFICATIONS

USER-WITH-API-TOKEN

C-PASSWORD-HASHES-ANALYSIS

C-PASSWORD-POLICY

I-PasswordSpraying

C-DSHEURISTICS

C-PRE-WIN2000-ACCESS-MEMBERS

C-AAD-PRIV-SYNC

C-SHADOW-CREDENTIALS

I-Kerberoasting

I-UnauthKerberoasting

Tenable Web App Scanning

Tenable OT Security

What else should I do to remain secure?

Cyber hygiene is even more critical in the face of heightened awareness than it is in normal times. Many of the attacks stemming from Iranian-sponsored threat actors mirror tactics used by other cyber actors, including exploiting software and devices that use weak authentication. Attacks have also targeted operational technology (OT) devices. To strengthen your cyber defenses, we recommend:

• Using strong passwords and enforcing a strong password policy
• Enabling multi-factor authentication (MFA)
• Changing default passwords, especially on OT hardware
• Patching vulnerabilities in assets exposed to the internet
• Identifying and prioritizing your most valuable assets for remediation
• Developing a remediation plan and continuing to test and improve it

• Tenable Blog: Navigating a Heightened Cyber Threat Landscape: Military Conflict Increases Attack Risks
• Tenable Blog: AA24-241A : Joint Cybersecurity Advisory on Iran-based Cyber Actors Targeting US Organizations
• Tenable Blog: AA22-257A: Cybersecurity Agencies Issue Joint Advisory on Iranian Islamic Revolutionary Guard Corps-Affiliated Attacks
• Department of Homeland Security National Terrorism Advisory System Bulletin - June 22, 2025

Join Tenable's Research Special Operations (RSO) Team on the Tenable Community.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Don’t let hidden cloud risks become tomorrow’s headline breach. The time to dismantle the toxic cloud trilogy is now. Here’s how Tenable Cloud Security can help.

In today’s cloud environments, individual misconfigurations or vulnerabilities are dangerous — but it’s their combinations that can lead to catastrophic breaches. The Tenable Cloud Security Risk Report 2025 reveals that nearly 29% of organizations still have at least one toxic cloud trilogy. While this is a reduction from last year, it’s still alarming. These high-risk clusters occur when a single cloud workload is:

• Publicly exposed to the internet
• Critically vulnerable due to unpatched CVEs
• Over-permissioned, with identity and access management (IAM) roles that allow lateral movement or privilege escalation

This trifecta has the potential to open up a highly exploitable attack path in the cloud.

Let’s walk through a real-world example:

1. An attacker scans public IP ranges and finds an Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instance running a web server (public exposure)
2. They detect an unpatched remote code execution (RCE) vulnerability in that server (critical vulnerability).
3. Upon exploitation, they gain access to an IAM role with iam:PassRole, ec2:RunInstances, or even *:* (excessive permission).
4. The result? Full environment compromise — which could enable actions including sensitive data exfiltration or infrastructure takeover.

This is not a rare edge case. Tenable’s research shows that toxic trilogies are still common, often born from the “get it working fast” mentality during development — and left unremediated in production.

Many organizations scan infrastructure-as-code but neglect active cloud workloads, missing CVEs that exist in live environments. In some cases, teams delay mitigation to wait for all patches to be available or lack urgency because they don’t have context into the true risk of the vulnerability.

✅ Tenable Cloud Security advantage:

• Agentless scanning of cloud workloads in runtime.
• Integrated code-to-cloud visibility — from CI/CD pipelines to production environments.
• Exposure-aware prioritization of vulnerabilities that factors in public access and identity privileges.

Misconfigured security groups, open ports or overexposed resources make workloads discoverable and attackable from the internet.

✅ Tenable Cloud Security advantage:

• Continuous monitoring of cloud network configurations.
• Automated detection of public access paths to high-value assets.
• Risk scoring that increases based on combined exposure and vulnerability context, including likelihood of exploitation.

IAM roles are often over-permissioned during development and never scoped down. Overly broad policies are an open invitation to attackers.

✅ Tenable Cloud Security advantage:

• Integrated cloud infrastructure and entitlement management (CIEM) capabilities to map effective permissions across all identities.
• Least privilege policy recommendations generated from real-world usage patterns, and Just in Time (JIT) access for least-privilege granularity through time limits.
• Detection of trust policy misconfigurations that enable unintended role assumptions.

Security teams lack a unified view that correlates identity, network and workload risk across hybrid environments.

✅ Tenable One platform integration:

• Tenable Cloud Security feeds into the Tenable One Exposure Management Platform, delivering unified visibility and analytics.
• See the full attack path — not just individual issues — with automated toxic risk detection.
• Prioritize what matters most using cross-domain context (identity + vulnerability + exposure).

To eliminate toxic workload risk, security teams need more than scanning — they need continuous, contextualized security across the full stack. Tenable’s cloud-native application protection platform (CNAPP) capabilities offer:

• Identify vulnerabilities not just by severity, but by exposure and exploitability.
• Scan both static code and live cloud assets for comprehensive coverage.

• Automatically identify toxic combinations across your cloud infrastructure.
• Visualize attack paths and sever the most critical links before attackers can use them.

• Continuously audit all IAM roles, users and service identities.
• Detect unused credentials, over-permissioned roles and dangerous trust relationships.

• Tenable ranks toxic trilogies as top risks, not isolated misconfigurations.
• Prioritization is driven by real-world exploitation potential — not theoretical risk.

A critical CVE on an isolated virtual machine isn’t your biggest risk. But a medium-severity bug on a public-facing container with excessive IAM rights? That’s breach material.

Tenable Cloud Security gives you the visibility to find these toxic combinations fast — and the context to fix them before they’re exploited. Tenable Cloud Security, as part of Tenable One, gives you that kind of visibility across your hybrid cloud.

• ➡️ Download the Tenable Cloud Security Risk Report 2025
• ➡️ Read Part 1 of this blog series: Secrets in the Open: Cloud Data Exposures That Put Your Business at Risk

Tenable One empowers security teams to go beyond surface-level risk tracking and drive measurable improvements across their security programs. With unified visibility and customizable dashboards, Tenable One makes it easy to monitor the KPIs that matter most, helping teams shift from reactive firefighting to proactive, strategic exposure management.

Effective exposure management isn't just about identifying risks — it's about continuously measuring and reducing real exposure. Key performance indicators (KPIs) provide security teams with critical visibility into program effectiveness, helping them prioritize actions, monitor progress and ensure alignment with broader business objectives.

In this blog, we’ll highlight the top KPIs Tenable One customers track to reduce risk, accelerate remediation and demonstrate impact to stakeholders.

Tracking service level agreement (SLA) performance is crucial for understanding how consistently your organization meets its remediation targets. This provides insight into whether your security team is keeping pace with exposure management commitments or if risk is accumulating across specific asset groups.

• SLA Compliant Assets Over Time: This metric offers visibility into how well your organization is meeting its remediation goals. It highlights which areas are effectively keeping up with exposure resolution and where unresolved risks may be building up.
   

  Tenable One dashboard widget 

• Top Critical and High Detections by Number of Findings Exceeding SLA: These metrics highlight growing technical debt — findings that remain unresolved beyond their expected timelines, increasing your organization's risk exposure. Consistent tracking allows for early detection of bottlenecks, ownership gaps, or resource constraints before they lead to larger, more challenging risks. By tracking findings approaching SLA, teams gain a proactive view, enabling them to act on critical assets — either through remediation or mitigation – before SLA breaches occur.

  Tenable One dashboard widget 

Monitoring trends in these KPIs allows organizations to identify periods of declining compliance and pinpoint areas requiring immediate attention.

A holistic understanding of your organization's risk posture and evolution over time is fundamental to strategic exposure management. 

• Cyber Exposure Score (CES) Over Time: This metric provides a high-level view of your organization’s total risk exposure. It aggregates risk across all assets, reflecting how the attack surface evolves and whether remediation efforts are effectively reducing overall risk. Monitoring CES trends helps your security team understand the direction of their risk posture — whether it's improving, plateauing, or worsening — and serves as a strategic signal for leadership.

  Tenable One dashboard widget 

• Assets Exposure Score by Exposure Category (VM, OT, Cloud, etc.): This metric allows you to compare risk posture across different technology stacks, prioritize remediation efforts and allocate resources to areas with the highest average exposure.

  Tenable One dashboard widget

• CES Exposure Score by Exposure Category and Asset Type: This metric helps identify whether specific asset types within a category disproportionately contribute to cumulative risk, facilitating precise action and enabling data-driven decisions on resource allocation.

  Tenable One dashboard widget

Tracking these metrics enables data-driven decisions on resource allocation. It allows for drill-downs into contributing assets and exposure categories, ensuring your efforts are always aligned with the most critical risks.

Effective remediation tracking is critical to ensuring weaknesses are not merely detected but addressed promptly and consistently. This category of KPIs focuses on measuring the efficiency of vulnerability resolution, tracking how long issues remain open and identifying potential delays or regressions.

• Findings by State Over Time: This metric illustrates the progression of findings through "Active," "Fixed," and "Resurfaced" states over time. It offers visibility into remediation volume, closure rates and recurring issues. A steady increase in resurfaced findings can indicate incomplete fixes or recurring vulnerabilities due to configuration drift or asset churn.

  Tenable One Dashboard Widget

• Findings Age by Severity: This metric highlights which high-severity issues are aging without resolution, serving as a key risk indicator tied to SLA adherence.

  Tenable One dashboard widget 

• Average Remediation Days by Asset Type: This metric helps uncover which teams or environments take longer to remediate issues, pointing to inefficiencies or gaps in ownership.

  Tenable One dashboard widget

When tracked collectively, these metrics empower security teams to assess the speed and consistency of remediation; detect bottlenecks and high-risk delays across severity levels and asset owners; and focus remediation efforts where they are most impactful. Organizations can monitor and fix trends, investigate spikes in resurfaced findings, and benchmark asset groups based on average remediation time to drive process improvements.

Tenable One provides security teams with unified, customizable risk dashboards and reports. These tools offer the actionable insights needed to track and optimize your exposure management outcomes, empowering your organization to effectively measure, manage and reduce exposure risk.

By effectively tracking these essential KPIs within Tenable One, organizations can:

• Reduce risk and prevent breaches

Make data-driven decisions to focus remediation efforts where they matter most, optimize resource allocation and proactively address critical risks before they escalate.

• Accelerate remediation

Identify remediation bottlenecks and ownership gaps to drive accountability, ensure timely resolution of high-risk issues and track progress to stay on target with SLA commitments.

• Secure budget and buy-in

Communicate program effectiveness and measurable improvements to stakeholders, demonstrating how security initiatives directly support business goals and reduce organizational risk.

Explore how Tenable One can empower your organization to quantify and reduce exposure risk.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. This week, Tenable experts discuss best practices for communicating cyber risk. You can read the entire Exposure Management Academy series here.

Despite headline-grabbing incidents and keen interest from C-suites and boardrooms, many security leaders still struggle to gain executive buy-in or rally cross-departmental support. The challenge isn't the data itself. On the contrary, it’s often how you deliver the message. Many security teams are buried in mounds of information from an array of disconnected security solutions. This makes it tough to present a consolidated, understandable overview of cyber risk.

That brings up a couple of questions. First, what can you do to fix this communication challenge and improve how technical teams convey risk to non-technical decision-makers? Second, how can security teams give context to their IT counterparts to effectively prioritize remediation efforts? One way is to move to exposure management. 

Exposure management gives security leaders the processes and technologies they need to continuously assess the accessibility, exploitability and criticality of digital assets across all systems, applications, devices, resources and identities. As a result, security leaders can proactively answer questions about their organization’s exposure risk. 

A well-executed exposure management program can help you distill complex issues and vast stores of data into clear, digestible metrics. You’ll also be able to avoid overly technical language, which will help engage with leadership and board members. And you’ll avoid burning out your IT teams with endless tasks by giving them real-world guidance about what to fix first and why.

Security professionals understand technical jargon. But most others don’t. Board members focus on business disruption, liability and cost. C-level executives worry about the overall strategic direction of the business, along with any risks that might imperil the future of the organization. Other executives, especially those who run a line of business, are laser-focused on their respective areas. They appreciate security but likely don’t know the lingo and lack the context needed to understand cyber risk.

Exposure management helps translate technical complexity into clear, concise business language. This translation is vital for winning executive support and for shifting security from a reactive posture to a strategic mindset 

Jorge Orchilles, Senior Director of Readiness and Proactive Security at Verizon, summed it up well in his contribution to the Exposure Management Academy: “Instead of delivering long lists of vulnerabilities that mean little to non-technical leaders, we can present a clear picture in a few key points.”

A primary stumbling block that stands in the way of clear communication in cybersecurity is information overload, with teams often buried in alerts and data, much of which is just noise.

As Robert Huber, Tenable’s Chief Security Officer and Head of Research, wrote recently, “Not all risks are created equal.” He says that, if you think of everything as a top priority, then nothing is. 

An exposure management program can help organizations focus on the issues that pose a true disruption to the business. That clarity, which distinguishes between meaningful signals and background noise, is invaluable for making better, more explainable decisions. Huber says that this approach has enabled his team to zero in on critical issues so they can focus on what really matters and drive the right outcomes.

Effective cyber risk management can be hindered when IT and security operate in separate spheres, speaking different languages, which can create friction and missed opportunities.

An exposure management platform can offer a common framework and a shared view of risk for both security and IT. Tenable’s CIO, Patricia Grant, sees securing the enterprise as a joint responsibility. 

“The security team sets the posture,” she says. “But IT owns the infrastructure. Exposure management gives us a common language to operate in.” 

Grant adds that, when you can put an issue in the context of the risk it poses, rather than just thinking about it as another patch, you’ll see much better engagement. The lesson here is that clear communication is more than a nicety. It can create action. Moreover, when technical teams and business stakeholders align, they agree on priorities and make progress.

Successful exposure management extends beyond prioritizing known vulnerabilities. It provides a full picture of deficiencies across all your environments. 

“As security professionals, we’ve had to move away from thinking of cybersecurity as just ‘scan-patch-rescan,’” says Arnie Cabral, Senior Staff Security Engineer at Tenable, echoing Grant. “Exposure management has been the catalyst for that shift and gives us a much broader lens with the ability to narrow the scope.”

This fresh perspective can yield surprising benefits. 

“Our exposure management platform became our de facto inventory tool,” Cabral says. “There were times people would ask, ‘What’s this asset doing here?’ We didn’t have an easy answer. Now, we do. We’re able to transform the data into actual usable information with real insight.” 

That visibility, combined with clear communication about the risk implications of these findings, helps his team connect with wider stakeholders. “We’re doing more than just fixing exposures,” he says. “We’re helping the business as a whole understand its risk and take actions where necessary.”

By enabling a centralized perspective, exposure management can foster more straightforward communication throughout an organization with consistent metrics and easily understandable visuals. 

Of course, technical specialists can access the detailed data that’s essential for their work. But, at the same time, executives and board members will gain a clear understanding of the organization's overall security status. They’ll see the areas that need attention without needing to decipher complex technical details. 

All members of an organization — technical and non-technical — can compare performance against industry counterparts and monitor key performance indicators (KPIs) over time. This benchmarking helps provide invaluable context and addresses the common question that plagues us all: "How is the organization performing?" 

These valuable perspectives enable more targeted resource deployment and build cooperation across different business units by furnishing the metrics they care about.

Ultimately, exposure management helps organizations transcend the limitations of isolated data and inscrutable terminology. It creates a comprehensive awareness of the entire attack surface, which lets security leaders clearly define risk, demonstrate progress and helps everyone understand their role in an organization's cyber readiness.

• Check out the Tenable exposure management resource center to discover the value of exposure management and explore resources to help you stand up a continuous threat exposure management program.

Check out highlights from Tenable’s “2025 Cloud Security Risk Report,” which delves into the critical risk from insecure cloud configurations. Plus, Google reveals a Russia-sponsored social engineering campaign that targeted prominent academics’ Gmail accounts. And get the latest on AI system security, just-in-time access, CIS Benchmarks and more!

Dive into six things that are top of mind for the week ending June 20.

Houston, we have a cloud data-security problem.

Tenable’s “2025 Cloud Security Risk Report,” published this week, found that 9% of publicly accessible cloud-storage resources hold sensitive data, almost all of which – 97% – is labeled as either restricted or confidential.

“This kind of exposure creates an ideal entry point for threat actors and poses a serious, immediate security risk,” reads the report, which provides in-depth coverage of cloud security issues including data and secrets exposure; identity management; cloud workload protection; and artificial intelligence (AI) defense.

The report, authored by the Tenable Cloud Research team, is based on workload telemetry analysis from public cloud and enterprise environments scanned with the Tenable Cloud Security cloud native application protection platform (CNAPP) between October 2024 and March 2025.

Other key findings include:

• 54% of the organizations using Amazon Web Services (AWS) Elastic Container Service (ECS) task definitions have at least one secret – meaning, a privileged credential – embedded in their configurations, which creates a direct attack path.
• 29% of organizations have at least one toxic cloud trilogy — meaning a cloud workload that is publicly exposed, critically vulnerable and highly privileged. This stat is down nine percentage points from the previous report, but it’s still too high.
   

(Tenable’s “2025 Cloud Security Risk Report,” June 2025)

Here are some solid tips and best practices from the report:

• Continuously monitor for public access and automate detection of misconfigured storage services.
• Safeguard secrets by using the secrets-management tools that cloud service providers (CSPs) provide.
• Detect toxic cloud trilogies by correlating identity, vulnerability and network configuration data.
• Boost cloud identity security by adopting just-in-time access capabilities, which put a time limit on access granted to identities.
• Inventory, classify and track your sensitive data in your cloud environment.

To get more details, check out:

• The blog “Secrets in the Open: Cloud Data Exposures That Put Your Business at Risk”
• The announcement “Tenable Research Finds Pervasive Cloud Misconfigurations Exposing Critical Data and Secrets”
• The full report “2025 Cloud Security Risk Report”
• The upcoming webinar “Why Your Cloud Data May Not Be Secure After All: Insights from Tenable Research”
• The blog “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources”

A threat actor sponsored by the Russian government recently impersonated U.S. Department of State staff and gained persistent access to the email mailboxes of prominent academics and Russia critics.

That’s according to the Google Threat Intelligence Group, which detailed the social engineering impersonation scheme in a blog post this week.

The threat actor targeted its victims between April and early June of this year by establishing rapport with them and luring them to set application specific passwords (ASPs).

An ASP is a ransonly-generated 16-digit passcode that allows a Google user to grant access to their Google account to a third-party app or device that doesn’t support “Sign in with Google” authentication nor two-step verification.
 

In this case, the threat actor emailed victims a PDF document inviting them to access a fraudulent State Department cloud environment. The instructions prompted victims to create an ASP.

“Once the target shares the ASP passcode, the attackers establish persistent access to the victim’s mailbox,” reads the blog post, which cites research from Citizen Lab about this same campaign. Google has “re-secured” the Gmail accounts compromised during this social engineering campaign.

In the blog, Google states that using ASPs isn’t recommended and that they’re “unnecessary in most cases.” If a user generates an ASP, Google sends a notification to their Gmail account, recovery email address and any devices signed into the Google account. Users can revoke ASPs on demand.

For more information about preventing social engineering attacks:

• “How to avoid and prevent social engineering attacks” (TechTarget)
• “Understanding Social Engineering: Tactics, Threats, and Prevention” (CTO Magazine)
• “Phishing attacks: defending your organisation” (U.K. National Cyber Security Centre)
• “What are social engineering attacks?” (TechTarget)
• “How AI is making phishing attacks more dangerous” (TechTarget)

Looking to boost your strategies and practices for securing your AI systems? A new report aims to unpack the technology layers that make up an AI system, hoping that a clearer understanding of this “tech stack” will lead to improved AI security.

The Paladin Global Institute’s “The AI Tech Stack: A Primer for Tech and Cyber Policy” report is aimed at cybersecurity practitioners, IT professionals and policy makers, because it’s critical for these three groups to have a solid grasp of how AI systems are built and deployed.

“This framing will give policymakers and tech innovators the tools to take an informed approach to AI security,” Kemba Walden, President of Paladin Global Institute, said in a statement.

The report outlines five core, interdependent layers of the AI “tech stack”:

• Governance: This layer includes a scaffolding of security protocols, legal requirements, ethical principles and policies for secure AI development and deployment.
• Application: This layer consists of the user interface via which AI capabilities are offered to users, including AI chatbots, search engines and voice assistants.
• Infrastructure: This layer is made up of the computational foundation powering AI systems, such as data centers, networks and energy systems.
• Model: This is the “core computational component” where data is processed according to sophisticated AI algorithms in order to pinpoint patterns, generate decisions and more.
• Data: Here resides the foundational raw information that fuels AI models.

“Robust security across this stack is a technical necessity and a strategic imperative,” the report reads.

As shown in the table below, the report explains the security risks in each layer of the AI “tech stack.”

(Source: Paladin Global Institute’s “The AI Tech Stack: A Primer for Tech and Cyber Policy” report, June 2025)

The report also offers recommendations for preventing and mitigating the key cyber threats faced by AI systems. It argues that the right security strategy is to take a systemic approach, as opposed to isolated controls. The report also calls for embedding security starting in the early stages of AI system development.

Recommendations include:

• Securing the data layer with encryption and access controls
• Housing the model layer in environments protected with robust access controls and secure APIs
• Applying foundational cybersecurity practices to the infrastructure and application layers, as well as AI-specific protections
• Developing dynamic, interoperable standards in the governance layer, in order to boost trust in AI systems

For more information about AI security, check out these Tenable resources:

• “Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?” (on-demand webinar)
• “Who's Afraid of AI Risk in Cloud Environments?” (blog)
• “Tenable Cloud AI Risk Report 2025” (research report)
• “2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud” (on-demand webinar)
• “How AI Can Boost Your Cybersecurity Program” (blog)

During our recent webinar “Tenable Cloud Security Customer Update, June 2025,” we polled attendees about their use of just-in-time (JIT) access and about how automated their detection of overprivileged identities is. Check out what they said.

(19 webinar attendees polled by Tenable, June 2025)

(19 webinar attendees polled by Tenable, June 2025)

Watch this on-demand webinar to learn about how JIT access can slash your exposures from compromised identities.

Attackers are launching ransomware attacks by exploiting vulnerabilities in SimpleHelp’s eponymous remote monitoring and management product.

That’s the warning from the U.S. Cybersecurity and Infrastructure Security Agency (CISA), which added that victims include customers of a utility billing software provider.

“This incident reflects a broader pattern of ransomware actors targeting organizations through unpatched versions of SimpleHelp RMM since January 2025,” reads CISA’s cybersecurity advisory.
 

SimpleHelp’s versions 5.5.7 and earlier contain several vulnerabilities, including the path traversal vulnerability CVE-2024-57727, which is likely the one the ransomware attackers are exploiting, according to CISA.

Recommended mitigations include:

• Vulnerable third-party vendors:
  • Immediately upgrade from SimpleHelp versions 5.5.7 or earlier to the latest version of the product.
  • Direct your downstream customers to secure their endpoints and conduct threat hunting on their network.
• Vulnerable downstream customers and end users:
  • Determine if you’re running an unpatched SimpleHelp version directly or embedded in third-party software.
  • Immediately upgrade to the latest version of the product.
• Downstream customers and end users with systems encrypted via ransomware:
  • Take the compromised system offline.
  • Reinstall the operating system using a bootable USB drive or DVD
  • Wipe the system and restore data exclusively from a clean backup.

CISA also offers proactive mitigation recommendations, such as:

• Keep an update inventory of all your software and hardware assets.
• Back up your system on a daily basis to a separate offline device.
• If possible, don’t expose remote access services to the web.

To get more details, read:

• The CISA advisory “Ransomware Actors Exploit Unpatched SimpleHelp Remote Monitoring and Management to Compromise Utility Billing Software Provider”
• The CISA alert “CISA Releases Cybersecurity Advisory on SimpleHelp RMM Vulnerability”

If your organization uses the CIS Benchmarks to tighten up software configurations, this one's for you.

The Center for Internet Security (CIS) has updated 12 of its CIS Benchmarks secure configuration guidelines, including those for Amazon Elastick Kubernetes Service, Microsoft 365 and Google Cloud Platform.

Specifically, these CIS Benchmarks were updated:

• CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.7.0
• CIS Cisco IOS XE 17.x Benchmark v2.2.0
• CIS Google Cloud Platform Foundation Benchmark v4.0.0
• CIS Microsoft 365 Foundations Benchmark v5.0.0
• CIS Microsoft SQL Server 2019 Benchmark v1.5.0 — Final Update
• CIS Microsoft SQL Server 2022 Benchmark v1.2.0
• CIS Microsoft Windows 10 Enterprise Benchmark v4.0.0
• CIS Microsoft Windows 11 Stand-alone Benchmark v4.0.0
• CIS Microsoft Windows Server 2022 Benchmark v4.0.0
• CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) Benchmark v1.7.0
• CIS SUSE Linux Enterprise 12 Benchmark v3.2.1
• CIS VMware ESXi 7.0 Benchmark v1.5.0
   

In addition, CIS released these three brand new Benchmarks:

• CIS Apple MacOS 14.0 Sonoma Intune Benchmark v1.0.0
• CIS Apple MacOS 15.0 Sequoia Intune Benchmark v1.0.0
• CIS Ubuntu Linux 22.04 LTS STIG Benchmark v1.0.0

You can use the CIS Benchmarks’ configuration recommendations to harden products against attacks. There are more than 100 Benchmarks for 25-plus vendor product families. Product categories covered by the CIS Benchmarks include cloud platforms; databases; desktop and server software; mobile devices; operating systems; and more.

To get more details, read the CIS blog “CIS Benchmarks June 2025 Update.” For more information about the CIS Benchmarks list, check out its home page and FAQ, as well as:

• “Getting to Know the CIS Benchmarks” (CIS)
• “Security Via Consensus: Developing the CIS Benchmarks” (Dark Reading)
• “How to Unlock the Security Benefits of the CIS Benchmarks” (Tenable)
• “CIS Benchmarks Communities: Where configurations meet consensus” (Help Net Security)
• “CIS Benchmarks: DevOps Guide to Hardening the Cloud” (DevOps)
   

In this sixth installment of Tenable’s “Stronger Cloud Security in Five” blog series, we offer three recommendations that you can quickly roll out to help you expedite, prioritize and fine-tune how you detect and respond to cloud security issues.

The dynamic, distributed and fast-changing nature of cloud environments makes it imperative for organizations to have a streamlined and swift process for detecting and responding to cloud security issues.

Failure to promptly and effectively respond to cloud security findings can quickly lead to major breaches that threaten your organization’s sensitive data, business operations, regulatory compliance, and more.

As the “SANS 2024 Detection and Response Survey” shows, cloud detection and response is a priority for organizations. The report, based on a survey of almost 400 cybersecurity professionals – including incident response handlers, security analysts, security managers and security directors – found that:

• 53% of respondents planned to adopt more advanced cloud-native security tools.
• 52% were looking to integrate artificial intelligence and machine learning for enhanced threat detection and response.
• 71% planned to boost training for security teams on cloud-specific threats.

In this blog, we offer you three ways to accelerate your response in the cloud. Our recommendations are meant to get you started with a “quick win” that only takes minutes and that can serve as the foundation for implementing best practices with a broader scope.

Read on to get the details on these three tips:

• Sketch out owners for different categories of cloud security findings.
• Think about your most sensitive cloud resources and the types of security findings that – if they affected these resources – would merit a response.
• Set up notifications alerting the appropriate teams about these security findings via messaging tools or ticketing solutions. 

A key for swiftly responding to cloud security issues is knowing who to go to — for particular assets — when in the heat of the moment. 

For a quick win, think about the people who make up your security team and the roles they play in areas such as identity and access management (IAM); DevSecOps; governance, risk and compliance; and vulnerability management; and sketch these key owners out.

If you need to jog your memory, think through different ways your organization might best assign ownership, including:

• By specific cloud accounts or groups of accounts
• By specific types and categories of findings, such as IAM-related issues
• By assigning owners to clusters of resources that belong to a specific project

By documenting the teams that own specific categories of cloud security findings, you pave the way for decisive and quick responses to cloud security issues. 

Having sketched out some of the ownership of security findings, you want to think about one or two of your most sensitive resources and identify which issues impacting them would warrant firing off an alert. The idea here is to set up one or two alerts for issues whose high severity would be obvious, such as suspicious changes to the permissions of an S3 bucket that holds data for your company's payment processing infrastructure. By thinking through this, you will be prioritizing the one or two issues that pose the greatest risk to your cloud environment’s “crown jewels.”

Once you have your rough list of sensitive resources, some critical issues you might be interested in would be:

• Changes being made to sensitive security groups
• Changes to the configuration of critical storage buckets
• Changes to access permissions from internal or external networks

By taking time to think through what your most critical cloud resources are, you will be on a path to proactively applying stronger safeguards and controls to them, thereby reducing the risk they’ll be breached. 

Once you’ve sketched out the key responsibilities across your organization, as well as the critical resources and the critical issues impacting them, the final quick action you can take is to start setting up a few alerts around these connections. 

You don’t need to set up every possible critical alert right now, but starting with one or two of the most critical alerts will give you good momentum to embark on a more comprehensive project later on. If possible, consider integrating your alerting system with a corporate messaging tool, like Slack or Microsoft Teams. This will offer you an effective way to make these notifications timely and actionable. If you have a bit more time, it’s very valuable to integrate this type of notification into your ticketing system or security information and event management (SIEM) system. 

There are different ways in which our Tenable Cloud Security cloud native application protection platform (CNAPP) can help you streamline and automate the three recommendations we’ve outlined in this blog for accelerating your response to cloud security findings.

First, Tenable Cloud Security allows you to assign custom properties and labels that can be applied to resources to add context for risk assessment. These have many uses, and many Tenable customers leverage this capability to tag different resources with their owners.

Tenable Cloud Security offers policy templates that provide a flexible way of defining exactly which resources you want to monitor, how, and for what.

And — of course — Tenable Cloud Security can tie all this together so you can quickly send notifications to resource owners about detected issues that are within their scope of responsibilities. Whichever way your team and your stakeholders work, Tenable Cloud Security can integrate your alerts there with the ability to send alerts and reports to recipients via Slack, Teams, email, Jira, ServiceNow, Datadog, Splunk, QRadar, Sumo Logic and Telegram, as well as to many others via webhooks. 

Find out how you can take action to speed up and fine-tune your cloud detection and response, as well as your overall multi-cloud security in just five minutes.

• "Stronger Cloud Security in Five: The Importance of Cloud Configuration Security"
• "Stronger Cloud Security in Five: How To Protect Your Cloud Workloads"
• "Stronger Cloud Security in Five: Securing Your Cloud Identities"
• “Stronger Cloud Security in Five: How DSPM Helps You Discover, Classify and Secure All Your Data Assets”
• “Stronger Cloud Security in Five: 3 Quick Ways to Improve Kubernetes Security in GCP”

Sensitive data and secrets are leaking. How cloud security leaders can shut them down.

Despite the billions of dollars organizations are investing in cybersecurity, one of the most preventable threats persists: sensitive data and credentials exposed in publicly accessible cloud services. According to the Tenable Cloud Security Risk Report 2025, 9% of public cloud storage resources contain sensitive data — including personally identifiable information (PII), intellectual property (IP), Payment Card Industry (PCI) details, and protected health information (PHI).

Even more concerning, the report shows that over half of organizations using Amazon Web Services (AWS) Elastic Container Service (ECS) task definitions and Google Cloud Platform (GCP) Cloud Run have, knowingly or not, at least one secret embedded in these services.

These exposures are concerning, as they are the kind of exploitable oversights attackers are already scanning for — and weaponizing.

Exposed secrets — like API keys and encryption tokens — can open the door to attackers, enabling lateral movement, data exfiltration or full environment takeover.

This isn’t just a misconfiguration issue. It’s a governance gap, made worse by legacy security tooling and, in some cases, the mistaken perception that native cloud services provide sufficient protection.

Security leaders must shift from detection to prevention and improve their sensitive data protection by enforcing the following:

• Automated data discovery and classification: Know what data lives in your environment and continuously assess its sensitivity. This should be an ongoing, telemetry-driven effort — not a quarterly scan.
• Eliminate public access by default: Enforce least privilege for both data and network access. Public storage should be the rare exception.
• Employ enterprise-grade secrets management: Remove hardcoded secrets and implement cloud-native tools like AWS Secrets Manager and Microsoft Azure Key Vault.
• Cloud Security Posture Management (CSPM): Use identity-intelligent CSPM to unify visibility across your cloud footprint and detect misconfigurations, secrets, and excessive permissions in real time.

Key takeaway: Exposed secrets and sensitive data aren’t obscure edge cases. They’re systemic risks hiding in plain sight — and must be eliminated before attackers exploit them.

• Download the Tenable Cloud Security Risk Report 2025
• Join our upcoming research webinar Why Your Cloud Data Might Not Be Secure After All: Insights From Tenable Cloud Research

Tenable Cloud Research discovered a supply chain compromise vulnerability in Google's Gerrit code-collaboration platform which we dubbed GerriScary. GerriScary allowed unauthorized code submission to at least 18 Google projects including ChromiumOS (CVE-2025-1568), Chromium, Dart and Bazel, which are now remediated. Third-party organizations that use Gerrit may also be at risk from GerriScary.

• Tenable Cloud Research discovered GerriScary, a way to infiltrate Google’s software supply chain by exploiting misconfigured permissions in Gerrit, Google’s open-source code-review system used across many major Google projects.
• At least 18 Google projects were found to be exposed, proving that open collaboration without strong safeguards is a serious security concern - even for tech giants. The affected Google projects include, among others, ChromiumOS (CVE-2025-1568), third-party Chromium packages, Dart and Bazel.
• Gerrit, developed by Google, is used both internally at the company and by the wider open-source community. While affected Google projects have been fixed, other projects may still remain vulnerable to the attack.
• Organizations that use Gerrit should check their projects’ permissions to confirm they are not exposed.

ChromiumOS code injection proof-of-concept (POC)

Gerrit is an open-source, web-based code collaboration and review system developed by Google. It allows developers to propose, discuss and approve code changes before they are merged into large-scale software projects.

GerriScary, discovered by Tenable Cloud Research, is a supply chain compromise vulnerability in Gerrit’s projects that allowed any registered user to push code changes to many of Google’s projects. Registration to Gerrit is open to anyone.

By exploiting misconfigurations in permissions and the voting system’s label handling, attackers could have executed malicious code without user interaction, enabling supply chain attacks.

Moreover, attackers could have exploited a race condition with bot code-submission timings to push a change, leading to a 0-click malicious code push to the vulnerable projects.

Affected projects that haven’t mitigated this vulnerability are susceptible to a supply-chain attack due to excessive default permissions and logic flaws in the code-review process. For projects with vulnerable configurations in place, attackers can inject malicious code into trusted build pipelines.

A number of Google projects were affected, including ChromiumOS, third-party Chromium packages, Bazel and Dart. For a full list of affected packages please see Appendix A. 

By default, Gerrit contains a default permission (“addPatchSet”) that allows any registered user to modify existing code change suggestions. In addition to this permission, some of the vulnerable projects contained a logic flaw in the patch set approval process that caused new patch sets not to require new code reviews and approvals as intended. This flaw allowed a risky scenario where a legitimate code change approved by trusted developers would remain trusted and approved even when malicious code is pushed by an attacker - without requiring any re-confirmation or approval.

Google and the ChromiumOS team changed the label persistence configuration across patch sets in the vulnerable projects to mitigate the issue.

The ChromiumOS team also pushed a change to limit the “addPatchSet” permission to trusted contributors.

Our GerriScary discovery began when, during another research project, we stumbled upon the following link: https://chromium.googlesource.com/

The source code of the open-source product in that specific case, Chromium, was present in the googlesource.com domain. Users can easily access the corresponding Gerrit project through the “Code Review” button in this domain while logged in to a Google account.

Just like Chromium, there are many projects with corresponding subdomains that Google hosts, such as dart.googlesource.com and its corresponding Gerrit system dart-review.googlesource.com.
 

Gerrit: Dart project

Since anyone can register, we registered, and logged in with our Google account. The natural attacker’s question arises: What can a registered user do in Gerrit? We tried to create a code change, to see if we could push it. As expected, it failed.

After reading Gerrit’s documentation, we got more clarity on the terms. From Gerrit’s documentation on patch sets:

“As described in Changes, a change represents a single commit under review. Each change is assigned a Change-Id. It is very common to amend a commit during the code review process. Gerrit uses the Change-Id to associate each iteration of the commit with the same change. These iterations of a commit are referred to as patch sets. When a change is approved, only the latest version of a commit is submitted to the repository.”

Basically, each patch set is a new commit version.

Gerrit’s security model revolves around two key technical structures: permissions, which define who can perform actions; and labels, which define what approvals are required before code changes can be merged into a project.

Permissions are enforced based on Git references, such as refs/heads/*, refs/for/*, and refs/meta/* — and they dictate actions like reading, pushing, submitting and editing changes. Permissions are granted to groups, and those groups can be globally defined, such as Registered Users, or locally scoped to the project or even to the change itself. 

For example, a commonly configured permission is “addPatchSet”, which, when granted, allows a user to upload a new patchset to an existing code change, even if that change was created by someone else. 

An example of active code change

The second mechanism, labels, also known as “Submit Requirements,” are metadata scores applied during the code review process. Labels are declared in the project’s configuration and typically include fields like “Code-Review” and “Verified.” Each label has a defined scoring range. For example, “Code-Review” may allow scores from -2 (strong disapproval) to +2 (final approval), while Verified might allow -1 and +1 to represent test failures or passes. Labels serve as gates: for a change to be eligible for submission, it must satisfy the label rules set in the project configuration.

Permissions and labels are managed in a configuration file called project.config. This file specifies the permissions granted to users for each project.

Each permission rule in project.config follows a structure like this:

The example above demonstrates a highly permissive configuration: any registered user—a user who merely created a Gerrit account - could push changes directly to the refs/heads/* namespace and decide on a “Code-Review +2.”

The interesting fact about permission handling in Gerrit is the following quote from Gerrit’s documentation, referencing the “addPatchSet” permission:

“By default, this permission is granted to Registered Users on refs/for/*, allowing all registered users to upload a new patch set to any change. Revoking this permission (by granting it to no groups and setting the "Exclusive" flag) will prevent users from uploading a patch set to a change they do not own.”

That default sounds reasonable since Gerrit is a community-based system > However, it probably can open the door to more attacks, like GerriScary.

We checked these defaults and it seems like they are present in many Google projects.

When pressing the “Reply” button on code changes to try and add votes and affect the voting system, we did not have enough permissions to upvote any submission requirements:
 

No permissions to vote on any submit requirement

So we wondered: What if we find a code change that has already been approved and has its submission requirements satisfied and then add our malicious code with “addPatchSet”? What will happen to the submission requirements? Surprisingly, in some cases, nothing.

We discovered that we can abuse a Gerrit mechanism called “Copy Conditions”. Turns out that the vulnerable Google projects are configured to copy their labels to additional patch sets. “Copy Conditions” in Gerrit define whether label scores from prior patch sets are retained on new revisions, based on the nature of the change, such as unchanged code or purely metadata edits. Label scores also play a crucial role in determining if a change must be re-reviewed. 

The “Copy Conditions” rules are pretty complicated to write and understand, which might be the reason they made the affected projects vulnerable.

The affected projects had misconfigured “Copy Conditions” in place that allowed us to add our malicious patch sets and retain the submit requirements. Alarmingly, this resulted in a code change that contained malicious code and was fully approved.

In submittable code changes, all of the submit requirements and label scores are completed or fulfilled. We were able to find submittable code changes by using Gerrit queries and scraping. For example:
 

Using Gerrit queries to find submittable code changes

The final step to merge a code change is to submit it successfully. Most projects we observed handle verified code-change submissions with automated bots, and some of them are handled by developers who have to press “Submit” to submit the verified code change. When a developer presses “Submit,” a bot will merge the code change.
 

The Commit Queue bot merges the code change

In most cases, we did not have the “Submit” permission. Sometimes the bot pushed the code change seconds after the code change was verified, and sometimes it took minutes, or hours, which allowed eagle-eyed developers to stop or block the malicious code-push attempt.

We wanted to minimize this window to zero, resulting in a full supply-chain compromise without any user interaction by the victim.

We discovered we can successfully race the automated bot submission. A race condition attack happens when two or more things try to happen at the same time, and the outcome depends on who finishes first.

Here’s how we did it.

Gerrit project maintainers can create custom labels. Google has its own custom label named “Commit-Queue”. In Google's setup, a vote of “Commit-Queue+2” instructs an automated bot to finalize and submit the code change.

When the "Commit-Queue" label in particular is equal to 2, it signals to the automation bot to submit a merge and the bot eventually merges the change. Some of these bots' operations can be observed by looking at merged change logs.

Let’s use this as an example: https://dart-review.googlesource.com/c/sdk/+/392640

In this specific case, a bot named Commit-Queue - dart-scoped@luci-project-accounts.iam.gserviceaccount.com has pushed the change. We have not yet observed a repository that operates differently.

This is the exact timing delay attackers can abuse: The race window from a “Commit-Queue” to a successful bot submission. As an example, it’s five minutes in ChromiumOS and in Dart repositories, and seconds to a minute on other Google repositories:
 

Example of the five-minute time difference between the Commit Queue vote and an actual merge

The “Copy Conditions” logic flaw can be abused to get the race, as mentioned. This setting includes labels like "Code Review", but also controls custom labels like the "Commit Queue" label that Google uses in its Gerrit instances.

Given this configuration, any modified code that retains “Submit Requirements” can lead to a full chain of malicious code pushed to the vulnerable repositories, without any user interaction at all. 

Attackers could look for submittable code changes that were also labeled “Commit-Queue +2”, and race the bot submission by adding a malicious patch set just before it merges the code change.

Here’s what happens on ChromiumOS when you abuse these three components:

• Default “addPatchSet” permission granted to registered users
• Unsafe labels’ “Copy Conditions” logic on vulnerable projects
• Race window from commit queue vote to bot submission and an unsafe custom “Commit-Queue” label copy condition logic

Attackers can write a scraper or query the Gerrit API with automation to hook changes that have a submittable status, and have been labeled “Commit-Queue +2”. When the exploit code detects such a change, it will modify the change's code with the “addPatchSet” permission, and inject malicious code into the change, all of whose submit requirements have been verified and fulfilled. Since the change was already voted “Commit-Queue +2”, it's a matter of 5 minutes in ChromiumOS and in Dart repositories as an example, and seconds to a minute on other Google repositories, until the change is merged by the bot, including the malicious code. This is the exact race window the attacker has - between the commit-queue +2 vote, to the bot actually submitting the change.

This “Copy Conditions” misconfigurations allows for abusing the “addPatchSet” permission which is granted by default to registered users, to inject malicious code into a change without a vote reset. Because of that, although we did not confirm it specifically as a precaution, it is highly likely that the copyCondition logic for the "Commit-Queue" label is similarly misconfigured to copy votes across patch sets.

Since we do not have permission to view the config of each Gerrit project (project.config file), we opted to dynamically scan Google’s Gerrit projects, without disrupting the projects.

We discovered a fingerprinting technique in Gerrit that allowed us to determine whether we have the “addPatchSet” permission on a project. By analyzing the HTTP response status code of a request to modify a commit message, we observed that a successful request—when properly authorized—returns a “200 OK” status, which is expected.
 

Commit message example is marked in red

However, sending commit message modification requests to many projects is both noisy and inefficient. We found that submitting the same commit message that is already present in a modification request returns a “209” status code (can be used as a fingerprint) if we have the required permission. Using this method, we were able to scan Google’s Gerrit projects and identify many affected ones. 

We discovered some Google projects that allow denial of service and disruption of code changes; modifications by registered users such as removing and adding code change CCs (carbon copy) and reviewers; and messing with submit-requirement votes to deny code changes from being pushed:
 

To support the vulnerability disclosure, we created POCs on ChromiumOS, Dart, and two third-party packages of Chromium: Dawn and BoringSSL. To avoid disruption, we did not live test the race condition component, but we did test uploading an innocent comment to some Google projects. These allowed us to prove the impact of GerriScary, while following ethical research rules.

One comment we added to a random file in a ChromiumOS project was actually pushed, and can be seen on the ChromiumOS code search tool as a valid POC for our findings:
 

ChromiumOS code injection POC

Google fixed the label-persistence configuration (“Copy Conditions”) in the affected projects. This change ensured that new patch sets now require fresh code reviews and verifications by developers, preventing previously approved labels from carrying over without re-evaluation.

The ChromiumOS team also decided to remove the “addPatchSet” permission from the Registered Users group, and to only give the permission to trusted contributors.

These proactive steps were part of Google's commitment to maintaining the security and integrity of its systems.

While these Google-managed projects have been secured, other projects utilizing Gerrit may still be vulnerable and should apply secure configurations to mitigate potential risks.

https://chromium-review.googlesource.com/c/chromiumos - (ChromiumOS)

https://dart-review.googlesource.com/ - (Frontend language, the backbone of Flutter apps)

https://dawn-review.googlesource.com/ - (3rd party Chromium dependency)

https://boringssl-review.googlesource.com/ - (3rd party Chromium dependency)

https://gn-review.googlesource.com/ - (Build system of Chromium, Fuchsia, and related projects)

https://bazel-review.googlesource.com - (Google's build engine)

https://gerrit-review.googlesource.com/#(/zull/jobs) - (Gerrit itself, /zull/jobs and /gcompute-tools specifically)

https://ceres-solver-review.googlesource.com/ - (C++ library)

https://code-review.googlesource.com/ - (Includes a Git mirror)

https://quiche-review.googlesource.com - (Google's production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools)

https://android-kvm-review.googlesource.com/ - (Virtualized Android runtime)

https://opensecura-review.googlesource.com/ - (AI hardware backbone)

https://cue-review.googlesource.com/ - (Data validation language)

https://linux-review.googlesource.com/ - (Open-source operating system)

https://plan9port-review.googlesource.com/ - (Unix with Plan 9 utilities)

https://hafnium-review.googlesource.com/ - (Supplies memory isolation)

https://nginx-review.googlesource.com/ - (High-performance web server)

https://weave-review.googlesource.com/ - (Network application layer protocol)

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, Jorge Orchilles, Senior Director of Readiness and Proactive Security at Verizon, offers an up-close glimpse at the thinking that drove his move to exposure management. You can read the entire Exposure Management Academy series here.

As we shift our security focus at Verizon to proactive exposure management, we’re consolidating tools and teams to focus on real-world, exploitable risks. By aligning offensive security functions under a unified strategy, prioritizing exploitable threats and fostering collaboration, we're moving our focus beyond compliance-based remediation to risk-based remediation.

You know the story: Those of us in cybersecurity play a high-stakes game of Whac-a-mole® just about every day. We spend our lives chasing down vulnerabilities and issuing (or responding to) mandates like, "Patch within 30 days” or “Code red, patch now!”

But as attack surfaces grow and threat actors become more sophisticated, this reactive approach has become inadequate. 

At Verizon, we recognized that, with such a heterogeneous landscape that has to serve the diverse needs of corporate, retail, mobile field techs and more, the best solution was not another collection of disparate tech. We needed a single, consolidated exposure management platform that could cover every corner of our enterprise. The journey to get there broke down silos and shifted our mindset from being compliance-driven to a risk-based focus. 

Importantly, before we even considered new technology, we needed to align multiple teams, each with their own tools and priorities, behind a shared strategy.

Security teams have always juggled a patchwork of tools: Separate tools for attack surface management, asset visibility, vulnerability scanning, identity exposure and cloud security. In most companies, different teams operate the solutions and each one requires its own set of expertise. The intent of the fragmentation is to ensure you have people with the right skills remediating the right problems. 

The siloed approach slows response times and creates blind spots that can leave critical vulnerabilities unaddressed simply because they fall outside a team’s area of expertise. You cannot do attack path analysis in silos!

I don’t want to be in the business of just checking boxes. 

We needed to build a security program that prioritizes real-world risks, rather than every vulnerability. And, in that effort, it’s clear that the value of an integrated approach outweighs the benefits of niche features.

So, to handle these challenges, we opted to consolidate under a single platform: Tenable One.

While the right platform makes all the difference, implementing exposure management isn't purely technical. It’s organizational. Launching an exposure management program means shifting ownership of key, siloed security functions, which can require teams to work together in ways they haven’t before.

For example, at Verizon, attack surface management was previously handled by a separate team. Now, those individuals are part of my group. The Active Directory team, which runs identity exposure tools like Bloodhound, remains independent, but we collaborate closely so they see the security insights as valuable rather than punitive. 

The internet of things (IoT) and operational technology (OT) security specialists who previously used a different set of tools now all work within the same framework.

Security teams accustomed to working in silos must now share data and decision-making, which can be a tough adjustment. I found that the key to overcoming this is transparency and partnership. 

In fact, reading a bit of Dale Carnegie regularly can be just as important as a daily dose of Brian Krebs. 

So, to ease the transition, rather than imposing top-down mandates, we’ve focused on aligning teams through shared objectives, clear communication and demonstrating value early in the process. By involving stakeholders from the start, in areas like identity security, IT operations and cloud security, we’re ensuring that change isn’t something done to them, but something they actively shape and support.

I want to emphasize that none of this happened overnight. 

It required high-level buy-in and careful planning. These teams weren’t just being asked to use a new tool, they were being asked to change the way they work. The only way to make that transition successful is by showing team members how this approach makes their jobs easier, not harder.

One of the biggest mindset shifts in exposure management is recognizing that not every vulnerability needs to be patched immediately. Sure, it can be a hard thing to wrap your head around. But when everything is critical, nothing is critical. And that approach just leads to burnout, inefficiency and more exposures. 

Instead, at Verizon, we focus on vulnerabilities that are actually exploitable and part of a realistic attack path.

So, if there’s a critical vulnerability in an application but no feasible way for an attacker to reach it, should it really be the top priority? On the other hand, if a vulnerability provides a direct path to a crown jewel asset, we need to address it immediately. 

The key is prioritization based on real-world attack scenarios, not arbitrary severity scores.

Another critical advantage of exposure management is how it changes security conversations at the executive level. Instead of delivering long lists of vulnerabilities that mean little to non-technical leaders, we can present a clear picture in a few key points:

• What’s at risk?
• How could an attacker get in?
• What are the most urgent priorities to fix?

And when a major vulnerability hits, we don’t have to scramble to figure out if we are affected. We have the data at our fingertips. That’s the real value of exposure management: Speed, clarity and the ability to act before attackers do.

At its core, exposure management is about shifting from reactive security to proactive security. It’s not just about fixing vulnerabilities anymore. It’s about understanding risk in the context of the business. 

As more organizations move in this direction, exposure management will continue to evolve. 

Vendor consolidation is ongoing, teams are being restructured and security leaders are realizing that patching everything everywhere all at once is an impossible task. 

So, like Verizon, the industry must focus on what really matters: Preventing the attacks that could actually lead to a compromise.

And for those of us at the tip of the spear in this shift, it’s time to stop being reactive and start managing exposure like the strategic risk it is.

• Read the Security leaders’ guide to exposure management strategy, a proven, pragmatic approach to standing up an exposure management program — plus advice for scoping it, engaging stakeholders and obtaining buy-in.

Whac-a-Mole is a registered trademark of Mattel Inc.

Check out NIST best practices for adopting a zero trust architecture. Plus, learn how OpenAI disrupted various attempts to abuse ChatGPT. In addition, find out what Tenable webinar attendees said about their exposure management experiences. And get the latest on cyber crime trends, a new cybersecurity executive order and more!

Dive into six things that are top of mind for the week ending June 13.

Zero trust architectures’ (ZTAs) popularity has grown as traditional on-prem security perimeters dissolve with the adoption of cloud services, mobile devices, remote employees, IoT devices and more. But ZTA implementations aren’t “one-size-fits-all” affairs. They must be customized to individual environments.

To help organizations plan and deploy ZTAs, the U.S. National Institute of Standards and Technology (NIST) this week published a guide titled “Implementing a Zero Trust Architecture: Full Document (SP 1800-35).”

By offering 19 concrete ZTA implementation examples, the new guide is meant to complement NIST’s “Zero Trust Architecture (SP 800-207)” which was published in mid-2000 and unpacks what a ZTA is, as well as its components, benefits and risks.

“This guidance gives you examples of how to deploy ZTAs and emphasizes the different technologies you need to implement them,” Alper Kerman, a NIST computer scientist and the guide’s author, said in a statement. “It can be a foundational starting point for any organization constructing its own ZTA.”
 

To craft the new ZTA guide, NIST enlisted the help of 24 technology partners, including Tenable. “Our role? Help ensure that every device, user, and system is verified, monitored, and protected. This is what public-private partnership looks like at its best,” Tenable Senior VP of Global Government Affairs James Hayes wrote in a LinkedIn post.

In addition to the 19 examples, the guide also includes a description of these core steps applicable to all ZTA implementations:

• Discovering and inventorying all of your environment’s IT assets, including hardware, software, applications, data and services
• Specifying the security policies the ZTA will enforce regarding who can access each resource, according to the principles of least privilege
• Identifying and inventorying your existing security tools, technologies and capabilities, and determining which ones will be part of the ZTA
• Designing your access topology based on risk and the value of your data
• Rolling out ZTA components involving people, processes and technologies, and deploying baseline security components for areas including: 
  • continuous environment monitoring and asset detection
  • identity and access management
  • vulnerability scanning and assessment
  • endpoint protection
• Verifying the implementation supports your zero-trust objectives by:
  • continuously monitoring network traffic for suspicious activity
  • auditing and validating access-enforcement decisions
  • verifying enforced policies correlate with defined ones
  • performing periodic, scenario-based testing
• Continously improving and evolving the ZTA based on changes to your goals, threat landscape, technology and requirements

To get more details, read:

• The “Implementing a Zero Trust Architecture: Full Document (SP 1800-35)” guide
• The “Implementing a Zero Trust Architecture: High-Level Document (SP 1800-35)” complementary document
• The companion fact sheet
• The ZTA homepage of NIST’s National Cybersecurity Center of Excellence 
• The statement “NIST Offers 19 Ways to Build Zero Trust Architectures” 

For more information about zero trust, check out these Tenable resources:

• “Rethink security with a zero-trust approach” (solutions page)
• “What is zero trust?” (cybersecurity guide)
• “5 Things Government Agencies Need to Know About Zero Trust” (blog)
• “Making Zero Trust Architecture Achievable” (blog)
• “Security Beyond the Perimeter: Accelerate Your Journey to Zero Trust” (on-demand webinar)

Cyber espionage. Social engineering. Fraudulent employment schemes. Covert operations. Scams.

Those are some of the malicious uses of OpenAI’s artificial intelligence tools that the company has detected and halted in recent months.

“Every operation we disrupt gives us a better understanding of how threat actors are trying to abuse our models, and enables us to refine our defenses,” the company wrote in the report “Disrupting malicious uses of AI: June 2025,” published this week.

Specifically, OpenAI details 10 incidents with the goal of sharing how it flagged and defused them in the hopes that the lessons it learned can benefit other AI defenders.
 

Here’s a quick glance at three of the malicious use cases the maker of ChatGPT discusses in the report:

• In a deceptive IT-worker employment scheme, cyber scammers likely based in North Korea used ChatGPT to automate, streamline and enhance a variety of fraudulent activities, such as the creation of false resumes and the recruitment of North American residents to participate in the scams.
• ChatGPT was also abused by fraudsters likely located in China to mass-produce social media posts intended to spread misinformation as part of covert schemes to influence people’s opinions on geopolitical issues related to China. Written mostly in English and Chinese, the posts appeared primarily on TikTok and X, as well as on Facebook and Reddit.
• Russian-speaking malicious actors used a cluster of ChatGPT accounts to develop and refine a multi-stage malware campaign, including the setup of the command-and-control infrastructure. The malware’s capabilities included credential theft, privilege escalation and attack obfuscation.

“We’ll continue to share our findings to enable stronger defenses across the internet,” the report reads.

For more information about AI security, check out these Tenable resources:

• “How to Discover, Analyze and Respond to Threats Faster with Generative AI” (blog)
• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood” (blog)
• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Tenable Cloud AI Risk Report 2025” (report)
• “Tenable Cloud AI Risk Report 2025: Helping You Build More Secure AI Models in the Cloud” (on-demand webinar)

During our recent webinar “Security Without Silos: How to Gain Real Risk Insights with Unified Exposure Management,” we polled attendees about their exposure management knowledge, challenges and concerns. Check out what they said.

(44 webinar attendees polled by Tenable. Respondents could choose more than one answer.) 

(85 webinar attendees polled by Tenable)

(89 webinar attendees polled by Tenable)

Want to learn more about how unified exposure management works in the real world? Watch this webinar on-demand! 

As has been widely documented by researchers and experienced by users, AI systems often make mistakes — a major challenge for AI developers. What can be done?

A critical piece of this puzzle is to build AI systems that recognize when they’re presented with a task for which they haven’t been trained, and are able to say they don’t know how to proceed.

That’s according to the article “Out of Distribution Detection: Knowing When AI Doesn’t Know” published this week by two experts from Carnegie Mellon University’s Software Engineering Institute (SEI).

In the piece, Eric Heim, a senior machine learning research scientist, and Cole Frank, an AI workforce development engineer, explore the issue of out-of-distribution detection (OoD) — flagging when an AI system faces situations it’s not trained to tackle — with a focus on AI military applications.

“By understanding when AI systems are operating outside their knowledge boundaries, we can build more trustworthy and effective AI capabilities for defense applications — knowing not just what our systems know, but also what they don't know,” they wrote.
 

The authors offer three broad categories of OoD detection:

• Anomaly detection and density estimation, which try to model what “normal” data looks like
• Learning with rejection and uncertainty-aware models, which seek to detect instances of OoD
• Adding OoD detection capabilities to existing models

The authors caution that all three OoD detection categories have their pros and cons, and that OoD detection methods aren’t foolproof, and, as such, should be considered “a last line of defense in a layered approach to assessing the reliability of ML models during deployment.”

“Developers of AI-enabled systems should also perform rigorous test and evaluation, build monitors for known failure modes into their systems, and perform comprehensive analysis of the conditions under which a model is designed to perform versus conditions in which its reliability is unknown,” they wrote.

For more information about OoD and about AI model accuracy in general:

• “Never Assume That the Accuracy of Artificial Intelligence Information Equals the Truth” (United Nations University)
• “Accurate and reliable AI: Four key ingredients” (Thomson Reuters)
• “What do we need to know about accuracy and statistical accuracy?” (U.K. Information Commissioner’s Office)
• “Out-of-Distribution Detection Is Not All You Need” (Université de Toulouse, Toulouse, France)
• “Rule-Based Out-of-Distribution Detection” (IEEE)

The Trump administration has put the spotlight on boosting the U.S. federal government’s cybersecurity posture with the recently issued Executive Order (EO) 14306.

EO 14306 aims “to strengthen the nation’s cybersecurity by focusing on critical protections against foreign cyber threats and enhancing secure technology practices,” reads a complementary White House fact sheet.
 

The EO addresses topics including AI system vulnerabilities, IoT security, quantum computing risk, patch management, secure software development and critical infrastructure defense.

“This EO reinforces the importance of shifting from reactive to proactive cybersecurity,” Tenable Senior VP of Global Government Affairs James Hayes wrote in a blog.

“By addressing emerging risks — such as AI exploitation, post-quantum threats and software supply chain weaknesses — the administration is signaling the need for adaptability and continuous improvement,” he added.

To learn more about EO 14306 and about how Tenable can help federal agencies comply with the EO’s requirements, check out the blog “New Cybersecurity Executive Order: What You Need To Know.”

Leveraging AI in increasingly powerful ways, cyber criminals have ramped up data theft, which they’re using as the foundation for myriad cyber attacks, including online fraud, ransomware, child exploitation and extortion.

That’s a key takeaway from Europol’s “Internet Organised Crime Threat Assessment 2025” report, published this week. The report aims to highlight major trends in cyber crime in order to help law enforcement agencies, policy makers and the tech industry respond.

“From phishing to phone scams, and from malware to AI-generated deepfakes, cybercriminals use a constantly evolving toolkit to compromise systems and steal personal information,” reads a Europol statement. 
 

Initial access brokers (IABs) then sell, resell and repackage stolen credentials and data in dark web forums and criminal marketplaces. Cyber criminals have also upped their use of communication apps that offer end-to-end encryption to negotiate deals and sell compromised data.

With regards to AI, cyber crooks continue to abuse it, especially generative AI tools, to launch ever more sophisticated social engineering attacks. “Criminals now tailor scam messages to victims’ cultural context and personal details with alarming precision,” the statement reads.

For more information about data security, check out these Tenable resources:

• “Securing Financial Data in the Cloud: How Tenable Can Help” (blog)
• “CISA and NSA Cloud Security Best Practices: Deep Dive” (blog)
• “Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?” (on-demand webinar)
• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Stronger Cloud Security in Five: How DSPM Helps You Discover, Classify and Secure All Your Data Assets” (blog)

A new cybersecurity Executive Order aims to modernize federal cybersecurity with key provisions for post-quantum encryption, AI risk and secure software development.

On June 6, 2025, the White House released a new Executive Order (EO) aimed at modernizing the nation’s cybersecurity posture. As cyber threats continue to evolve in scale and sophistication, the EO reinforces the federal government’s commitment to defending digital systems that power critical services, infrastructure and national security. It also creates renewed urgency for vulnerability management by calling on federal agencies to incorporate management of AI vulnerabilities into their existing vulnerability management practices. 

1. Addressing AI and IoT security

Rather than impose new restrictions on AI technologies, the EO focuses on visibility and vulnerability management within AI software and systems. It gives federal agencies a November 1, 2025 deadline to incorporate management of AI software vulnerabilities into their existing vulnerability management practices. The EO also supports the launch of the voluntary Cyber Trust Mark program to help secure consumer and federal IoT devices by promoting transparency and baseline protections.

1. Encouraging stronger patch management

The EO directs the National Institute of Standards and Technology (NIST) to update Special Publication 800–53 (Security and Privacy Controls for Information Systems and Organizations) to provide guidance on how to securely and reliably deploy patches and updates.

1. Reinforcing critical infrastructure defense

Critical infrastructure operators, particularly in energy, communications and transportation, are called to align with enhanced security standards. This includes deeper coordination with the Cybersecurity and Infrastructure Security Agency (CISA) and adherence to frameworks like the Federal Operational Cybersecurity Alignment (FOCAL) Plan.

1. Emphasizing secure software development

Federal agencies are now required to adopt updated secure software development practices in line with revised guidelines from NIST. This includes deeper integration of an update Secure Software Development Framework (SSDF) and improved vendor attestations for software integrity.

1. Preparing for quantum-safe encryption

Recognizing the long-term risks posed by quantum computing, the EO mandates that federal agencies begin transitioning to post-quantum cryptographic standards. Agencies must inventory current cryptographic assets and develop migration plans to safeguard sensitive data for the future.

1. Strengthening internet infrastructure

The EO directs action to secure the Border Gateway Protocol (BGP), a foundational component of internet routing. Agencies are expected to assess and strengthen their network infrastructure to protect against BGP hijacking and related risks.

1. Aligning policy to practice

Notably, the EO states that “Agencies’ policies must align investments and priorities to improve network visibility and security controls to reduce cyber risks.” It further calls on the Director of the Office of Management and Budget to issue guidance for addressing critical risks and adapting modern practices and architectures across federal information systems and networks. 

This EO reinforces the importance of shifting from reactive to proactive cybersecurity. By addressing emerging risks — such as AI exploitation, post-quantum threats and software supply chain weaknesses — the administration is signaling the need for adaptability and continuous improvement. The EO also underscores the need for secure patch management, enhanced critical infrastructure standards and coordination with CISA, and a push for federal agencies to align their policies, investments and practices to better manage cyber risks.

As a long-time partner of the federal government, Tenable provides FedRAMP authorized solutions to help federal agencies proactively identify and reduce cyber exposures. Tenable One FedRAMP delivers unified visibility and risk-based prioritization across IT, OT, cloud infrastructure and identity systems. Tenable is proud to be one of the original signatories of CISA’s “Secure by Design" Pledge and an active partner of the National Cybersecurity Center of Excellence. We’ve articulated to our customers how we’ve taken steps to implement the provisions of the pledge. 

With capabilities aligned to secure software development practices, continuous vulnerability management, cryptographic asset discovery and AI-aware risk detection, Tenable empowers agencies to meet the evolving mandates of the Executive Order. By integrating comprehensive risk-based insights into existing security workflows, Tenable helps agencies operationalize zero-trust principles, understand how to securely and promptly deploy patches and updates, accelerate incident response and maintain continuous compliance, all while strengthening overall cyber resilience in support of national security objectives. 

1. 9Critical
2. 56Important
3. 0Moderate
4. 0Low

Microsoft addresses 65 CVEs, including two zero-day vulnerabilities, with one being exploited in the wild.

Microsoft addresses 65 CVEs in its June 2025 Patch Tuesday release, with nine rated critical, and 56 rated as important. Our counts omitted one vulnerability reported by CERT CC.

This month’s update includes patches for:

• .NET and Visual Studio
• App Control for Business (WDAC)
• Microsoft AutoUpdate (MAU)
• Microsoft Local Security Authority Server (lsasrv)
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office Outlook
• Microsoft Office PowerPoint
• Microsoft Office SharePoint
• Microsoft Office Word
• Nuance Digital Engagement Platform
• Power Automate
• Remote Desktop Client
• Visual Studio
• WebDAV
• Windows Common Log File System Driver
• Windows Cryptographic Services
• Windows DHCP Server
• Windows DWM Core Library
• Windows Hello
• Windows Installer
• Windows KDC Proxy Service (KPSSVC)
• Windows Kernel
• Windows Local Security Authority (LSA)
• Windows Local Security Authority Subsystem Service (LSASS)
• Windows Media
• Windows Netlogon
• Windows Recovery Driver
• Windows Remote Access Connection Manager
• Windows Remote Desktop Services
• Windows Routing and Remote Access Service (RRAS)
• Windows SDK
• Windows SMB
• Windows Security App
• Windows Shell
• Windows Standards-Based Storage Management Service
• Windows Storage Management Provider
• Windows Storage Port Driver
• Windows Win32K GRFX

Remote code execution (RCE) vulnerabilities accounted for 38.5% of the vulnerabilities patched this month, followed by information disclosure vulnerabilities at 26.2%.

CVE-2025-33053 is a RCE in Web Distributed Authoring and Versioning (WebDAV). It was assigned a CVSSv3 score of 8.8 and is rated important. An attacker could exploit this vulnerability through social engineering, by convincing a target to open a malicious URL or file. Successful exploitation would give the attacker the ability to execute code on the victim’s network.

According to Microsoft, it was exploited in the wild as a zero-day. It was reported by researchers at Check Point Research, who have released a blog post discussing the discovery of this zero-day. According to the researchers, CVE-2025-33053 was exploited by Stealth Falcon, an APT group that has been observed using zero-day exploits in espionage attacks.

CVE-2025-33073 is an EoP vulnerability affecting the Windows Server Message Block (SMB) client. It was assigned a CVSSv3 score of 8.8 and was publicly disclosed prior to a patch being made available. According to Microsoft, successful exploitation requires an attacker to execute a crafted script to force a target device to connect to an attacker-controlled machine using SMB credentials. If successful, the attacker could elevate their privileges to SYSTEM.

CVE-2025-33070 is an EoP vulnerability in Windows Netlogon. It was assigned a CVSSv3 score of 8.1 and is rated as critical. An attacker could exploit this vulnerability to gain domain administrator privileges. According to Microsoft, a successful attack requires the attacker to take additional actions in order to prepare a target for exploitation. Despite these requirements, Microsoft has assessed this vulnerability as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

CVE-2025-47162, CVE-2025-47164, CVE-2025-47167 and CVE-2025-47953 are RCE vulnerabilities affecting Microsoft Office. Each of these critical vulnerabilities were assigned CVSSv3 scores of 8.4 and all except CVE-2025-47953 were assessed as “Exploitation More Likely.” Microsoft notes that Preview Pane is an attack vector for exploitation of these vulnerabilities.

In addition, CVE-2025-47173, another RCE in Microsoft Office was patched this month. It received a CVSSv3 score of 7.8, was rated as important and assessed as “Exploitation Unlikely.” Unlike the other Office vulnerabilities, the preview pane is not an attack vector for CVE-2025-47173.

CVE-2025-33071 is a RCE vulnerability affecting Windows Kerberos Key Distribution Center (KDC) proxy service, an authentication mechanism used for KDC servers over HTTPS. It received a CVSSv3 score of 8.1 and is rated as critical. An unauthenticated attacker could exploit this vulnerability utilizing a crafted application to exploit a cryptographic protocol vulnerability in order to execute arbitrary code. According to the advisory, this only impacts Windows Servers that have been “configured as a [MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protocol server.” While the advisory does mention that exploitation requires the attacker to win a race condition, this vulnerability was still assessed as “Exploitation More Likely.”

CVE-2025-32713 is an EoP vulnerability in the Windows Common Log File System (CLFS) Driver. It was assigned a CVSSv3 score of 7.8 and is rated as important. CVE-2025-32713 was assessed as “Exploitation More Likely.” Successful exploitation would allow an attacker to elevate their privileges to SYSTEM.

Prior to this month's release, Microsoft has patched five other EoP vulnerabilities in the Windows CLFS driver in 2025, three of which were exploited as zero-days. This includes CVE-2025-29824 from the April 2025 Patch Tuesday release and both CVE-2025-32701 and CVE-2025-32706, which were patched in the May 2025 Patch Tuesday release.

A list of all the plugins released for Microsoft’s June 2025 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

• Microsoft's June 2025 Security Updates
• Tenable plugins for Microsoft June 2025 Patch Tuesday Security Updates

Join Tenable's Research Special Operations (RSO) Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, Tenable security engineers Arnie Cabral and Jason Schavel share how you can use risk-based metrics. You can read the entire Exposure Management Academy series here.

We’re information security engineers at Tenable. If you’re anything like us, you spend your days on the front lines of the battle against a constantly changing set of cybersecurity threats. No matter your role, you probably face any number of complex challenges to stay one step ahead of the bad guys. 

To be most effective, you need to move beyond operating across silos toward bringing all of the data together. Exposure management helps bring this all together. 

Maybe you’re contemplating a move to exposure management or maybe you’ve already started the shift. (Not sure how mature your program is? Check out the Tenable exposure management security assessment.) No matter where you are, exposure management represents a fundamental shift toward a unified view of exposures across the attack surface. It involves continuously discovering, assessing, prioritizing and remediating all types of security exposures, including vulnerabilities, misconfigurations and excessive permissions across various assets. As we like to say, “give us all the things.”

In our roles, we are helping Tenable move in this direction. So we thought we’d share some of our experiences. 

If you have any questions or you’d like to share your exposure management experiences with us, please use the form at the bottom of the page. 

Exposure management is about more than just finding flaws. It's about understanding business risk and prioritizing actions that reduce the potential for attack. If you react to every alert or finding, you’ll soon end up draining your resources, burning out the staff and wasting tons of valuable time.

So, with limited resources, how can security teams effectively manage the vast threat landscape and focus on what truly matters? 

Robust, risk-based metrics are the key to guiding the exposure management lifecycle, which begins with comprehensive and continuous discovery of all assets, identities and applications. Then, by prioritizing risks based on business impact and technical context, and by proactively mitigating the highest-risk exposures through remediation, you’ll have an ongoing exposure management process. 

Exposure management builds upon vulnerability management to deliver results based on severity and adds the context and prioritization that comes with risk-based vulnerability management (RBVM). In addition, it ingests a wide array of security data sources across the enterprise. Exposure management provides critical context for those assets and we’re able to look at more than just the usual data points.

This approach can transform raw data into actionable intelligence so your organization has a focused, proactive defense.

A fundamental part of effective exposure management is consistent, clear communication about the organization's risk posture. Exposure management helps us paint a more holistic picture of our environment. For example, we monitor our cloud accounts and we have several different sensors there. Exposure management unites all those sources and shows us everything in a consolidated view, in contrast to the old way of looking at the data via multiple point products and having to put that all together manually.

These metrics provide a snapshot comparing the current exposure landscape to previous periods. They offer an overview of quantifiable risk across different business units and asset groups. Frequent assessments are essential for tracking progress, identifying emerging risk areas, and informing strategic decisions within a continuous exposure management framework.

Our exposure management program relies on metrics that facilitate effective prioritization. It’s about understanding which exposures represent the most significant threat right now and communicating those threats to the right asset owners to ensure effective remediation of findings:

• Exploitability and threat context: Is there a known exploit for this exposure? Is it being actively used by threat actors? Prioritizing exposures based on real-world threat intelligence ensures remediations target the most likely attack vectors.
• Asset criticality and business context: How critical is the affected asset to the business? Understanding the potential impact of an exploit guides prioritization beyond technical severity alone.
• Actual impact vs. theoretical risk: A high-severity vulnerability might pose little actual risk in your specific environment due to mitigating controls or specific configurations. Assessing actual impact helps filter out less critical issues, though investigating every exposure's context remains challenging.
• Remediation service level agreements (SLAs): Tracking remediation timeliness against SLAs provides a crucial performance indicator for the exposure management program. Deviations often point to bottlenecks or systemic issues in remediation workflows, patching processes, or asset visibility that need addressing.
• Exposure trends: Monitoring trends over time so you can understand whether exposures are increasing or decreasing (overall and in specific areas) is vital. Upward trends signal potential breakdowns or emerging risks requiring investigation and potentially resource reallocation.

Risk-based metrics are fundamental to each stage of the exposure management lifecycle. We look at it like this: 

• Discovery and assessment: Metrics give us the context we need to understand the raw data we gather from scanning and assessment tools.
• Prioritization: These metrics provide an objective basis to help us decide which exposures we should tackle first.
• Validation: Often, it can be hard to validate our remediation efforts. We can use metrics to understand whether we succeeded and if we reduced risk.
• Mobilization: Clear reporting based on these metrics helps mobilize the right teams and secure necessary resources.

By using metrics to connect technical findings with business risk, we have been able to communicate more effectively with our leadership. In turn, we have data that justifies the resources we need for targeted remediations and we’ve demonstrated the value of our exposure management program.

Incorporating risk-based metrics as part of an exposure management program requires addressing challenges like managing diverse asset types (including user workstations, mobile devices, cloud, IoT, etc.) so you can ensure accurate data across disparate tools and maintain visibility across the changing attack surface.

But an effective exposure management program requires more than just tools. Your metrics-driven approach should help you to continuously understand and reduce risk across the entire attack surface. 

With risk-based metrics focused on exploitability, impact, SLAs and trends, you’ll start to move beyond reactive prioritization. You and your team will proactively prioritize efforts, make smarter remediation decisions and optimize resource allocation. Ultimately, you’ll build a more resilient defense.

We’re all ears. Share your question and maybe we’ll feature it in a future post.

MktoForms2.loadForm("//info.tenable.com", "934-XQB-568", 14070);

Check out a new roadmap for adopting quantum-resistant cryptography. Plus, find out how your company can create a better cybersecurity environment. In addition, MITRE warns about protecting critical infrastructure from cyber war. And get the latest on exposure response strategies and on CISO compensation and job satisfaction.

Dive into five things that are top of mind for the week ending June 6.

Is your organization looking for guidance on how to carry out its migration to post-quantum cryptography (PQC)? A group that includes MITRE, Microsoft and IBM just released a roadmap designed to help organizations plan and execute their adoption of PQC.

Titled “Post-Quantum Cryptography (PQC) Migration Roadmap,” the 20-page document from the “Post Quantum Cryptography Coalition” breaks down PQC migrations into four major stages:

• Preparation, which includes identifying the transition’s main goals, assigning a project leader and identifying key stakeholders
• Baseline understanding, which includes a comprehensive inventory of the data and assets to be protected, as well as determining required resources and budgets
• Planning and execution, which includes collaboration with internal and external partners to either acquire or develop the necessary tools for the migration
• Monitoring and evaluation, which includes establishing metrics for tracking the project’s progress and for reassessing cryptographic security, based on the evolution of quantum capabilities
   

"This roadmap empowers CIOs and CISOs to act decisively, taking proactive steps to protect sensitive data now and in the future,” Wen Masters, MITRE’s VP of cyber technologies, said in a statement. 

Transitioning to PQC, also known as quantum-resistant cryptography, is a complex process that’s expected to take the typical enterprise multiple years to complete and, as such, it will require exacting planning and ultra-precise execution.

Embarking on the process to adopt PQC is necessary because when quantum computers become generally available — expected to happen at some point between 2030 and 2040 — they’ll be able to crack today’s public key cryptographic algorithms, which protect all types of digitally stored and transmitted data

Algorithms for quantum-resistant encryption are already available. The U.S. National Institute of Standards and Technology (NIST) released three quantum-resistant algorithm standards in 2024 and expects to release a fourth in 2026. There’s another PQC standard called Covercrypt from the European Telecommunications Standards Institute (ETSI). Earlier this year, NIST picked its fifth PQC algorithm, expected to be available for use in 2027. 

Other resources designed to help organizations with PQC adoption include NIST’s white paper “Considerations for Achieving Crypto Agility” and the U.K. National Cyber Security Centre’s (NCSC) “Timelines for migration to post-quantum (PQC) cryptography.” 

For more information about how to protect your organization against the quantum computing cyber threat:

• “How to achieve crypto-agility and future-proof security” (TechTarget)
• “Moody’s sounds alarm on quantum computing risk, as transition to PQC ‘will be long and costly’” (Industrial Cyber)
• “Post-quantum cryptography migration use cases” (IETF)
• “US unveils new tools to withstand encryption-breaking quantum. Here's what experts are saying” (World Economic Forum)
• “You need to prepare for post-quantum cryptography now. Here’s why” (SC World)
• “Quantum and the Threat to Encryption” (SecurityWeek)

Corporate culture can have a major impact on the success or failure of a company’s cybersecurity efforts. So how do you create an organizational environment that boosts cybersecurity?

That’s the question the U.K. National Cyber Security Centre (NCSC) tackled with the publication this week of its “Cyber security culture principles” guidance. The document unpacks six core recommendations aimed at getting the staff to embrace cybersecurity processes. 

“The principles describe cultural conditions that are essential underpinnings for an organisation to be cyber secure and offer an approach to developing that culture,” reads an NCSC blog.
 

Here’s a high-level view of three of these principles:

• Frame cyber as an enabler: Foster a sense that cybersecurity is everyone’s responsibility by clearly positioning it as a “shared purpose.” Demonstrate how cybersecurity isn’t a barrier to but rather a facilitator for achieving business goals.
• Encourage openness: Make it easy for employees to report security issues and to ask questions. Investigate issues fairly and transparently, with the goal of fixing problems and sharing lessons learned, as opposed to affixing blame.
• Embrace change: Stay attuned to emerging cyber risks and be ready to modify cybersecurity processes accordingly. Show how this capacity to adapt to new cyber threats helps strengthen the organization’s resilience.

For more information about creating a healthy cybersecurity culture in your organization:

• “How to Create an Enterprise-Wide Cybersecurity Culture” (Information Week)
• “A new age of cybersecurity culture” (KPMG)
• “Signs Your Organization's Culture Is Hurting Your Cybersecurity” (Dark Reading)
• “How to turn around a toxic cybersecurity culture” (CSO)
• “Creating a Culture of Cybersecurity Awareness” (IT Executives Council)

VIDEO

Improve Your Cyber Security Culture (SANS Institute)

In addition to preventing and mitigating standalone cyber threats and attacks, U.S. critical infrastructure organizations must have a plan in case a lengthy, widespread cyber war breaks out.

That’s the call from MITRE, which has published a fact sheet with key actions for getting critical infrastructure organizations ready for an all-out cyber conflict that disrupts multiple essential services for a sustained period of time.

Titled “5 Steps To Prepare Critical Infrastructure for a Cyber War,” the document is aimed at critical infrastructure operators; federal, state and local governments; businesses; and communities.
 

The fact sheet is based on a classified tabletop exercise held at MITRE’s headquarters in December in which 70 government and private-sector organizations participated in a simulated cyber war.

“The event revealed the urgent need for infrastructure owners/operators, government agencies, and communities to shift from addressing isolated cyber incidents to preparing for large-scale cyber conflicts lasting weeks to months,” the document reads.

Here are five steps MITRE views as necessary for critical infrastructure organizations to get ready for a cyber war scenario:

• Create a civil defense mindset: Make citizens aware that basic services like electricty, water, telecom and transportation may be impacted. Stakeholders should plan how to issue emergency responses and how to prioritize restoration efforts.
• Manage limited resources: Critical infrastructure operators should test their incident response plans, while governments must plan with businesses how to address service outages.
• Plan to operate under extreme conditions: Recovering from the impacts of cyber war requires planning for coping with devastating outages that last weeks. Measures should include training staff for manual, disconnected operations, and boosting cyber resilience.
• Strengthen emergency communications systems: Develop communication systems and processes that’ll withstand a cyber war’s disruptions, along with ways to authenticate the identity of those involved.
• Ensure workforce readiness: Because the workforce will likely shrink during a cyber war emergency, contingency plans should be made to operate with a smaller staff, including training workers for this scenario.

Full details about the tabletop exercise are available to U.S. critical infrastructure owners and operators, as well as to government agencies. Those interested can request access by writing to this email address: CICSTTX@mitre.org.

For more information about cyber warfare:

• “Preparing for Cyber Warfare: 6 Key Lessons From Ukraine” (Dark Reading)
• “Cyberwarfare: The new frontlines” (Cybersecurity Guide)
• “‘Russia can turn the lights off’: how the UK is preparing for cyberwar” (The Guardian)
• “The Growing Threat of Cyberwarfare from Nation-States” (PaymentsJournal)
• “Russia’s Most Notorious Special Forces Unit Now Has Its Own Cyber Warfare Team” (Wired)

During our recent “Tenable Vulnerability Management Customer Update, June 2025” webinar, we polled attendees on their exposure response strategies and challenges. Check out what they said.

(152 webinar attendees polled by Tenable, June 2025) 

 (145 webinar attendees polled by Tenable, June 2025. Respondents could choose more than one answer.)

Watch this on-demand webinar to get the latest on Tenable Vulnerability Management and to learn how to develop exposure response strategies.

With median salaries north of $500,000 and top earners making $1.3 million-plus annually, CISOs at large enterprises are making bank, but, ironically, job dissatisfaction among them is high.

That’s according to the “2025 Compensation and Budget for CISOs in Large Enterprises Benchmark Report” from IANS Research and Artico Search, which also found that a large percentage of these CISOs are actively looking for new jobs.

“Large enterprise CISOs might be among the highest paid across industries, yet our report reveals that many CISOs feel stretched too thin, and low job satisfaction keeps them open to new opportunities,” reads an IANS Research blog about the report.

Specifically, many of these CISOs are unhappy with their team’s budget and, to a lesser extent with their compensation. It’s also common for them to struggle broadening their focus from overseeing cybersecurity technology to supporting business initiatives.

“When elevating an enterprise CISO role, the position is less about technical acumen and more about business risk and business alignment,” Matt Comyns, Artico Search co-founder and president, said in the blog. 

“In some respects, the market is training technical leaders in a way that is mismatched from the aspired job of CISO,” he added.
 

(Source: “2025 Compensation and Budget for CISOs in Large Enterprises Benchmark Report” from IANS Research and Artico Search, May 2025)

The report defines these CISOs as those who work at enterprises with more than $1 billion in revenue. They make an average of about $700,000 in total compensation annually.

For more information about CISO trends:

• “Why Security Leaders Are Opting for Consulting Gigs” (Dark Reading)
• “CISO Burnout Is Increasing — Here’s How to Help Them” (Reworked)
• “CISO Paychecks: Worth the Growing Security Headaches?” (Dark Reading)
• “Has the CISO finally been accepted as a key strategic player?” (Deloitte)
• “CISOs in 2025: Evolution of a High-Profile Role” (Information Week)

In this fifth installment of Tenable’s “Stronger Cloud Security in Five” blog series, we offer three best practices for quickly hardening your Kubernetes environment’s security in GCP: remove wide inbound access to cluster APIs; remove root permissions from containers; and remove privileged permissions from publicly accessible groups. 

Securing your Kubernetes environment is critical in order to protect your cloud application development lifecycle and your container orchestration. However, properly configuring and managing Kubernetes is complicated, and this often leads to lax security controls that put organizations at an elevated risk for a breach.

As the “Tenable Cloud Risk Report 2024” found, security weaknesses in Kubernetes environments aren’t the exception – they’re the norm:

• 78% of organizations have publicly accessible Kubernetes API servers, and 41% of those are set to allow inbound internet access.
• 44% run privileged containers, which have access to the host’s resources and kernel capabilities, making them a major risk if attackers gain access to them.
• 58% have cluster-admin role bindings, which give some users complete control over all of their organizations’ Kubernetes environments.

Here we outline three best practices that take no more than five minutes to implement and that’ll quickly boost the security of your Google Cloud Platform’s (GCP) Kubernetes environment. Read on!

The Google Kubernetes Engine (GKE) API lets you query and manipulate the state of API objects in Kubernetes. Thus, you should configure its authorized networks setting so it restricts inbound internet access to specific IP addresses. Otherwise, if the authorized network setting is disabled, any public IP address can access the Kubernetes API without any restrictions, creating a significant risk for malicious users to tamper with the API. 

If you don't use a mechanism to restrict access to your cluster's control plane, it may be exposed to network access publicly.

One way this can be mitigated is to limit the authorized networks that can access the control plane in this way: 

1. In the GCP Portal, open the resource page of GKE cluster.
2. Under the “Networking - Control plane authorized networks” setting, click the pencil button.
3. Check “Enable control plane authorized networks.”
4. Edit the “Authorized Networks” to allow access only to specific IP addresses that require access to the Kubernetes API.
5. Click “Save Changes” to confirm

By taking these steps, you shrink your Kubernetes clusters’ attack surface and reduce the risk that hackers will breach the control plane via brute-force attacks, API vulnerability exploitation and other attack methods.

If attackers exploit a vulnerability in a privileged container’s application, they could control the container’s host and wreak havoc in your Kubernetes environment. For example, attackers could tamper with host devices and kernel parameters, and make malicious OS system calls, such as retrieving files and disabling security controls. 

That’s why we don’t recommend running privileged containers. You should evaluate Kubernetes workloads and flag every container spec that has the securityContext.privileged flag set to “true,” as shown in the screenshot below.
 

(Source: Tenable)

Here’s how you remediate this:

1. For each deployment where a container is provisioned with a privileged security context, set the flag for "privileged" to “false.” 
2. Add a Pod Security Standard policy to the namespace default.

You should be aware that the groups like system:anonymous user and system:unauthenticated can be used by anyone with access to the cluster. In GKE, the system:authenticated group, though it may sound more secure, actually allows access to anyone who can identify with any Google identity (e.g., a Gmail account), making it public.
 

(Source: Google’s “Best practices for GKE RBAC” documentation) 

Unfortunately, it’s quite common for organizations to inadvertently grant these groups privileged access, which opens the door for potentially anyone on the internet to access critical resources in your Kubernetes environment. 

In addition, combining this with the first issue we discussed — unrestricted network access to the cluster's control plane — grants permissions that can be leveraged by anyone with network access to the control plane, which in turn has network access from anywhere. 

This dangerous scenario puts your organization at an elevated risk for a breach if attackers exploit a security flaw in your Kubernetes environment, such as a container pod with a critical vulnerability.

To remedy this simply remove any unnecessary role bindings from the publicly accessible groups.

We hope you’ve found these three Kubernetes security “quick win” tips helpful and valuable. They’re just a small sample of the comprehensive Kubernetes security best practices our cloud security experts can help you adopt and automate with our Tenable Cloud Security cloud native application protection platform (CNAPP).

With Tenable Cloud Security, you can streamline and simplify core Kubernetes security elements across multi-cloud environments, including:

• Obtaining comprehensive, continuously updated visibility into all your resources
• Controlling access to clusters and enforcing least-privilege access
• Enforcing policy and configuration control at scale
• Detecting container vulnerabilities and malware
• Automating remediation and mitigation of security issues, including misconfigurations, policy violations and overprivileged identities

Find out how you can take action to boost your Kubernetes and your overall multi-cloud security in just five minutes.

• "Stronger Cloud Security in Five: The Importance of Cloud Configuration Security"
• "Stronger Cloud Security in Five: How To Protect Your Cloud Workloads"
• "Stronger Cloud Security in Five: Securing Your Cloud Identities"
• “Stronger Cloud Security in Five: How DSPM Helps You Discover, Classify and Secure All Your Data Assets”

Crucial for applying Active Directory Group Policy Objects, client-side extensions (CSEs) are powerful but also present a significant, often overlooked, attack vector for persistent backdoors. Rather than cover well-documented common abuses of built-in CSEs, this article demonstrates how to create custom malicious ones. These are harder for defenders to identify than legitimate built-in CSEs used in malicious contexts, which have known globally unique identifiers.

Group Policy Objects (GPOs), a core feature of Active Directory (AD), allow administrators to centrally manage and configure operating systems, applications and user settings across all computers in a domain by configuring a set of rules and configurations.
 

(Source: Microsoft)

It is well-known that attackers with sufficient AD access can abuse GPOs for malicious actions like code execution, malware deployment, immediate scheduled tasks, privilege escalation, and stealthy persistence establishment; these techniques are generally well-documented.

Each GPO comprises two main parts:

• The groupPolicyContainer object (GPC) in AD’s LDAP, holding metadata such as display names and CSE lists
• The Group Policy Template (GPT) in AD’s SYSVOL share, containing the actual policy files and scripts

Have you ever wondered how the settings defined in a GPO actually get applied on a client computer? The magic behind this process lies in the CSEs.

CSEs are critical components that enable GPOs to apply specific settings such as software installation, registry edits, folder redirection, scheduled tasks, or Internet / power options and more to client machines.

While Group Policy defines and distributes configuration policies across the network, it’s the CSE on the client side that interprets and enforces these policies. Each CSE is essentially a dynamic link library (DLL) file on the client Windows machine responsible for processing a particular type of Group Policy setting. When a computer processes GPOs, its Group Policy engine reads the policies and invokes the relevant CSEs to effectively apply the settings.

The successful application of settings from a specific Group Policy area relies on the correct handling of CSEs. Even if a GPO is properly linked and the user/machine is included in the security filter, the settings it contains may fail to apply under two key conditions related to CSEs:

• The CSE is not installed and registered on the client machine.
• The CSE's GUID is not listed in the GPO's attributes.

Therefore, both the local CSE availability and its correct reference within the GPO’s attributes are mandatory.

Every CSE is uniquely identified by a Globally Unique Identifier (GUID). This GUID acts as the registration key and the link between the policy settings defined in the GPO and the processing logic (the DLL) on the client.

While official Microsoft documentation mentions some CSEs, the list is incomplete. A more complete list can be found online. Also, the following PowerShell command can be executed on your machine to list them:

CSEs are registered in the registry under the following path: 
HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
 

On the left, under the GPExtensions key, you will find multiple subkeys, each named with the GUID of a specific CSE. The settings of each of them are defined on the right.

Here are some important settings to be aware of: 

• (Default): This is the name of the CSE.
• DllName: This the DLL corresponding to the CSE to be loaded by the GPO engine. The system searches for the DLL in the C:\Windows\System32 directory when a relative path is used. Alternatively, the full path to the DLL can be directly specified.
• NoGPOListChanges: If this value is 1, it indicates that it is not necessary to call the callback function (ProcessGroupPolicy) when there has been no change in the GPO.
• ProcessGroupPolicy: This is the name of the function exported by the library to be called by the GPO engine to apply the CSE settings.

For detailed information on other functionalities, please consult the official Microsoft documentation on Creating a Policy Callback Function.

When you configure settings within a specific GPO using the Group Policy Management Editor, the tool records which types of settings you've configured and the necessary CSEs. It does this by storing the GUIDs of these CSEs within attributes of the GPC object in AD.

Specifically, you need to look at these two attributes on the GPC object:

• gPCMachineExtensionNames: This attribute lists the GUIDs of the CSEs required to process settings configured in the Computer Configuration section of the GPO.
• gPCUserExtensionNames: This does the same for user configuration.

The expected format is the concatenation of the GUIDs: 
[<CSE GUID1><TOOL GUID1>][<CSE GUID2><TOOL GUID2>] etc.
 

For example, if we analyze the gPCMachineExtensionNames attribute of the “Default Domain Policy” shown above, we can see that the first part of each GUID-pair in the screenshot above can be identified as a CSE:

• 35378EAC-683F-11D2-A89A-00C04FBBCFA2: Registry/Administrative Template
• 827D319E-6EAC-11D2-A4EA-00C04F79F83A: Security
• B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A: EFS

Note: CSE GUIDs within Group Policy attributes, such as gPCMachineExtensionNames, must be sorted in case-insensitive ascending order. If this order is not maintained, CSEs risk being ignored during Group Policy processing.

The first GUID relates to the CSE function, and the second GUID in the pair is not important for today. For deeper GPO auditing insights, see Aurélien Bordes' 2019 SSTIC paper.

Articles discussing the malicious use of CSEs in AD often highlight two themes: the potential for red teams to abuse specific well-known CSEs, and the corresponding need for blue teams to track their execution. For instance:

• Scheduled Tasks {AADCED64-746C-4633-A97C-D61349046527}:
  • “GPOddity: exploiting Active Directory GPOs through NTLM relaying, and more!”, Synacktiv (Quentin Roland)
  • “Abusing GPO Permissions”, harmj0y (Will Schroeder)
• Files {7150F9BF-48AD-4DA4-A49C-29EF4A8369BA}:
  • “Weaponizing Group Policy Objects Access”, TrustedSec (Jason Lang)
• Various CSEs:
  • “A Red Teamer’s Guide to GPOs and OUs”, wald0 (Andy Robbins)

Surprisingly, public methods or articles explaining how to abuse custom CSEs for this persistence method seem absent, especially given that Microsoft explains the CSE creation process itself. This obscurity is valuable to an attacker, offering inherent discretion through an unknown CSE GUID, plus the benefit of SYSTEM code execution capability.

Let's proceed by creating a custom CSE to explore different ways attackers might leverage it for malicious purposes.

We will use Visual Studio to create a custom CSE DLL with the friendly name “Group Policy Shell Configuration” and filename advshcore.dll (using base advshcore to appear inconspicuous in the System32 Windows folder). Create a new DLL project, name it “RogueCSE,” and click “Create” to begin.

In your project, create advshcore.def and add this content:

In dllmain.cpp, now add the necessary includes, defines, and variables functions:

Implement the DllMain function as follows:

Next, two helper functions are created. The first, a simple logger, proves privileged SYSTEM code execution by writing to a file. Though this example is benign, attackers could substitute malicious code, such as for a reverse shell, C2 agent, or NTDS.dit exfiltration to a public share.

Next, a function logs the execution context:

We will now follow Microsoft's guidance for custom CSEs, implementing only the exported ProcessGroupPolicy function with minimal content for our test.

And that’s it, we have all the minimum requirements for our own CSE.

An extension can be registered here either manually or automatically:

• Manually: You can do this by creating all the required items, as we explained previously in the section “What do CSEs look like on a client machine?”
• Automatically: As described by Microsoft in the CSE documentation (and also in the Component Object Model -COM- documentation), the “DllRegisterServer” function can be implemented to allow self-registration using regsvr32.

The automatic method requires “DllRegisterServer” and “DllUnregisterServer” to manage the following registry keys:

• The key associated with our GUID under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.
• (Default): “Group Policy Shell Configuration”.
• DllName: “advshcore.dll”.
• NoGPOListChanges: “0” to call the ProcessGroupPolicy function every time, even if there is no change in the GPO.
• ProcessGroupPolicy: We kept the suggested name here.

The Solution Explorer should now show the project like this:

Before building, change the Visual Studio solution configuration to Release (x64) from its Debug (x64) default using the toolbar's dropdown menu. Then:

1. Open the RogueCSE project properties (Right-click > Properties).
2. Verify that Configuration is Release and Platform is x64.
3. Under Configuration Properties > General:
   1. Set Target Name to “advshcore”.
4. Under Configuration Properties > C/C++ > Code Generation:
   1. Change Runtime Library to Multi-threaded (/MT).
5. Under Configuration Properties > Linker > Input:
   1. Enter “advshcore.def” for Module Definition File.
6. Click “Apply” and then “OK” to save these project settings.
7. Finally, build the solution by selecting Build > Build Solution from the main menu bar. Your custom DLL (“advshcore.dll”) is now ready to be registered as a new CSE.

Recall that this technique represents a novel persistence method, effectively creating a backdoor in the domain on targeted workstations and servers. For this example scenario, assume an attacker gains sufficient privileges (e.g., Domain Admins) to access and operate on a domain controller.

On the compromised domain controller, the attacker would then perform these steps:

1. Copy the previously created DLL file (“advshcore.dll”) to the C:\Windows\System32 folder.
2. Register the DLL by executing the following command:

A confirmation will be displayed indicating that the DLL registration succeeded.
 

You can verify in the registry that the custom CSE has been registered correctly.
 

As explained at the beginning of this article, a GPO only loads CSEs whose GUIDs are listed in its gPCMachineExtensionNames or gPCUserExtensionNames attributes. Therefore, to enable our custom CSE, we must now add its GUID to the gPCMachineExtensionNames attribute of the target GPO.

We can use the following PowerShell code to perform this update:

Next, either wait for the Group Policy refresh cycle, which typically takes about five minutes on domain controllers, or trigger an immediate update by running gpupdate /force on the test domain controller.

After the policy refresh, verify that the C:\RogueCSE.log file has been created with content like:
 

Note that the custom code within the CSE DLL runs in the Group Policy Client service context (GPSVC) and with highly privileged SYSTEM permissions.

Observing the log file over time confirms that the custom CSE code executes during each Group Policy refresh cycle. On the domain controller, this refresh occurs at the short interval mentioned earlier of around 5 minutes. This persistence method also works on member machines, although their default refresh interval is significantly longer – approximately 90 minutes, plus a random offset.

In summary, a custom CSE, advshcore.dll, was successfully deployed to a DC, demonstrating basic logging. This served as a proof-of-concept but also highlighted significant abuse potential. Adversaries could exploit Group Policy infrastructure for stealthy communication channels or persistent backdoors. Leveraging native OS features instead of external malicious tools makes this technique difficult to detect through forensic analysis or threat identification. This underscores the vital need for vigilant monitoring and strict security controls for GPOs and CSEs in AD environments.

With the fundamental steps covered, let's consider broader application. An attacker with domain privileges (e.g., Domain Admin) could propagate this CSE-based persistence across the network.

To distribute the payload, the attacker might place the DLL in an inconspicuous SYSVOL location like \\SYSVOL\<domain_name>\scripts\SecurityProviders, making it domain-accessible. We will now explore various approaches, analyzing their strengths and weaknesses.

To ensure reliable deployment, especially for intermittently connected endpoints, attackers might use Files Group Policy Preference to copy the custom CSE DLL locally, allowing its registry path to point to this local file. A GPO, often using a startup script, can then register this local CSE. Its gPCMachineExtensionNames attribute must also be updated with the GUIDs of any required built-in CSEs and the custom one.

Although robust, this deployment method increases detectability due to significant GPO changes and the typical use of known CSEs for payload delivery, a pattern often monitored. Detecting such activity can involve Windows Event Log analysis, including:

• Security Event ID 5145: Monitor this event to detect write access to the SYSVOL share. This can identify when the malicious DLL is written, or when files related to Group Policy settings for Files Preferences, Scheduled Tasks, or Startup Scripts are created or modified within SYSVOL.
  
   

   

• Security Event ID 4688 “A new process has been created”: Monitor this event, specifically its "Process Command Line" field, to detect specific types of process execution. This can identify when a startup script is run or a process is launched by an immediate scheduled task.

• Task Scheduler Operational Event ID 201: Monitor this event to identify the specifics of completed scheduled tasks. This can reveal the task name (e.g., "Test2") and the action it performed (e.g., running ‘cmd.exe’).
   

• gPCMachineExtensionNames attribute: Finally, monitor this critical attribute for unauthorized changes. These can be found via LDAP queries or Security Event ID 5136,which logs directory object modifications.
   

Note: The discussed large-scale deployment methods using common Group Policy features (Files GPP, Scripts, Scheduled Tasks) often trigger blue team alerts.

Alternatively, a custom CSE DLL can be hosted on a network share, instead of being copied locally, and loaded via its registered network path. For our straightforward example, SYSVOL will serve as this share, and the DLL's registered path will point there.
 

PowerShell cmdlets like New-ItemProperty offer an alternative to regsvr32.exe for CSE DLL registration, potentially bypassing common monitoring of regsvr32 (documented by the MITRE ATT&CK T1218.010). This remote-scriptable method lacks GPO-based persistence – the backdoor won't be reapplied by GPO if altered – but offers stealth: a GPO attribute having only a custom GUID might bypass certain defenses.

GUID hijacking is another stealthy approach: attackers redirect an unused legitimate CSE's registered DLL path to a malicious one. Adding this compromised but valid-looking GUID to a GPO can bypass defenses that only check GUIDs, not DLL paths.

These examples show custom malicious CSEs' covert potential.

Abusing custom CSEs can create stealthy backdoors into AD environments. Attackers can deploy custom DLLs and register them as CSEs, and then manipulate GPOs to load these malicious extensions. This technique leverages trusted Windows components, making it difficult to detect using standard security measures.

Traditional detections often focus on famously abused CSEs, such as those for Scheduled Tasks or Startup Scripts. However, registering and deploying a custom CSE can be achieved without these easily identifiable actions, bypassing common alerts. Techniques like hosting the DLL on a network share and directly modifying the registry can further reduce detectability, though these methods might trade off reliability. Alternatively, hijacking an unused built-in CSE GUID and altering its DLL path can be a particularly evasive strategy.

While the initial registration of a custom CSE can be detected, once the backdoor is configured within a GPO, identifying it becomes challenging. The CSE code runs with SYSTEM privileges during each Group Policy refresh cycle, offering persistent and potentially long-term control to an attacker. This highlights the importance of rigorously monitoring CSE registrations and GPO modifications, as well as examining event logs for unexpected activity related to Group Policy Client Service (GPSVC) and changes in the gPCMachineExtensionNames attribute. Regularly checking for custom CSEs as Tenable Identity Exposure does through the GPO Execution Sanity Indicator of Exposure is essential for securing Active Directory environments.
 

Frequently asked questions about “BadSuccessor,” a zero-day privilege escalation vulnerability in Active Directory domains with at least one Windows Server 2025 domain controller.

Tenable’s Research Special Operations (RSO) and the Identity Content team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding a newly disclosed zero-day in Active Directory called BadSuccessor.

What is BadSuccessor?

BadSuccessor is the name of a zero-day privilege escalation vulnerability in Active Directory that was discovered and disclosed by Yuval Gordon, a security researcher at Akamai.

According to Gordon, the flaw exists in delegated Managed Service Accounts (dMSAs), a service account type in Active Directory (AD) that was introduced in Windows Server 2025 to enable the migration of non-managed service accounts.

What are the vulnerabilities associated with BadSuccessor?

As of June 2, Microsoft had not assigned a CVE identifier for BadSuccessor. Microsoft is the CVE Numbering Authority (CNA) for its products. Since there are currently no patches available for BadSuccessor, no CVE has been assigned. If Microsoft does assign a CVE alongside patches for it, we will update this blog accordingly.

How is BadSuccessor exploited?

To exploit BadSuccessor, an attacker needs to be able to access a user account with specific permissions in AD, and at least one domain controller in the domain needs to be running Windows Server 2025.

Based on Akamai’s research, even if an AD domain is not using dMSAs, nor operates at the 2025 functional level, all that is required is that a targeted user has either the permission to:

• Create a new dMSA (msDS-DelegatedManagedServiceAccount object class) in any container or organizational unit (OU)
• Abuse an existing dMSA by modifying its msDS-ManagedAccountPrecededByLink attribute

When was BadSuccessor first disclosed?

On May 21, Akamai published a blog post about BadSuccessor, which included a detailed overview of the flaw, as well as detection and mitigation guidance.

How severe is BadSuccessor?

BadSuccessor has the potential to be very severe, as exploitation could allow an attacker to achieve full domain, and then forest, compromise in an Active Directory environment. However, one mitigating factor is that it only affects domains with at least one Windows Server 2025 domain controller.

How prevalent are AD domains with at least one Windows Server 2025 domain controller?

Based on a subset of Tenable’s telemetry data, we found just 0.7% of AD domains have at least one Windows Server 2025 domain controller. This appears to be lower than other statistics we’ve seen reported.

Was BadSuccessor exploited as a zero-day?

As of June 2, there have been no indications that BadSuccessor has been exploited in the wild.

Why is it called BadSuccessor?

According to Gordon, the name “BadSuccessor” is tied to the fact that the user account (or dMSA) becomes the nefarious “successor” by inheriting the elevated privileges of another identity in the AD environment.

6/ We named this attack BadSuccessor, because that's exactly what the dMSA becomes - the unintended heir to a high-privilege identity.
A successor, with all the right keys.

— Yuval Gordon (@YuG0rd) May 21, 2025

Is there a proof-of-concept (PoC) available for BadSuccessor?

Yes, there are several proofs-of-concept (PoCs) for BadSuccessor available on GitHub, including a.NET implementation called SharpSuccessor. It is also available in NetExec, the successor to the infamous CrackMapExec hack tool. It was also added to BloodyAD, the Active Directory privilege escalation framework.

Are patches or mitigations available for BadSuccessor?

As of June 2, there were no patches available for BadSuccessor. However, in the Akamai blog post from May 21, Microsoft indicated they would “fix this issue in the future.” If and when a patch becomes available, we will update this section.

Akamai’s blog post includes details on detecting BadSuccessor as well as mitigation suggestions.

Has Tenable released any product coverage for these vulnerabilities?

While Microsoft has not yet released patches for BadSuccessor, Tenable Identity Exposure customers can utilize our recently released (v3.95) Indicator of Exposure (IoE) for BadSuccessor.

Once Microsoft assigns a CVE and releases patches, we will update this section with additional Tenable coverage.

• BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory

Join Tenable's Research Special Operations (RSO) Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, Tenable’s chief security officer Robert Huber looks at how exposure management can help you move beyond silos. You can read the entire Exposure Management Academy series here.

The way we use technology — in IT, cloud security, operational technology (OT), internet of things (IoT), AI and countless applications — has led to a corresponding array of specialized security tools. Think about all the tools you use: vulnerability assessment, identity security, endpoint detection and response (EDR), data loss prevention (DLP), cloud native application protection platforms (CNAPP), mail protection, cloud access security broker (CASB), mobile device management (MDM) and privilege access management (PAM). 

That’s a lot of tools — and a lot of silos. But it doesn’t end there. Each of those tools has a subset of capabilities that can result in even more silos across your security program. Of course, all of this reflects the issues we face and the way our organizations are structured. But, sadly, attackers don’t care about our org charts or toolsets. And thank goodness they haven’t figured out how to use pivot tables yet!

They just look for weaknesses, exploit them and move laterally across domains to achieve their goals. In fact, those silos we’ve built can inadvertently help them by hindering communication and context between teams, making it difficult to see our true exposures — or the risks that pose a real threat.

As a security leader myself, I know this pain firsthand. 

Before adopting a more unified approach, I constantly felt like I was buried in fragmented data from countless tools and teams. 

Much of my day was lost to context-switching, trying to manually piece together a coherent picture from disconnected silos. This makes communicating clear priorities incredibly difficult. 

You often can't compare apples-to-apples, leading to subjective decisions about which risk truly matters most. It’s an exhausting, inefficient cycle that makes it hard to confidently answer a key question: "What should we focus on right now?" It also makes it tough to report accurately on our risk posture.

This struggle highlights why distinguishing significant exposures from the background noise of all possible weaknesses is so critical for effective risk management. If you want to reduce your risk, you need to identify the problems that truly matter most to your organization. Key questions to ask yourself as you evaluate your organization’s exposures include:

• Is it preventable? Most breaches start with something that could have been fixed, such as a misconfiguration, a known vulnerability or unnecessary privileges.
• Is it exploitable? An attacker needs a way to actually use the weakness. This could be via a known exploit code, weak passwords or multi-factor authentication (MFA) identity compromise.
• Is it impactful? A weakness that results in lost revenue, data theft or operational downtime could significantly harm the organization's mission. Linking technical risk to potential business impact is key.

Too often, we approach security in fragments, unlike attackers who look for any viable path. This leaves us struggling to be strategic. Some of the common roadblocks include:

• Lack of a unified view: Different tools focus on specific domains or risk types, so no single platform provides a complete view of the attack surface.
• Inconsistent risk scoring: Each tool uses its own metrics, which makes it hard to compare relative risk across the environment or understand the cumulative risk associated with critical assets.
• Missing technical context: If you don’t connect the dots between assets, identities and their associated risks, it's impossible to understand the likely attack paths available to adversaries.
• Missing business context: Security data often lacks information about which assets support critical business functions, hindering the ability to prioritize based on potential business impact.

Historically, a significant portion of our security investments focused on detecting and responding to attacks already in progress. This makes sense because it’s where breaches cause obvious damage.

But regulations and best practices are changing. Rules from the U.S. Securities and Exchange Commission (SEC) (requiring reporting of material impact within four days for public companies) and the Cybersecurity and Infrastructure Security Agency (CISA) (requiring reporting of “substantial cyber incidents” within three days for critical infrastructure) mandate much faster transparency and accountability. The timeframe for understanding and disclosing significant incidents is shrinking dramatically.

This pressure, combined with the high cost of breaches, increases the strategic importance of finding and fixing significant exposures before they lead to reportable incidents and material impact. Investing proactively in understanding and reducing exposure is often far less costly and disruptive than managing the fallout of a major breach. Reduce risk and increase security ROI.

Understanding how breaches happen and the limitations of siloed security points to the need for a more integrated, exposure-focused strategy. This isn't about abandoning detection and response capabilities. On the contrary, it’s about augmenting those capabilities by strengthening preventative security to better understand and prioritize risks before they cause harm.

Solving this requires a structured approach. As my colleague Nathan Dyer wrote in Five Steps to Move to Exposure Management, the core principles involve:

• Gaining comprehensive visibility across the entire attack surface, including assets and identities
• Identifying all forms of preventable risk, such as vulnerabilities, misconfigurations and privilege issues with consistent, contextualized scoring
• Critically aligning technical risk with business context to understand potential impact and prioritizing remediation on the exposures and attack paths, including key choke points, that pose the greatest threat to critical functions
• Continuously measuring and communicating exposure to optimize security investments and report effectively to stakeholders, including the board

Exposure management platforms support this lifecycle, providing capabilities to aggregate disparate data, calculate risk scores (like asset exposure scores, vulnerability priority rating, asset criticality rating) that incorporate exploitability and criticality, map assets to business functions, visualize attack paths, identify choke points for efficient remediation, and provide dashboards for tracking and reporting exposure trends against internal goals or industry benchmarks.

Ultimately, by breaking down data silos and adopting an exposure management mindset, security leaders can gain a more holistic view of their attack surface and true business risk. This enables better resource allocation, more defensible prioritization, clearer communication about security posture and, ultimately, a more effective preventative security program aligned with organizational objectives.

Here’s my advice to security leaders fighting silos and looking to move to exposure management.

• Think like an attacker: Adversaries exploit seams between siloed views. Security strategy must strive for a unified understanding of the attack surface.
• Focus on material exposure: Prioritize risks that are preventable, exploitable and demonstrably impactful to critical business functions, not just technically severe in isolation.
• Drive strategic outcomes: Implementing an exposure management approach enables more effective resource allocation, clearer communication of risk posture to stakeholders (including the board) and ultimately, a more defensible and efficient security program.

We’re all ears. Share your question and maybe we’ll feature it in a future post.

Check out ETSI’s new global standard for securing AI systems and models. Plus, learn how CISOs and their teams add significant value to orgs’ major initiatives. In addition, discover what webinar attendees told Tenable about their cloud security challenges. And get the latest on properly decommissioning tech products; a cyber threat targeting law firms; and more!

Dive into six things that are top of mind for the week ending May 30.

What is the proper way to secure your artificial intelligence models and systems? Are you confused by all the different AI security recommendations and guidance? The European Telecommunications Standards Institute (ETSI) is trying to bring clarity to this issue.

ETSI, in collaboration with the U.K. National Cyber Security Center (NCSC) and the U.K. Department for Science, Innovation & Technology (DSIT), has published a global standard for AI security designed to cover the full lifecycle of an AI system.

Aimed at developers, vendors, operators, integrators, buyers and other AI stakeholders, ETSI’s “Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems” technical specification outlines a set of foundational security principles for an AI system’s entire lifecycle.

Here's an overview of the five stages of an AI system and the 13 security principles that must be adopted:

• Secure design stage
  • Raise awareness about AI security threats and risks.
  • Design the AI system not only for security but also for functionality and performance.
  • Evaluate the threats and manage the risks to the AI system.
  • Make it possible for humans to oversee AI systems.
• Secure development stage
  • Identify, track and protect the assets.
  • Secure the infrastructure.
  • Secure the supply chain.
  • Document data, models and prompts.
  • Conduct appropriate testing and evaluation.
• Secure deployment stage
  • Communication and processes associated with end-user and affected entities.
• Secure maintenance stage
  • Maintain regular security updates, patches and mitigations.
  • Monitor system behavior.
• Secure end-of-life stage
  • Ensure proper data and model disposal.
     

Each one of the 13 security principles is further broken down into multiple provisions that detail more granular requirements. 

For example, in the secure maintenance stage, ETSI calls for developers to test and evaluate major AI system updates as they would a new version of an AI model. Also in this stage, system operators need to analyze system and user logs to detect security issues such as anomalies and breaches.

The 73-page companion technical report, “Securing Artificial Intelligence (SAI): Guide to Cyber Security for AI Models and Systems,” offers significantly more technical detail about each provision. 

Together the technical specification and the technical report “provide stakeholders in the AI supply chain with a robust set of baseline security requirements that help protect AI systems from evolving cyber threats,” reads an NCSC blog.

For more information about AI security, check out these Tenable resources:

• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Tenable Cloud AI Risk Report 2025” (report)
• “Who's Afraid of AI Risk in Cloud Environments?” (blog)
• “Tenable Cloud AI Risk Report 2025: Helping You Build More Secure AI Models in the Cloud” (on-demand webinar)
• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood” (blog)

Cybersecurity teams’ involvement in large-scale organizational initiatives yields significant monetary benefits – especially if CISOs are incorporated early into these efforts.

That’s a key finding from Ernst & Young’s “2025 EY Global Cybersecurity Leadership Insights Study,” which surveyed 550 C-suite and cybersecurity leaders globally from organizations with more than $1 billion in annual revenue.

Specifically, the study found that cybersecurity teams contribute a median of $36 million to every enterprise-wide initiative they’re involved in. That’s equivalent to between 11% and 20% of the value of each project.

“CISOs who are involved early in cross-function decision-making generate more value than those who were consulted late or not at all,” the report reads. 

“CEOs, CFOs and boards should take steps to more meaningfully integrate cybersecurity into transformations and other strategic initiatives,” it adds.
 

The finding points to how CISOs and their cybersecurity teams are expanding their scope from managing security, risk and compliance to becoming “key enablers of business growth.”

Unfortunately, over the past two years, cybersecurity budgets have shrunk as a percentage of annual revenue, and only 13% of surveyed CISOs said they get looped in early into critical business decisions.

Using a framework, the report concluded that cybersecurity adds considerable value to these six key types of initiatives:

• Adopting and building technology
• Strengthening brand trust and reputation
• Improving customer experience
• Transforming and innovating across the business
• Expanding to new markets
• Developing new products and services

For more information about how CISOs and their cyber teams add value to business ventures:

• “Better metrics can show how cybersecurity drives business success” (CSO)
• “Build CISO Strategic Impact and Visibility” (IANS Research)
• “Nearly half of CISOs now report to CEOs, showing their rising influence” (Help Net Security)
• “CISOs embrace rise in prominence — with broader business authority” (CSO)
• “How leading CISOs build business-critical cyber cultures” (CIO)

During our recent webinar “Confident in the Cloud: How to Overcome Complexity and Get AWS Security Right,” we asked attendees about their cloud security practices and challenges. Check out what they said.

(137 webinar attendees polled by Tenable, May 2025)

(60 webinar attendees polled by Tenable, May 2025)

Interested in learning about proven best practices for how to control and secure your AWS environment? Watch this webinar on-demand!

It’s important to properly dispose of software and hardware products after removing them from your IT environment.

To help organizations with this process, the U.K. National Cyber Security Centre (NCSC) has published guidance on how to securely retire obsolete technical wares.

“Decommissioning can be highly expensive and complex, with potentially severe repercussions if not executed properly,” the NCSC document reads. “Outdated or unsupported assets can pose an unacceptable risk to the organisation.”
 

For example, an improperly decommissioned IT product could allow unauthorized people to access confidential data and could be used to breach services and devices.

The NCSC guidance, titled “Decommissioning assets,” addresses topics including:

• How to plan the decommissioning process
• How to carry out the decommissioning of obsolete assets
• What to do after the decommissioning process is completed

For more information about properly disposing of obsolete hardware and software:

• “How to Decommission IT Hardware” (Techbuyer)
• “Why end-of-life IT is ruining innovation and how to fix it” (OliverWyman)
• “Cybersecurity guidance: Obsolete products (Canadian Centre for Cyber Security)
• “The Top 5 Risks of Using Obsolete and Unsupported Software” (IT Convergence)
• “Managing the risks of legacy IT” (Australian Cyber Security Centre)

Hacker group Silent Ransom is targeting law firms via phishing calls and emails aimed at tricking employees into granting it remote access to their computers. Once they gain remote access, the attackers steal confidential data and use it to extort the victims.

So said the U.S. Federal Bureau of Investigation (FBI) in an alert titled “Silent Ransom Group Targeting Law Firms.”

Silent Ransom, also known as Luna Moth, Chatty Spider and UNC3753, employs two different schemes:

• It emails its targets offering fake, inexpensive subscriptions, and when victims request that the subscription be cancelled, the attackers email them a link that downloads remote access software on their computers.
• A Silent Ransom attacker calls a law firm employee and, pretending to be a member of the IT department, asks the victim to join a remote access session.

Detecting a Silent Ransom attack is difficult. Its hackers don’t leave behind traditional attack indicators because they use legitimate remote-access and systems-management tools. Thus, to spot a Silent Ransom breach, the FBI recommends looking for:

• New, unauthorized downloads of systems-management and remote-access tools
• A WinSCP or Rclone connection made to an external IP address
• Anonymous emails or calls claiming data was stolen
• Emails regarding how to cancel a subscription service
• Unsolicited calls from individuals claiming to work in the law firm’s IT department

To mitigate the threat, FBI recommendations include:

• Train staff on recognizing and resisting phishing attempts.
• Establish and relay policies for when and how your law firm’s IT department will reach out to employees and prove their identities.
• Regularly back up company data.
• Adopt multi-factor authentication for all employees.

For more information about remote access attacks:

• “12 remote access security risks and how to prevent them” (TechTarget)
• “Guide to Securing Remote Access Software” (CISA)
• “Remote-access tools the intrusion point to blame for most ransomware attacks“ (Cybersecurity Dive)
• “Avoiding Ratting – Remote Access Trojans” (Get Safe Online)
• “RDP and Other Remote Login Attacks” (Ransomware.org)

The Center for Internet Security has updated its CIS Benchmarks for Kubernetes, Azure Kubernetes Service and Microsoft Intune, and has released a new CIS Benchmark for Red Hat Enterprise Linux Security Technical Implementation Guide (STIG).

These are the CIS Benchmarks updated in April:

• CIS Azure Kubernetes Service (AKS) Benchmark v1.7.0
• CIS Kubernetes Benchmark v1.11.1
• CIS Microsoft Intune for Windows 10 Benchmark v4.0.0
• CIS Microsoft Intune for Windows 11 Benchmark v4.0.0

Meanwhile, the brand new Benchmark is CIS Red Hat Enterprise Linux 9 STIG Benchmark v1.0.0.
 

Organizations can use the CIS Benchmarks’ secure-configuration guidelines to harden products against attacks. Currently, there are more than 100 Benchmarks for 25-plus vendor product families in categories including: 

• cloud platforms
• databases
• desktop and server software
• mobile devices
• operating systems

To get more details, read the CIS blog “CIS Benchmarks May 2025 Update.” For more information about the CIS Benchmarks list, check out its home page, as well as:

• “How to use CIS benchmarks to improve public cloud security” (TechTarget)
• “How to Unlock the Security Benefits of the CIS Benchmarks” (Tenable)
• “CIS Benchmarks Communities: Where configurations meet consensus” (HelpNet Security)
• “CIS Benchmarks: DevOps Guide to Hardening the Cloud” (DevOps)

CIS Benchmarks

The acquisition of Apex Security adds a powerful new layer of visibility, context and control to the Tenable One Exposure Management Platform to govern usage, enforce policy and control exposure across both the AI that organizations use and the AI they build.

Over the past 25 years, we’ve seen the attack surface shift dramatically — from traditional on-prem environments to cloud, to OT/IOT, and more. But the changes we’re seeing right now with AI feel different. Faster. More disruptive. And, frankly, more unpredictable.

That’s why I’m excited to share that Tenable has signed a definitive agreement to acquire Apex Security, a company we’ve been following for some time. They've built a powerful product that solves real problems in the emerging world of AI risk. Their focus is helping organizations secure both the AI they use and the AI they build — a problem that's becoming more critical every day.

It’s clear we’re in the early stages of a major shift. Developers are integrating large language models into products and internal tools. Employees are using generative tools in everyday workflows. AI is everywhere — but the tools to manage that risk at scale? Not so much.

Last year, we introduced AI Aware to help organizations get visibility into shadow AI. It’s been incredible to see how quickly customers adopted it — more than 6,400 customers in over 100 countries are using it today. But we also heard loud and clear: visibility isn’t enough. Security leaders want to govern usage, enforce policy, and prevent exposures before attackers take advantage. That’s exactly what Apex was built to do.

Their technology adds a powerful layer of visibility, context, and control to what we’re building with Tenable One - our exposure management platform for your entire enterprise. Once the deal closes, we will move quickly to integrate these capabilities into the platform.

This isn’t just about adding another feature — it’s about helping customers take action during a critical window of time. Most organizations haven’t yet experienced a large-scale AI-driven attack. That’s the point. We have a unique opportunity to get ahead of the threat — to define how AI is secured before attackers define it for us.

I’m proud of the team at Tenable for continuing to lead in Exposure Management, and I’m looking forward to welcoming our future teammates from Apex once the deal closes. This is how we stay in front of the attack surface — by seeing where it’s going, and building for it now.

More to come soon.