Security Boulevard

via the comic humor & dry wit of Randall Munroe, creator of XKCD

Permalink

The post Randall Munroe’s XKCD ‘Chess Zoo’ appeared first on Security Boulevard.

Don’t Mess With Texas Privacy: “We will hold all these companies accountable,” rants state attorney general Ken Paxton (pictured).

The post Allstate Violates Drivers’ Privacy, Texas AG Alleges appeared first on Security Boulevard.

Intune Attack Paths — Part 1 Prior Work

Several people have recently produced high-quality work around Intune tradecraft. I want to specifically mention:

• Chris Thompson and his work on Maestro
• Dirk-jan Mollema and his work with Primary Refresh Tokens
• Adam Chester and his work with Web Account Manager
• Brett Hawkins and his work with Intune lateral movement detection
• Thibault Van Geluwe de Berlaere, Karl Madden, and Corné de Jong, and their work on abusing MS Graph permissions against Intune
• Dr. Nestori Syynimaa and his work around Bypassing Conditional Access by faking device compliance
• Rudy Ooms and his work with decrypting Intune traffic

What is Intune?

Intune is a Microsoft service that administrators can use for endpoint management. Microsoft appears to be investing most of its efforts into pushing administrators towards Intune and away from other endpoint management systems such as SCCM.

Intune isn’t universal… yet.

Intune adoption appears to be far from universal — admins are still widely using “legacy” endpoint management systems such as Group Policy and SCCM; however, with Microsoft pushing its customers towards Intune, we expect Intune adoption to accelerate in the coming years and for Intune tradecraft to become more relevant.

Intune is an attractive system for adversaries to target, as it is an authorized system capable of performing the most highly privileged actions on endpoints, such as running arbitrary commands and applications as the NT AUTHORITY\SYSTEM principal.

Intune Trust Boundary

Intune is an Azure service and requires an existing Entra tenant for admins to use it. Only one Intune instance can be associated with each Entra tenant. Intune instances can not be associated with more than one Entra tenant.

Two roles in the Entra tenant grant full control of an Intune instance:

• Global Administrator
• Intune Administrator

There is also a distinct authorization system within the Intune service with its own roles and mechanics.

Because the Intune service must be associated with precisely one Entra tenant, and because Entra’s authorization system grants full control of the Intune instance, the trust boundary around an Intune instance is established and enforced by the Entra tenant:

Intune Devices vs. Entra Devices

The Intune service refers to managed endpoints as “devices.” This is the same word Entra uses when describing endpoints. Intune Devices are typically endpoints that are registered or joined to the Entra tenant, but this is not a hard requirement. It is possible to manage an endpoint in Intune while that endpoint is not registered or joined to an Entra tenant.

Because of this, Intune Devices are distinct objects from Entra Devices. They are accessed and managed with a distinct API and they have universally unique identifiers that are distinct from Entra Devices:

We can determine when an Intune Device is the same endpoint as an Entra Device by comparing two fields:

1. The deviceId field on Entra Devices
2. The azureADDeviceId field on Intune Devices

In this example, we can see that the two devices are, in fact, the same endpoint:

An Intune Device may represent the same endpoint as an Entra Device; furthermore, both of these objects may also represent an on-premises Active Directory joined computer. When that is the case, the on-premises AD computer’s LDAP object will have the same value for its objectGUID property:

This is one endpoint represented across three systems with three distinct objects.

Intune RBAC vs. Entra RBAC vs. MS Graph

Intune has its own role-based access control (RBAC) system that is distinct from the Entra ID RBAC system, but the Intune service is also subject to Entra RBAC — an Entra Global Admin has full control of the Intune instance. Intune is accessed via the MS Graph API and there are several relevant MS Graph permissions that can control access to the Intune instance as well.

Intune RBAC — Role Assignments

The Intune RBAC system is very similar to the Entra RBAC system in that it is based on role definitions, role assignments, permissions, and scopes.

The first material difference of note is that Intune roles must be assigned to groups. While it is possible to create an Intune role assignment for a user, the system will not respect this configuration. Intune role assignments only work when assigned to groups, while Entra roles work when assigned to any principal type:

Intune RBAC — Permissions

Intune permissions (more accurately called Resource Operations) enable specific actions against specific Intune object classes. Intune permissions are formatted as:

Microsoft.<ServiceName>_<ObjectClass>_<Action>

All Intune permissions have “Intune” as the service name.

An example Intune permission is:

Microsoft.Intune_DeviceConfigurations_Create

This permission enables a principal to Create new Intune objects called DeviceConfigurations. This is a powerful permission that enables remote code execution on Intune-managed endpoints.

At time of writing, Intune has 239 distinct permissions, there does not appear to be an online resource listing all of these permissions, and MS Graph serves them at the /deviceManagement/resourceOperations API endpoint. BARK’s Get-IntuneResourceOperations hits that endpoint to list all Intune permissions.

