Tenable Blog

MCP tools are implicated in several new attack techniques. Here's a look at how they can be manipulated for good, such as logging tool usage and filtering unauthorized commands.

Background

Over the last few months, there has been a lot of activity in the Model Context Protocol (MCP) space, both in terms of adoption as well as security. Developed by Anthropic, MCP has been rapidly gaining traction across the AI ecosystem. MCP allows Large Language Models (LLMs) to interface with tools and for those interfaces to be rapidly created. MCP tools allow for the rapid development of “agentic” systems, or AI systems that autonomously perform tasks.

Beyond adoption, new attack techniques have been shown to allow prompt injection via MCP tool descriptions and responses, MCP tool poisoning, rug pulls and more.

Prompt Injection is a weakness in LLMs that can be used to elicit unintended behavior, circumvent safeguards and produce potentially malicious responses. Prompt injection occurs when an attacker instructs the LLM to disregard other rules and do the attacker’s bidding. In this blog, I show how to use techniques similar to prompt injection to change the LLM’s interaction with MCP tools. Anyone conducting MCP research may find these techniques useful.

Experiments with MCP

For my research, I used the 5ire client because it makes it incredibly simple to switch out and restart MCP servers and switch between LLMs. In 5ire, I can easily configure our MCP servers (for this test case, I’ve already configured the reference MCP weather server):

Tenable Research using the 5ire client, April 2025

Anatomy of an MCP server

Let’s talk about how an MCP server is written and configured. First, we define a simple MCP server in Python with FastMCP. The FastMCP library makes it fairly simple to get up and running with MCP.

I can use this framework to develop several different servers and tools for my experiments. Now that I’ve got the framework, I’ll create a tool.

Now that I know how to create a simple tool in Python, let’s see what else I can do.

Logging tool use

Multiple MCP servers can be configured in an MCP host and each server can have multiple tools. As I was exploring this new technology, I wondered if there was a way to log all tool calls across configured MCP servers. This is doable at the MCP host level or via each MCP server, but I asked myself: why not find another way? I wanted to log all MCP tool calls that the host makes, so I decided to see if I could create a tool that would insert itself before any other tool calls and log information about those tool calls.

Let’s break down the above MCP tool:

1. I start out with a decorator from FastMCP (1) to indicate this is an MCP tool.
2. Then I define the function (2) with all of the parameters I want. The function name and parameters are exposed to the LLM and the LLM is intelligent enough to infer how to populate them.
3. Next is the description (3). This is the meat of the tool, instructing the LLM to insert this tool before any other tool call. You can read through the parameters and what I’m trying to accomplish. It may seem a little repetitive, but this is the current iteration that seems to work well across different models.
4. Then, I write it to a file (4). I could use Python’s ‘logger’ here, but I had issues getting that working with the MCP clients we used. In most of our testing, it wasn’t easy to get anything written to stdout, so we chose logging to a file instead.
5. Finally, we return a nice message thanking the AI and passing the name of the actual tool to run (5).

In testing, some models had no problem inserting the tool before any other tool call. Some did it sporadically, while others did not unless we asked about it.

Source: Tenable Research, April 2025

As the image above shows, the LLM runs the logging tool just before it runs the weather tool I requested. The logging tool then logs information about the tool it was asked to run, including the MCP server name, MCP tool name and description, and the user prompt that caused the LLM to try to run that tool. In this case, it actually logs twice, but I wasn’t able to investigate why.

Tool filtering / firewall

Using the same method, I can block unapproved tools from running.

Here I’m using the same technique to run prior to other tools calls. In this case I’m simply looking for the tool name to match a string `get_alerts`. If it matches, I tell the LLM not to run the tool. Sometimes it respects this!

Source: Tenable Research, April 2025

MCP introspection

This method of using the tool description block to ask the LLM to run this tool before other tools could clearly be abused. Can I use a similar technique to find out about other tools in use that ask for a similar hierarchy? I give it a try:

Note that I’m logging to the same log file so that it’s easier to see what’s happening. In a real world scenario, these tools would likely log to separate files.

Source: Tenable Research, April 2025

Here we can see that log_other_inline_tools runs after the logging tool in this case. The tool then logs the other “inline” tool that the LLM is aware of. It then lists the other available tools.

Can this technique be used to extract the LLM system prompt?

Maybe. Here’s what I tried:

You can see in the return value that I tried to trick the model further by giving it a score at the end, so maybe it’ll think I’m really doing some sort of analysis.

Source: Tenable Research, April 2025

Source: Tenable Research, April 2025

Source: Tenable Research, April 2025

Source: Tenable Research, April 2025

Source: Tenable Research, April 2025

It seems like the LLM models vary between something realistic and complete hallucination. Remember that the models try to figure out how to fill out the tool’s parameters. So, if they don’t have a good idea of what goes where, they may just make it up. Based on my testing, it looks like Claude Sonnet 3.7 displays a piece of the prompt it has around running tools. Google Gemini 2.5 Pro Experimental seems to do the same. OpenAI’s GPT-4o puts variations in the log each time, so it seems like it’s just made up. It should also be noted that directly asking for the system prompt is successful for some models while unsuccessful for others. Regardless, some prompt text is still sent to the logging tool. While I can’t say for certain if I’m seeing actual developer instructions or hallucinated text, these tests may be useful to facilitate other research.

Conclusion

Tools should require explicit approval before running in most MCP Host applications. In fact, this is required by the MCP specification. Still, there are many ways in which tools can be used to do things that may not be strictly understood by the specification. Here I’ve demonstrated a few interesting techniques that could be used to develop security tooling, perform research or to help identify other malicious tools. These methods rely on LLM prompting via the description and return values of the MCP tools themselves. Since LLMs are non-deterministic, so, too, are the results. Lots of things could affect the results here: the model in use, temperature and safety settings, specific language, etc. Additionally, the descriptions used to instruct the LLM to do different things with the tools may need to be different depending on the model used. I’ve had varying results with different models, though I haven’t tested every case on every model.

Some of these techniques could be used to advance both positive and negative goals. We believe that some can be used to further LLM and MCP research.

The code from this blog can be found on github.

References

While working on this blog, I saw some great work by Trail of Bits dubbing one of the techniques used here “jumping the line.” I offer one possible detection method in the MCP Introspection section of this post. In that section, I show the use of an MCP tool to identify other MCP tools requesting to run first.

Traditional approaches to cloud access rely on static, permanent permissions that are often overprivileged. Learn how just-in-time access completely changes the game.

The access challenge in modern cloud environments

As cloud adoption accelerates, organizations are grappling with a fundamental security challenge: How do you grant people the access they need — such as on-call developers needing to debug problems, site reliability engineers (SREs) needing to repair issues with infrastructure, or DevOps engineers needing to provision or architect resources — without opening the door to overprivileged accounts and breach risks?

Traditional approaches rely heavily on static, permanent permissions. Human users often receive more access than necessary simply because it’s hard to predict specifically which permissions they’ll need. These permissions rarely get revoked, leaving organizations exposed.

This is where Tenable Cloud Security changes the game. As a powerful cloud-native application protection platform (CNAPP) solution, Tenable Cloud Security doesn't just identify access-related risk — it actively helps you solve it.

In this blog, we explore how you can address the excessive permissions challenge using the just-in-time (JIT) access capability in Tenable Cloud Security.

Just-in-time access: The elegant solution to human identity risk

JIT access enables organizations to dramatically reduce their exposure from compromised identities by providing a substitute for permanent access. Instead of being granted standing access, which may be exploited if and when an identity is compromised, users are provided with the eligibility to request temporary access based on a defined business need.

Here’s how it works:

1. All (or at the very least sensitive) standing access is removed.
2. Users are assigned eligibility profiles for specific resources or roles.
3. Users request access and are optionally required to provide a reason when access is needed.
4. If required, the request can be approved by an assigned approver or simply be automatically granted, which still has a huge security benefit compared to a standing permission.
   • For highly sensitive cases where more than one person needs to confirm access, several approval levels can be enforced if necessary.
5. Access is granted for a limited time (measured in hours), then automatically revoked.

JIT access dramatically reduces the attack surface tied to human identities, ensuring that elevated privileges are used only when necessary and only for as long as needed.

Fig. 1: Creating an eligibility to request just-in-time access to a cloud environment instead of standing permissions User experience: Where security meets usability

Tenable understands that even the best security solution won't succeed without adoption and cooperation from its target audience. That’s why JIT access in Tenable Cloud Security is designed with a seamless user experience in mind.

Access requests and approvals can be managed directly within messaging platforms, such as Slack or Microsoft Teams, which meet your teams where they are. Users and approvers stay in their native workflows while benefiting from a secure, auditable process.

Fig. 2: Filling out the access request form directly from Slack

Fig. 3, below, shows how the request, approval and access link are all grouped together on the same thread for a simplified, clean and simple experience.

Fig. 3: The request generated, approval granted and connection link to the cloud environment all in one thread in Slack

And speaking of audits, Tenable Cloud Security doesn’t just log access. It provides a clean, intuitive activity log interface for every session. Unlike the often fragmented logs from cloud providers, these are tailored for easy auditing, compliance review or incident response. So, if you want to apply more scrutiny and review what happened during sessions, or if you are compelled to do so in the event of an incident, it’s extremely easy to open up the session log and review it.

Fig. 4: The intuitive activity log for events generated in the cloud environment during the JIT access session; easy to review and filter to perform scrutiny / investigate incidents Expanding the reach: JIT access in Tenable Cloud Security now extends to SaaS applications

Based on customer feedback, Tenable extended JIT functionality to cover identity provider (IdP) group memberships. This is a big deal.

In many organizations, access to software as a service (SaaS) applications (such as secrets managers, observability tools, ticketing platforms, etc.) is governed through group memberships in identity providers like Okta or Microsoft Entra ID. With Tenable Cloud Security, you can now provide temporary group membership through the same JIT access model — effectively controlling and auditing access to SaaS apps with the same granularity and automation as cloud resources.

This means Tenable Cloud Security customers now have unified control over cloud infrastructure and SaaS access through a single solution.

Simplified procurement: JIT access is now included with Tenable Cloud Security

Perhaps the most exciting news: JIT access no longer requires a separate purchase. As of today, it’s included with Tenable Cloud Security.

Billing is simple. Just as Tenable Cloud Security charges based on the number of cloud resources, JIT access treats each eligible user as a billable resource. If you're a Tenable Cloud Security customer, you already have access to the full power of JIT — no separate contract, no additional platform. For example, if you have a team of five developers eligible to request elevated permissions, these would count as an additional five billable resources, no matter how many eligibilities they have.

Why JIT access makes Tenable Cloud Security the CNAPP of choice

Tenable Cloud Security doesn’t just identify problems. It solves them:

• It prioritizes identity risks with real-world context.
• It provides granular, real-time controls for both service and human identities.
• It offers native integration with your daily collaboration tools.
• It simplifies auditability and incident response.
• It extends protection beyond the cloud to the SaaS layer.
• It streamlines adoption with an intuitive UX and frictionless billing model.

Conclusion: Access management, reimagined

The best security tools blend into your workflow and quietly eliminate risk before it becomes a problem.

Tenable Cloud Security's JIT access capability is more than a feature — it's a philosophy shift. It reduces identity-based risk without sacrificing agility. It simplifies compliance without adding overhead. And it empowers teams to move fast, stay secure and maintain clarity over who has access to what, when and why.

If you're already a Tenable Cloud Security customer, there’s never been a better time to start using JIT access. And if you're evaluating CNAPPs, ask yourself: do they help you fix the problem, or just show you where it is?

With Tenable Cloud Security, the answer is clear.

Visit https://www.tenable.com/announcements/provide-access-just-in-time to learn more about how JIT access capabilities in Tenable Cloud Security can help you reduce your exposures.

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 CIO Patricia Grant looks at how the CIO/CSO relationship is key to a successful exposure management program. You can read the entire Exposure Management Academy series here. 

When I first joined Tenable, one of the first things I did was sit down with our CSO, Robert Huber, to align on how we were going to work together. 

In 2024, I was even featured in a WSJ article titled CIOs and CISOs Are ‘Better Together because that’s what it comes down to. We can’t operate in silos. If you’re serious about securing your organization, your IT and security teams have to be tightly linked philosophically and operationally. Exposure management is a great example of where that partnership plays out every day.

Risk is shared — and so is the responsibility 

Let me start with a simple truth: securing the enterprise is a shared responsibility between IT and security. While the CSO defines the strategy and risk posture, IT plays a critical role in execution — from patching systems and deploying controls to maintaining uptime and interpreting security signals.

That’s why tight alignment between our teams isn’t optional — it’s essential. We have regular interlocks to ensure we’re making decisions with the same context and urgency. Annual planning isn’t enough anymore. The threat landscape shifts by the quarter — sometimes by the month — so our collaboration has to be constant, responsive and agile.

Ultimately, you can’t do exposure management the right way without a strong relationship between the CIO and the CSO. We’re both accountable and responsible for protecting our employees, customers, partners and the company. And we both bring something essential to the table. 

A single pane of glass beats swivel-chair security

Exposure management is a great tool to keep us on track. 

It gives us a unified view across all our assets, including cloud, on-prem and hybrid. I’m not a fan of “swivel-chair security.” I don’t want my team jumping between tools trying to figure out what to fix first. Exposure management moves us toward a single pane of glass. 

We can see what matters, what’s critical, what needs to be patched now and what can wait. 

That kind of visibility is essential when your infrastructure spans everything from data centers and headquarters to home offices and digital nomads working from just about anywhere.

Endpoints are the new front line

Unlike data centers or cloud infrastructure, endpoints move with your workforce — and that makes them harder to secure. At Tenable, we’ve taken a firm stance: when a zero-day emerges, patch your device within 24 hours or it’ll be automatically locked.

But security doesn’t stop at the office door. No matter where employees are, they’re part of the defense. That’s why we focus on education — not to slow people down, but to empower them to keep the business safe.

Exposure management uncovers what you don’t know

We’ve also learned that managing systems is only part of the battle. You’ve got to worry about identities, access and misconfigurations. 

And it’s not just about what you know. Exposure management helps you uncover what you don’t know. Things like systems you forgot were running or ports you didn’t realize were open are now visible.

The “Oh, no, I didn’t know that port was live” moment happens more often than you’d think. Exposure management finds and closes that down. 

Prioritizing the right problems is a strategic advantage

Risk prioritization is always a looming challenge. The goal isn’t to fix everything. It’s to fix what matters most. Chasing thousands of vulnerabilities without context wastes time and energy. Exposure management helps us shift the conversation from volume to impact.

That’s what exposure management solves. Instead of bragging that “we closed 3,000 vulnerabilities,” we can say, “we addressed the 50 that posed real risk.” 

That’s a fundamental mindset shift for IT teams. And, yes, it comes down to change management.

Change management isn’t optional anymore

Change management is underrated, especially in cybersecurity. I’ve always said going live on day one with technology is easy. It’s day two and beyond that’s hard. And in this hybrid, distracted world, traditional methods just don’t cut it. 

People aren’t reading emails. And they’re half-listening in meetings. So we need new approaches. We go for quick hits, with clear messaging, along with different formats to cater to different learning styles. Cybersecurity is everyone’s job, and reaching everyone means rethinking how we communicate.

Speaking the board’s language means translating risk

We need to elevate the conversation. I regularly participate in board-level discussions about cybersecurity, and the key is translating cyber risk into business language. It’s not just about technical debt or patch status anymore. It’s about quantifying risk the same way the CFO quantifies financial exposure. 

Boards don’t want tech jargon. They want to know: Are we covered? Where are we vulnerable? What’s the worst-case scenario? An exposure management solution helps translate technical complexity into strategic insight.

Helping our customers protect what they can’t see

At Tenable, we take that same philosophy to our customers. Exposure management isn’t just about visibility. It’s about enabling action. I see our job as helping customers answer those questions. Threat exposure management gives our customers clarity into what they need to know. 

That means knowing the threats that matter, the systems that are exposed and the actions that will make a difference. You can’t protect what you are not aware of as a risk. And in a world where the attack surface is constantly expanding and evolving — whether it’s AI, autonomous vehicles or just more remote workers — you need to see everything. You need a single pane of glass.

Takeaways

Ultimately, you can’t do exposure management the right way without a strong relationship between the CIO and the CSO. We’re both accountable and responsible for protecting our employees, customers, partners and the company. And we both bring something essential to the table. 

So, my advice to fellow CIOs: Stay close to your CSO. Build trust. Share responsibility. 

And make sure your teams are operating from the same playbook. Because in cybersecurity, the stakes are too high to go it alone.

Have a question about exposure management you’d like us to tackle?

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);

Timely vulnerability remediation is an ongoing challenge for organizations as they struggle to prioritize the exposures that represent the greatest risk to their operations. Existing scoring systems are invaluable but can lack context. Here’s how Tenable’s Vulnerability Watch classification system can help.

Background

Over the past six years working in Tenable’s research organization, I’ve watched known vulnerabilities and zero-day flaws plague organizations in the immediate aftermath of disclosure or even years afterwards. Following each blog post or threat report we’ve published, I kept coming back to the same question: Why are so many organizations struggling to remediate vulnerabilities in a timely manner?

As someone who followed the evolution of COVID-19 variants throughout the beginning of the pandemic, I saw that the World Health Organization (WHO) began to label new variants under a classification system as the virus began to mutate. This classification system was designed to help prioritization efforts for monitoring and research. It included accessible labels like variants of interest and variants of concern to help communicate urgency and focus global attention.

I began to wonder: What if we borrowed from the same type of classification system used by the WHO and applied it to vulnerability intelligence? Numeric-based systems like the Common Vulnerability Scoring System (CVSS) and Exploit Prediction Scoring System (EPSS) provide mechanisms for prioritization based on scoring. However, they don’t always provide enough context to help decision makers. So, what if we used simple, clear and status-based terminology to communicate risks surrounding vulnerabilities in order to guide action?

This led us to develop Vulnerability Watch, a classification system for vulnerabilities inspired by the WHO’s classification of COVID-19 variants. Vulnerability Watch is a small, but important part of Tenable’s Vulnerability Intelligence offering that was launched in 2024. Now, in addition to being available in product, Vulnerability Watch classifications can be found on the Tenable CVE page, as well as within individual CVE pages for select vulnerabilities that have been classified under the Vulnerability Watch.

In this blog, we discuss some of the challenges organizations face when it comes to vulnerability prioritization and remediation and how a classification system like Vulnerability Watch can help.

If everything is important, nothing is important

CVSS is the most widely used metric when assigning a severity score for Common Vulnerabilities and Exposures (CVEs). CVSS scores are assigned by a vendor and or an authority like the National Institute of Standards and Technology (NIST). Each CVE score is based on various metrics from exploitability to impact, with a corresponding severity level tied to these scores. Severity levels include low, medium, high and critical.

When looking at repositories, such as the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog, we can make observations about severity and vulnerability risk. In 2024, CISA added a total of 186 CVEs to the KEV.

Source: Tenable Research

Four in ten (40%) of these 186 CVEs were rated as critical. The remaining 60% was made up of high severity vulnerabilities (46.2%) and medium vulnerabilities(13.4%). This underscores that severity alone is not enough when it comes to making decisions around vulnerability prioritization.

Remediation rates underscore a need for more clarity

While the KEV serves as a valuable resource for security practitioners, we still see many organizations not patching these critical flaws in a timely manner. Despite the severity and inclusion on the KEV, our research has found an overall trend of poor remediation rates.

This trend was highlighted as part of a collaboration with Verizon on the 2025 Data Breach Investigations Report (DBIR). Tenable Research analyzed over 160 million data points and evaluated the remediation rates for a list of 17 CVEs in edge devices highlighted in the DBIR. Of the 17 CVEs, over half (52.9%) were non-critical flaws (less than 9.0 CVSS scores).

We also analyzed average remediation rates for these CVEs across various industry sectors. Through this analysis, we found many industries faced challenges with remediating many of these flaws. For instance, CVE-2024-21762 and CVE-2024-23113, a pair of critical Fortinet flaws, had very long remediation rates, averaging between 172 days and 260 days. Even CVE-2024-3400, a critical vulnerability in Palo Alto Networks PAN-OS assigned the maximum CVSS score of 10.0, also saw most industries average over 100 days to remediate the flaw.

There are a variety of reasons why organizations may struggle with remediation — including organizational siloes, operational downtime required to patch systems, and difficulty determining how to prioritize vulnerabilities based on the risk they represent. While existing scoring systems provide invaluable guidance, we believe additional context is needed in order to improve remediation times.

A semantic layer for vulnerability intelligence

Our Vulnerability Watch classifications are not a replacement for CVSS, EPSS or any other scoring metric. Those still serve a distinct purpose in vulnerability prioritization. We also recognize that cybersecurity teams are often inundated by a deluge of alerts and it can be difficult at times to separate the signal from the noise. These vulnerability watch classifications offer a semantic layer to help translate risk into terminology that is easier to understand for various stakeholders in remediation efforts.

Tenable’s Vulnerability Watch classifications

Vulnerability Watch includes the following classifications: vulnerability being monitored, vulnerability of interest and vulnerability of concern. The following are short descriptions of each classification.

Vulnerability Being Monitored

A vulnerability being monitored (VBM) is a vulnerability that has the potential to impact customers of a particular software or hardware and is being actively tracked and researched by Tenable Research. VBMs may quickly evolve into Vulnerabilities of Interest (VOIs) or Vulnerabilities of Concern (VOCs) if a proof-of-concept (PoC) or exploitation is discovered, or if additional intelligence indicates that special attention should be given to this vulnerability. VBMs are actively monitored and elevated to VOI/VOC status should Tenable’s Vulnerability Intelligence justify an escalation of vulnerability status.

A few recent examples of VBMs include CVE-2024-48887, an unverified password change vulnerability in FortiSwitch, and CVE-2025-23120, a remote code execution flaw in Veeam Backup and Replication.

Vulnerability of Interest

A vulnerability of interest (VOI) is a vulnerability that meets the criteria of a VBM, but for which additional intelligence indicates that risk of impacts to customers is elevated or demonstrated through the publication of a PoC or details that could be used to craft a PoC along with initial reports of exploitation.

A few recent examples of VOIs include CVE-2025-22457, which was exploited by a China-Nexus threat actor known as UNC5221, and CVE-2025-32433, a remote code execution flaw in Erlang/OTP SSH.

Vulnerability of Concern

A Vulnerability of Concern (VOC) is a vulnerability that meets the criteria of a VOI, but for which active, widespread exploitation is imminent or ongoing. For VOCs, the ease of exploitation combined with severity of the issue may lead us to believe that widespread exploitation is imminent, if it has not already begun. Maintainers of software or devices vulnerable to VOCs can expect to see exploitation attempts and probing for vulnerable assets.

A few recent examples of VOCs include a pair of ConnectWise Screen Connect vulnerabilities (CVE-2024-1709, CVE-2024-1708) and Citrix Bleed (CVE-2023-4966).

The classifications are also flexible: a CVE can be reclassified from VBM to VOI, from VOI to VOC, or even from VOC back to VOI as risk context evolves.

Conclusion

We know there’s no single panacea for the challenges of vulnerability prioritization and remediation. These challenges require a multi-pronged approach. Backed by Tenable Research experts, our Vulnerability Watch classifications can help demystify some of the complexities introduced by CVSS and EPSS and provide stakeholders a simpler, more intuitive way to assess and prioritize risks posed by emerging threats that can contribute to faster responses and remediation.

Our Vulnerability Watch classifications can now be found on our CVE page.

Get more information

• Tenable Vulnerability Intelligence and Exposure Response
• Turning Data into Action: Intelligence-Driven Vulnerability Management

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

SAP has released out-of-band patch to address CVE-2025-31324, a critical zero-day vulnerability in SAP NetWeaver that has been exploited by threat actors. Organizations are strongly encouraged to apply patches as soon as possible.

Background

On April 22, ReliaQuest published details of their investigation of exploit activity in SAP NetWeaver servers. Initially it was unclear if their discovery was a new vulnerability or the abuse of CVE-2017-9844, a vulnerability that could lead to a denial-of-service (DoS) condition or arbitrary code execution. ReliaQuest reported their findings to SAP and on April 24, SAP disclosed CVE-2025-31324, a critical missing authorization check vulnerability with the highest severity CVSS score of 10.0.

CVEDescriptionCVSSv3VPRCVE-2025-31324SAP NetWeaver Unauthenticated File Upload Vulnerability10.08.1

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

Analysis

CVE-2025-31324 is an unauthenticated file upload vulnerability affecting the Metadata Uploader component of SAP NetWeaver Visual Composer. Successful exploitation of this vulnerability could allow an unauthenticated attacker to upload malicious files which can be used by an attacker to achieve code execution. The flaw is the result of missing authorization checks to the “/developmentserver/metadatauploader” endpoint. According to ReliaQuest, this vulnerability has been exploited in the wild as a zero-day by threat actors who have abused the flaw to upload malicious web shells to affected hosts. These webshells were used to deploy malware and establish communications with command and control (C2) servers.

Proof of concept

At the time this blog was published, no proof-of-concept (PoC) code had been published for CVE-2025-31324. If a public PoC exploit becomes available, we anticipate a variety of attackers will attempt to leverage this flaw in their attacks as SAP products are widely used by a variety of organizations, including government agencies.

Solution

SAP has released patches for affected versions of SAP NetWeaver. At this time, the SAP security note #3594142 is not publicly accessible, so we are unable to provide a list of affected and patched versions. It is important to note that these patches were released after SAP’s April 2025 Security Patch Day published on April 8. So even if those patches were applied, you will still need to apply the out-of-band patches released for CVE-2025-31324.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2025-31324 as they’re released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify public facing assets running SAP NetWeaver by using the following filters:

Get more information

• ReliaQuest Blog: ReliaQuest Uncovers New Critical Vulnerability in SAP NetWeaver
• SAP Security Patch Day - April 2025

Join Tenable's Security Response Team on the Tenable Community.

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

Check out highlights from this year’s Verizon DBIR, including a surge in zero-day exploits targeting edge devices and VPNs. Plus, find out what’s new in the latest version of MITRE ATT&CK. Also, see what Tenable webinar attendees said about AI security. And get the latest on ransomware preparedness for OT systems and on the FBI’s 2024 cyber crime report.

Dive into five things that are top of mind for the week ending April 25.

1 - Verizon DBIR: To break in, hackers favor credentials and vulnerabilities

As your organization fine-tunes its cyber defenses, here’s an unsurprising yet highly relevant fact: The two most common avenues for cyberattackers to hack into victims’ networks are compromised credentials and exploited vulnerabilities.

That’s according to Verizon’s “2025 Data Breach Investigations Report” (DBIR), which was published this week. The report is based on an analysis of 22,000 real-world security incidents — including about 12,200 confirmed breaches — that occurred globally between Nov. 1, 2023 and to Oct. 31, 2024.

"The DBIR's findings underscore the importance of a multi-layered defense strategy," Chris Novak, VP of Global Cybersecurity Solutions at Verizon Business, said in a statement. 

"Businesses need to invest in robust security measures, including strong password policies, timely patching of vulnerabilities, and comprehensive security awareness training for employees," he added.

Cyber attackers used credential abuse as their initial access vector in 22% of breaches. Meanwhile, vulnerability exploitation came in second at 20%, a spike of 34% compared with the prior period. Phishing (16%) ranked third.

 

What drove the sharp rise in vulnerability exploits? The raft of zero-day bugs that attackers have exploited in network edge devices and virtual private networks. These accounted for 22% of vulnerability exploits — a proportion that rocketed from just 3% during the prior period. Organizations fully remediated only 54% of these edge vulnerabilities. The median time-to-remediate was 32 days.

Tenable Research was a key contributor to this section of the 2025 DBIR by providing enriched data on the most exploited vulnerabilities. 

“We analyzed over 160 million data points and zeroed-in on the 17 edge device CVEs featured in the DBIR to understand their average remediation times,” Tenable Senior Staff Research Engineer Scott Caveza wrote in a blog that details Tenable Research’s contribution.

Other key findings in the 2025 DBIR include:

• Ransomware attacks rose 37% and were present in 44% of all breaches. However, median ransom payments fell to $115,000 from $150,000, as 64% of victims refused to pay.
• Third-party involvement in breaches surged to 30%, up from 15%, which highlights the growing cyber risks organizations face from their supply chain partners, such as vendors and contractors.
• 15% of employees routinely access generative AI systems via their work devices — at least once every two weeks. But most (72%) do so using personal accounts, suggesting they’re circumventing corporate policies that prohibit using generative AI tools for work.
• The percentage of malicious emails crafted using AI has risen from about 5% to about 10% in the past two years.

To get more details, check out: Tenable’s blog “Verizon 2025 DBIR: Tenable Research Collaboration Shines a Spotlight on CVE Remediation Trends” and these Verizon resources:

• “2025 Data Breach Investigations Report” home page
• The report’s announcement
• A complementary infographic

2 - MITRE ATT&CK update beefs up cloud, mobile security sections

Information about protecting VMWare’s ESXi hypervisor. Expanded guidance on mobile and cloud security. More intel on nation-state actors and cyber crime operations.

That’s just some of what’s new in the latest version of the MITRE ATT&CK framework, the popular knowledge base of cyberattack tactics, techniques and procedures designed to help security teams develop threat models and methodologies.

Announced this week, version 17 of MITRE ATT&CK “aims to help defenders stay aligned with where adversaries are headed by looking at where they’ve recently been,” MITRE ATT&CK officials wrote in a blog.

“This release aims to inform defensive efforts by focusing on the platforms adversaries are exploiting, the techniques they’re adapting, and the environments they’re targeting,” they added.

Here’s some of what’s new:

• In response to a spike in attacks against virtualization systems, a new platform has been added devoted to securing VMWare’s ESXi hypervisor, which hackers have targeted recently. Specifically, the new MITRE ATT&CK version adapts 34 existing techniques to ESXi and adds four new techniques for it.

• There’s broader guidance on protecting mobile devices and securing cloud environments. 

  For example, on the cloud security front, there’s new information about how OAuth app integrations are abused in software-as-a-service (SaaS) platforms to bypass multi-factor authentication (MFA) and swipe data.

  For mobile security, the new version documents recent techniques and tools that attackers are using, among other things, to make their attacks stealthier. There’s also new guidance to help developers build safer software for mobile devices.

• Regarding nation-state attackers, the new version adds information on various groups, including Salt Typhoon, RedEcho, Velvet Ant and Sea Turtle.

To get more information, check out:

• The blog “ATT&CK v17: New Platform (ESXi), Collection Optimization, & More Countermeasures”
• The MITRE ATT&CK v17 release notes
• The MITRE ATT&CK framework
• The MITRE ATT&CK FAQ

3 - Tenable polls webinar attendees on AI security

During our recent webinar “2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud,” we polled attendees on AI security, including which risks they’re most concerned about. Find out what they said.

(63 webinar attendees polled by Tenable, April 2025)

(74 webinar attendees polled by Tenable, April 2025)

Want details on the findings of our “Tenable Cloud AI Risk Report 2025” and on mitigation and security best practices for protecting your AI workloads and applications? Watch the webinar on-demand.

4 - SANS publishes ransomware response framework for ICS/OT environs

How can critical infrastructure organizations prepare an effective response plan for ransomware attacks against their industrial control systems and operational technology (OT) systems?

SANS Institute tackled that question and the result is a white paper published this week titled “A Simple Framework for OT Ransomware Preparation.” 

With the document, SANS aims to outline an actionable, hands-on approach for critical infrastructure organizations seeking to build or fine-tune ransomware response playbooks.

“The key message? Preparation matters. And in the OT world, a lack of preparation can have real-world consequences,” reads a SANS blog titled “Building a Better OT Ransomware Response Plan: A Simple Framework for ICS Environments.”

At a high level, SANS recommendations for critical infrastructure organizations with OT / ICS environments include:

• Before drafting the playbook, you need to collect foundational data about your environment, such as its architecture, asset inventory, key staff and security controls.
   
• It’s also key to proactively foster collaboration between the IT, OT and cybersecurity teams.
   
• The ransomware-preparedness playbook should cover five key areas:
  • Preparation
  • Identification
  • Containment
  • Eradication
  • Recovery

“By focusing on the unique challenges of OT networks, such as their architectural immaturity and the criticality of safe operations, the framework provides actionable guidance to enhance incident response capabilities,” the white paper reads.

For more information about protecting OT systems from ransomware and other cyber attacks, check out these Tenable resources:

• “Managing OT and IT Risk: What Cybersecurity Leaders Need to Know” (blog)
• “Operational Technology (OT) Security: How to Reduce Cyber Risk When IT and OT Converge” (resource page)
• “Mind the Gap: A Roadmap to IT/OT Alignment” (white paper)
• “How to Unlock Advanced IoT Visibility for Cyber-Physical Systems” (blog)
• “Unlock advanced IoT visibility to better secure your OT environment” (on-demand webinar)

Tenable.ot Security Spotlight - Episode 1: The Ransomware Ecosystem

Tenable.ot Security Spotlight - Episode 2: The Business Risk From a Ransomware Attack on OT Systems

Tenable.ot Security Spotlight - Episode 3: Ransomware in OT Systems

5 - FBI: U.S. cyber crime losses hit “staggering” levels in 2024

Cyber crime shows no sign of abating in the U.S.

Americans lost $16.6 billion due to internet crime last year, up 33% compared with 2023 and a new record, the U.S. Federal Bureau of Investigation said in its “Internet Crime Report 2024.” The data comes from the FBI’s IC3 division, which fields internet crime complaints.

Cyber fraud schemes account for most of the monetary losses — $13.7 billion — according to the report, released this week. Investment scams ranked first, accounting for about $6.5 billion, followed by business email compromise (BEC) at around $3 billion and tech support scams at almost $2 billion.

Overall, cyber crime victims filed almost 860,000 complaints. Of those, about 256,000 included a loss of money, for an average loss per complaint of about $19,300. Although the overwhelming majority of complaints came from the U.S., the report includes complaints from 200-plus countries.

(Source: FBI’s “Internet Crime Report 2024,” May 2025)

The rest of the losses came from cyber threats: $1.57 billion. Critical infrastructure organizations filed more than 4,800 cyber threat complaints, most of them for ransomware attacks — up 9% — and data breaches. Akira, LockBit, RansomHub, Fog and Play were the top ransomware variants impacting the critical infrastructure sector.

(Source: FBI’s “Internet Crime Report 2024,” May 2025)

For more information about cyber threats to critical infrastructure:

• “Critical Infrastructure Security and Resilience” (CISA)
• “Volt Typhoon: U.S. Critical Infrastructure Targeted by State-Sponsored Actors” (Tenable)
• “Critical infrastructure at state, local levels at heightened risk of cyberattacks” (Cybersecurity Dive)
• “Why using IT cybersecurity to protect OT puts industrial organizations at risk” (World Economic Forum)
• “Cybersecurity of Critical Infrastructure with ICS/SCADA Systems” (IEEE)

Microsoft synchronization capabilities for managing identities in hybrid environments are not without their risks. In this blog, Tenable Research explores how potential weaknesses in these synchronization options can be exploited.

Synchronizing identity accounts between Microsoft Active Directory (AD) and Entra ID is important for user experience, as it seamlessly synchronizes user identities, credentials and groups between on-premises and cloud-based systems. At the same time, Tenable Research shows the following synchronization options can introduce cybersecurity risk that extend beyond hybrid tenants:

• the already known Directory Synchronization Accounts Entra role
• the new On Premises Directory Sync Account Entra role
• the new Microsoft Entra AD Synchronization Service application

In 2024, Microsoft introduced two new security hardening measures for hybrid Entra ID synchronization. However, despite these improvements, both the Directory Synchronization Accounts and the new On Premises Directory Sync Account roles retain access to critical synchronization APIs. Moreover, the new 'Microsoft Entra AD Synchronization Service' application exposes the privileged ADSynchronization.ReadWrite.All permission, introducing another potential attack path that security teams must watch closely.

In this technical blog, we break down the changes Microsoft made to each of its synchronization options, explore where new risks were introduced and provide guidance on how Tenable Identity Exposure can help you monitor and secure your hybrid synchronization environment.

Directory Synchronization Accounts role: Where it all begins

In hybrid environments, Entra ID — the Identity Provider in Microsoft’s suite of Entra products — and Active Directory (AD) are synchronized through a specific service account in Entra ID (called “SYNC_…<server>_<random>” for Entra Connect and “ADToAADSyncServiceAccount” for Entra Cloud Sync). This service account is assigned the Entra role called Directory Synchronization Accounts and it is hidden in Azure Portal / Entra Admin Center.

In August 2024, as part of its security hardening effort, Microsoft announced it had removed unused permissions from the privileged Directory Synchronization Accounts role.

At Tenable Research we wondered: how can Entra ID <-> AD synchronization continue working following this reduction of privileges?

Answer: our tests showed that the Directory Synchronization Accounts role is still privileged because it can continue calling the synchronization API.

In December 2024, Microsoft announced a second security hardening with the introduction of a new app called Microsoft Entra AD Synchronization Service.

At Tenable Research, we were naturally curious about this new app. What does it look like? What are its characteristics? Does it have an API? Does it have, or expose, interesting permissions?

Answer: this application exposes the ADSynchronization.ReadWrite.All API permission, which is privileged since it allows calling the private synchronization API.

Directory Synchronization Accounts Entra role remains privileged

In June 2024, I explored the "Directory Synchronization Accounts" role in the article Stealthy Persistence with “Directory Synchronization Accounts” Role in Entra ID. I explained two ways role was privileged:

• it had privileged Entra permissions; and
• it had implicit permissions in the private undocumented “Azure AD Synchronization” API (the one at https://adminwebservice.microsoftonline.com/provisioningservice.svc).

The latter is also called “Sync provisioning service” by Dr. Nestori Syynimaa who implemented it in AADInternals.

The August security hardening update introduced a number of changes to the Directory Synchronization Accounts role, but did these changes successfully eliminate the role’s privileges?

Reduced permissions in the Directory Synchronization Accounts role

The Directory Synchronization Accounts role used to have 48 Entra role permissions. It underwent a drastic reduction as a result of the security hardening, with Microsoft removing all of them and replacing them with only one: microsoft.directory/onPremisesSynchronization/standard/read. Now that the role only has this read permission, it isn’t privileged anymore, which might lead you to assume it is not dangerous.

Previously, the role included microsoft.directory/applications/credentials/update and microsoft.directory/servicePrincipals/credentials/update, which could allow attackers to add credentials to privileged applications/service principals so they could authenticate as these service principals and benefit from their privileges. These made the role privileged.

Fabian Bader popularized in 2023 a similar technique of abusing this role by taking over privileged applications, via the microsoft.directory/applications/owners/update and microsoft.directory/servicePrincipals/owners/update permissions. He has since updated his article From on-prem to Global Admin without password reset after Microsoft eliminated these permissions.

But permissions for the Synchronization API were implicit in the Directory Synchronization Accounts role, i.e. not listed as Entra role permissions in the role itself. So what about them?

Implicit synchronization API permissions are still present

Since they are implicit, the only way I knew to test their privileges was to simply try it out and see what happened.

I created a user, assigned it only the Directory Synchronization Accounts role and used the corresponding commands of the AADInternals toolkit, like Set-AADIntAzureADObject and Set-AADIntUserPassword. These continued working as they had before Microsoft’s security hardening. Here’s a proof with a password reset:

PS C:\> Import-Module -Name AADInternals [...] PS C:\> $at = Get-AADIntAccessTokenForAADGraph Logging in to Microsoft Services Enter email, phone, or Skype: <redacted>@<redacted>.onmicrosoft.com Password: <redacted> PS C:\> $userid = (Read-AADIntAccesstoken $at).oid PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId <redacted> -AccountId $userid [...] PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object { $_.ObjectType -eq "Role" } ObjectId DisplayName Description -------- ----------- ----------- <redacted> Directory Synchronization Accounts Only used by Azure AD Connect service. PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor <redacted> -Password <redacted> CloudAnchor Result SourceAnchor ----------- ------ ------------ CloudAnchor 0 <redacted>

The Result is 0 means that the password reset worked.

I conclude then that these implicit permissions remain present in the Directory Synchronization Accounts role and thus the role is still privileged. It can be used to create and edit users, reset their password and manage synchronized groups. This isn’t that surprising; I had assumed it would be so, for how else could the AD <-> Entra ID synchronization process continue working after the massive permissions reduction?

I wondered a while ago if this wasn’t perhaps made possible via the microsoft.directory/passwordHashSync/allProperties/allTasks Entra permission in the role, but as we can see, it continues working without it so this hypothesis is rejected. It’s indeed an implicit and hidden permission.

Of course there are some limitations when abusing the private undocumented Azure AD Synchronization API. For example, this API is meant for managing hybrid users only. In Entra ID you can have cloud-only users as well and hybrid users. Previously, this API was allowed to touch both kinds of users. This wasn’t necessary and could create a larger-than-necessary blast radius if it was abused. Microsoft addressed this by restricting the power of this API to only hybrid users.

Which is, by the way, one of the reasons why we have an Indicator of Exposure in Tenable Identity Exposure in order to verify that privileged accounts in Entra ID are cloud-only. But even with these limitations, we can agree that the Directory Synchronization Accounts role is risky enough to cause concern.

What about the new On Premises Directory Sync Account Entra role?

Microsoft announced the permissions reduction as part of its initial security hardening in August 2024. I had noticed things moving one month earlier, when I detected a new, interesting role called On Premises Directory Sync Account. This new role is very similar to the Directory Synchronization Accounts role that I know very well. Both are hidden in Azure Portal / Entra Admin Center. The On Premises Directory Sync Account role is even undocumented. This is likely because they aren’t meant to be used by customers. Even so they both remain present and available for misuse by attackers.

It’s unclear to me what Microsoft’s reasons were for creating the new On Premises Directory Sync Account role. Perhaps it’s meant to be used with Entra Cloud Sync, and the old one for Entra Connect, as Nathan McNulty thought too. The descriptions for Entra Connect and Entra Cloud Sync don’t make this clear, and both synchronization software still use the old Directory Synchronization Accounts role. If anyone has a clue, please let me know!

Here are the details of both roles coming from the Microsoft Graph API:

 Old roleNew roleDisplay nameDirectory Synchronization AccountsOn Premises Directory Sync AccountIDd29b2b05-8046-44ba-8758-1e26182fcf32a92aed5d-d78a-4d16-b381-09adb37eb3b0DescriptionOnly used by Microsoft Entra Connect service.Only used by Microsoft Entra Connect Sync Account.Rich descriptionThis role is automatically assigned to the Microsoft Entra Connect service, and is not intended or supported for any other use.This role is automatically assigned to the Microsoft Entra Connect Sync Account, and is not intended or supported for any other use.Permissionsmicrosoft.directory/onPremisesSynchronization/standard/readmicrosoft.directory/onPremisesSynchronization/standard/readIs privilegedfalsefalse

Naturally I wondered if there was a difference when calling the Synchronization API, but it turns out both roles allow the same operations. Here’s the same proof as before, this time with a user having the On Premises Directory Sync Account role:

PS C:\> Import-Module -Name AADInternals [...] PS C:\> $at = Get-AADIntAccessTokenForAADGraph Logging in to Microsoft Services Enter email, phone, or Skype: <redacted>@<redacted>.onmicrosoft.com Password: <redacted> PS C:\> $userid = (Read-AADIntAccesstoken $at).oid PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId <redacted> -AccountId $userid [...] PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object { $_.ObjectType -eq "Role" } ObjectId DisplayName Description -------- ----------- ----------- <redacted> On Premises Directory Sync Account Only used by Microsoft Entra Connect Sync Account. PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor <redacted> -Password <redacted> CloudAnchor Result SourceAnchor ----------- ------ ------------ CloudAnchor 0 <redacted>

As we noted with the old Directory Synchronization Accounts role, the new On Premises Directory Sync Account role also can only touch hybrid users and cannot modify Entra applications/service principals since it doesn’t have the necessary permissions either. Moreover, the latest version of Entra Connect (2.4.129.0 at the time this blog was written), continues to create a user called On-Premises Directory Synchronization Service Account with the old Directory Synchronization Accounts role assigned.

Tenable considers both Entra synchronization roles as privileged

According to the new privileged roles and permissions feature of Entra ID, these roles are not considered privileged. The new feature marks some permissions as privileged which then flows down to all roles having at least one privileged permission. Because the Directory Synchronization Accounts role and the On Premises Directory Sync Account role lack privileged permissions they are not marked as privileged.

Tenable respectfully disagrees with this conclusion because of the potential for abuse of these roles.

Now, let’s talk about that new app: Microsoft Entra AD Synchronization Service

No, Entra "AD" is not a typo. And even though the name might lead one to conclude this is a brand new offering, it appears that the name is likely meant to indicate its function as a bridge between Entra [ID] and AD.

Microsoft describes Entra AD Synchronization Service as “a dedicated first-party application to enable the synchronization between Active Directory and Microsoft Entra ID.” It’s described as being for customer tenants using Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync service. While Microsoft communicated about this new app in December and made it available in all tenants, for now it isn't used. At least not publicly. My goal in discussing it here is to raise awareness of the fact that, while this app is not yet generally used, it is available and already open for potential abuse.

As a first-party application, the application object (aka “app registration”) is hosted in Microsoft’s tenant, while the corresponding Service Principal (SP) object (aka “enterprise application”) is instantiated in the customer’s tenant (see how below). Below are key characteristics of this service principal (retrieved via the Graph API):

AttributeValuedisplayNameMicrosoft Entra AD Synchronization ServiceidNot relevant as it’s different in each tenantappId6bf85cfa-ac8a-4be5-b5de-425a0d0dc016appOwnerOrganizationIdf8cdef31-a31e-4b4a-93e4-5f571e91255a
(well-known “Microsoft Services” tenant where many first-party apps are registered)servicePrincipalNames["6bf85cfa-ac8a-4be5-b5de-425a0d0dc016"]

In my test tenant, this SP doesn’t have any app/delegated permissions granted. But its related app exposes two permissions:

• app permission (appRoles): ADSynchronization.ReadWrite.All having the ID ab43b826-2c7a-4aff-9ecd-d0629d0ca6a9
• delegated permission (publishedPermissionScopes): ADSynchronization.ReadWrite.All having the ID 0b41ed4d-5f52-442b-8952-ea7d90719860

The SP doesn’t have any password/key/federated credentials set. Entra ID blocked my attempts to add some (CannotUpdateLockedServicePrincipalProperty), which I believe is caused by app instance property lock.

So, how to get this SP in your tenant if you don’t have it already? I already had Entra Connect in my test tenant, so I just had to reinstall it, which triggered the creation of the SP. Surprisingly, according to the audit logs, it was created by the classic synchronization service user (“SYNC_…<server>_<random>” for Entra Connect):

Perhaps you have noticed in the above image the following intriguing Credential property: [{"CredentialType":2,"KeyStoreId":"291154f0-a9f5-45bb-87be-9c8ee5b6d62c","KeyGroupId":"291154f0-a9f5-45bb-87be-9c8ee5b6d62c"}]

I’ve observed the same for other SPs so we can ignore it.

The dangers of ADSynchronization.ReadWrite.All

Now, I know that the “Microsoft Entra AD Synchronization Service” app exposes a single permission: ADSynchronization.ReadWrite.All. This permission is available both as an app permission and a delegated permission. So I tried using it with a client Service Principal.

1. Create an app registration

2. In the “API permissions” menu, click “Add a permission” and search for the “Microsoft Entra AD Synchronization Service” API:

3. Select the “application permissions” type. There’s only one, as I already know, so I check it and add:

4. Grant admin consent:

5. Assign credentials to the client app to allow authenticating as its SP

Now that I have a new client SP, with this permission granted on the Microsoft Entra AD Synchronization Service API, how to use it?

On the Microsoft Entra AD Synchronization Service SP, I have no clue (e.g. reply URL) where the corresponding API is. But I know that it’s related to synchronization and I assume it’s meant to replace the usual service account. So, I’ll try to access the Synchronization API. This is the API we discussed earlier in this blog — the private undocumented “Azure AD Synchronization” API at https://adminwebservice.microsoftonline.com/provisioningservice.svc, also called “Sync provisioning service” by Dr. Nestori Syynimaa who implemented it in AADInternals.

Here’s the PowerShell script I’m using to obtain a token (using the client credentials grant OAuth 2.0 flow, also refer to this doc on the .default scope), for the Microsoft Entra AD Synchronization Service API (using known ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016), with the credentials of my client app. Then it shows the content of the token and tries to use the Synchronization API to reset the password of a hybrid user:

Import-Module AADInternals -Force $TenantId = <redacted>' $ClientId = '<redacted>' # my "client app for Microsoft Entra AD Synchronization Service" $ClientSecret = '<redacted>' $at = $null $response = $null $response = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" -Body @{grant_type = "client_credentials"; client_id = $ClientId; client_secret = $ClientSecret; scope="6bf85cfa-ac8a-4be5-b5de-425a0d0dc016/.default"} $at = $response.access_token Read-AADIntAccessToken -AccessToken $at Set-AADIntUserPassword -AccessToken $at -SourceAnchor <redacted> -Password <redacted>

Here’s the output I get. First, the obtained access token:

aud : 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016 iss : https://login.microsoftonline.com/<$TenantId>/v2.0 [...] azp : <$ClientId> [...] idtyp : app oid : <object ID of my client SP> [...] roles : {ADSynchronization.ReadWrite.All} sub : <object ID of my client SP> tid : <$TenantId> [...]

Which confirms that I obtained a token as desired: meant for (aud) the Microsoft Entra AD Synchronization Service API, with the ADSynchronization.ReadWrite.All permission. Then, I have the confirmation that it works when I use it (since the Result is 0):

CloudAnchor : CloudAnchor Result : 0 SourceAnchor : <redacted>

Actually it doesn’t work immediately, because normally the token to call the Synchronization API has to be for the Azure AD Graph API (graph.windows.net), which is, by the way, currently being deprecated. And the code of AADInternals doesn’t expect anything else, so to make it work, I had to add -Force:$True to the following line of code in Set-UserPassword, like so:

$AccessToken = Get-AccessTokenFromCache -AccessToken $AccessToken -ClientID "1b730954-1685-4b74-9bfd-dac224a7b894" -Resource "https://graph.windows.net" -Force:$True

To conclude, any service principal granted the ADSynchronization.ReadWrite.All permission on the “Microsoft Entra AD Synchronization Service” app can do everything that the Synchronization API allows (such as resetting hybrid users’ passwords). Therefore, these potential service principals must be considered as malicious until the app is officially put in use. Then, when Microsoft releases it, there will be legitimate cases to exclude, of course.

Tenable Identity Exposure considers “ADSynchronization.ReadWrite.All” to be dangerous

Tenable Identity Exposure has two Indicators of Exposure related to the topic of dangerous API permissions:

• Dangerous Application Permissions Affecting the Tenant
• Dangerous Delegated Permissions Affecting the Tenant

They were focused on dangerous permissions on the Azure AD Graph and MS Graph APIs, but following this research, we’ve expanded them to include the ADSynchronization.ReadWrite.All permission on the Microsoft Entra AD Synchronization Service API (see screenshot below).

I want to highlight here that most online resources and tools are focused on checking permissions granted for the two most well-known APIs — Azure AD Graph and MS Graph API permissions, e.g. RoleManagement.ReadWrite.Directory. By only focusing on these two APIs, organizations risk overlooking the dangerous permission on the Microsoft Entra AD Synchronization Service API. You can use Tenable Identity Exposure to address these permissions, or you can check your scripts/tools to better secure your hybrid identity environment

Conclusion

Even after Microsoft’s 2024 hardening efforts, hybrid Entra ID synchronization remains a critical exposure point. The 'Directory Synchronization Accounts' and 'On Premises Directory Sync Account' roles still retain implicit access to sensitive synchronization APIs, and the new 'Microsoft Entra AD Synchronization Service' app introduces the powerful ADSynchronization.ReadWrite.All permission — creating additional risk if misused.

Security teams should proactively monitor for these roles and permissions in their environments, treat them as privileged and ensure they are continuously assessed for exposure risks. Tenable Identity Exposure accounts for these evolving exposures to help defenders stay ahead.

Tenable Research will continue to monitor this evolution to provide the most accurate indicators to our customers — ensuring you have the visibility needed to protect your hybrid identity environments.

In the first installment of Tenable’s “Stronger Cloud Security in Five” blog series, we covered cloud security posture management (CSPM), which focuses on protecting your multi-cloud infrastructure by detecting misconfigurations. Today, we turn to securing cloud workloads, which are the applications and services — along with all the resources they need to function — that run within your multi-cloud infrastructure.

Because cloud environments are dynamic, distributed and multi-layered, securing cloud workloads is challenging, as their security posture can quickly shift. The variety of workloads — virtual machines, container images, databases, serverless functions, and more — adds to the complexity.

Also complicating matters: The deployment of cloud workloads on more than one cloud service provider (CSP), which requires that security teams protect workloads in multi-cloud environments.

In fact, an Enterprise Strategy Group (ESG) survey last year found that most organizations need to secure applications across multi-cloud environments. The report also found that almost all organizations suffered serious cybersecurity incidents.

As a result, 89% of organizations planned to invest more in cloud security platforms and DevSecOps, including in cloud workload protection platforms, ESG Cybersecurity Practice Director Melinda Marks explained.

Clearly, cloud workload integrity is essential. As the Cloud Security Alliance tells us in its “Security Guidance: For Critical Areas of Focus in Cloud Computing”: “For businesses using the cloud, securing these workloads is not just about protecting data. It is also about ensuring that their operations can continue without interruption.” 

At Tenable, we believe that to secure your multi-cloud workloads, you need a cloud-native application protection platform (CNAPP) with a strong cloud workload protection solution that can help you prevent, detect and address exposures, including vulnerabilities, misconfigurations and insecure APIs.

“Choosing a security provider that has conflicting priorities can introduce risk. The best cloud security program is built on independence, transparency and aligned priorities around your security needs.” -- Tenable Chief Product Officer Shai Morag

Here are five key best practices for protecting your cloud workloads.

1 - Continuous and contextualized vulnerability management

It’s critical to automate the continuous scanning of your cloud workloads to detect vulnerabilities across operating systems, containers, virtual machines, and more — whenever they crop up.

In addition, you need contextualized vulnerability analysis. Your CNAPP’s CWP tool must enrich the context of detected vulnerabilities with granular research information, including severity ratings and exploit details. This rich context will allow you to identify the riskiest vulnerabilities to your organization and prioritize remediation accordingly.

For example, you’ll be able to detect cloud workloads afflicted with toxic combinations, such as those that are publicly exposed and have critical vulnerabilities and excessive permissions. How prevalent is this “toxic trilogy”? The “Tenable Cloud Risk Report 2024” found that almost 40% of organizations have at least one toxic trilogy — and 27% have at least five. 

2 - Cloud scanning

To protect workloads in a cloud-native manner, you’ll need an effective method to scan. Agentless scanning is one effective way to do just that. By using the APIs provided by CSPs to gather security data, agentless scanning protects workload performance and delivers a holistic view of your security posture at scale. 

You get visibility into your cloud workload inventory, telemetry and risks, including vulnerabilities, data exposure, overprivileged identities, malware and misconfigurations across virtual machines, containers, serverless workloads and Kubernetes clusters. With this data in hand, you can establish sound priorities to guide your remediation efforts. 

3 - Build-to-runtime container security

A critical component of cloud workload security is the protection of containers throughout their lifecycles — from build to deployment. This continuous, end-to-end container security also needs to be automated and baked into your DevOps workflows and CI/CD pipeline.

Such an automated and comprehensive approach is critical given the large number of containers in a typical cloud environment, the speed with which they’re spun up and down, and their ephemeral duration.

“For businesses using the cloud, securing these workloads is not just about protecting data. It is also about ensuring that their operations can continue without interruption.” -- Cloud Security Alliance

It all starts during the container build process. Your cloud workload protection platform (CWPP) must give your developers visibility into container risks, such as outdated operating system images and vulnerabilities. It should also empower developers to remediate the detected security flaws by giving them risk insights so they can prioritize remediation effectively.

You also need automated security scanning of the containers you check into registries, such as DockerHub and Amazon ECR.

Finally, containers should undergo automated security tests in production runtime environments because attackers will readily exploit buggy and misconfigured containers.

4 - Automated compliance monitoring

Improperly securing your cloud workloads can have serious implications if your organization runs afoul of the numerous and complex cybersecurity laws and rules that apply to cloud computing.

Keeping your cloud workloads compliant with government regulations and industry standards requires a methodical, automated approach that can match your cloud environments’ quicksilver nature.

A CWP system that automatically identifies compliance violations and provides out-of-the-box policies and templates can dramatically simplify the thorny cloud compliance process.

5 - Centralized security visibility and management

Your CWP system should provide a unified, continuously updated and contextually rich view of your multi-cloud workload resources and their risks — and it should do this in an agnostic manner. 

As Tenable Chief Product Officer Shai Morag pointed out recently: “Choosing a security provider that has conflicting priorities can introduce risk. The best cloud security program is built on independence, transparency and aligned priorities around your security needs.”

In ESG’s survey, respondents expressed a preference for consolidated solutions and platforms “to help provide better context, drive efficient actions, rapidly mitigate issues and save valuable time” instead of having to manually analyze results from separate solutions, ESG’s Marks said.

At Tenable, we believe that a centralized CWP user interface with multi-cloud visibility, security management and reporting gives your teams a single source of truth for cloud workload risks, allowing them to collaborate and prioritize remediation. 

Learn how you can take action to boost your cloud security in just five minutes.

The 2025 Verizon Data Breach Investigations Report (DBIR) reveals that vulnerability exploitation was present in 20% of breaches — a 34% increase year-over-year. To support the report, Tenable Research contributed enriched data on the most exploited vulnerabilities. In this blog, we analyze 17 edge-related CVEs and remediation trends across industry sectors.

Background

Since 2008, Verizon’s annual Data Breach Investigations Report (DBIR) has helped organizations understand evolving cyber threats. For the 2025 edition, Tenable Research contributed enriched data on the most exploited vulnerabilities of the past year. We analyzed over 160 million data points and zeroed-in on the 17 edge device CVEs featured in the DBIR to understand their average remediation times. In this blog, we take a closer look at these vulnerabilities, revealing industry-specific trends and highlighting where patching still lags — often by months.

In this year’s DBIR, vulnerabilities in Virtual Private Networks (VPNs) and edge devices were particular areas of concern, accounting for 22% of the CVE-related breaches in this year’s report, almost eight times the amount of 3% found in the 2024 report.

Analysis

The 2025 DBIR found that exploitation of vulnerabilities surged to be one of the top initial access vectors for 20% of data breaches. This represents a 34% increase over last year’s report and is driven in part by the zero-day exploitation of VPN and edge device vulnerabilities – asset classes that traditional endpoint detection and response (EDR) vendors struggle to assess effectively. The DBIR calls special attention to 17 CVEs affecting these edge devices, which remain valuable targets for attackers. Tenable Research analyzed these 17 CVEs and evaluated which industries had the best and worst remediation rates across the vulnerabilities. As a primer, the table below provides this list of CVEs and details for each, including their Common Vulnerability Scoring System (CVSS) and Tenable Vulnerability Priority Rating (VPR) scores. It’s worth noting that each of these CVEs was added to the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) list in 2024.

CVEDescriptionCVSSv3VPRTenable BlogCVE-2024-20359Cisco ASA and FTD Software Persistent Local Code Execution Vulnerability6.06.7CVE-2024-20353, CVE-2024-20359: Frequently Asked Questions About ArcaneDoorCVE-2023-6548Citrix NetScaler ADC and Gateway Authenticated Remote Code Execution (RCE) Vulnerability8.87.4CVE-2023-6548, CVE-2023-6549: Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC and NetScaler GatewayCVE-2023-6549Citrix NetScaler ADC and Gateway Denial of Service Vulnerability7.55.1CVE-2023-48788FortiClient Enterprise Management Server (FortiClientEMS) SQL Injection Vulnerability9.89.4CVE-2023-48788: Critical Fortinet FortiClientEMS SQL Injection VulnerabilityCVE-2024-21762Fortinet FortiOS Out-of-bound Write Vulnerability in sslvpnd9.87.4CVE-2024-21762: Critical Fortinet FortiOS Out-of-Bound Write SSL VPN VulnerabilityCVE-2024-23113Fortinet FortiOS Format String Vulnerability9.87.4CVE-2024-47575FortiManager Missing Authentication in fgfmsd Vulnerability (FortiJump)9.89.6CVE-2024-47575: Frequently Asked Questions About FortiJump Zero-Day in FortiManager and FortiManager CloudCVE-2023-46805Ivanti Connect Secure and Ivanti Policy Secure Authentication Bypass Vulnerability8.26.7CVE-2023-46805, CVE-2024-21887: Zero-Day Vulnerabilities Exploited in Ivanti Connect Secure and Policy Secure GatewaysCVE-2024-21887Ivanti Connect Secure and Ivanti Policy Secure Command Injection Vulnerability9.19.8CVE-2024-21893Ivanti Connect Secure, Ivanti Policy Secure and Ivanti Neurons for ZTA Server-Side Request Forgery (SSRF) Vulnerability8.27.2CVE-2023-46805, CVE-2024-21887, CVE-2024-21888 and CVE-2024-21893: Frequently Asked Questions for Vulnerabilities in Ivanti Connect Secure and Policy Secure GatewaysCVE-2023-36844Juniper Networks Junos OS PHP External Variable Modification Vulnerability5.32.9Exploit Chain Targets Unpatched Juniper EX Switches and SRX FirewallsCVE-2023-36845Juniper Networks Junos OS PHP External Variable Modification Vulnerability9.88.4CVE-2023-36846Juniper Networks Junos OS Missing Authentication Vulnerability5.32.9CVE-2023-36847Juniper Networks Junos OS Missing Authentication Vulnerability5.32.9CVE-2023-36851Juniper Networks Junos OS Missing Authentication Vulnerability5.32.9CVE-2024-3400Command Injection Vulnerability in the GlobalProtect Gateway feature of PAN-OS10.010CVE-2024-3400: Zero-Day Vulnerability in Palo Alto Networks PAN-OS GlobalProtect Gateway Exploited in the WildCVE-2024-40766SonicWall SonicOS Management Access and SSLVPN Improper Access Control Vulnerability9.87.4 

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

Tenable Research Analyzes Edge CVE Remediation Trends

Featured prominently in the DBIR, these 17 edge device CVEs were further analyzed by Tenable Research and are organized by vendor with each chart below consisting of CVEs fixed in the same patch release. To understand remediation efforts from Tenable’s telemetry data, we analyzed the average time in days for remediation of these vulnerabilities. The charts shown below spotlight the three industries that had the shortest average time to remediate each vulnerability as well as the three sectors that took the longest amount of time to remediate.

Cisco

CVE-2024-20359 was highlighted in April 2024 by Cisco Talos as one of two known vulnerabilities being exploited by an advanced persistent threat (APT) actor labeled as UAT4356 by Talos and STORM-1849 by the Microsoft Threat Intelligence Center. The flaw was used as part of an espionage campaign known as ArcaneDoor. From our analysis, we found that the education, energy and utilities, and shipping and transportation industries had the longest average remediation time for this vulnerability. CVE-2024-20359 was added to the CISA KEV list on April 24, 2024; the same date Cisco Talos released its research on ArcaneDoor. This KEV addition had a due date of seven days for federal civilian executive branch (FCEB) agencies, which are mandated by Binding Operational Directive (BOD) 22-01. Despite this short patch window, we see that the government sector had a surprisingly high average remediation rate of 116 days. While this is well outside the KEV due date, government was one of the three industries with the fastest average remediation rate.