Intune RBAC — Scope Groups

Intune’s RBAC system supports limiting role assignments to particular sets of endpoints. The mechanism for this is called Scope Groups. Scope Groups are Entra ID security groups. The default (and most common) configuration is to use a virtual scope group called allDevicesAndLicensedUsers. This scope group value means the role assignment will enable the principal to perform actions against all devices in the Intune instance.

Scope Groups may be used to limit which devices a principal can control when granted a role assignment. For example, the Entra group called “Seattle Admins” may have an Intune role assignment for the built-in role called “School Administrator”:

If the Intune admin wants to limit this role assignment to only granting control of devices in Seattle, they may create a new Entra group called “Seattle Devices” and then add the relevant Entra Devices (not the Intune Devices) to that group.

Recall from earlier that Entra devices and Intune devices that represent the same endpoint share a common property value that ties the objects to the same host.

Putting this all together, we can visualize the above configuration as such:

The one piece that is missing is the inclusion of the Scope Group configuration within the role assignment itself. Let’s add that in:

This configuration means that the “Seattle Admins” group will have all permissions granted by the “School Administrator” role, but only for those devices that belong to the groups listed in the “scopeGroups” attribute of the role assignment. The “Seattle Admins” group gains control of the Intune Device due to this configuration:

There may be other Intune devices in this instance, but if those devices are not added to the “Seattle Devices” group, then this configuration means the “Seattle Admins” group does not gain control of those other devices:

If an Entra Device that is associated with an Intune Device is added to the “Seattle Devices” group, then the “School Admins” group will gain control of that device:

If the “scopeGroups” property on the role assignment is changed to allDevicesAndLicensedUsers, then the “Seattle Admins” group will gain control of all Intune-managed devices within the Intune instance:

Intune RBAC — Scope Tags

The Microsoft documentation about scope tags begins with this paragraph:

You can use RBAC and scope tags to make sure that the right admins have the correct access and visibility to the required Intune objects. Roles determine what access admins have to which objects. Scope tags determine which objects admins can see.

Scope Tags limit visibility, they do not limit access.

Scope Tags are a distinct class of Intune object. They are referenced on most Intune objects including roles, role assignments, applications, and devices. For example, let’s say we want members of the “Seattle Admins” group to only be able to see devices that belong to the “Seattle Devices” group.

The Intune admin must first create the scope tag. Then, they modify the scope tag so that the scope tag itself includes the “Seattle Devices” group:

Next, the Intune admin would modify the existing role assignment connecting the “Seattle Admins” group to the “School Administrator” role. The modification is to update the “scopeTags” attribute on the role assignment itself to reference the existing scope tag. When this update happens, the members of the “Seattle Admins” group will lose the ability to see any device that is not a member of the “Seattle Devices” group:

While the members of the “Seattle Admins” group can no longer see those devices in Intune, they still control those devices. We can prove this in a lab by logging in as a member of the “Seattle Admins” group and deploying a new configuration to include all devices. Because the “scopeGroups” attribute of the role assignment is inclusive of all devices, the change will apply to all devices.

Scope tags do not appear to be commonly used in the real world. There are complicated rules around scope tags that I believe will introduce enough friction to discourage most Intune admins from making use of scope tags.

Entra ID RBAC

Two built-in roles in Entra have full control of an Intune instance:

• Global Administrator
• Intune Administrator

Principals with either of those roles are not limited in any way by Intune RBAC. I still need to look into which specific Entra ID permissions may be relevant in the same way, as admins may be using custom Entra ID roles that also have control of Intune.

MS Graph App Roles

Intune is accessed via MS Graph, which has its own set of permissions related to Intune. The MS Graph app roles that apply to Intune include, for example:

• DeviceManagementRBAC.ReadWrite.All
• DeviceManagementConfiguration.ReadWrite.All
• DeviceManagementManagedDevices.ReadWrite.All

Most (all?) of the Intune-relevant MS Graph app roles begin with “DeviceManagement”.

Some of these app roles enable abuse. For example:

• DeviceManagementConfiguration.ReadWrite.All app role enables arbitrary, privileged command execution on all Intune-managed endpoints
• DeviceManagementRBAC.ReadWrite.All enables privileged role assignment in Intune, including the ability to grant Intune role assignments that lead to arbitrary, privileged command execution on Intune-managed endpoints

Those are the two MS Graph app roles I have completed the research on. There are others that appear very attractive, including:

• DeviceManagementApps.ReadWrite.All
• DeviceManagementServiceConfig.ReadWrite.All

Intune Arbitrary Command Execution via Remediations

Intune is an endpoint management system and, as such, provides Intune admins with various mechanisms for performing privileged actions on endpoints such as controlling operating system configurations, installing arbitrary applications, and running arbitrary commands.

One method of running arbitrary commands is by using Remediations (previously known as “Proactive Remediations”). Remediations allow Intune admins to run PowerShell scripts on Intune-managed devices as the Windows NT AUTHORITY\SYSTEM principal.

Remediations run PowerShell scripts. To run a remediation script, the admin must create or modify an existing PowerShell script. This step is done locally on the admin’s own host.

Next, the Intune admin must create or modify an existing script package. Creating a new script package is done by making a “POST” request to the MS Graph /devicemanagement/deviceHealthScripts endpoint. This is a privileged action. In order to successfully make a “POST” request to that endpoint, a principal must have one of the following:

A. One of these Entra ID roles:

1. Global Administrator
2. Intune Administrator

B. An Intune role assignment including the atomic permission (resource operation), Microsoft.Intune_DeviceConfigurations_Create. These built-in Intune roles have that permission:

1. School Administrator
2. Policy and Profile Manager

C. The MS Graph app role, DeviceManagementConfiguration.ReadWrite.All

The PowerShell script is stored as a base64-encoded string on the deviceHealthScript resource:

The script package defines which groups are able to run the package. For example, the admin may assign the script package to the “Seattle Devices” group in order to make the package available to those devices:

Script packages also allow admins to include or exclude devices using assignment filters:

Finally, script packages allow admins to exclude groups using an exclusion property of the package:

We have not observed wide-spread usage of exclusion groups or inclusion/exclusion filters. Due to the complexity involved with these filters, we do not expect most Intune admins to make use of filters beyond using the readily-available “All devices” assignment, or selecting specific groups to include.

We expect a typical environment to not make use of most of these filter mechanisms. In our example, we will simplify the diagram so that the “Seattle Devices” group is included in the script package:

Now that the script package is created and assigned to the “Seattle Devices” group, the script will automatically run on a specified interval; the default is once every 24 hours.

Intune Arbitrary Command Execution via On-Demand Proactive Remediation

Intune allows administrators to run specific remediation scripts on specific devices via a feature called on-demand proactive remediations. This feature is currently in preview and subject to change.

In order to run an on-demand proactive remediation, the admin must create a script (or target an existing script). The documentation for the initiateOnDemandProactiveRemediation action indicates that this action can be used to trigger several kinds of scripts within the Intune platform:

• deviceHealthScripts
• deviceManagementScripts
• deviceComplianceScripts

At the time of writing (December 17, 2024), I have finished the work to understand which permissions are required in order to perform the initiateOnDemandProactiveRemediation action when sending a POST request to this URI:

https://graph.microsoft.com/beta/deviceManagement/managedDevices/{managedDeviceId}/initiateOnDemandProactiveRemediation

A service principal with the following MS Graph app role will successfully perform a “POST” request to the above endpoint:

• DeviceManagementManagedDevices.PrivilegedOperations.All

A principal with an Intune role activated that includes one of the following permissions will successfully perform a “POST” request to the above endpoint:

• Microsoft.Intune_RemoteTasks_OnDemandProactiveRemediation

The following built-in Intune roles have that/those permissions:

• Help Desk Operator
• School Administrator

In the previous section titled “Intune Arbitrary Command Execution via Remediations”, we discussed how script package filters limit which devices a remediation script package will automatically run on. For the endpoint discussed in this section, the initiateOnDemandProactiveRemediation action is not limited by those filters. Even if a script package is explicitly configured to not run on a set of devices, the initiateOnDemandProactiveRemediation action will successfully execute those same script packages on that same set of devices.

This may or may not be Microsoft’s intent. I opened a GitHub issue here asking them whether this is intended: https://github.com/MSEndpointMgr/Intune/issues/76

Intune Script Packages

There are several Intune resource types admins can use to store and execute scripts on Intune-managed devices. The most obvious is a resource called deviceHealthScript. These objects are called “Script Packages” in the Intune portal GUI:

Look carefully at the above screenshot. Look at what the arrow on the left is pointing at. The Intune portal GUI calls the items in this list “Script Packages”. The Intune GUI says there are 37 “script packages”. Now carefully look at what the arrow on the right is pointing at: the number 37. Now look at the URI that was accessed to retrieve that number: it’s the deviceHealthScripts URI.

“Script Package” is the customer-facing name. That is the name Microsoft uses in the remediations feature documentation. “deviceHealthScript” is the name that MS Graph’s Intune API endpoints uses.

Because most Intune admins will likely be more familiar with the term “Script Package”, that is the name we will use when describing these objects.

Script packages (deviceHealthScripts) are Intune resources. There are several properties on these objects that are interesting to an attacker:

• id — The universally unique identifier (UUID) of the script package
• detectionScriptContent — Base64 encoded PowerShell “detection” script that will run on an endpoint executing this script package
• remediationScriptContent — Base64 encoded PowerShell “remediation” script that will run on an endpoint executing this script package
• runAsAccount — Whether the script will run as the logged-on user or as the NT AUTHORITY\SYSTEM principal