Source: Tenable Research, April 2025

Citrix

CVE-2023-6548 and CVE-2023-6549 are a pair of zero-day vulnerabilities that were exploited against Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway appliances. These vulnerabilities were patched in early January 2024, only months after Citrix addressed CVE-2023-4966, a critical flaw in NetScaler appliances called “CitrixBleed” that was widely exploited by a variety of attackers. While Citrix appliances continue to remain a high value target for attackers, the remediation rates, even amongst the three industries with the shortest average remediation rates, are much higher than we anticipated. The lowest average patch rate observed was 160 days for the consulting industry.

Source: Tenable Research, April 2025

Fortinet

CVE-2024-21762 and CVE-2024-23113 are two critical severity vulnerabilities affecting Fortinet’s FortiOS network operating system. At the time the Fortinet advisory was released for these vulnerabilities, CVE-2024-21762 was listed as “potentially being exploited in the wild.” Just a day later, CISA added it to the KEV list. Similar to the Citrix vulnerabilities above, the average remediation time for these vulnerabilities ranged from 172 days on the low end to over 260 days on the high end. The consulting industry had the longest average remediation rate while the software, internet and technology sector had the shortest at 172 days.

Source: Tenable Research, April 2025

In stark contrast to the Fortinet CVEs above is CVE-2023-48788, a critical SQL injection vulnerability affecting FortiClient Enterprise Management Server (FortiClientEMS). The communications and telecommunications sector led the way with an average remediation rate of only 12 days with healthcare a distant second, with an average of 71 days to remediate the flaw.

Source: Tenable Research, April 2025

Similar to CVE-2023-48788, CVE-2024-47575, a missing authentication vulnerability in FortiManager dubbed “FortiJump,” appears to have been urgently addressed by organizations. Our analysis revealed it had the lowest average remediation rates of the 17 CVEs we examined. Remediation times averaged a week, even for the slowest to patch industries.

Source: Tenable Research, April 2025

Ivanti

Over the last five years, Ivanti’s Connect Secure and Policy Secure have been targeted by a variety of threat actors including ransomware groups and other nation-state aligned threat actors. Unsurprisingly, CVE-2023-46805 and CVE-2024-21887 have been reportedly abused by threat actors in chained attacks to achieve RCE. Additionally, these flaws were exploited as zero-days. From our analysis, even the quickest of industries to remediate these flaws took over 260 days to do so with the highest average just shy of 300 days.

Source: Tenable Research, April 2025

Only a few weeks after patches for CVE-2023-46805 and CVE-2024-21887 were released, Ivanti released a new advisory with additional CVEs, including CVE-2024-21893. While initially it was believed that CVE-2024-21893 was only exploited in limited attacks, Shadowserver reported a major increase in exploit activity hours prior to a public proof-of-concept (PoC) being released. Interestingly this vulnerability saw some differing remediation rates with the biotechnology and chemicals sector being the fastest to patch with an average of nine days for remediation.

Source: Tenable Research, April 2025

Juniper Networks

Next we examined five CVEs from Juniper Networks (CVE-2023-36844, CVE-2023-36845, CVE-2023-36846, CVE-2023-36847 and CVE-2023-36851) affecting Junos OS. These vulnerabilities were quickly exploited in a chained attack just days after being disclosed by Juniper Networks, which released its patches on August 17, 2024. While four of the five vulnerabilities had medium severity CVSSv3 scores, chaining these flaws allows for a remote, unauthenticated attacker to execute arbitrary code on unpatched devices. The average remediation rate for these vulnerabilities varied greatly, with food and beverage at over 420 days and shipping and transportation on the low end with an average remediation time of 80 days.

Source: Tenable Research, April 2025

Palo Alto Networks

CVE-2024-3400 is a critical command injection vulnerability affecting the Palo Alto Networks GlobalProtect Gateway feature of PAN-OS that was exploited in the wild as a zero-day. In our dataset, this CVE had a smaller footprint than others examined, yet it shared a similar trend with most industries requiring over 100 days to remediate. The banking, finance and insurance sector performed far better with an average of 45 days to close out this vulnerability.

Source: Tenable Research, April 2025

SonicWall

The final CVE we examined was CVE-2024-40766, a critical improper access control vulnerability in the SonicWall SonicOS management access and SSLVPN. This flaw saw exploitation from ransomware groups, including Fog and Akira, which utilized the vulnerability to gain initial access to their victims' networks. In the case of this SonicWall vulnerability, average remediation rates were low in comparison to the other CVEs we examined, with the slowest sector taking 52 days (consulting) and the fastest (engineering) taking an average of only six days.

Source: Tenable Research, April 2025

Conclusion

The 17 CVEs we examined in our analysis, while only representing a small portion of the CISA KEV, encompass devices that have an elevated risk, due to their placement at the forefront of a network. Despite these being some of the most valuable targets for attackers, our examination of remediation rates show us that there’s still room for improvement across all industry verticals. Known and exploitable vulnerabilities continue to be abused by threat actors, many of which take advantage of readily available exploits. Data has become increasingly valuable and attackers and APT groups alike have zeroed in on the exploits and vulnerabilities that provide and help them maintain access to victim networks. In order to reduce risk and harden your networks, we recommend addressing each of the CVEs discussed in this post as well as reading the Verizon 2025 DBIR to understand the trends and tactics used by threat actors. Security isn’t just for infosec professionals — it’s everyone’s responsibility. The data compiled by Verizon, in collaboration with Tenable, offer valuable insights into today’s modern threat landscape and what you can do to better protect the networks, devices and people you defend.

Identifying affected systems

A list of Tenable plugins for the vulnerabilities discussed in the blog can be found on the individual CVE pages for each of the CVEs listed below. These links will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

• CVE-2024-20359
• CVE-2023-6548
• CVE-2023-6549
• CVE-2023-48788
• CVE-2024-21762
• CVE-2024-23113
• CVE-2024-47575
• CVE-2023-46805
• CVE-2024-21887
• CVE-2024-21893
• CVE-2023-36844
• CVE-2023-36845
• CVE-2023-36846
• CVE-2023-36847
• CVE-2023-36851
• CVE-2024-3400
• CVE-2024-40766

Get more information

• Verizon 2025 Data Breach Investigations Report (DBIR)

Join Tenable's Security Response Team on the Tenable Community.

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

U.S. government agencies are required to bring their Microsoft 365 cloud services into compliance with a recent Binding Operational Directive. Here’s how Tenable can help.

Overview

Malicious threat actors are constantly targeting cloud environments. The risk of compromise can be reduced by enforcing secure configurations of security controls. With this goal in mind, the Cybersecurity and Infrastructure Security Agency (CISA) created the Secure Cloud Business Applications (SCuBA) project. The SCuBA project currently provides secure configuration baselines for Microsoft 365 and Google Workspace.

In December 2024, as part of the SCuBA project, CISA released a Binding Operational Directive (BOD) 25-01: Implementation Guidance for Implementing Secure Practices for Cloud Services. This directive requires U.S. government agencies and departments in the federal civilian executive branch to implement secure configuration baselines for certain software as a service (SaaS) products.

Scope

The scope of the BOD 25-01 includes all production or operational cloud tenants (operating in or as a federal information system) utilizing Microsoft 365. CISA may release additional SCuBA Secure Configuration Baselines for other cloud products which would fall under the scope of this directive. The complete list of required configurations is available here.

While the CISA BOD 25-01 applies to government agencies, any organization using Microsoft 365 would reduce the risk of compromise by adhering to these baselines.

Required actions

According to BOD 25-01, there are several required actions for in-scope cloud tenant agencies that shall be completed by the following dates:

• February 21, 2025 - following CISA reporting instructions:
  • submit tenant name and system owning agency/component for each tenant
  • submit an updated the inventory annually in the first quarter
• April 25, 2025 - deploy SCuBA assessment tools and begin continuous reporting
• June 20, 2025 - implement all mandatory SCuBA policies identified at BOD 25-01 Required Configurations.

In-scope cloud tenants are also required to:

• Implement all future updates to mandatory SCuBA policies
• Implement all mandatory SCuBA Secure Configuration Baselines and begin continuous monitoring prior to granting an Authorization to Operate for new cloud tenants.

Required configurations

As of March 2025, the following configurations are required for BOD 25-01:

Microsoft 365 (M365)Microsoft Entra IDMS.AAD.1.1v1Legacy authentication SHALL be blocked.MS.AAD.2.1v1Users detected as high risk SHALL be blocked.MS.AAD.2.3v1Sign-ins detected as high risk SHALL be blocked.MS.AAD.3.1v1Phishing-resistant MFA SHALL be enforced for all users.MS.AAD.3.2v1If Phishing-resistant MFA has not been enforced yet, then an alternative MFA method SHALL be enforced for all users.MS.AAD.3.3v1If Phishing-resistant MFA has not been enforced yet and Microsoft Authenticator is enabled, it SHALL be configured to show login context information.MS.AAD.3.4v1The Authentication Methods Manage Migration feature SHALL be set to Migration Complete.MS.AAD.3.6v1Phishing-resistant MFA SHALL be required for Highly Privileged Roles.MS.AAD.5.1v1Only administrators SHALL be allowed to register applications.MS.AAD.5.2v1Only administrators SHALL be allowed to consent to applications.MS.AAD.5.3v1An admin consent workflow SHALL be configured for applications.MS.AAD.5.4v1Group owners SHALL NOT be allowed to consent to applications.MS.AAD.6.1v1User passwords SHALL NOT expire.MS.AAD.7.1v1A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role.MS.AAD.7.2v1Privileged users SHALL be provisioned with finer-grained roles instead [of] Global Administrator.MS.AAD.7.3v1Privileged users SHALL be provisioned cloud-only accounts that are separate from an on-premises directory or other federated identity providers.MS.AAD.7.4v1Permanent active role assignments SHALL NOT be allowed for highly privileged roles except for emergency and service accounts.MS.AAD.7.5v1Provisioning users to highly privileged roles SHALL NOT occur outside of a PAM system, because this bypasses critical controls the PAM system provides.MS.AAD.7.6v1Activation of the Global Administrator role SHALL require approval.MS.AAD.7.7v1Eligible and Active highly privileged role assignments SHALL trigger an alert.MS.AAD.7.8v1User activation of the Global Administrator role SHALL trigger an alert.Microsoft DefenderMS.DEFENDER.1.1v1The standard and strict preset security policies SHALL be enabled.MS.DEFENDER.1.2v1All users SHALL be added to Exchange Online Protection in either the standard or strict preset security policy.MS.DEFENDER.1.3v1All users SHALL be added to Defender for Office 365 Protection in either the standard or strict preset security policy.MS.DEFENDER.1.4v1Sensitive accounts SHALL be added to Exchange Online Protection in the strict preset security policy.MS.DEFENDER.1.5v1Sensitive accounts SHALL be added to Defender for Office 365 Protection in the strict preset security policy.MS.DEFENDER.4.1v2A custom policy SHALL be configured to protect PII and sensitive information, as defined by the agency, blocking at a minimum: credit card numbers, U.S. Individual Taxpayer Identification Numbers (ITINs), and U.S. Social Security numbers (SSNs).MS.DEFENDER.5.1v1At a minimum, the alerts required by the CISA M365 Secure Configuration Baseline for Exchange Online SHALL be enabled.MS.DEFENDER.6.1v1Microsoft Purview Audit (Standard) logging SHALL be enabled.MS.DEFENDER.6.2v1Microsoft Purview Audit (Premium) logging SHALL be enabled for ALL users.Exchange OnlineMS.EXO.1.1v1Automatic forwarding to external domains SHALL be disabled.MS.EXO.2.2v2An SPF policy SHALL be published for each domain that fails all non-approved senders.MS.EXO.4.1v1A DMARC policy SHALL be published for every second-level domain.MS.EXO.4.2v1The DMARC message rejection option SHALL be p=reject.MS.EXO.4.3v1The DMARC point of contact for aggregate reports SHALL include reports@dmarc.cyber.dhs.gov.MS.EXO.5.1v1SMTP AUTH SHALL be disabled.MS.EXO.6.1v1Contact folders SHALL NOT be shared with all domains.MS.EXO.6.2v1Calendar details SHALL NOT be shared with all domains.MS.EXO.7.1v1External sender warnings SHALL be implemented.MS.EXO.13.1v1Mailbox auditing SHALL be enabled.Power PlatformMS.POWERPLATFORM.1.1v1The ability to create production and sandbox environments SHALL be restricted to admins.MS.POWERPLATFORM.1.2v1The ability to create trial environments SHALL be restricted to admins.MS.POWERPLATFORM.2.1v1A DLP policy SHALL be created to restrict connector access in the default Power Platform environment.MS.POWERPLATFORM.3.1v1Power Platform tenant isolation SHALL be enabled.SharePoint Online and OneDriveMS.SHAREPOINT.1.1v1External sharing for SharePoint SHALL be limited to Existing Guests or Only People in your Organization.MS.SHAREPOINT.1.2v1External sharing for OneDrive SHALL be limited to Existing Guests or Only People in your Organization.MS.SHAREPOINT.2.1v1File and folder default sharing scope SHALL be set to Specific People (only the people the user specifies).MS.SHAREPOINT.2.2v1File and folder default sharing permissions SHALL be set to View only.Microsoft TeamsMS.TEAMS.1.2v1Anonymous users SHALL NOT be enabled to start meetings.MS.TEAMS.2.1v1External access for users SHALL only be enabled on a per-domain basis.MS.TEAMS.2.2v1Unmanaged users SHALL NOT be enabled to initiate contact with internal users.MS.TEAMS.3.1v1Contact with Skype users SHALL be blocked.MS.TEAMS.4.1v1Teams email integration SHALL be disabled.Additional configurations

In addition to the required configurations, the following configurations can also be evaluated:

Microsoft 365 (M365)Microsoft Entra IDMS.AAD.2.2v1A notification SHOULD be sent to the administrator when high-risk users are detected.MS.AAD.3.7v1Managed devices SHOULD be required for authentication.MS.AAD.3.8v1Managed Devices SHOULD be required to register MFA.MS.AAD.7.9v1User activation of other highly privileged roles SHOULD trigger an alert.MS.AAD.8.1v1Guest users SHOULD have limited or restricted access to Microsoft Entra ID directory objects.MS.AAD.8.2v1Only users with the Guest Inviter role SHOULD be able to invite guest users.Microsoft DefenderMS.DEFENDER.2.1v1User impersonation protection SHOULD be enabled for sensitive accounts in both the standard and strict preset policies.MS.DEFENDER.2.2v1Domain impersonation protection SHOULD be enabled for domains owned by the agency in both the standard and strict preset policies.MS.DEFENDER.2.3v1Domain impersonation protection SHOULD be added for important partners in both the standard and strict preset policies.MS.DEFENDER.3.1v1Safe attachments SHOULD be enabled for SharePoint, OneDrive, and Microsoft Teams.MS.DEFENDER.4.2v1The custom policy SHOULD be applied to Exchange, OneDrive, SharePoint, Teams chat, and Devices.MS.DEFENDER.4.3v1The action for the custom policy SHOULD be set to block sharing sensitive information with everyone.MS.DEFENDER.4.4v1Notifications to inform users and help educate them on the proper use of sensitive information SHOULD be enabled in the custom policy.Exchange OnlineMS.EXO.3.1v1DKIM SHOULD be enabled for all domains.MS.EXO.4.4v1An agency point of contact SHOULD be included for aggregate and failure reports.MS.EXO.12.1v1IP allow lists SHOULD NOT be created.MS.EXO.12.2v1Safe lists SHOULD NOT be enabled.Power PlatformMS.POWERPLATFORM.2.2v1Non-default environments SHOULD have at least one DLP policy affecting them.MS.POWERPLATFORM.5.1v1The ability to create Power Pages sites SHOULD be restricted to admins.SharePoint Online and OneDriveMS.SHAREPOINT.1.3v1External sharing SHALL be restricted to approved external domains and/or users in approved security groups per interagency collaboration needs.MS.SHAREPOINT.3.1v1Expiration days for Anyone links SHALL be set to 30 days or less.MS.SHAREPOINT.3.2v1The allowable file and folder permissions for links SHALL be set to View only.MS.SHAREPOINT.3.3v1Reauthentication days for people who use a verification code SHALL be set to 30 days or less.Microsoft TeamsMS.TEAMS.1.1v1External meeting participants SHOULD NOT be enabled to request control of shared desktops or windows.MS.TEAMS.1.3v1Anonymous users and dial-in callers SHOULD NOT be admitted automatically.MS.TEAMS.1.4v1Internal users SHOULD be admitted automatically.MS.TEAMS.1.5v1Dial-in users SHOULD NOT be enabled to bypass the lobby.MS.TEAMS.1.6v1Meeting recording SHOULD be disabled.MS.TEAMS.1.7v1Record an event SHOULD be set to Organizer can record.MS.TEAMS.2.3v1Internal users SHOULD NOT be enabled to initiate contact with unmanaged users.MS.TEAMS.5.1v1Agencies SHOULD only allow installation of Microsoft apps approved by the agency.MS.TEAMS.5.2v1Agencies SHOULD only allow installation of third-party apps approved by the agency.MS.TEAMS.5.3v1Agencies SHOULD only allow installation of custom apps approved by the agency.How Tenable can help

Tenable Vulnerability Management and Nessus customers can audit the posture of their Microsoft 365 environment with the CISA SCuBA for Microsoft 365 audit files:

• CISA SCuBA Microsoft 365 Entra ID
• CISA SCuBA Microsoft 365 Defender
• CISA SCuBA Microsoft 365 Exchange Online
• CISA SCuBA Microsoft 365 Power Platform
• CISA SCuBA Microsoft 365 SharePoint Online OneDrive
• CISA SCuBA Microsoft 365 Teams

More details for configuring your SCuBA Microsoft 365 environment for Compliance Auditing are available at Configure Azure for a Compliance Audit.

Tenable Research discovered a privilege-escalation vulnerability in Google Cloud Platform (GCP) that is now fixed and which we dubbed ConfusedComposer. The vulnerability could have allowed an identity with permission (composer.environments.update) to edit a Cloud Composer environment to escalate privileges to the default Cloud Build service account. The default Cloud Build service account includes permissions to Cloud Build itself, as well as to Cloud Storage, Artifact Registry, and more.

What are Cloud Composer and Cloud Build?

Cloud Composer is a fully managed workflow-orchestration service in GCP based on Apache Airflow that is used for scheduling and automating data pipelines.

Cloud Build is a fully managed continuous integration and delivery (CI/CD) service in GCP that builds, tests and deploys applications and containers at scale.

Cloud Composer uses Cloud Build to build packages, and that is exactly where attackers could have abused the process to escalate privileges.

ConfusedComposer vulnerability details

 

Cloud Composer allows users to install custom PyPI packages in their environments. However, this functionality introduced a privilege escalation vulnerability due to how Composer interacts with Cloud Build. When a user specifies a custom PyPI package, Composer initiates a behind-the-scenes build process, and the Cloud Composer service account automatically provisions a Cloud Build instance in the user's project. This instance is attached to the default Cloud Build service account, a highly privileged identity with broad permissions to GCP services including to Cloud Build itself, as well as to Cloud Storage, Artifact Registry or Container Registry, and more. (Click here to learn more about the default Cloud Build service account permissions).

An attacker with the composer.environments.update permission could have abused the Cloud Composer service orchestration process to escalate privileges. The attack would have been executed by injecting an attacker-controlled malicious PyPI package into the victim’s Composer custom-package configuration: 

 

 

When Cloud Build installs this package in an attempt to build the environment, it uses Pip. 

But how would one have executed remote code by adding a package to the Composer service? Turns out that Pip automatically runs pre- and post-package installation scripts. This would have allowed an attacker to execute arbitrary code within the correlated Cloud Build environment by using installation scripts inside their malicious package, despite lacking direct control over Composer’s underlying service account. 

The privilege escalation would have occurred when an attacker injected code that accessed the Cloud Build’s metadata API. Because the build instance runs with the default Cloud Build service account, an attacker could have extracted and exfiltrated its token. With this token, the attacker would have gained control over a privileged service account, allowing further escalation across the victim’s GCP project. This attack was particularly dangerous because the attacker did not need direct access to the Composer’s service account or to Cloud Build’s service account—only the ability to update a Composer environment. By simply adding a PyPI package to Composer, they could have manipulated the trusted automation pipeline to escalate privileges beyond their original access level. To clarify the impact of the now-fixed vulnerability: gaining full ownership of the project from the default Cloud Build service account was well within reach. 

The vulnerability fix and extra steps taken by GCP to enhance overall security

Previously, during update operations to perform PyPI module installations, Composer used the Cloud Build service account, which might have had broader permissions than the user performing the operation. After implementing the fix, Composer stopped using the Cloud Build service account and instead will use the Composer environment service account for performing PyPI module installations.

The fix has been rolled out to new Composer instances already (rel. notes), and existing instances should be updated to exhibit this behavior by April 2025 (rel. notes).

In addition, our findings led GCP to update parts of Composer’s documentation, such as the sections on Access Control, Installing Python Dependencies and Accessing the Airflow CLI.

A new attack class: Following the ConfusedFunction vulnerability

The ConfusedComposer privilege-escalation vulnerability in GCP builds upon a broader attack class of vulnerabilities in cloud services that we call "Jenga®" . This attack vector is a variant of ConfusedFunction, another GCP privilege-escalation vulnerability we discovered last year, and exploits the somewhat-hidden cloud provider misconfigurations related to cloud services permissions to escalate privileges beyond intended access levels. This variant highlights how attackers can abuse interconnected services the cloud provider automatically deploys behind the scenes, as part of a service-orchestration process.

(JENGA® is a registered trademark owned by Pokonobe Associates.)

 

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 CSO Robert Huber shares practical advice on using an exposure management program to focus on risks that have business impact. You can read the entire Exposure Management Academy series here.

There’s a trap security practitioners can often fall into. No, it’s not some tactic employed by the bad guys to trip us up. It’s a fairly simple trick of the mind: thinking that every risk deserves urgent attention. Maybe it’s human nature. If there’s a problem — no matter how big or small — some of us are just wired to want to fix it right away and get it off our punch list. 

But I’ve learned the hard way that not all risks are created equal. So treating each one as number-one priority is a surefire shortcut to burnout and inefficiency.

Like many of you, here at Tenable, we’ve been building our own internal exposure management program. On this journey, one of the most profound lessons I’ve learned is to prioritize risk based on business impact. 

Moving to that line of thinking has helped me bring clarity to chaos. It has reduced the noise and allowed me to focus myself and my team on what really matters, which is the key to a successful exposure management program.

Start with the right data

One of the big struggles for security professionals is context switching. 

When you meet with your business leaders to update them, you often have to scramble to pull together inputs from a dozen different tools and teams. 

That’s because the data is siloed, often incomplete and nearly impossible to compare. 

Our job in security is to provide these leaders — maybe your CEO or head of a business unit — with a clear, coherent picture of the most acute exposures. Try as we might, those pictures have been partly cloudy with a chance of inaccuracies.

So, as we started on the exposure management journey, our initial step was to assimilate the data. And I mean all of it. With help from Vulcan (now part of Tenable), we combed through tools, platforms and teams for every scrap of data. 

Believe me, until you do that, you can’t prioritize meaningfully. You’re just guessing.

Understand risk in context

OK, bringing all that data together was a huge task. You’ll probably think, “Mission accomplished!” But that’s just the start.

Once the data’s in one place, the real work begins. That’s when I ask: What does this risk mean in context?

You should look at it from a couple of angles: First, consider it in the context of other risks across your organization. Then, think about the risks in the context of the business itself. How could this risk affect your revenue, operations or reputation? 

If you don’t think this way right off the bat, you’ll just end up reacting to the loudest alert, not the most important one. And we know how that goes. As I heard often during officer candidate school in the military: focus on the important, not the urgent — which is especially helpful when you don’t have enough time in the day.

Identify the systemic issues

Exposure management isn’t about patching one vulnerability at a time. It’s about identifying what I call the big rocks. Whatever you call them, these are systemic issues that affect thousands of assets or users. Left unaddressed, they can truly put the business at risk.

Sometimes we don’t fix those big rocks right away. That might be because a patch broke a critical system or legacy infrastructure doesn’t support a specific control. When that happens, the exposure becomes a tracked business risk on our risk register. And it stays on the radar until we resolve it.

That’s a big shift from the old model, where issues could disappear into ticket queues with no clear owner and no resolution in sight. 

With exposure management platforms, leadership and even the board can have their eyes on these issues. That’s because we’re aligning security priorities with business priorities.

Clearly communicate risk 

Of course, none of this works unless you communicate clearly. 

And communication can be a big challenge. You could use simple traffic light charts (i.e., red, yellow, green) to represent control coverage. But how do you accurately assign those colors? It can be a subjective exercise based more on your gut than real data. 

With exposure management software, your eventual goal should be to make that process quantitative and, ideally, real-time so you don’t have to pull a team off their work every quarter to do manual updates. 

Soon, we’ll live in a world where the moment something changes, we’ll see it communicated immediately. With that instantaneous information at our disposal, we’ll decide whether to act, defer or escalate.

Manage change so it doesn’t manage you

Exposure management isn’t just a technical shift. It’s a change management exercise. 

You’re asking teams to work differently, respond to new priorities and trust a centralized system that makes decisions based on data that might be unfamiliar.

That kind of shift takes time. It requires building relationships, clarifying expectations and iterating on the program until it works for everyone. 

As my colleague Arnie Cabral wrote in What it Takes to Start the Exposure Management Journey, we’ve started by rebuilding our policies, defining roles and responsibilities and ensuring that the people doing the work know exactly what’s expected — and why.

Takeaways: This is the path forward

We’re in the early days of this exposure management journey. And some of our industry certifications and policies still require us to fix everything above a certain CVSS score, whether or not it truly poses a threat. So there will be a level of reconciliation ahead between traditional compliance models and this more pragmatic, business-aligned approach.

But I believe exposure management, when done right, can bridge that gap. It will give you the ability to say, “These are the risks that matter most — and here’s why.”

That’s how you’ll make better decisions in the long run. You’ll better protect your business. And you’ll move security from reactive to strategic.

Have a question about exposure management you’d like us to tackle?

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);

Proof-of-concept code has been released after researchers disclosed a maximum severity remote code execution vulnerability in Erlang/OTP SSH. Successful exploitation could allow for complete takeover of affected devices.

Background

On April 16, Fabian Bäumer, Marcus Brinkmann, Marcel Maehren, and Jörg Schwenk of the Ruhr University Bochum in Germany disclosed a critical vulnerability in Erlang/OTP SSH to the OpenWall vulnerability mailing list. Additionally an official advisory was posted to the GitHub project for Erlang/OTP crediting the researchers for their disclosure.

CVEDescriptionCVSSv3VPRCVE-2025-32433Erlang/OTP SSH Remote Code Execution Vulnerability10.010

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

Analysis

CVE-2025-32433 is a remote code execution (RCE) vulnerability affecting the Erlang/OTP SSH server. The vulnerability exists due to a flaw in the SSH protocol message handling which could allow an unauthenticated attacker to execute arbitrary code. According to the advisory, all users running Erlang/OTP SSH servers are impacted and to assume impact if your application utilizes the Erlang/OTP SSH library. This vulnerability received the maximum CVSSv3 score of 10.0 and when the SSH daemon is running as root, allows an attacker to completely compromise an affected device.

At the time this blog was published, no known exploitation has been observed, however with the ease of exploitation and critical severity, we anticipate attacks will occur soon.

Proof of concept

On April 17, researchers at Platform Security released a public proof-of-concept (PoC) exploit for CVE-2025-32433. The writeup notes that the PoC was generated with the help of ChatGPT and Cursor, and that it was fairly simple to do so using those AI tools.

The PoC initiates an SSH protocol negotiation as a normal client would. But, before authenticating the user, the client sends an unexpected message with an arbitrary command. The vulnerable server will process these messages and execute the commands. A patched server will disconnect immediately upon seeing these messages prior to authentication.

An additional PoC has been released, and the Horizon3 Attack Team posted on X (formerly Twitter) that they had developed a PoC but have chosen not to release it as of writing.

Just finished reproducing CVE-2025-32433 and putting together a quick PoC exploit — surprisingly easy. Wouldn’t be shocked if public PoCs start dropping soon. If you’re tracking this, now’s the time to take action. #Erlang #SSH pic.twitter.com/hBqJMfFHMN

— Horizon3 Attack Team (@Horizon3Attack) April 17, 2025

Solution

Erlang/OTP has released patches to address this vulnerability.

Affected VersionsFixed VersionsOTP-27.3.2 and belowOTP-27.3.3OTP-26.2.5.10 and belowOTP-26.2.5.11OTP-25.3.2.19 and belowOTP-25.3.2.20

If immediate patching cannot be performed, restricting access via a firewall or disabling the SSH server are mitigation steps provided by Erlang/OTP. However, we strongly recommend upgrading as soon as possible to fully remediate this vulnerability.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2025-32433 as they’re released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify hosts running Erlang/OTP SSH Server.

Get more information

• Openwall mailing list announcement for CVE-2025-32433
• Advisory for CVE-2025-32433

Join Tenable's Security Response Team on the Tenable Community.

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

Check out NIST’s effort to further mesh its privacy and cyber frameworks. Plus, learn why code-writing GenAI tools can put developers at risk of package-confusion attacks. Also, find out what Tenable webinar attendees said about identity security. And get the latest on the MITRE CVE program and on attacks against edge routers.

Dive into five things that are top of mind for the week ending April 18.

1 - NIST updates Privacy Framework, tailoring it to the Cybersecurity Framework and adding an AI section

Recognizing the data protection and cyberattack prevention overlap and are deeply intertwined, the U.S. government is aligning two foundational privacy and cybersecurity frameworks.

This week, the U.S. National Institute of Standards and Technology (NIST) released a draft update of its Privacy Framework (PFW) that more closely interconnects it with the popular Cybersecurity Framework (CSF), which was updated in 2024.

Although the PFW can be used on its own, this updated version makes its use with the CSF “seamless” so that organizations can leverage the two frameworks “to manage the full spectrum of privacy and cybersecurity risks,” Julie Chua, Director of NIST’s Applied Cybersecurity Division, said in a statement.

Both frameworks have a “Core” section, which outlines detailed activities and outcomes aimed at helping organizations discuss risk management. “The PFW 1.1 Public Draft Core is realigned with the CSF 2.0 Core in many places, making life easier on users,” NIST said in the statement.

The “NIST Privacy Framework 1.1 Initial Public Draft” also adds a new section about the risks to data privacy from artificial intelligence. Specifically, organizations can use it to “ensure that organizational privacy values are reflected in the development and use of AI systems,” the PFW draft reads.

NIST first published the PFW in 2020, with the goal of helping organizations mitigate the privacy risks associated with the processing of personal data in their computer systems. It outlines five core functions:

• Identify, which includes inventorying the organization’s data-processing scenarios and conducting privacy risk assessments
• Govern, which involves the creation and adoption of the organization’s governance structure for data privacy
• Control, which addresses the organization’s development and implementation of appropriate data-management activities
• Communicate, which includes sharing publicly how the organization processes personal data and manages privacy risks
• Protect, which touches on the organization’s data security processes aimed at preventing cyber breaches

The PFW 1.1 draft is open for public comment until June 13, 2025. NIST plans to publish a final version later this year.

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

• “What Makes This “Data Privacy Day” Different?” (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)
• “The Data-Factor: Why Integrating DSPM Is Key to Your CNAPP Strategy” (blog)
• “Data Security in Healthcare: How Tenable Cloud Security Can Help” (blog)

2 - GenAI code-generation hallucinations open the door for package-confusion attacks 