Intune admins can populate the detectionScriptContent and remediationScriptContent properties of these objects with anything they want; it doesn’t need to be a PowerShell script, but PowerShell is the only type of script that will successfully execute on an endpoint running a script package.

Adversaries find PowerShell scripts attractive because they may have contents that lead to successfully actioning an operational objective. Those contents may include less-sensitive data such as internal hostnames, or highly-sensitive data such as credentials.

A principal with one of the following Entra ID admin roles can read the contents of all script packages within an Intune instance:

• Global Administrator
• Intune Administrator
• Global Reader
• Security Reader
• Reports Reader
• Security Operator
• Security Administrator
• Helpdesk Administrator

A principal with one of the following built-in Intune roles can read the contents of all script packages within an Intune instance:

• Help Desk Operator
• Endpoint Security Manager
• Policy and Profile Manager
• Read Only Operator
• School Administrator
• Application Manager

The atomic Intune permission that enables reading script package contents is:

• Microsoft.Intune_DeviceConfigurations_Read

These MS Graph app roles allow a service principal to read all deviceHealthScripts in the Intune instance:

• DeviceManagementConfiguration.Read.All
• DeviceManagementConfiguration.ReadWrite.All

Intune Platform Scripts

Platform scripts are Intune resources that store information about scripts that can run on Intune-managed devices. “Platform script” is the user-facing name of this resource. The MS Graph API refers to these resources as deviceManagementScripts. We will refer to them as “Platform Scripts”.

Platform scripts, similar to script packages, contain the base64-encoded script that will run on Intune-managed endpoints. Those scripts may contain sensitive information such as internal host names or credentials.

A principal with one of the following Entra ID admin roles can read the contents of all platform scripts within an Intune instance:

• Global Administrator
• Intune Administrator
• Global Reader
• Security Reader
• Reports Reader
• Security Operator
• Security Administrator
• Helpdesk Administrator

A principal with one of the following Intune roles can read the contents of all platform scripts within an Intune instance:

• Help Desk Operator
• Endpoint Security Manager
• Policy and Profile Manager
• Read Only Operator
• School Administrator
• Application Manager

The atomic Intune permission that enables reading platform script contents is:

• Microsoft.Intune_DeviceConfigurations_Read

These MS Graph app roles allow a service principal to read all platform scripts in the Intune instance:

• DeviceManagementConfiguration.Read.All
• DeviceManagementConfiguration.ReadWrite.All

Intune Compliance Scripts

Compliance scripts are scripts that run during an Intune-managed Windows or Linux system. Compliance scripts are referred to as “Scripts” within the compliance policy GUI, and as “deviceComplianceScripts” by the API. We will call them “Compliance Scripts”.

Compliance scripts are associated with compliance policies. Compliance policies specify which devices/groups are in-scope for that particular policy. Compliance scripts automatically run once every 24 hours when associated with a compliance policy.

Admins can force a compliance script to execute “on-demand” by instructing a device to “sync”.

Intune Device User Hunting

When an on-premises Active Directory user logs onto a domain-joined computer, several artifacts are created within the operating system that make it possible to impersonate that user. This is well-established knowledge going back to at least 2008 when Luke Jennings published the seminal paper, “Security Implications of Windows Access Tokens — A Penetration Tester’s Guide”.

Similar tradecraft exists to take advantage of Entra users logging on to Windows endpoints, as discussed by Dirk-jan Mollema in, for example, his blog post titled “Digging Further Into the Primary Refresh Token”, and as discussed by Adam Chester in his blog post titled, “WAM BAM — Recovering Web Tokens From Office”.

This tradecraft means adversaries are interested in discovering which Intune-managed devices users have logged onto. There are several data sources we can pull from to discover which users have logged onto which devices, each with their own strengths and drawbacks:

User Hunting via Sign-in Logs

Of the built-in options, Entra sign-in logs are the highest-fidelity source for discovering which users have performed some kind of abusable logon on a device.

Sign-in logs are a trove of information. In the above screenshot, we can see:

• The UUID of the user that performed a sign-in
• The date and time of the sign-in
• The application the user was “signing into” (Azure Portal)
• Version information about the browser the user used
• The UUID of the Entra device the user used

This is more than enough information to populate an attack graph:

Notice that, in the above diagram, we have labeled the device as an “Entra Device” and not as an “Intune Device”. This is because Entra logs the Entra device identifier, NOT the Intune device identifier. Recall from earlier that we can identify hosts that are both Entra-joined and Intune-managed devices by comparing the deviceId and azureADDeviceId property values:

We can connect the Entra and Intune device nodes with an edge indicating they are the same host. This reveals the full pattern connecting the Intune device to the Entra user:

But Entra sign-in logs come with serious limitations. Adversaries may be unable or unwilling to rely on Entra sign-in logs for user hunting for a few reasons:

1. Comprehensive sign-in log collection is very slow. It can take several hours to collect those logs from the MS Graph API
2. The available filters to constrain the sign-in logs MS Graph returns do not materially reduce the time it takes to collect those logs
3. Reading sign-in logs requires non-default permissions that an initial-access user or service principal is unlikely to possess

User Hunting via Intune Device “usersLoggedOn” Attribute

Intune devices have a property called usersLoggedOn. This attribute is a collection of loggedOnUser resources. A loggedOnUser resource contains two pieces of information:

• The Entra ID of the user that logged onto the device
• The timestamp of the most recent time that user logged onto that device

This data source gives us all three elements we need to construct a similar attack graph as in the previous section:

Using this attribute for user hunting comes with some advantages:

• Collecting Intune devices via the MS Graph API is dramatically faster than collecting Entra sign-in logs
• The usersLoggedOn attribute stores 30 days worth of logons (the same length as Entra sign-in logs)
• The rights needed to collect Intune devices may be “lower” than those needed to collect sign-in logs

User Hunting via Entra/Intune Device Owner

Entra and Intune devices have “owners”. Ownership of an Entra or Intune device does not guarantee control of the device, nor does it guarantee that the user that owns the device uses the device. In the real world, we see many Entra and Intune devices where the owner has been set to an IT contact. We do not consider device ownership a reliable indicator for the purposes of user hunting.

User Hunting via Intune Device Primary User

Intune devices have “primary users”. The “primary user” value of an Intune device is set different ways depending on how the device was enrolled: https://learn.microsoft.com/en-us/mem/intune/remote-actions/find-primary-user?WT.mc_id=Portal-Microsoft_Intune_Devices#who-is-assigned-as-the-primary-user

In the real world, we have seen little reason to put much trust in the “primary user” of an Intune device for user hunting purposes, especially in light of the Intune device usersLoggedOn attribute.

Conclusion and Future Work

Intune attack paths are interesting for the attack paths that emerge within the Intune platform itself. But these attack paths are compelling for the attack paths that emerge connecting Entra/Azure to on-premises Active Directory and vice versa. This blog post hopefully sets some foundational knowledge to setup for the next post(s) in this series, which will show real examples of performing the abuse primitives this post discusses.

I will also be continuing Intune tradecraft research, to include:

• Finishing research on atomic Entra ID RBAC permissions that enable abuse of Intune resources
• Learning how line of business apps and permissions against them can be abused
• Investigating Intune device query and determining the data collection and other abuse primitive types that may be enabled by this feature
• Researching Remote Help and Intune’s Teamviewer integration to understand how those features work and how they may be abused for lateral movement
• And more…

References

• https://www.systanddeploy.com/2023/07/run-on-demand-remediation-script-on.html
• https://gist.github.com/SMSAgentSoftware/70f76191cd9c420e7fb39f17aa602c03
• https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments
• https://github.com/Mayyhem/Maestro
• https://securityintelligence.com/x-force/detecting-intune-lateral-movement/
• https://medium.com/learning-mem/about-intune-primary-user-84591ddbb1e

Intune Attack Paths — Part 1 was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Intune Attack Paths — Part 1 appeared first on Security Boulevard.

Deb Radcliff interviews OWASP Top Ten core team member Brian Glas. What do the OWASP Top Ten web application vulnerabilities have to do with C languages? And where do those vulnerabilities coincide with Software Bills of Materials (SBOMs)?  As the Top Ten core team begins analyzing the 2025 data, we pose these questions to Brian…

The post OWASP Top 10: What’s C Got to Do With It? appeared first on CodeSecure.

The post OWASP Top 10: What’s C Got to Do With It? appeared first on Security Boulevard.

Building an in-house redaction system requires overcoming significant technical challenges and investing considerable resources to develop and maintain the process. This article explores some of the challenges you may face if your organization decides to go down the build-it-yourself path.

The post Redacting sensitive free-text data: build vs buy appeared first on Security Boulevard.

Silver Spring, United States / Maryland, 15th January 2025, CyberNewsWire

The post Aembit Announces Speaker Lineup for the Inaugural NHIcon appeared first on Security Boulevard.

Tel Aviv, Israel, 15th January 2025, CyberNewsWire

The post Sweet Security Introduces Patent-Pending LLM-Powered Detection Engine, Reducing Cloud Detection Noise to 0.04% appeared first on Security Boulevard.

Sweet Security today added a cloud detection engine to its cybersecurity portfolio that makes use of a large language model (LLM) to identify potential threats in real-time.

The post Sweet Security Leverages LLM to Improve Cloud Security appeared first on Security Boulevard.

Zero trust as a concept is simple to grasp. Implementing a zero trust architecture, on the other hand, is complex because it involves addressing a unique mix of process, procedure, technology and user education. Here are some considerations to keep in mind as you begin your journey.