Here’s a warning for developers who use generative AI to write code: Generative AI tools may prompt you to download software packages that are infected with malware.

That’s the main finding from the study “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” by researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech.

How can this happen? When prompted to write code, generative AI tools powered by large language models (LLMs) often suggest that developers download software packages from public repositories.

However, in many cases, the software packages the generative AI tools mention don’t exist. The tools invent names for non-existent software packages and falsely say the packages are located in specific software repositories.

Best case scenario is that the developer goes looking for the imagined software package and doesn’t find it. Unfortunately, cyberattackers are taking note. They’re baptizing their malicious packages with the made-up names and storing them in repositories, hoping developers will inadvertently download them thinking they’re legit. 

 

“These hallucinations, which arise from fact-conflicting errors when generating code using LLMs, represent a novel form of package confusion attack that poses a critical threat to the integrity of the software supply chain,” the researchers wrote.

The researchers generated 576,000 code samples in Python and JavaScript using 16 generative AI tools and two unique prompt datasets. Here are some key findings:

• The incidence of package hallucination was an average of 5.2% for commercial tools and 21.7% for open-source tools.
• The tools generated about 205,000 unique hallucinated package names.

“Our experiments and findings highlight package hallucinations as a persistent and systemic phenomenon while using state-of-the-art LLMs for code generation, and a significant challenge which deserves the research community’s urgent attention,” the researchers wrote.

The researchers also tested several mitigation techniques that helped reduce the incidence of software-package hallucinations, including retrieval augmented generation; self refinement; and fine tuning.

For more information about AI security and the risks of using generative AI for writing code:

• “Cybersecurity Risks of AIGenerated Code” (Georgetown University)
• “AI-generated code risks: What CISOs need to know” (ITPro)
• “The risks of AI-generated code are real — here’s how enterprises can manage the risk” (Venturebeat)
• “Gen AI could speed up coding, but businesses should still consider risks” (ZDNet)
• “AI coding agents come with legal risk” (CIO)

3 - Tenable polls webinar attendees on identity security

During our recent webinar “Three Reasons Why It's Time to Embrace Identity as Part of Exposure Management,” we polled attendees about identity security topics, such as their ability to correlate identity incidents with broader attack paths. Check out what they said.

(119 webinar attendees polled by Tenable, March 2025)

(110 webinar attendees polled by Tenable, March 2025)

(144 webinar attendees polled by Tenable, March 2025)

Check out this on-demand webinar to learn how you can adopt a more proactive identity security strategy as part of your exposure management program. 

4 - Canada’s cyber agency warns about spike in router hacking 

Nation-state attackers associated with China’s government, including the cyber espionage group Salt Typhoon, are ramping up attacks on network edge routers of critical infrastructure organizations.

The Canadian Centre for Cyber Security issued the warning this week via an advisory titled “People’s Republic of China activity targeting network edge routers: Observations and mitigation strategies” which details the threat and offers mitigation recommendations.

Compromised network edge routers can allow attackers to breach a network and then monitor, modify, and exfiltrate network traffic, and even move deeper into the victim’s network, according to the advisory.

A key insight: The attackers are feasting on low-hanging fruit -- misconfigured and unpatched routing devices. The best and simplest prevention? Patch these products as soon as possible.

 

“Threat actors often compromise network perimeter defenses by exploiting known vulnerabilities in edge devices. These security weaknesses are usually already identified, and patches are available to fix them. However, breaches occur because these patches are not consistently applied or implemented in a timely manner,” the advisory reads.

The Cyber Centre has also observed router compromises stemming from basic security mistakes, such as the use of default and weak passwords, and of default security settings.

Other mitigation recommendations include:

• Disable unnecessary network edge services, especially unsecured ones such as HTTP.
• Remove direct internet access to device management interfaces, restricting admins to internal and secure management networks.
• Protect all administrative access with phishing-resistant multi-factor authentication.
• Use modern encryption standards.
• Keep firmware updated.
• Adopt secure, centralized logging, encrypt logging traffic and store logs offsite.

For more information about Salt Typhoon:

• “Salt Typhoon: An Analysis of Vulnerabilities Exploited by this State-Sponsored Actor” (Tenable)
• “China’s Salt Typhoon Spies Are Still Hacking Telecoms—Now by Exploiting Cisco Routers” (Wired)
• “New CISA Hardening Guidance Provides Valuable Insights for Network Security Engineers” (Tenable)
• “What Should the US Do About Salt Typhoon?” (Dark Reading)
• “What is Salt Typhoon? A security expert explains the Chinese hackers and their attack on US telecommunications networks” (The Conversation)

5 - CVE program renewed for one year, but questions about its future linger

A collective gasp was heard around the cybersecurity world on Tuesday, when news broke that the MITRE Common Vulnerabilities and Exposures (CVE) program might be in imminent danger of shutting down.

Fortunately, this scenario didn’t materialize, after the U.S. Cybersecurity and Infrastructure Security Agency (CISA) came to the rescue and extended the program’s funding for one year just as it was set to expire.
 

Naturally, concerns remain about the MITRE CVE program and the critical services it provides, given the close call it experienced and the limited one-year extension it obtained.

Speaking to The Wall Street Journal, Tenable Chief Security Officer and Head of Research Bob Huber said efforts to reform the CVE program will likely yield a public-private partnership of some sort. 

“Most of the companies that operate in this place are well-known amongst each other, as are the people responsible for those programs. I think there’s an opportunity here to improve that partnership and spread the responsibility,” Huber told the Journal.

As of the end of 2024, the CVE program had published more than 250,000 CVEs. Launched in 1999, the CVE program provides a foundational, common taxonomy for tracking vulnerabilities and exposures.

To get all the details and insights about this issue, check out these two Tenable blogs:

• “MITRE CVE Program Funding Extended For One Year”
• “Frequently Asked Questions About the MITRE CVE Program Expiration and Renewal”

Concerns about the future of the MITRE CVE Program continue to circulate. The Tenable Security Response Team has created this FAQ to help provide clarity and context around this developing situation.

Background

The Tenable Security Response Team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding changes around the MITRE CVE Program. As the situation continues to evolve, we will continue to provide updates as new information is released.

FAQ

What is the current status of the MITRE CVE Program?

As of April 16, 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has extended funding for the MITRE CVE Program for one year. In a post and update to their website, CISA confirmed the extension, and a spokesperson added that they “executed the option period on the contract to ensure there will be no lapse in critical CVE services.”

pic.twitter.com/DYv4uKzLrq

— Cybersecurity and Infrastructure Security Agency (@CISAgov) April 16, 2025

When did CVE Board Members find out about the expiration of the MITRE CVE Program and other related programs?

CVE Board members received a notification from MITRE on April 15, 2025. This notification was circulated on social media and picked up in news articles. Tenable published a blog post about the forthcoming expiration and updated it on April 16 upon news of the subsequent renewal.

What is the importance of the CVE Program?

The CVE Program provides the industry with a common identifier used for identifying vulnerabilities which in turn allows the industry to fully track all affected products, remediations, tactics, techniques and procedures (TTPs) and risk measurements for a vulnerability. Without this we run the risk of being unable to accurately map active exploitation and associated risk to that vulnerability.

One important function that the CVE program serves is to operate as a CVE Naming Authority (CNA) of last resort, particularly when there are disputes over CVE issuance. This helps to minimize conflicting reports and duplicate records.

What is the value of having a CVE Naming Authority (CNA)?

The CVE Program enables various entities to become a CNA. The CNA program allows vendors, researchers, open source developers and others to reserve and assign CVEs while providing information about a vulnerability. Currently there are over 450 CNAs that participate in the CVE Program.

What is Tenable’s relationship with the CVE Program?

Tenable is a CNA within the CVE Program and, as such, issues CVEs for its own products and vulnerabilities in other products discovered by its research team for which there is no CNA.

What about the announcements of efforts from the CVE Foundation and GCVE?

On the morning of April 16, 2025, the CVE Foundation published a press release regarding an effort for transitioning the CVE program to a non-profit foundation established by active CVE Board members. The CVE Foundation aims to move the CVE Program away from a government-funded project to eliminate the risk of “a single point of failure in the vulnerability management ecosystem.”

Additionally, we are aware of other efforts being launched, including the Global CVE (GCVE) allocation system by the Computer Incident Response Center Luxembourg (CIRCL). According to their FAQ, GCVE is a “decentralized system for identifying and numbering security vulnerabilities.” The GCVE site notes that existing CNAs can become GCVE Numbering Authorities (GNAs) and would have autonomy to define their own policies for the identification of vulnerabilities.

Tenable will continue to monitor these evolving efforts surrounding CVE and other programs and update the community as we learn more.

How is Tenable impacted by the interruptions to CVE issuance at both MITRE and the National Vulnerability Database (NVD)?

With uncertainty around interruptions to the CVE Program, Tenable has reserved a sufficient number of CVEs for disclosing vulnerabilities in our products and those discovered in other products.

Tenable is not dependent on either MITRE or NVD for sourcing the logic needed to determine if a product is vulnerable or not. We source our coverage from vendor advisories, which will enable us to continue providing coverage as long as vendors publish security advisories.

Get more information

• Tenable Blog: MITRE CVE Program Funding Extended For One Year
• Tenable Blog: Recent NVD Delays Won’t Affect Tenable Vulnerability Management Customers Thanks To Our Diverse Scoring Sources
• CVE Foundation
• Global CVE Allocation System (GCVE)

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Oracle addresses 171 CVEs in its second quarterly update of 2025 with 378 patches, including 40 critical updates.

Background

On April 15, Oracle released its Critical Patch Update (CPU) for April 2025, the second quarterly update of the year. This CPU contains fixes for 171 unique CVEs in 378 security updates across 32 Oracle product families. Out of the 378 security updates published this quarter, 10.6% of patches were assigned a critical severity. Medium severity patches accounted for the bulk of security patches at 54.5%, followed by high severity patches at 32.3%.

This quarter’s update includes 40 critical patches across 15 CVEs.

SeverityIssues PatchedCVEsCritical4015High12252Medium20698Low106Total378171Analysis

This quarter, the Oracle SQL Developer product family contained the highest number of patches at 103, accounting for 27.3% of the total patches, followed by Oracle Hyperion at 43 patches, which accounted for 11.4% of the total patches.

A full breakdown of the patches for this quarter can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Oracle Product FamilyNumber of PatchesRemote Exploit without AuthOracle SQL Developer10382Oracle Hyperion432Oracle Secure Backup4235Oracle Communications3422Oracle E-Business Suite3126Oracle Commerce1611Oracle Enterprise Manager1511Oracle JD Edwards1111Oracle Hospitality Applications85Oracle Database Server73Oracle TimesTen In-Memory Database76Oracle REST Data Services65Oracle Analytics65Oracle Essbase42Oracle Communications Applications44Oracle Insurance Applications41Oracle MySQL42Oracle Policy Automation44Oracle Construction and Engineering32Oracle Financial Services Applications32Oracle Food and Beverage Applications32Oracle Java SE33Oracle PeopleSoft32Oracle Supply Chain30Oracle NoSQL Database22Oracle Retail Applications20Oracle Siebel CRM22Oracle Application Express11Oracle Autonomous Health Framework10Oracle GoldenGate11Oracle Graph Server and Client10Oracle Fusion Middleware11Solution

Customers are advised to apply all relevant patches in this quarter’s CPU. Please refer to the April 2025 advisory for full details.

Identifying affected systems

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released. This link uses a search filter to ensure that all matching plugin coverage will appear as it is released.

Get more information

• Oracle Critical Patch Update Advisory - April 2025
• Oracle April 2025 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

MITRE’s CVE program has been an important pillar in cybersecurity for over two decades. While CISA secured funding on April 16 to extend the program for the next year, the lack of clarity surrounding its long-term future creates great uncertainty about how newly discovered vulnerabilities will be cataloged.

Updated Apr 16, 2025: The Cybersecurity and Infrastructure Security Agency (CISA) has stepped in to secure funding for the next year and ensure there will be no lapse in critical CVE services. Additionally, a coalition of CVE Board members have launched the CVE Foundation, a non-profit organization intending to maintain stability and independence of the CVE program.

Background

On April 15, reports circulated that the contract for funding the Common Vulnerabilities and Exposures (CVE) program along with other related programs, such as Common Weakness Enumeration (CWE), would be expiring on April 16. The letter below was sent to CVE Board Members and published on social media and other forums announcing the expiration of these programs:

The legitimacy of this letter and its contents was confirmed by cybersecurity journalist Brian Krebs in a post on Mastodon. Tenable has also independently confirmed the letter’s legitimacy.

CVE program importance

While flawed in some ways, the CVE program, which recently celebrated its 25th anniversary, has been an important pillar in cybersecurity for over two decades. It provides a common taxonomy for cybersecurity solutions and organizations to track vulnerabilities and exposures. Since its launch in 1999, the CVE program has published over 250,000 CVEs as of the end of 2024.

Risk to CVE program

With the report that the funding for the CVE program is potentially set to expire on April 16, the biggest concern stems from the fact that CVE Numbering Authorities, or CNAs, will no longer be able to reserve and assign CVEs for newly discovered vulnerabilities. While CNAs typically try to reserve a block of CVEs, the lack of transparency surrounding the future of the CVE program creates uncertainty surrounding newly discovered vulnerabilities. The historical CVE database will remain intact on GitHub following the expiration of the CVE program. However, MITRE’s CVE program also provides a centralized repository of CVEs from which many organizations fetch data and this may disappear. The lack of this centralized repository will create difficulties going forward for tracking new and noteworthy vulnerabilities under a common identifier.

Tenable’s response to the potential expiration of the MITRE CVE program

Tenable is closely monitoring the situation surrounding the possible expiration of the CVE program funding.

Last year, when we learned about NIST’s National Vulnerability Database (NVD) experiencing delays surrounding analysis efforts, we highlighted that Tenable Vulnerability Management products utilize a diverse range of sources for CVSS scoring and our customers experienced little to no impact.

As a provider of vulnerability scanning technology, we are not dependent on the CVE program directly for our vulnerability coverage. We develop our vulnerability coverage against vendor advisories directly, and will continue to do so, so long as vendors make those advisories available whether they contain CVE identifiers or not. Tenable also provides its customers with a richly sourced and curated Vulnerability Intelligence feed that provides contextualized information for any given vulnerability, regardless of a CVE assignment or not.

Tenable is a CNA, and we allocate CVEs for our vulnerability disclosures through our Tenable Research Advisories page. We also have reserved a large number of CVE designators for disclosures to ensure the cybersecurity community has clear identity for future discovered vulnerabilities.

As new developments surrounding the CVE program emerge, we will update this blog post accordingly.

Get more information

• MITRE Warns CVE Program Faces Disruption Amid US Funding Uncertainty

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, we feature the first Exposure Management Academy FAQ. We’ll run these FAQs from time to time to share some of the most common questions we receive about exposure management. You can read the entire Exposure Management Academy series here.

By Team Tenable

Here at the Exposure Management Academy, we get questions all the time. So we’re inaugurating an occasional FAQ series this week with an up-close look at exposure management itself, the role of AI in exposure management and how cyber exposure management and cloud security work together. In future FAQs, we’ll cover a range of topics. Stay tuned. 

What is exposure management?

It’s the essential question that always comes first: Just what is exposure management? In our first Exposure Management Academy post we covered what exposure management is and why it matters in depth. 

But for this FAQ, we’ll keep it short. Exposure management gives teams visibility and context across the modern attack surface so they can separate the actual exposures that can have a material impact on the business from all the noise. This means that your team can minimize churn and help prevent breaches by closing the exposures (or toxic risk combinations) attackers exploit before attacks get underway.

As the natural evolution of vulnerability management, exposure management extends visibility to include all preventable risks across the attack surface: Common Vulnerabilities and Exposures, misconfigurations, excessive permissions and all asset types — multi-cloud, IT, OT, IoT, identities, applications, containers, as well as unseen and unmanaged assets. 

Unlike traditional security prioritization approaches, exposure management requires a mindset shift. Not all risk is created equal and not every risk needs to be addressed instantly. Instead, exposure management combines threat intelligence, such as accessibility and exploitability of risks, with technical and business context, including attack paths leading to crown jewels, to prioritize remediation of toxic risk that is most likely to have an impact on your organization.

How does exposure management use AI?

At the heart of exposure management is the need to unify visibility, insight and action across traditionally siloed tools, processes and staff. Solving this challenge requires more than just aggregation of data in a central repository. 

Artificial intelligence plays a critical role in exposure management by deduplicating, correlating and normalizing asset and risk data across typically siloed tools and technologies. It maps the complex data relationships needed to identify and visualize toxic risk combinations and attack paths, which prioritizes business-impacting exposures. Plus, it enriches decision making with additional context, such as threat intelligence and MITRE techniques, to provide the remediation guidance needed to quickly and effectively mobilize teams.

Exposure management platforms typically put an array of AI flavors to work, including generative artificial intelligence, deep learning, AI and machine learning to fuel its capabilities. They help improve end-user productivity and enable preventive security in three ways:

• Help explain: AI can provide succinct guidance so you can better understand product findings.
• Conduct a search: AI can simplify searching across your asset inventory, which provides complete visibility.
• Take action: AI can proactively give you insights for actions that will have the most impact on your exposures.

Exposure management platforms also offer a wide range of assessment methods that surface AI software packages, libraries and browser plugins. This capability helps you to see unauthorized AI usage, detect AI vulnerabilities and gain clarity on AI development occurring within your organization.

For Tenable, AI is integral to the functionality of the Tenable One Exposure Management Platform. Below are some examples of how we put AI to work in the product to solve other complex challenges, such as:

• Identifying vulnerabilities that attackers are likely to exploit in the short term: Machine learning-based algorithms power our Vulnerability Priority Rating (VPR). By analyzing each vulnerability regularly to determine how likely it is that an exploit could be used against it, VPR provides a score you can use to prioritize your remediation efforts.
• Predicting the operating system (OS) of an unauthenticated asset: Machine learning-based algorithms enable Tenable to use host response to TCP packet data to predict the OS of an unauthenticated asset. This increases vulnerability assessment and inventory accuracy.
• Improving the efficiency and effectiveness of common processes: Generative AI-based research tools improve the efficiency and effectiveness of processes like reverse engineering, code debugging, web app security and visibility into cloud-based tools.
• Achieving a unified view of privileges: AI-based methods deliver a holistic view of all user identities and entitlement risks, including on-premises and cloud environments.

Is exposure management cloud-based?

Yes, you should expect an exposure management solution to be cloud-based for some very strategic reasons. 

First, exposure management requires continuous assessment of the threat landscape and dynamically changing environments, such as containers and Kubernetes. That calls for a highly scalable data platform with the storage and compute power necessary to process trillions of unique asset, identity, risk and threat data points.

Exposure management platforms often collect data through API integrations with existing point security tools that are usually cloud-based, including cloud security posture management, external attack surface management, vulnerability management, identity and access management, endpoint detection and response/extended detection and response, configuration management database and cloud infrastructure and entitlement management. These integrations are far easier, faster and more robust when the platform itself is cloud-native and API-first.

In addition, exposure management requires advanced relationship mapping and analysis, such as attack path modeling, machine learning for prioritization and AI-generated remediation guidance. These compute-heavy tasks are best handled in cloud environments built for data science and real-time inference.

Organizations can deploy a SaaS-based exposure management platform in days rather than months and quickly deliver continuous improvements. It also enables continuous delivery of new capabilities, such as new risk models, threat intelligence and exposure logic.

Have a question about exposure management you’d like us to tackle?

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);

If it feels like your entire cybersecurity program is once again operating on a geopolitical fault line, you're not imagining things.

The intersection of global politics and cybersecurity has grown a whole lot messier — and more consequential — in recent weeks. With the current U.S. Administration turning up the heat on China through aggressive tariffs and foreign policy pressure, the ripple effects on cybersecurity are no longer hypothetical. They’re here. And they’re accelerating.

Trade wars mean cyber wars

Let’s start with the obvious: the U.S.-China trade war. After the administration slapped 145% tariffs on key Chinese imports, Beijing didn’t just fume — they likely leveraged their extensive access to our infrastructure. Literally. According to a recent Wall Street Journal report, Chinese officials quietly acknowledged involvement in attacks on U.S. critical infrastructure. The message? Cyber is the battlefield.

Cybersecurity advisor and author Tom Kellermann has said that attacks by the Chinese state-backed Salt Typhoon and Volt Typhoon operations have enabled infiltration of U.S. critical infrastructure. These intrusions could be leveraged today for intelligence in these times of escalating tensions as well as tomorrow for more destructive attacks if relations truly deteriorate. 

And increases in cyber activity exploiting U.S. tariff policies have been noted by BforeAI CEO Luigi Lenguito in the last few weeks, with criminals already engaging in invoice fraud and other scams involving shipping company impersonation.

This isn’t just state-on-state stuff. The private sector is feeling the pressure. A growing number of threat analysts are flagging a rise in industrial espionage and IP theft attempts, particularly targeting sectors tied to strategic national interests — energy, tech and semiconductors.

The private sector is carrying more of the cyber defense load

With the federal government currently reevaluating roles, budgets and security clearances across key cybersecurity agencies, more of the frontline burden is shifting to the private sector. This transition is happening just as geopolitical tensions are driving up the volume and sophistication of attacks.

Critical industries — like energy, finance, healthcare and manufacturing — are increasingly being targeted by state-aligned threat actors. These organizations are expected to maintain operational readiness, detect threats, and respond quickly.

For cybersecurity professionals, this shift means greater responsibility, higher stakes and a growing need for clarity around real risk. Now more than ever, visibility and proactive defense strategies are essential. Preventing an attack is so much more important, and actually cheaper, than cleaning up in the aftermath.

Your vendors are feeling it, too

The entire security ecosystem is absorbing the shockwaves from rapidly changing economic policy. Tariffs on Chinese-made chips and components are complicating hardware supply chains and raising costs across the board. Some cybersecurity vendors are bracing for delays and price hikes, which could mean you’re waiting longer (and paying more) for upgrades to critical infrastructure.

And yet — despite all of this — some U.S. companies are doubling down on their ties with China. A recent survey conducted by the U.S. Chamber of Commerce found that 70% of firms who responded plan to maintain or even increase engagement.

What you should be watching (and doing)

So, what does this mean for those of us on the front lines of cyber defense? Here are some recommendations for moving forward in these conflicted times:

• Build geopolitical risk into your threat models. These tensions aren’t going away — they’re now part of the everyday threat landscape.
• Pressure-test your supply chain visibility. Tariff-driven changes could leave you exposed to unvetted tech or delays that weaken your defenses.
• Track policy shifts like you would threat intel. What’s happening in Washington and abroad is directly shaping your risk profile. Avoid operational paralysis associated with government changes and instead double down on security to thwart learned helplessness.
• Advocate for the resources you need. If your leadership is second-guessing security investments, the headlines are your best argument.
• Routinely assess your posture management. The threat from both nation-state and cybercriminals will only increase over the next six to 12 months. Periodically measure your exposure to attack using a proven cybersecurity framework and tooling that measures compliance to the listed security controls.
• Take a proactive stance. Don’t wait for an alert to tell you something’s wrong. Implement an exposure management program to help you understand your real risk before attackers do, so you can take action before exposures become breaches.

Cybersecurity efforts are often reactive — teams scramble to respond to new cyber threats as they arise. In today’s world, reactive security is not only inadequate; it’s irresponsible, and it puts national security at risk. A proactive approach is what’s needed in these turbulent times. One in which organizations use accurate assessment of real-world risks to address the most critical vulnerabilities, misconfigurations and overprivileged identities before they can be used in an attack. The more unstable the geopolitical climate, the more essential it is to proactively reduce your organization’s exposure and bolster its proactive defenses.

Check out why a global geopolitical spyware campaign could ensnare mobile users outside of its target groups. Plus, the U.K.’s cyber agency offers cyber governance resources to boards of directors. Also, find out what webinar attendees told Tenable about using port scanning and service discovery to detect attack paths. And much more!

Dive into five things that are top of mind for the week ending April 11.

1 - Alert: Mobile spyware campaign could spill beyond targeted victims

Attackers are spreading two spyware variants in an attempt to infect mobile devices of individuals and groups tied to causes that the Chinese government opposes. 

However, all mobile users should take heed because the campaign is global and aggressive, meaning anyone could become a victim.

So said cyber agencies from Australia, Canada, Germany, New Zealand and the U.S. in joint advisories this week, outlining how attackers are targeting supporters of various China-related movements with the BadBazaar and Moonshine spyware variants.

“The indiscriminate way this spyware is spread online also means there is a risk that infections could spread beyond intended victims,” reads one advisory. 

Those targeted include journalists, non-governmental organizations, businesses and representatives of groups associated with:

• Taiwanese independence
• Tibetan rights
• Uyghur Muslims
• Hong Kong democracy advocacy
• Falun Gong movement

 

 

Moonshine and BadBazaar are two types of trojan malware, meaning attackers hide them in legit-looking mobile applications that users voluntarily download. In this particular campaign, attackers are embedding Moonshine and BadBazaar in applications designed to appeal to the intended victims, such as a Uyghur keyboard app and a Tibet-related app.

Once a user inadvertently installs a malicious app, attackers use it to obtain the mobile device’s location data in real-time; access its microphone and camera; retrieve stored messages and photos; and more.

 The cyber agencies’ mitigation recommendations include:

• Don’t root or jailbreak your mobile device, as this leaves it more vulnerable to cyber attacks.
• Only download apps from trusted app stores like those from Google and Apple.
• Periodically review your installed apps and their permissions, deleting apps you no longer use and restricting excessive permissions.
• Be careful with links, files and apps shared on social media sites, online forums and messaging tools. Scan links with a URL reputation service before clicking on them, and upload suspicious files or apps to a malware analyzer.

The advisories mention a Chinese IT services firm with ties to China’s government as being possibly linked to the spyware campaign. However, the Chinese Embassy in Washington, D.C. told the Reuters news agency that the Chinese government isn’t involved in this situation.

To get more information, check out these resources from the U.K. National Cyber Security Centre (NCSC):

• The announcement “NCSC and partners share guidance for communities at high risk of digital surveillance”
• The advisory “BadBazaar and Moonshine: Spyware targeting Uyghur, Taiwanese and Tibetan groups and civil society actors”
• The technical advisory “BadBazaar and Moonshine: Technical analysis and mitigations”

For more information about protecting mobile devices against spyware attacks:

• “How to find and remove spyware from your phone” (ZDNet)
• “Did you know a VPN can protect you from spyware? Here's how” (Yahoo Tech)
• “Your Android phone could have stalkerware — here’s how to remove it” (TechCrunch)
• “Apple: Mercenary spyware attacks target iPhone users in 92 countries” (BleepingComputer)
• “Why rebooting your phone daily is your best defense against zero-click attacks” (ZDNet)

2 - NCSC offers cyber governance resources for corporate boards

With cybersecurity governance now one of their main responsibilities, boards of directors need strong cybersecurity knowledge – but many are lacking in this area.

That’s why the U.K. National Cyber Security Centre this week published a package of cyber governance resources for board members.

“From my experience of working with senior leaders across private and public sectors, I know that strong cyber governance is key to resilience, growth, and long-term success. Board members play a vital role in making this happen,” NCSC CEO Richard Horne wrote in a blog.

 

 

The NCSC cyber governance resources for board members include:

• The “Cyber Governance Code of Practice,” which outlines the board’s responsibilities in these five key governance areas:
   
  • Risk management
  • Strategy
  • People
  • Incident planning, response and recovery
  • Assurance and oversight
     
• The “Cyber Governance Training” document, which provides five interactive training modules, each focusing on one of the “Code of Practice” principles
   
• The “Cyber Security Toolkit for Boards,” which explains how to implement the five key cyber governance areas
  
  For example, for risk management the toolkit unpacks how to identify the organization’s critical assets and how to collaborate with its supply chain partners. In the strategy area, it goes into how to embed cybersecurity into the organization and what cybersecurity regulations are relevant to boards.

For more information about cyber governance guidance for boards of directors:

• “Principles for Board Governance of Cyber Risk” (Harvard Law School)
• “NACD Director's Handbook on Cyber-Risk Oversight” (National Association of Corporate Directors)
• “A cybersecurity guide for board directors” (Corporate Governance Institute)
• “How boards can effectively oversee AI to drive value and responsible use” (PwC)
• “Guidelines on the Corporate Governance of Cybersecurity” (Board Foundation)

3 - Tenable poll looks at port scanning for attack path detection

During a recent webinar about Tenable Nessus, we polled attendees about their use of port scanning and service discovery to detect attack paths. Check out what they said.

(65 webinar attendees polled by Tenable, April 2025 – Respondents could choose more than one answer.)

(75 webinar attendees polled by Tenable, April 2025)

(76 webinar attendees polled by Tenable, April 2025)

Watch the full “Nessus Customer Update, April 2025” webinar on-demand to learn what’s new and coming soon in Nessus, and to get more details about identifying attack paths using port scanning and service discovery.

4 - Report: Fewer U.K. businesses hit by cyber attacks, but challenges persist

The percentage of U.K. businesses that suffered a cyber breach or attack dropped to 43% last year from 50% in 2023, but the cybersecurity challenges they face remain daunting.

That’s the main takeaway from the U.K. government’s “Cyber Security Breaches Survey 2025,” which in addition to businesses also surveyed charities and educational institutions. 

“The 2025 survey emphasises that while progress is being made in certain areas, evolving threats like phishing and ransomware, and disparities between different types of organisations highlight persistent vulnerabilities,” reads the report, which was published this week.

Key findings from the report include:

• Phishing remains by far the most prevalent type of breach or attack, suffered by 85% of businesses.
• Among small businesses, the adoption of cyber hygiene practices increased, including cyber risk assessments; business continuity plans; and formal cyber policies.
• Basic cyber controls are in place in the majority of businesses, including malware protection; password policies; network firewalls; and resticted admin rights.
• Adoption of advanced controls remains low, including multi-factor authentication (40%); VPNs for remote access (31%); and user monitoring (30%).
• Management of supply chain risks is extremely low, with only 14% of businesses assessing risks from direct suppliers and only 7% doing so for their entire supply chain.

For more information about phishing protection:

• “How To Recognize and Avoid Phishing Scams” (U.S. Federal Trade Commission)
• “How to defend your organisation from email phishing attacks” (NCSC)
• “How AI is making phishing attacks more dangerous” (TechTarget)
• “Teach Employees to Avoid Phishing” (U.S. Cybersecurity and Infrastructure Security Agency)
• “Top 10 tips for employees to prevent phishing attacks” (TechTarget)

5 - CIS updates Benchmarks for Apple, Microsoft, Cisco products

Apple macOS, Microsoft Windows 11 Enterprise and Cisco NX-OS are some of the products whose Center for Internet Security (CIS) Benchmarks got an update in March.

Specifically, these secure-configuration recommendations were updated:

• CIS Amazon Web Services Foundations Benchmark v5.0.0
• CIS Apple macOS 12.0 Monterey Cloud-tailored Benchmark v1.1.0
• CIS Apple macOS 15.0 Sequoia Cloud-tailored Benchmark v1.1.0
• CIS Cisco NX-OS Benchmark v1.2.0
• CIS Kubernetes Benchmark v1.11.0
• CIS Microsoft Azure Foundations Benchmark v4.0.0
• CIS Microsoft Windows 11 Enterprise Benchmark v4.0.0
• CIS Ubuntu Linux 20.04 LTS Benchmark v3.0.0
• CIS VMware ESXi 8.0 Benchmark v1.2.0

 

In addition, CIS released these two brand new Benchmarks: 

• CIS Microsoft Windows Server 2025 Benchmark v1.0.0
• CIS Oracle Database 23ai Benchmark v1.0.0

The CIS Benchmarks are secure-configuration guidelines designed to help organizations harden products against cyber attacks. CIS offers 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 April 2025 Update.”

For more information about the CIS Benchmarks list, check out its home page, 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)