Draft guidance on implementing a zero trust architecture, released by the National Institute of Standards and Technology (NIST) on Dec. 4, 2024, gives government agencies and private sector organizations a solid blueprint to follow. There are a number of additional considerations to keep in mind as you begin your journey.

First and foremost, zero trust is an alternative way of thinking about information security that treats trust as a vulnerability. It removes trust entirely from digital systems and is built upon the idea that security must become ubiquitous throughout the infrastructure. The concepts of zero trust are simple:

• All resources are accessed in a secure manner, regardless of location.
• Access control is on a "need-to-know" basis and is strictly enforced.
• All traffic is inspected and logged.
• The network is designed from the inside out.
• The network is designed to verify everything and trust nothing.

A zero trust architecture can be implemented using commercial off-the-shelf technology. It's built upon current cybersecurity best practices and dovetails with a robust exposure management program. In fact, exposure management and zero trust go hand-in-hand.

5 things to keep in mind about zero trust

Here are five considerations as you begin your zero trust journey:

1. Zero trust is a strategy, not a SKU. In most organizations, it can be implemented using existing off-the-shelf cybersecurity products. There is no single zero trust product your organization can purchase and plug in to transform your risk posture overnight.
2. Zero trust requires a foundation of strong exposure management. As the National Institute of Standards and Technology (NIST) guidelines make clear, you can't build a zero trust strategy without first having accurate visibility into all of the organization's assets — including IT, cloud, operational technology (OT) and internet of things (IoT). An exposure management program can provide you with that level of visibility as well as the ability to act on findings in real time.
3. User profiles matter more than ever. A zero trust strategy requires you to continuously monitor all users all the time. Identity and access management capabilities such as Entra ID and Active Directory, which are used to manage user profiles and privileges, must be continuously monitored and kept up to date.
4. No one is trusted — no exceptions. This may not please senior leaders, who can sometimes behave as if the rules don't apply to them. Brushing up on your diplomatic skills is advised. Ultimately, though, a zero trust architecture can be implemented without creating significant friction for end users.
5. Zero trust requires thoughtful communication. There are people throughout the organization who have built their careers on the legacy cybersecurity principles of moat-and-castle and trust-but-verify. They may be threatened or feel that their jobs are in jeopardy if they aren't engaged in the zero trust buildout from day one.

Zero trust as a concept is simple to grasp. What makes zero trust complex to implement are the same factors that make any cybersecurity strategy complex: the unique mix of processes, procedures and technology found in your IT infrastructure, as well as the need for significant user education. It's best to start small and roll out from there, rather than trying to boil the ocean.

For cybersecurity leaders in government agencies, preparing for a zero trust architecture is less an exercise in evaluating technologies and more an exercise in strategic thinking, requiring you to answer fundamental questions such as:

• What is your agency’s core mission or value proposition?
• What are the workflows required to fulfill that mission?
• Who owns those workflows?
• How does data flow in the organization?
• Which are your high-value assets, the so-called "keys to the kingdom"?
• How does the organization determine who is granted access to these high-value assets?
• How often does the organization audit user permissions once they are set?
• What building blocks do you already have in place to support a zero trust strategy?

Answering these questions requires full visibility and continuous monitoring of your entire attack surface, including IT, internet of things (IoT) and operational technology (OT) assets, and the ability to assess the criticality of each asset to deliver on your organization's core mission. No zero trust journey can begin without first addressing these fundamentals of exposure management.

How zero trust and exposure management go hand-in-hand

Exposure management transcends the limitations of siloed security programs. Built on the foundations of risk-based vulnerability management, exposure management takes a broader view across your modern attack surface, applying both technical and business context to more precisely identify and more accurately communicate cyber risk, enabling better business outcomes.

An exposure management program combines technologies such as vulnerability management, web application security, cloud security, identity security, attack path analysis and patch management to help an organization understand the full breadth and depth of its exposures and take the actions needed to reduce them through remediation and incident response workflows. Exposure management gives security teams a full, dynamic and accurate picture of the attack surface at any point in time, aiding in the implementation of zero trust policies and architecture.

Learn more

• Download the Gartner report How to Grow Vulnerability Management into Exposure Management
• Read the blogs Tenable and the Path to Zero Trust and Making Zero Trust Architecture Achievable
• View the updated draft Guidance for Implementing a Zero Trust Architecture, released by NIST on Dec. 4, 2024

The post 5 Things Government Agencies Need to Know About Zero Trust appeared first on Security Boulevard.

Discover how Grip complements TPRM platforms by uncovering shadow SaaS, enhancing identity security, and addressing risks traditional TPRM methods miss.

The post Grip vs. TPRM | Amplify your TPRM Strategy appeared first on Security Boulevard.

The rapid increase in cyberattacks is putting greater pressure on Cyber Resilience and IT Infrastructure teams to ensure the reliability, integrity, and availability of their systems

The post The CISOs Guide to Cyber Recovery appeared first on Continuity™.

The post The CISOs Guide to Cyber Recovery appeared first on Security Boulevard.

Prague, Czech republic, 15th January 2025, CyberNewsWire

The post Wultra Secures €3M to Protect Financial Institutions from Quantum Threats appeared first on Security Boulevard.

As 2024 drew to a close, Google caught global attention with the announcement of its latest quantum computing chip, Willow. Many believe that with Willow, Google has set a new benchmark for 2025, unveiling the extraordinary potential of quantum computing and what the quantum future could look like in the days ahead. If you think […]

The post Google’s Willow Chip: Another Push to Start Your Post-Quantum Cryptography (PQC) Preparation Now appeared first on Security Boulevard.

The cybersecurity landscape is entering an unprecedented era of complexity, with AI-driven threats, geopolitical tensions, and supply chain vulnerabilities reshaping how organizations approach digital security. This analysis explores key trends and strategic imperatives for 2025 and beyond.

The post The Future of Cybersecurity: Global Outlook 2025 and Beyond appeared first on Security Boulevard.

The post Patch Tuesday Update - January 2024 appeared first on Digital Defense.

The post Patch Tuesday Update – January 2024 appeared first on Security Boulevard.

Attacks on individual applications were down month to month in December 2024, but one of the most dangerous types of attacks was up significantly. That’s according to data Contrast Security publishes monthly about the detection and response of real-world application and application programming interface (API) attacks with Application Detection and Response (ADR). What you’re about to see is data that we gather from the attacks on our apps and those of our customers, anonymized and averaged. 

The post Unsafe Deserialization Attacks Surge | December Attack Data | Contrast Security appeared first on Security Boulevard.

Find out why unknown build assets is a growing problem and how Legit can help.

The post How to Prevent Risk From Unknown Build Assets appeared first on Security Boulevard.

Fortinet patched a zero day authentication bypass vulnerability in FortiOS and FortiProxy that has been actively exploited in the wild as a zero-day since November 2024.

Background

On January 14, Fortinet released a security advisory (FG-IR-24-535) addressing a critical severity vulnerability impacting FortiOS and FortiProxy.

CVE Description CVSSv3 CVE-2024-55591 FortiOS and FortiProxy Authentication Bypass Vulnerability 9.6 Analysis

CVE-2024-55591 is an authentication bypass vulnerability in FortiOS and FortiProxy. An unauthenticated, remote attacker could exploit this vulnerability by sending a specially crafted request to a Node.js websocket module. Successful exploitation may grant an attacker super-admin privileges on a vulnerable device. According to the Fortinet advisory, this vulnerability has been exploited in the wild.

Zero Day Campaign May Have Been Active Since November

Researchers at Arctic Wolf published a blog post on January 10 detailing a campaign first observed in mid-November 2024 of suspicious activity related to the exploitation of a zero-day vulnerability, which is presumed to be CVE-2024-55591. Arctic Wolf Labs details four distinct phases of the campaign that were observed against Fortinet FortiGate firewall devices; scanning, reconnaissance, SSL VPN configuration and lateral movement. For more information on the observations of this campaign, we recommend reviewing its blog post.

At the time this blog was published, the Fortinet advisory did not credit Arctic Wolf with the discovery of CVE-2024-55591. However, the indicators of compromise (IoCs) listed in the Fortinet advisory overlap with the report from Arctic Wolf.

Historical exploitation of Fortinet FortiOS and FortiProxy

Fortinet FortiOS and FortiProxy have been targeted by threat actors previously, including targeting by advanced persistent threat (APT) actors. We’ve written about several noteworthy Fortinet flaws since 2019, including flaws impacting SSL VPNs from Fortinet and other vendors:

CVE Description Patched Tenable Blog CVE-2024-21762 Fortinet FortiOS Out-of-bound Write Vulnerability in sslvpnd February 2024 CVE-2024-21762: Critical Fortinet FortiOS Out-of-Bound Write SSL VPN Vulnerability CVE-2023-27997 FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability June 2023 CVE-2023-27997: Heap-Based Buffer Overflow in Fortinet FortiOS and FortiProxy SSL-VPN (XORtigate) CVE-2022-42475 FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability December 2022

CVE-2022-42475: Fortinet Patches Zero Day in FortiOS SSL VPNs

AA23-250A: Multiple Nation-State Threat Actors Exploit CVE-2022-47966 and CVE-2022-42475

CVE-2022-40684 FortiOS and FortiProxy Authentication Bypass Vulnerability October 2022 CVE-2022-40684: Critical Authentication Bypass in FortiOS and FortiProxy CVE-2020-12812 FortiOS Improper Authentication Vulnerability July 2020 CVE-2018-13379, CVE-2019-5591, CVE-2020-12812: Fortinet Vulnerabilities Targeted by APT Actors CVE-2019-5591 FortiOS Default Configuration Vulnerability July 2019 CVE-2018-13379, CVE-2019-5591, CVE-2020-12812: Fortinet Vulnerabilities Targeted by APT Actors CVE-2018-13379 FortiOS Path Traversal/Arbitrary File Read Vulnerability August 2019 CVE-2018-13379, CVE-2019-11510: FortiGate and Pulse Connect Secure Vulnerabilities Exploited In the Wild Proof of concept

At the time this blog post was published, there were no public proof-of-concept exploits for CVE-2024-55591.

Solution

Fortinet published its security advisory (FG-IR-24-535) on January 14 to address this vulnerability. The advisory also contains IoCs and workaround steps that can be utilized if immediate patching is not feasible. Fortinet has released the following patches for FortiOS and FortiProxy.

Affected Product Affected Version Fixed Version FortiOS 7.0 7.0.0 through 7.0.16 Upgrade to 7.0.17 or above FortiProxy 7.0 7.0.0 through 7.0.19 Upgrade to 7.0.20 or above FortiProxy 7.2 7.2.0 through 7.2.12 Upgrade to 7.2.13 or above

Fortinet also released several additional security advisories on January 14 for vulnerabilities affecting FortiOS and FortiProxy:

Affected Product(s) Vulnerability Description Security Advisory CVSSv3/Severity FortiOS, FortiProxy, FortiMail, FortiSwitch, FortiVoiceEnterprise, FortiNDR, FortiWLC, FortiADC, FortiAuthenticator, FortiRecorder, FortiDDoS-F, FortiDDoS, FortiSOAR and FortiTester An externally controlled reference to a resource may allow an unauthenticated attacker to poison web caches between an affected device and an attacker using crafted HTTP requests FG-IR-23-494 4.1 / Medium FortiAnalyzer, FortiAnalyzer Cloud, FortiAuthenticator, FortiManager, FortiManager Cloud, FortiOS, FortiProxy, FortiSASE An unauthenticated attacker with access to the Security Fabric protocol may be able to brute force an affected product to bypass authentication. FG-IR-24-221 8.0 / High FortiOS An authenticated, remote attacker may be able to prevent access to the GUI using specially crafted requests and causing a denial of service (DoS) condition. FG-IR-24-250 4.8 / Medium FortiOS An authenticated attacker may be able to cause a DoS condition due to a NULL pointer dereference vulnerability in the SSLVPN web portal. FG-IR-23-473 6.2 / Medium FortiManager, FortiOS, FortiProxy, FortiRecorder, FortiSASE, FortiVoice and FortiWeb A path traversal vulnerability may be exploited by a remote attacker with access to the security fabric interface, allowing the attacker to access and modify arbitrary files. FG-IR-24-259 7.1 / High FortiOS An unauthenticated attacker may be able to exploit an out-of-bounds write vulnerability to cause a DoS condition. FG-IR-24-373 3.5 / Low FortiOS An unauthenticated attacker may be able to exploit an out-of-bounds read vulnerability to cause a DoS condition. FG-IR-24-266 7.5 / High FortiOS An authenticated attacker with low privileges may be able to cause a DoS condition due to two NULL pointer dereference vulnerabilities. FG-IR-23-293 6.4 / Medium FortiOS An unauthenticated attacker may be able to exploit a resource allocation vulnerability to cause a DoS condition using multiple large file uploads. FG-IR-24-219 7.1 / High FortiOS An authenticated attacker may be able to exploit an integer overflow vulnerability to cause a DoS condition. FG-IR-24-267 3.2 / Low FortiOS An authenticated attacker may be able to exploit an improper access control vulnerability. FG-IR-23-407 4.7 / Medium FortiOS, FortiProxy and FortiSASE An unauthenticated attacker may be able to exploit a http response splitting vulnerability in FortiOS, FortiProxy and FortiSASE FG-IR-24-282 6.4 / Medium FortiOS An unauthenticated attacker may be able to exploit a man-in-the-middle vulnerability to intercept sensitive information. FG-IR-24-326 3.5 / Low Identifying affected systems

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

Additionally, customers can utilize Tenable Attack Surface Management to identify public facing Fortinet assets:

  Get more information

• Fortinet FG-IR-24-535 Security Advisory
• Arctic Wolf Blog - Console Chaos: A Campaign Targeting Publicly Exposed Management Interfaces on Fortinet FortiGate Firewalls

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

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

The post CVE-2024-55591: Fortinet Authentication Bypass Zero-Day Vulnerability Exploited in the Wild appeared first on Security Boulevard.

Authors/Presenters: Emma Stewart

Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – Pick Your Poison: Navigating A Secure Clean Energy Transition appeared first on Security Boulevard.

SYMMETRY CUSTOMER CASE STUDY Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems ABOUT Industry:Fintech Size:1K – 3K employees...

The post Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems appeared first on Symmetry Systems.

The post Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems appeared first on Security Boulevard.