Zero Day Initiative

It’s the second Tuesday of the month, and, as expected, Microsoft and Adobe have released their latest security offerings – all tariff free. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for April 2025

For April, Adobe released 12 bulletins addressing 54 CVEs in Adobe Cold Fusion, After Effects, Media Encoder, Bridge, Commerce, AEM Forms, Premiere Pro, Photoshop, Animate, AEM Screens, FrameMaker, and the Adobe XMP Toolkit SDK. Adobe lists the update for Cold Fusion as Priority 1 but states there are no exploits in the wild for the bugs being patched. The patch for AEM Forms is set to Priority 2. These aren’t new CVEs; just updates to dependencies. The patch for Commerce is also marked as Priority 2, although the CVEs being addressed are Important and Moderate. Still, the security bypasses shouldn’t be ignored. All of the other patches from Adobe are listed as Priority 3.

The patch for After Effects fixes seven bugs, two of which are Critical code execution flaws. The fix for Media Encoder corrects two code execution bugs. There’s just a single Critical fix in the Bridge update. That’s the same for the patches for Premiere Pro and Photoshop. The patch for Animate addresses two Critical and two Important bugs. The AEM Screens patch fixes a single cross-site scripting (XSS) bug. The update for FrameMaker fixes 10 CVEs, including several code execution bugs. Finally, the patch for the Adobe XMP Toolkit SDK fixes five different Out-of-Bounds (OOB) Read memory leaks.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. 

Microsoft Patches for April 2025

This month, Microsoft released a whopping 124 new CVEs in Windows and Windows Components, Office and Office Components, Azure, .NET and Visual Studio, BitLocker, Kerberos, Windows Hello, OpenSSH, and Windows Lightweight Directory Access Protocol (LDAP). One of these bugs was reported through the Trend ZDI program. With the additional third-party CVEs being documented, it brings the combined total to 134 CVEs.

Of the patches released today, 11 are rated Critical, two are rated Low, and the rest are rated Important in severity. The April release tends to be heavier, and this level of output doesn’t disappoint. It’s a small comfort that only one of these bugs is listed as publicly known or under active attack at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerability currently being exploited in the wild:

-   CVE-2025-29824 - Windows Common Log File System Driver Elevation of Privilege Vulnerability
This privilege escalation bug is listed as under active attack and allows a threat actor to execute their code with SYSTEM privileges. These types of bugs are often paired with code execution bugs to take over a system. Microsoft gives no indication of how widespread these attacks are. Regardless, test and deploy this update quickly.

-   CVE-2025-26663/CVE-2025-26670 - Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
These bugs allow a remote, unauthenticated attacker to execute their code on affected systems just by sending a specially crafted LDAP message. They would need to win a race condition, but we’ve seen plenty of exploits work around this requirement. Since just about everything can host an LDAP service, there’s a plethora of targets out there. And since no user interaction is involved, these bugs are wormable. LDAP really shouldn’t be allowed through your network perimeter, but don’t rely on that alone. Test and deploy these updates quickly – unless you’re running Windows 10. Those patches aren’t available yet.

-  CVE-2025-27480/CVE-2025-27482 - Windows Remote Desktop Services Remote Code Execution Vulnerability
Here are some more Critical-rated bugs that don’t rely on user interaction. An attacker just needs to connect to an affected system with the Remote Desktop Gateway role to trigger another race condition, resulting in code execution. RDS is popular for remote management, so it is often reachable from the Internet. If you must leave it open to the world, consider IP restricting it to known users, then test and deploy these patches.

-  CVE-2025-29809 - Windows Kerberos Security Feature Bypass Vulnerability
There are several security feature bypass (SFB) bugs in this release, but this one stands out above the others. A local attacker could abuse this vulnerability to leak Kerberos credentials. And you may need to take actions beyond just patching. If you rely on Virtualization-Based Security (VBS), you’ll need to read this document and then redeploy with the updated policy.

Here’s the full list of CVEs released by Microsoft for April 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other Critical-rated patches, there are several impacting Office and Excel. For all of these bugs, the Preview Pane is an attack vector, but Microsoft lists that user interaction is required. I’m not sure how to reconcile that other than to think maybe a user needs to manually preview an attachment from the Preview Pane. And Mac users are out of luck because the updates for Microsoft Office LTSC for Mac 2021 and 2024 are not available yet. There’s a Critical-rated Hyper-V bug, but it relies on authentication and social engineering, so it’s unlikely to be exploited in the wild. The final Critical bug is for TCP/IP and sounds intriguing. It centers around DHCPv6. An attacker could send a crafted response to a legitimate DHCPv6 request to execute code on the target system. That would usually require a Machine-in-the-Middle (MitM) type of attack. I would love to know how a crafted response leads to code execution. Hopefully, the researcher who reported this to Microsoft will publish their findings now that the bug is patched.

Moving on to the other code execution bugs, there are additional open-and-own bugs in Office components, but these do not have a Preview Pane vector. There’s also this month’s crop of RRAS and Telephony Service bugs. These seem to be a staple of every release now. There’s a bug in the RDP client, but it requires someone to connect to a malicious server. There are two bugs in SharePoint that confuse me. Both say that “Site Owner” permissions are required for exploitation, but one lists this as Low privilege while the other lists it as High. This lack of consistency from Microsoft is frustrating. Speaking of inconsistencies, there’s another RDS Gateway bug identical to the two already documented above. However, this one is rated Important instead of Critical. Same description. Same CVSS score. Even the same researcher. ¯\_(ツ)_/¯

There are nearly 50 privilege escalation bugs in this month’s release, and most of these simply either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code (or ROOT in the case of Microsoft AutoUpdate for Mac). As always, there are some notable exceptions. The bug in Azure could allow the loading of DLLs into an enclave, which could then be used for code execution within that enclave. The bugs in Visual Studio could allow an attacker to escalate to a targeted user’s level. The bugs in Digital Media could allow for escalating code to run at Medium integrity. One of the bugs in the kernel could allow for an escalation to Secure Kernel. This is a newer feature, and if I’m not mistaken, this is the first bug of its kind. The bug in Kerberos is interesting as it allows an attacker to gain additional privileges from the Key Distribution Center. However, there are quite a few extra steps involved, including having a MitM. The final EoP this month is in System Center, however, there is no patch available as no existing System Center deployments are impacted. In the spirit of consistency, Microsoft also notes that only customers who re-use existing System Center installer files to deploy new instances in their environment are affected by this vulnerability – so maybe some versions are impacted. Instead of a patch, Microsoft recommends users delete the existing installer setup files (.exe) and then download the latest version of their System Center product. You can find the links in the bulletin.

In addition to the one SFB already discussed, there are eight additional patches for security feature bypasses. Mostly, you can tell what’s being bypassed in the title. The BitLocker bugs bypass Bitlocker. The Hello bug bypasses Hello. The bug in Mark of the Web (MotW) bypasses MotW defenses. The bug in Security Zone Mapping allows content to be treated as if it were in a different zone. The bug in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to bypass a security feature locally. The bugs in OneNote and Word allow for the opening of files that should otherwise be blocked. Again, Mac users will have to wait for their patches. Finally, the bug in Defender would allow applications to run that would otherwise be blocked.

Looking at the information disclosure bugs in the April release, a few of these merely result in info leaks consisting of unspecified memory contents. There are also some that lead to the disclosure of the ever-nebulous “sensitive information.” The bugs in Azure Local Cluster could allow the disclosure of device information such as a token, credentials, resource IDs, SAS tokens, user properties, and other sensitive information. The bug in Dynamics Business Central could allow an attacker to recover cleartext passwords from memory. The bug in NTFS allows an authenticated attacker to disclose file path information under a folder where the attacker doesn't have permission to list content. That is also the case for the bug in ReFS. The vulnerability in Admin Center in Azure could allow unauthorized read-only access to the local file system. The final info disclosure bug for April resides in Outlook for Android. If exploited, it could allow an attacker to read targeted e-mails.

Moving on to the 14 Denial-of-Service (DoS) bugs getting patches this month, many simply state that an attacker could deny service over a network to that component. Again, there’s no indication if that’s temporary or a permanent DoS. Does the system blue screen? Is a reboot needed? Does the service recover if the attack stops? I suppose we’ll never know.

Finally, there are three spoofing bugs receiving patches this month, and two of these are rated Low in severity. The bugs in Edge for iOS can be used to trick users into clicking something they thought was safe. One also requires that multiple instances of the browser be opened, which sounds unlikely. The Important-rate bug in Windows Hello just states unauthorized attackers could perform spoofing locally, but Microsoft provides no details on what sort of spoofing.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on May 13. I’ll be in Germany setting up for Pwn2Own Berlin, but I’ll return with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Use-after-free is a memory corruption condition where a program references memory after it has been released back to the allocator. Statically detecting these bugs can be challenging. In the past, several approaches have addressed this problem, such as GUEB by Josselin Feist and Sean Heelan's work on Finding use-after-free bugs with static analysis.

This blog post explores the usage of Binary Ninja’s Medium Level Intermediate Language (MLIL) to establish a data flow graph by tracing interactions between a specific memory allocation and other memory regions. Building on the data flow graph, it is further utilized in context-insensitive reachability analysis across functions to identify potential Use-After-Free (UAF) vulnerabilities in binaries. Like any other static code analysis approach, this one also has classification errors. While acknowledging the classification errors inherent to static code analysis, we highlight primitives that may also be adaptable for modeling other types of vulnerabilities.

For readers interested in Binary Ninja APIs, refer to our earlier blog post, which comprehensively explains using Binary Ninja Intermediate Languages (ILs) and Static Single Assignment (SSA) form.

Building a Data Flow Graph of Memory Allocation

In this context, data refers to the pointer associated with a specific memory allocation that is the subject of tracking and analysis. The data flow information is visualized as a graph, where:

•    Nodes represent different memory regions.
•    Edges represent pointer store operations that establish relationships or interactions between these regions.

In this implementation, four distinct types of nodes are utilized to construct the data flow graph, each serving a specific purpose:

Tracked Allocation Node (Red): Represents a memory allocation of interest, and acts as the focal point for tracking interactions across the graph.

Function Stack Frame Nodes (Green): Represent the stack frames of individual functions visited during inter-procedural analysis.

Dynamic Memory Nodes (Blue): Represent Static Single Assignment (SSA) variables that cannot be tied to a specific source. These could include dynamically allocated memory or arguments passed to functions for which we lack insights within the scope of the function.

Global Memory Nodes (Black): Global variables across functions are not comprehensively tracked. However, these nodes help analyze interactions within a single function.

The edges in the graph represent pointer store operations, establishing connections between memory allocations. The source node corresponds to the memory being written to and the destination node represents the pointer value being stored. The edge attributes capture the offsets from allocation base addresses. The “write” attribute indicates the offset from the base of an allocation (source node) where the pointer is written to, and the “points” attribute indicates the offset within an allocation (destination node) that the written pointer value points to. New edges are created for every unique value of “write” or “points” attribute. Write operations to stack memory are represented using absolute values from the base of the stack as represented by Binary Ninja and hence will have negative offsets for most of the architectures. When “write” or “points” attribute is 0, it means base of an allocation. Edges are additionally created during unresolved memory load operations, assuming that the relevant memory store occurred outside the function scope. This graphical representation helps understand how memory regions interact. Below is a section of a sample graph generated during analysis of OpenSLP, providing better clarity on the details described:

Figure 1 - Section of Data Graph

Mapping Relationships Between SSA Variables, Graph Nodes, and Edges

Now that we have an understanding of our graph structure, let's explore how SSA variables are mapped to the nodes in the data flow graph. In our automated analysis, the first SSA variable to be tracked is the one assigned the return value of an allocator call, such as malloc() or calloc(). Furthermore, a Binary Ninja GUI interface could be developed to enable users to mark arbitrary variables for tracking and include them in further analysis. Once we identify the SSA variable of interest, we can leverage the definition-use chain to traverse all its uses within the function. Binary Ninja provides the get_ssa_var_definition() and get_ssa_var_uses() APIs to retrieve a variable's definition site and its uses, respectively. Consider the below C code and Binary Ninja’s MLIL SSA representation of the same:

Here, the return value of call to malloc() is written to SSA variable rax#1 and the further usage of rax#1 in the function can be fetched using get_ssa_var_uses() API:

A variable points to a node, and in this context, rax#1 points to the Tracked Allocation Node (Red). When rax#1 is assigned to var_10#1, this information is propagated to var_10#1 and subsequently to any further assignments. When a variable assignment involves pointer arithmetic, a piece of offset information is stored in addition to the node. In this case, the offset is 0 because all the variables point to the base of the Tracked Allocation Node.

The ptr variable in the function stack is represented by the SSA variable var_10#1, which stores the pointer to the allocated memory. The offset for this variable can be extracted and represented as an edge in the graph. In essence, two data structures are constructed: a dictionary that maps SSA variables to nodes and a graph that connects various memory regions, represented as nodes. Since SSA variables are associated with their specific functions, they can be uniquely identified across functions during inter-procedural analysis.

Figure 2 - Connection Between Tracked Allocation Node (Red) and Stack Frame Node (Green)

The following code snippet demonstrates the creation of a Tracked Allocation Node (Red node) and the initialization of the SSA variable dictionary, which contains information about the SSA variable and the node it references:

Let's examine another example of code and its MLIL translation to understand the process of creating a Dynamic Memory Node (Blue).

Within the function scope, there is no information about the location recptr points to. When recptr->link is initialized with the return value of a call to malloc(), a Dynamic Memory Node is created with an edge to the Tracked Allocation Node. This corresponds to the MLIL instruction 0000118a [rax_1#2 + 8].q = rdx#1 @ mem#1 -> mem#2 (MLIL_STORE_SSA), where the edge attribute contains the offset information. The variable rax_1#2 can be tracked back to arg1#0 using the SSA use-def chain.

Figure 3 - Connection Between Tracked Allocation Node (Red) and Dynamic Memory Node (Blue)

Essentially, whenever memory store operations such as MLIL_SET_VAR_SSA, MLIL_STORE_SSA, or MLIL_STORE_STRUCT_SSA are encountered, edges are created in the graph. In Binary Ninja’s MLIL SSA form, MLIL_SET_VAR_SSA is not strictly a memory store operation since stack writes are translated to SSA variables. However, the variables still retain offset information, which can be used to construct the data flow graph.

Translating Memory Loads to Graph Edges

While memory store operations are translated into graph edges, as previously discussed, load operations from memory outside the function scope are also represented as graph edges. Consider the following example:

Within the function scope, there is no specific information about recptr. However, when the pointer returned by malloc() is written to recptr_new->link, this memory is traced back to the argument passed, i.e., recptr (arg1#0), using the SSA use-def chain. The memory load operation recptr->link is translated to 0000117d rax_1#2 = [rax#1 + 8].q @ mem#0 in the MLIL SSA representation. This load operation is represented as an edge between arg1#0 and rax_1#2. The underlying assumption here is that if the memory is being loaded, it must have been initialized beforehand. Memory store, assignment, and load operations serve as the fundamental building blocks of the data flow graph.

Figure 4. Data Flow Graph Developed from Memory Store and Load Operations

Traversing the Data Flow Graph to Propagate Information

Now that we understand how variables are initialized as mappings to nodes in the graph and how memory accesses are translated to edges, the next question is: how is this information propagated when traversing instructions in the SSA def-use chain? The answer lies in the SSA variable dictionary and the graph that we initialized previously.

        -- A direct variable assignment is straightforward. The value of the source variable is assigned to the destination variable. Consider an expression like rax#0 = rbx#0. Here rax#0 is assigned with the value of rbx#0 from the SSA variable dictionary.

        -- For a variable assignment where pointer arithmetic is involved, offset information is stored in addition to the node. Consider an expression like rax#0 = rbx#0 + 0x10. Here rax#0 is assigned with the node pointed to by source variable rbx#0 and holds the offset value to the node, which is 0x10.

        -- For a variable assignment where pointer arithmetic is involved, the node information from the source variable is directly assigned to the destination variable, just as in the case of direct assignment. However, in this situation, the offset information is updated to reflect the pointer arithmetic operation. Consider an expression like rax#0 = rbx#0 + 0x10. Here rax#0 is assigned with the node pointed to by source variable rbx#0 but the offset value is set to 16.

        -- A variable assignment where data is loaded from memory like rax_1#2 = [rax#1 + 8].q, the edges of the graph are visited to fetch the target node pointed to by the source variable. To detail further, the node and the offset associated with rax#1 (base variable) is fetched from the SSA variable dictionary. Then the final offset is computed as the sum of “offset” fetched from SSA variable dictionary and the offset from the load instruction. Once the node and the computed offset are available, we find the edge which has the “write” offset equal to that of the computed offset by walking through all the edges of the node. The destination node and “points” offset associated with this edge are assigned to rax_1#2. Essentially, we resolve a memory load operation to node and offset values, which can be used to update the SSA variable dictionary. Below is the code snippet to demonstrate this:

Callees are visited after all the instructions in a def-use chain of the calling function have been processed. A callee is considered for further analysis only if any arguments passed to the function have mappings in the SSA variable dictionary. Recursion is managed by monitoring the call stack for repeated calls to the same function and terminating the analysis after a predefined number of iterations.

In cases where stack memory is passed as an argument, the callee is also analyzed if the stack offset passed is less than the write offset value of any edges associated with the respective Function Stack Frame Nodes (Green). This consideration ensures that even if a structure element is initialized within a function and the base of the structure is passed to the callee (with the stack growing downwards and using negative offsets), the analysis accounts for it appropriately.

Once the instructions in the SSA def-use chains of both the caller and callees have been traversed, the data flow graph generation is considered complete, with all variable information fully populated for further analysis.

Logging Instructions Linked to Tracked Allocation

After completing the SSA variable mapping and generating the data flow graph, the instructions are revisited. All memory loads, memory stores, or call instructions dependent on the Tracked Allocation Node are recorded, along with the statically generated call stack. These are considered as "Use". Additionally, call instructions involving deallocator functions are logged and considered as "Free". Below is a sample code snippet for handling MLIL_STORE_SSA instruction:

Inter-Procedural Analysis for Use-After-Free Detection via Call Stack

Once the logging is done, detecting potential use-after-free bugs involves analyzing all basic blocks categorized as "Free" and verifying if any paths lead to basic blocks categorized as "Use". If such a path exists, it is flagged as a potential use-after-free condition. Since double-free bugs are related to use-after-free, the analysis also examines whether a path exists from one "Free" block to another "Free" block. If such a path is detected, it is flagged and logged as a potential double-free condition.

In forward data flow analysis, there is at least one common function in the call stack leading to "Free" and the call stack leading to "Use." For example, consider a scenario where function A allocates memory, passes it to function B for use, which propagates it further to function C, where it gets freed. The instructions using the allocation in B have a call stack of A leading to B, while the call stack for function C includes A leading to B and B leading to C. The last common function in these two call stacks is B.

The analysis conducted here is not context-sensitive and focuses solely on reachability. Therefore, instead of identifying a direct path between the basic block in C that frees the memory and the instructions in B that use the memory, the analysis checks for a path within the last common function, i.e., between the basic block in B that calls function C and the basic blocks in B that use the memory. This approach allows for inter-procedural analysis while limiting the pathfinding to the last common function, improving efficiency and scope control. Otherwise, one may have to inline multiple functions into a single graph to perform reachability analysis.

Additionally, loops require special attention to minimize false positives. In loops, backward edges can connect basic blocks following a deallocation to those preceding an allocation. Therefore, instructions executed after an allocation but before a deallocation can still appear reachable in the graph, potentially being misidentified as use-after-free. To mitigate this, all incoming edges to the basic block that invokes the allocator function are removed in the control flow graph. This effectively disconnects statements that would otherwise appear reachable within the loop, reducing the false positive results.

Automated Detection of Allocator and Deallocator Calls

While it is ideal to use allocator and deallocator wrappers specific to the program as input for this analysis, manually identifying them can be challenging. An easier starting point is to input standard functions like malloc(), realloc(), and free(), examine the outcomes, and progressively refine the analysis based on the results. By cross-referencing allocator functions like malloc() and leveraging def-use chains, we can determine if the pointer returned by an allocator function is subsequently returned by the caller. If so, the caller is likely a wrapper around the allocator. For finding deallocator functions, the approach is similar to the one mentioned as “Function aliases” by Sean Heelan. Binary Ninja’s dataflow analysis can be used to verify whether any of the caller's function parameters are directly passed to a deallocator such as free(). This can be identified by checking if the parameter’s value type is RegisterValueType.EntryValue. If this condition is met, it indicates a potential wrapper around the deallocator function.

Using a JSON file with minimal allocator details, numerous functions involved in allocating and deallocating data structures were identified in OpenSLP. These discovered functions can be incorporated into the JSON file for further analysis. Currently, the "arg" key holds no significance in the implementation.

Since we perform forward data flow analysis, which involves visiting the functions that invoke the allocator call as well as the callees of those functions, identifying these wrappers allows us to shift the starting point of our analysis. Simply put, instead of beginning our analysis inside SLPMessageAlloc(), where forward data flow analysis has limited scope because it calls calloc() without further interactions, we can focus on analyzing all the functions that call SLPMessageAlloc(). This approach broadens the scope and provides better insights into the data flow.

Analyzing Real-World Vulnerabilities from the Past

To understand how the tool works, let's test it on some known vulnerable programs. Since GUEB already provides a list of identified vulnerabilities, I chose to use them as examples here.

CVE-2015-5221: JasPer JPEG-2000

There is a use-after-free/double-free vulnerability in mif_process_cmpt() as seen in RedHat Bugzilla.

By tracking the allocation and deallocation APIs, jas_tvparser_create() and jas_tvparser_destroy() respectively, the following results are observed:

In this case, mif_process_cmpt() is inlined into mif_hdr_get(), and the results are displayed accordingly.

CVE-2016-3177: Giflib

Here is a double-free vulnerability in gifcolor - #83 Use-after-free / Double-Free in gifcolor

In this case, the allocation and deallocation APIs used were EGifOpenFileHandle() and EGifCloseFile(), respectively, and the results are as follows:

GNOME-Nettool

This use-after-free vulnerability in get_nic_information() - Bug 753184. For this analysis, g_malloc0() and free() pair is tracked:

Figure 5. UAF in get_nic_information

CVE-2015-5177: OpenSLP

This double-free issue in SLPDProcessMessage() #1251064 demonstrates a different scenario compared to the previous bugs. The earlier cases involved allocation, free, and use within the same function. However, in this double-free case, we observe the effectiveness of inter-analysis. This highlights how bugs spanning multiple functions can be detected, providing a broader scope of analysis for complex code paths.

Pointers to memory allocated by SLPMessageAlloc() in SLPDProcessMessage() and SLPBufferAlloc() are passed to ProcessDAAdvert() when the message ID is set to SLP_FUNCT_DAADVERT. Within ProcessDAAdvert(), these pointers are further passed to SLPDKnownDAAdd(). If an error occurs in SLPDKnownDAAdd(), the buffers are freed using SLPMessageFree() and SLPBufferFree(), and a non-zero error code is returned to SLPDProcessMessage(). Subsequently, when SLPDProcessMessage() detects the non-zero error code, it attempts to free the same buffers again, resulting in a double-free condition. The upstream fix for this issue is found here - fix double free if SLPDKnownDAAdd() fails:

Interestingly, two double-free issues are reported due to SLPMessageFree(), even though SLPDKnownDAAdd() frees these pointers only once in the code. This discrepancy occurs because the compiler, for optimization purposes, generates multiple basic blocks for the same target of a goto statement. This leads to multiple results being reported. Our implementation does not track the buffer allocated through SLPBufferAlloc() because the pointers are passed across functions via global memory, which is not currently within the scope of our tracking.

Currently, the logging is very primitive. Every instruction classified as potential UAF condition is logged individually. Readability could be improved significantly by instead grouping the instructions by basic block or by function.

Conclusion

I hope you have enjoyed this look at using Binary Ninja to find use-after-free vulnerabilities through data flow analysis and graph reachability. The source code for the project can be found here - uafninja. If you find any vulnerabilities using these methods, consider submitting it to our bounty program.

Until then, you can find me on Twitter at @RenoRobertr, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Acknowledgments and References

•     Various blog posts from Trail of Bits on Binary Ninja
•     Josh Watson for various projects using Binary Ninja. The visitor class implementation is based on emilator
•    Jordan for all the code snippets and the Binary Ninja slack community for answering various questions
•    GUEB Static analyzer by Josselin Feist
•    Sean Heelan's work on Finding use-after-free bugs with static analysis.

Researching and reverse engineering Level 2 Electric Vehicle Supply Equipment (EVSE or loosely “charger”) efforts might require the equipment to be placed beyond the idle state. The idle state is straightforward and usually involves nothing more than powering up the charger. Indeed, this is a very useful state for research where the user interface is in operation, communications both wired and wireless are working and the mobile device app can interact. However, there are times when there is a need to force the charger into other states so that it behaves as though the electric vehicle is attached, the EV is asking for charge, or the EV is charging and the EVSE is providing charging current.  

At the Pwn2Own Automotive 2025 event, an add-on category was introduced that required a demonstration of an exploit while the equipment was in the charging state. This required manipulation of the charger via the charging cable in order to enter this charging state. This blog describes the device that we assembled to achieve this requirement. I will cover the design considerations that were made along with how the device operates. I will also provide the specifics on parts that we used; however, due to the wide range of requirements different researchers might have and substitutions they might make, I will only highlight the important points of the design and not describe this as a “step-by-step” build.  

As an example of a minimal “simulator” build, some chargers have been observed to provide an output signal when the charging cable attaches to the vehicle. If your research only involves this signal, then a diode and a single resistor inside your EV simulator enclosure may be enough to achieve your goal. So, understand our device first and then use that knowledge to build what you require for your research.

Safety

First and foremost is safety. If you are familiar with researching EVSE, you know that you will be dealing with deadly voltages. This is the case here as well. Even more dangerous is the fact that the EV simulator will enable the high voltage onto the charging cable and inside the simulator itself. This increases the number of components that have high voltage and thus increases the danger. Every precaution and safety measure should be taken in dealing with high voltage and high current. If you are not knowledgeable and confident with working around deadly high voltages or are not sure of appropriate safety measures, do not attempt to build a simulator or work with EVSE. An alternative might be to educate yourself and ask others with the appropriate qualifications for help.  As we were about to publish this blog, we found some pre-built devices that are limited but might still be an option for some.  These are listed in the “Pre-Built Alternatives” section below.

Basic Operation

The EV simulator is based on SAE J1772 operation. There are other standards that define EVSE to EV connections but our focus in this blog is strictly J1772.

The basic information needed can be found here.

The key items this implies are:

J1772-2009 connector is used.
Control signaling (over the Control Pilot signal) is strictly PWM/duty cycle.

If you study the wiki link above, you will see that the EV communicates to the EVSE on the CP line via a resistor network in the vehicle. The EVSE will sense a resistance to determine if the cable is connected to the EV (2740 ohms) and if the vehicle wants charging (882 ohms). On the flip side, the EVSE provides a 1kHz PWM signal to the vehicle to indicate the maximum current that the EVSE is willing to provide to the EV. This is done through the duty cycle of the signal. The duty cycle to current mapping is defined by J1772.

The EV simulator provides the proper resistance values using a rotary switch and monitors the PWM signal with a low-cost onboard oscilloscope. These parts reside on or inside a plastic enclosure to provide safety from high voltage and anchor the main components.

In our EV simulator, the rotary switch is set to “0” when we want to simulate a disconnected cable. It is set to “1” to simulate a connection to a vehicle but no charge being requested. Finally, it is set to “2” to simulate a connected vehicle requesting a charge. These are the only three states that we decided to incorporate into our simulator.

Figure 1 – The EV Simulator at the time of P20 Automotive Tokyo 2025

Parts

This is a list of components that we used to build our EV simulator and their links to Amazon USA. The resistors come in a kit, and we used 2700ohm for the 2740ohm requirement and 820ohm for the 882ohm requirement. These approximate values appeared to work on the EVSEs that we tested. However, you could find a more particular EVSE that needs values closer to the specification. In that case, you could combine other resistors in the kit to get closer to the specification.

As for the diode, you should try to use the one we used or one with even lower Vf specification. This diode worked with all of the chargers we were able to test. We tried higher Vf diodes with limited success. Some chargers were more tolerant of a higher Vf but many were not. The diode is required because most EVSE will test for its existence as a safety measure. 

·      Project box: LeMotech Junction Box
·      Receptacle: J1772 receptacle
·      Resistor 2740 ohm and 882 ohm: Chanzon 300 Piece Resistor Kit
·      Diodes: Chanzon 1N5817 Schottky Barrier Rectifier Diodes
·      Rotary switch: Taiss Universal Changeover Switch
·      Volt/Amp Meter: DROK Volt Amo Meter
·      Oscilloscope: FNIRSI DSO152 Oscilloscope
·      Load Plug: 20FT NEMA 6-15P/6-15R Power Extension Cord
·      Load: Cadet F Series Baseboard Heater

Considerations

A few of the items are not strictly necessary but do help in verifying the simulator is working as expected. Substitutions are also possible depending on your needs.

The bare minimum is the enclosure, the J1772 receptacle, and the proper resistor and diode values. How you manipulate the resistor network, monitor the PWM signal, and if you do or do not implement a load is flexible and up to you.

Assembly of (Our) EV Simulator

Our initial step in assembly was to drill or cut holes into the plastic enclosure. Placement isn’t critical; however, we did attempt to make things ergonomic and to not block the indicators with cables or our hands while manipulating the switch. Secondly, we connected the resistors and diode to the rotary switch and mounted that assembly inside the enclosure. This circuit connects to the Control Pilot (CP) and Protective Earth (PE) inside the enclosure.

Figure 2 – Schematic of components connected to the rotary switch.

Again, this was our implementation. We left S0 on our switch open to simulate a cable in the unconnected state without having to physically plug and unplug the cable. We also chose to control the two resistor states (S1 and S2) separately. The schematic in the wiki shows a different configuration in which only one toggle is required, and the values of the resistors are adjusted.  Both are valid so build based on your constraints. Finally, as seen in the schematic, we did not utilize states 3 -5 on the rotary switch because the additional charging states were not needed for our research at the time.

Next, the J1772 receptacle needs to be wired.

Figure 3 – The J1772 charge connector as seen from the open end

If you choose not to add a load to the simulator, the wiring is fairly easy. You only need to bring out the Control Pilot (CP) signal and the Protective Earth (PE) from the back of the connector. If you want to include a simulated battery load, you will need to also bring out the two high voltage lines (L1 and L2/N) with the appropriate size wire (remember, these can be high current depending on the load you pick). We conservatively used a 12-gauge wire, and our anticipated load was 500W. L1 and L2/N were then routed out of the enclosure to a plug so that the 500W load could be removed or added at will. The plug (in the material list above) was a heavy-duty extension cord that we cut and hardwired to the enclosure on one side and to the load on the other side. We also included a Volt/Amp meter to monitor the J1772 receptacle. When the EVSE engaged charging, the meter would show 230V (in our case) and 2.2A if the load was attached otherwise, 0A. Finally, an inexpensive battery-powered oscilloscope was attached with double-sided tape to the front of the enclosure. The probe cable was routed inside to monitor the PWM signal present on the CP wire. This simple scope defaulted to displaying several measurements, which included a duty cycle, so it was a good fit for this purpose. Other than pressing “Auto Set” once the 1KHz signal was present, there was no other configuration required.

Thus, the full enclosure schematic is:

Figure 4 – The full schematic of our EV simulator

Targets

This EV simulator was evaluated on all of the targets used at Pwn2Own Automotive 2025. This included Level 2 chargers from Autel, ChargePoint, WOLFBOX, Emporia, Ubiquity, and Tesla (with NACS adaptor). All the EVSE devices were successfully placed into the charging state and 500W was provided to the load using this simulator.

Pre-Built Alternatives 

As mentioned in the “Safety” section, we noticed a few consumer devices, which might be adequate for some research and would avoid having to assemble any parts. These devices appear to be designed primarily to charge electric scooters from an EVSE. To do this, they effectively provide the minimum circuit to enable the EVSE to energize the cable. Note that these do not provide a direct way to measure the CP signal.  Always follow the manufacturer’s safety instructions when using these devices.

·      220V J1772 Type1 Socket to NEMA 5-15/5-20 EV Charger Adapter
·      J1772 to Nema 5-20, EV Station Charging Adapter

Final Thoughts 

The J1772 standard is straightforward to implement for the limited purpose of emulating an attached vehicle to these chargers. There are more sophisticated protocols on the horizon (CAN over the CP signal) but most of the consumer-grade EVSEs continue to utilize J1772. Additionally, with such a large established base of J1772, support from the EVSEs and the EVs will likely continue far into the future.  Hopefully, this blog describing our design considerations and how we built our EV simulator will simplify the process for other researchers. While official contest specifics are still months away for the Pwn2Own Automotive event for 2026, there will almost certainly be a contest category for using the charging cable as the attack surface again. This was a highlighted addition to the 2025 event over 2024 and we hope to build on that for 2026.

Until then, you can follow us on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

We’ve reached the third Patch Tuesday of 2025, and, as expected, Microsoft and Adobe have released their latest security offerings. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for March 2025

For March, Adobe released seven bulletins addressing 37 CVEs in Adobe Acrobat Reader, Substance 3D Sampler, Illustrator, Substance 3D Painter, InDesign, Substance 3D Modeler, and Substance 3D Designer. Six of these bugs were reported through the ZDI program. The patch for Reader contains fixes for multiple Critical-rated code execution bugs. This should be the top priority for deployment. The fix for Illustrator also corrects some Critical-rated code execution bugs. That also holds true for the InDesign patch. For all of the products, an attacker would need to convince a user to open a specially crafted file.

The remaining patches all touch the Substance family of products. The fix for Substance 3D Sampler addressed seven bugs with some of those being Critical. The patch for Substance 3D Painter corrects two code execution bugs. The update for Substance 3D Modeler also has two CVEs, but only one is for a code execution bug. Finally, the patch for Substance 3D Designer addresses two Critical-rated code execution vulnerabilities.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for March 2025

This month, Microsoft released 56 new CVEs in Windows and Windows Components, Office and Office Components, Azure, .NET and Visual Studio, Remote Desktop Services, DNS Server, and Hyper-V Server. One of the actively exploited bugs was submitted through the Trend ZDI program. With the addition of the third-party CVEs, the entire release tops out at 67 CVEs.

Of the patches released today, six are rated Critical, and 50 are rated Important in severity. This is nearly identical to the release last month in volume, but the number of actively exploited bugs is extraordinary.

One of these bugs is listed as publicly known, and six(!) others are listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug discovered by a Trend researcher:

-    CVE-2025-26633 - Microsoft Management Console Security Feature Bypass Vulnerability
This bug was discovered by Aliakbar Zahravi and has been seen in the wild and used in targeted attacks. The specific flaw exists within the handling of MSC files. The product does not warn the user before loading an unexpected MSC file. An attacker can leverage this vulnerability to evade file reputation protections and execute code in the context of the current user. There is user interaction required here, but that doesn’t seem to be a problem for the attacker – EncryptHub (aka Larva-208). With more than 600 organizations impacted by these threat actors, test and deploy this fix quickly to ensure your org isn’t added to the list. Ali will have further details about these attacks out soon.

-    CVE-2025-24993 - Windows NTFS Remote Code Execution Vulnerability
CVE-2025-24985 - Windows Fast FAT File System Driver Remote Code Execution Vulnerability
These are two more bugs being exploited, and I group them together because they are triggered by the same action. To be exploited, a user would need to mount a specially crafted virtual hard drive (VHD). It’s interesting to see the root cause of these bugs is an overflow; heap-based for the NTFS and an integer overflow for Fast FAT. Once exploited, the attacker can execute code on an affected system. If paired with a privilege escalation (like the one below), they could completely take over a system.

-    CVE-2025-24983 - Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
This is another bug being actively exploited, but it’s a more traditional privilege escalation than the other one. In this case, an authenticated user would need to run a specially crafted program that ends up executing code with SYSTEM privileges. That’s why these types of bugs are usually paired with a code execution bug to take over a system. Microsoft doesn’t provide any information on how widespread these attacks are, but regardless of how targeted the attacks may be, I would test and deploy these patches quickly.

-    CVE-2025-24984/CVE-2025-24991 - Windows NTFS Information Disclosure Vulnerability
These are the final two bugs under active attack in this release. They have different triggers, but both simply lead to info leaks consisting of unspecified memory contents. CVE-2025-24984 requires physical access, which is unusual to see in an active attack. The other CVE requires the target to mount a specially crafted VHD. Even though the info leak isn’t targeted, it must be worth getting since these are being exploited. Don’t sleep on these. Test and deploy the fixes quickly.

Here’s the full list of CVEs released by Microsoft for March 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the other Critical-rated bugs, there’s a frightening-looking bug in DNS server that could allow code execution if an attacker sends a specially crafted DNS response to an affected server. However, that is incredibly unlikely to be parsed by the server. Having done DNS spoofing in a past life, it’s tricky, so this is unlikely to be exploited. The Office bug where Preview Pane is an attack vector is more likely to see exploits, but Microsoft confusingly states user interaction is required. Perhaps the target needs to preview the file in the Preview Pane? The bugs in Remote Desktop Services are also concerning as they could allow code execution if an attacker connects to an affected RDS gateway. The Remote Desktop Client bug is less concerning as a target would need to connect to a malicious server. Also less concerning is the bug in the Windows Subsystem for Linux as it requires elevated privileges to exploit.

Looking at the other code execution bugs, there are quite a few open and own bugs in Office components. This includes a bug in Access that’s listed as publicly known. There’s a fix for Azure PromptFlow that allows a remote, unauthenticated attacker to run code on an affected system. The bug in WinDbg could allow code execution due to the improper verification of cryptographic signature in .NET. However, Microsoft fails to provide any details of the exploit scenario. There’s a bug in exFAT that looks similar to two of the bugs being exploited in the wild. Since this one is not listed as exploited, it’s likely a variant of one (or both) of those. Finally, there are bugs in the RRAS and Telephony service, which seems like a monthly standard at this point. We have yet to see any of these types of bugs exploited, so there is not much concern there.

There are a handful of privilege escalation bugs receiving fixes in this month’s release, and most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. Beyond those, the bugs in Hyper-V could lead to Kernel Memory Access. The bug in Windows Server could lead to a file deletion, which can then be turned into a privilege escalation. A similar bug was reported as being under active attack last month. One of the Visual Studio bugs leads to escalating to privileges of the affected application. That’s also true for the bug in Azure Command Line Integration (CLI). The bug in ASP.NET Core and Visual Studio allows an attacker to escalate to the privileges of the compromised user. The bug in Azure Arc Installer leads to SYSTEM privileges, but you’ll need to do more than just patch to address it. This only affects machines onboarded via Group Policy, but if they were, you’ll need to roll out new GPOs to fully resolve the vulnerability.

In addition to the security feature bypass (SFB) bug being exploited in the wild, there are two other SFB fixes in this month’s release. The first is in MapUrlToZone. This bug allows attackers to bypass the security feature and have URLs processed in incorrect zones. The other is in Mark of the Web, which we have seen abused by threat actors in the past. Again, the vulnerability allows files to be treated as though they aren’t as dangerous as they seem and fails to warn users – who generally click on anything.

Looking at the Spoofing bugs in the March release, two are listed as NTLM Hash Disclosures. In both cases, user interaction is required. However, that interaction can be as simple as a single clicking (selecting) on a malicious file. If successful, an attacker could then spoof that NTLM hash for further compromise. There are not many details available for the File Explorer spoofing bug other than to say that a remote, unauthenticated attacker could “perform spoofing over a network.”

There are only two other information disclosure bugs this month, and one looks like a variant of the NTFS info disclosures under active attack. Again, it only yields unspecified memory contents. That’s also true for the bug in the Windows USB Video Driver, but Microsoft notes this is a physical attack. They don’t specify what type of physical attack, but considering it’s in a USB component, that likely means plugging in a USB device.

The March release contains just one Denial-of-Service (DoS) bug in the DirectX Graphics Kernel File, but it requires admin credentials to exploit.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on April 11, and I’ll return with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Simon Humbert and Guy Lederfein of the Trend Micro Research Team detail a recently patched code execution vulnerability in the Microsoft Windows Key Distribution Center (KDC) Proxy. This bug was originally discovered by k0shl and Wei in Kunlun Lab with Cyber KunLun. Successful exploitation could result in arbitrary code execution in the security context of the target service. The following is a portion of their write-up covering CVE-2024-43639, with a few minimal modifications.

An integer overflow has been reported for Microsoft Windows KDC Proxy. The vulnerability is due to a missing check for Kerberos response length.

A remote, unauthenticated attacker could direct KDC proxy to forward a Kerberos request to a server under their control, which would then send back a crafted Kerberos response. Successful exploitation could result in arbitrary code execution in the security context of the target service.

The Vulnerability

The Microsoft Windows operating system implements a default set of authentication protocols, including Kerberos, NTLM, Transport Layer Security/Secure Sockets Layer (TLS/SSL), and Digest, as part of an extensible architecture. For authentication within an Active Directory domain, Windows uses Kerberos.

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Kerberos builds on symmetric-key cryptography and requires a trusted third party, the key distribution center (KDC), that shares a key with all other parties in the authentication realm. Clients and services exchange Kerberos messages with the KDC. Kerberos messages can be transported over either UDP or TCP on port 88. When sent over TCP however, each request and response is preceded by the length of the message as 4 octets in network byte order.

The Microsoft Windows Server operating systems implement the Kerberos version 5 authentication protocol. Each Active Directory domain controller runs an instance of the Kerberos KDC, which uses the domain's directory service database as its security account database. To authenticate, a client must have network connectivity to a domain controller.

Although this is generally the case for machines located within an organization's network, this may not be true for clients using remote connections. To enable remote workloads, notably services such as RDP Gateway and DirectAccess, it is possible to proxy Kerberos traffic over HTTPS using a KDC Proxy.

A KDC Proxy is an HTTP-based server that implements the Kerberos KDC Proxy Protocol (KKDCP). Clients wrap their Kerberos request in a KDC proxy message and send it in the body of an HTTPS POST request where the Request-URI is set to /KdcProxy. KDC proxy messages are defined using Abstract Syntax Notation One (ASN.1). ASN.1 is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in a cross-platform way. The full specification of ASN.1 including its lexical units, separators, recursive definitions, native data types, whitespace, production rules, etc. can be found here.

Here is the structure of KDC Proxy messages:

Where:

·      kerb-message is a Kerberos message, including the 4 octet message length prefix.
·      target-domain is a DNS or NetBIOS domain name that represents the realm to which the Kerberos message must be sent (target-domain is required for KDC proxy requests but is not used for KDC proxy responses).
·      dclocator-hint is an optional field that contains additional data used to find a domain controller.

KDC Proxy messages are encoded using the Distinguished Encoding Rules (DER). DER is a type-length-value encoding system, each DER-encoded field has the following structure:

Identifier Octets encode the type of the Contents Octets. Generally, it consists of a single octet with the following structure:

The Class field can be one of Universal (bits: 00), Application Specific (bits: 01), Context-specific (bits: 10), or Private (bits: 11). The P/C field specifies whether the field is a primitive data type (bit: 0) such as INTEGER, or a constructed data type (bit: 1), i.e. whose Content Octets contain other primitive or constructed data types. If the Class field is Universal, then the specification defines several standard Tag Numbers such as BOOLEAN

(\x1), INTEGER (\x2), OCTET STRING (\x4), UTF8STRING (\x0C), SEQUENCE (\x10), IA5STRING (\x16), GeneralString (\x1B), etc. In the case of non-Universal classes, there are rules for encoding Tag Numbers larger than 30.

In DER, there are two ways to encode Length Octets. In the short form, a single Length Octet is used with the most significant bit set to 0, and the 7 remaining bits represent the number of Content Octets. In the long form, the most significant bit of the first Length Octet is set to 1, and the 7 remaining bits encode the number of subsequent Length Octets, which themselves contain the number of Content Octets. The long form is typically used only when necessary. All multibyte integers are in big-endian format.

As an example, here is how a KDC proxy request would look like after being encoded:

Indentation shows the relationship between constructed and primitive data types. Please note that the tag number for SEQUENCE is \x10, however, the SEQUENCE field is a constructed data type with the P/C field is set to 1. Therefore, the Identifier Octet for SEQUENCE is 0x30. The SEQUENCE items are assigned explicit tags from 0 to 2, and when encoded, they are encapsulated in an EXPLICIT tag data type. In the Identifier Octet for the EXPLICIT tag, the Class field is set to Context-Specific (bits: 10), and the P/C field is set to 1. Finally, Kerberos realms are encoded as KerberosString, which is an alias for GeneralString.

Upon reception of a KDC proxy request, the KDC proxy extracts the target-domain and locates a domain controller for that realm. First the KDC proxy queries the DNS SRV record for the name _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.<target_domain>, and resolves matching A records if needed. Then the KDC proxy sends an LDAP ping to the resulting set of IP addresses. An LDAP ping is a connection-less LDAP (CLDAP) rootDSE search for the Netlogon attribute, used to verify the aliveness of a domain controller, and check whether it matches a specific set of requirements. The domain controller returns a little-endian byte string that encodes a NETLOGON_SAM_LOGON_RESPONSE_EX structure.

Finally, the KDC proxy extracts kerb-message from the KDC proxy request and forwards it to the domain controller. Please note that KDC proxy only forwards Kerberos requests over TCP. Please also note that, while it can only be run on domain-joined machines, KDC proxy will proxy Kerberos requests for arbitrary domains. When KDC Proxy receives a Kerberos response from the domain controller, it wraps it in a KDC proxy message (which only contains the kerb-message field), and returns it to the client in the body of an HTTPS 200 OK response.

An integer overflow has been reported for Microsoft Windows KDC Proxy. The vulnerability is due to a missing check for the length of Kerberos responses.

After sending the Kerberos request to the domain controller, the KDC proxy reads 4 bytes from the network socket to get the Kerberos response length. Then, it attempts to read as many bytes as required to get the full response. A number of functions are involved in reading the Kerberos response, all of them are passed a pointer to a _KPS_IO structure as argument. _KPS_IO structures have a size of 0x120 bytes, here is a partial definition below (all structure definitions in this section were determined by reverse engineering; most structure and field names were chosen by us):

Whenever subsequent bytes are read from the socket, function KpsSocketRecvDataIoCompletion() in DLL file kpssvc.dll is called. It checks if enough bytes were read to get the full response, and if yes calls the function KpsPackProxyResponse(), passing a pointer to the _KPS_IO structure as an argument. KpsPackProxyResponse() first calls function KpsCheckKerbResponse() that validates the Kerberos response. Notably, if the byte that immediately follows the message length prefix is set to `0x7E` or `0x6B`, KpsCheckKerbResponse() verifies that the response is a properly constructed Kerberos message. If it is not the case, it does not perform any validation and returns without error.

KpsPackProxyResponse() local variables include a structure of type ASN1_KDC_PROXY_MSG. ASN1_KDC_PROXY_MSG structures have a size of `0x28` bytes, here is a partial definition below:

After calling KpsCheckKerbResponse(), KpsPackProxyResponse() initializes the structure as such: ASN1_KDC_PROXY_MSG.buf is set to _KPS_IO.recvbuf, and ASN1_KDC_PROXY_MSG.len is set to _KPS_IO.bytesread. Then, for wrapping the Kerberos response in a KDC proxy response it calls the function KpsDerPack(), passing the address of the ASN1_KDC_PROXY_MSG structure as an argument. From this moment on, the code flow alternates between functions from the DLL file kpssvc.dll implementing the KDC proxy server and functions from the Microsoft ASN.1 library msasn1.dll. The latter are subsequently referred to as "MSASN.1" functions.

KpsDerPack() calls MSASN.1 function ASN1_CreateEncoder(), which allocates a structure of type ASN1_encoder. ASN1_encoder structures have a size of `0x50` bytes, here is a partial definition below:

KpsDerPack() then calls MSASN.1 function ASN1_Encode(), passing pointers to the ASN1_encoder and ASN1_KDC_PROXY_MSG structures as arguments. ASN1_Encode() calls function ASN1Enc_KDC_PROXY_MESSAGE(). ASN1Enc_KDC_PROXY_MESSAGE() calls the MSASN.1 function ASN1BEREncExplicitTag(), passing a pointer to the ASN1_encoder structure as an argument. ASN1BEREncExplicitTag() is called twice, to encode the SEQUENCE and EXPLICIT fields.

Encoded data is appended to ASN1_encoder.buf, and the buffer is allocated then re-allocated as fields are being encoded. To do this, MSASN.1 functions call ASN1EncCheck(), passing the needed size as an argument. For the initial allocation, ASN1EncCheck() allocates space in the heap by calling the Windows API function LocalAlloc(). The size of the initial allocation is at least 1,024 bytes. During subsequent invocations, ASN1EncCheck() reallocates the buffer if it cannot fit the needed size. In that case, it adds the current size of the buffer and the needed size, then passes the result as an argument to the Windows API function LocalReAlloc().

ASN1BEREncExplicitTag() calls MSASN.1 function ASN1BEREncTag(). ASN1BEREncTag() encodes the Identifier Octets, first by calling ASN1EncCheck() to make sure ASN1_encoder.buf has enough space, then writing the Identifier Octets at the address ASN1_encoder.current, and finally incrementing ASN1_encoder.current. At this

stage, the length of constructed fields is not known, as it depends on the length of other constructed and primitive fields that are yet to be encoded. So ASN1BEREncExplicitTag() reserves a single byte for the Length Octets in ASN1_encoder.buf by calling ASN1EncCheck() with size 1, and incrementing ASN1_encoder.current by 1.

ASN1Enc_KDC_PROXY_MESSAGE() then calls MSASN.1 function ASN1DEREncOctetString() to encode the kerb-message OCTET STRING field, passing as arguments a pointer to the ASN1_encoder structure as well as ASN1_KDC_PROXY_MSG.buf and ASN1_KDC_PROXY_MSG.len. ASN1DEREncOctetString() is an alias for the function ASN1BEREncCharString(). ASN1BEREncCharString() first calls ASN1BEREncTag() to encode the Identifier Octets, then it calls ASN1BEREncLength(), passing ASN1_KDC_PROXY_MSG.len as argument.

ASN1BEREncLength() first computes the number of bytes required for encoding the Length Octets, adds ASN1_KDC_PROXY_MSG.len, and then passes the resulting value as an argument to ASN1EncCheck(). This ensures that ASN1_encoder.buf has enough space for both the Length Octets and the Contents Octets. ASN1BEREncLength() then writes the Length Octets at address ASN1_encoder.current, and finally increments ASN1_encoder.current by the size of Length Octets. Finally, ASN1BEREncCharString() calls the Windows API function memcpy() to copy ASN1_KDC_PROXY_MSG.len from address ASN1_KDC_PROXY_MSG.buf to address ASN1_encoder.current.

However, MSASN.1 functions do not always handle unexpected inputs properly, notably, they don't check for possible integer overflows when handling large length values. Furthermore, KpsSocketRecvDataIoCompletion() does not check the length of the Kerberos response before calling KpsPackProxyResponse(). Finally, the Kerberos response validation in KpsCheckKerbResponse() can be bypassed by setting the byte immediately following the message length prefix to any value other than 0x7E or 0x6B. As a consequence, it is possible for a malicious domain controller to send a large Kerberos response that will cause memory corruption errors.

Integer overflows and memory corruption errors occur when encoding the kerb-message OCTET STRING field. At this point, both SEQUENCE and EXPLICIT fields have already been encoded, ASN1_encoder.buf points to a buffer of size 1,024, and ASN1_encoder.current points at the address ASN1_encoder.buf + 4. The maximum size for Kerberos responses accepted by KDC Proxy is 4,294,967,295. If sending a Kerberos response with a length from 4,294,967,291 to 4,294,967,295 (inclusive), ASN1BEREncLength() will find that 5 bytes are required to encode the Length Octets, then add the length of the Kerberos response. However, the addition result is stored in a 4-byte unsigned variable that overflows. As a consequence, the size passed as an argument to ASN1EncCheck() is very small. ASN1EncCheck() does not reallocate the ASN1_encoder.buf buffer and later, when ASN1BEREncCharString() calls memcpy() a heap buffer overflow occurs.

Alternatively, when sending a Kerberos response with a length from 4,294,966,267 to 4,294,967,290 (inclusive), ASN1BEREncLength() calls ASN1EncCheck(). As the current ASN1_encoder.buf buffer is too small, ASN1EncCheck() proceeds to reallocate it. It adds the current size of the buffer (1,024) to the length of the Kerberos response. However, the addition result is stored in a 4-byte unsigned variable that overflows. As a consequence,

LocalReAlloc() actually decreases the size of the buffer. Later when ASN1BEREncCharString() calls memcpy() an out-of-bounds write or a heap buffer overflow occurs. As an interesting edge case, it is possible to pass 0 as the new size to LocalReAlloc(). LocalReAlloc() returns a memory address, not an error, however, the memory is not actually allocated, and an access violation occurs when attempting to write to that address.

A remote, unauthenticated attacker could direct KDC proxy to forward a Kerberos request to a server under their control, which would then send back a crafted Kerberos response. Successful exploitation could result in arbitrary code execution in the security context of the target service.

Note: to reach the vulnerable code, it is not enough to send a short Kerberos response with a large message length prefix value in the first four bytes. The Kerberos response length must actually match the prefix value.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on UDP port 389 and TCP port 88. Kerberos messages can be transported over either UDP or TCP on port 88. However, when sent over TCP, each request and response is preceded by the length of the message as 4 octets in network byte order.

The detection device must inspect Kerberos responses. Please note that KDC Proxy only uses TCP port 88 for Kerberos traffic (not UDP). Therefore, the device does not need to fully parse Kerberos responses. It just needs to parse the 4-byte message length prefix and be able to isolate responses within a TCP stream. If a Kerberos response is 0x80000000 (2,147,483,648) bytes or longer the traffic should be considered suspicious, an attack exploiting this vulnerability is likely underway.

Note: The detection guidance above is based on section 7.2.2 of the Kerberos V5 RFC. It mentions that, in the 4 octets message length prefix, the high bit must be set to 0. So, according to the RFC, the maximum length of Kerberos messages transmitted over TCP is 0x7FFFFFFF.

Questions About the Patch

Our research shows that the vulnerability lies in the ASN.1 library, however, the Microsoft advisory mentions the KDC Proxy server. Furthermore, the vulnerability was addressed by adding a length check in the KDC Proxy KpsSocketRecvDataIoCompletion() function. It is unclear why Microsoft chose this approach. It is possible that the ASN.1 library is known to have bugs, and that is expected for invoking software to check its inputs. It is also unclear whether any other software components can be used to trigger the vulnerability in the ASN.1 library. As such, the present report focuses on the KDC Proxy server.

Conclusion

This vulnerability was patched by the vendor in November. To date, no attacks have been detected in the wild. Microsoft doesn’t provide any mitigations for this bug, but they do note only servers configured as a KDC server are affected. Domain controllers are not impacted by this issue. They also note that since the vulnerability exists in the KDC Proxy Server service (KDCSVC), you are only vulnerable if you are already using KPSSVC in your environment. If you do not have it configured in your environment, then this vulnerability is not exploitable. We recommend all instances of KPSSVC server be patched immediately.

Special thanks to Simon Humbert and Guy Lederfein of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

If you just want to read the contest rules, click here.

Willkommen, meine Damen und Herren, zu unserem ersten Wettbewerb in Berlin! That’s correct (if Google translate didn’t steer me wrong). While the Pwn2Own competition started in Vancouver in 2007, we always want to ensure we are reaching the right people with our choice of venue. Over the last few years, the OffensiveCon conference in Berlin has emerged as one of the best offensive-focused events of the year. And while CanSecWest has been a great host over the years, it became apparent that perhaps it was time to relocate our spring event to a new home. With that, we are happy to announce that the enterprise-focused Pwn2Own event will take place on May 15-17, 2025, at the OffensiveCon conference in Berlin, Germany. While this event is currently sold out, we do have tickets available for competitors, and we believe the conference will also open a few more tickets for the public, too. The conference sold out its first run of tickets in under six hours, so it should be a fantastic crowd of some of the best vulnerability researchers in the world.

We couldn’t go to a new venue without introducing a new category, and what technology has generated the most questions regarding its security posture? Artificial Intelligence. That’s why we are introducing the AI category with six targets in different frameworks. We’re going well beyond just prompt injections – you’ll need to execute arbitrary code to win this category. Last year, we introduced the Cloud-Native/Container category, and we were thrilled to see a successful Docker container escape at the contest. We’ll see if the AI category can make a similar splash or if it goes uncontested. I would bet there will be some participation – if I were a betting man.

The Cloud-Native/Container category returns as does the Tesla category. Tesla has been a great partner since 2019, and they continue to innovate and increase the security of their vehicles, and I’m sure they will take the learnings from the recent Pwn2Own Automotive forward to the Berlin event. For this event, we’re focused simply on impact and getting code execution in a target component on the vehicle. For some targets, that may mean you need to get code execution in multiple systems on the way. And no, the awards aren’t cumulative. For example, you may need to exploit the infotainment system on the way to the Autopilot, but you’ll only get the award for the Autopilot.

Of course, Pwn2Own wouldn’t be the same without our classic categories, like web browsers, OSes, and Enterprise Servers. Last year, the Master of Pwn was awarded to Manfred Paul, who successfully exploited all four web browsers at the contest. Altogether, we’ll again be offering more than $1,000,000 USD in cash and prizes at this year’s event. We’re looking forward to a new venue and an exciting event with some cutting-edge exploitation on display. Here is a full list of the categories for this year’s event:  

          -- AI Category
          -- Web Browser Category
          -- Cloud-Native/Container Category
          -- Virtualization Category
          -- Enterprise Applications Category
          -- Server Category
          -- Local Escalation of Privilege Category
          -- Automotive Category

Of course, no Pwn2Own competition would be complete without us crowning a Master of Pwn (Meister von Pwn?). Since the order of the contest is decided by a random draw, contestants with an unlucky draw could still demonstrate fantastic research but receive less money since subsequent rounds go down in value. However, the points awarded for each unique, successful entry do not go down. Someone could have a bad draw and still accumulate the most points. The person or team with the most points at the end of the contest will be crowned Master of Pwn, receive 65,000 ZDI reward points (instant Platinum status), a killer trophy, and a pretty snazzy jacket to boot.

Let's look at the details of the rules for this year's event.

AI Category

We’re excited to introduce this category as it goes beyond what other AI “hackathons” have done already. In the past, AI Hackathons have focused on using AI to develop vulnerabilities or other offensive frameworks. We're opening up the AI infrastructure that is used to run models for exploitation - vector databases, frameworks for running models, and development toolkits. An attempt in this category must be launched from the contestant’s laptop. For the NVIDIA Container Toolkit target, the attempt must be launched from within a crafted container image and execute arbitrary code on the host operating system.

Back to top

Web Browser Category

While browsers are the “traditional” Pwn2Own target, we’re continuously tweaking the targets in this category to ensure they remain relevant. We re-introduced renderer-only exploits a couple of years ago, and their reward remains at $60,000. However, if you have that Windows kernel privilege escalation or sandbox escape, that will earn you up to $100,000 or $150,000 respectively. The Windows-based targets will be running in a VMware Workstation virtual machine. Consequently, all browsers (except Safari) are eligible for a VMware escape add-on. If a contestant can compromise the browser in such a way that also executes code on the host operating system by escaping the VMware Workstation virtual machine, they will earn themselves an additional $80,000 and 8 more Master of Pwn points. Full exploits are still required for Apple Safari and Mozilla Firefox. Here’s a detailed look at the targets and available payouts:

Back to top

Cloud-Native/Container Category

We’re excited to have this category return for its sophomore season, and we’re hopeful even more contestants will target one of these container targets. For an attempt to be ruled a success against these three, the exploit must be launched from within the guest container/microVM and execute arbitrary code on the host operating system. The final target in this category is gRPC – a modern open-source high-performance Remote Procedure Call (RPC) framework that can run in any environment.  A success here must leverage a vulnerability in the gRPC code base to obtain arbitrary code execution. Here are the payouts for this category:

Back to top

Virtualization Category

Some of the highlights for each contest can be found in the Virtualization Category, and we’re thrilled to see what this year’s event could bring with it. As usual, VMware is the main highlight of this category as we’ll have VMware ESXi alongside VMware Workstation as a target with awards of $150,000 and $80,000 respectively. Microsoft also returns as a target and leads the virtualization category with a $250,000 award for a successful Hyper-V Client guest-to-host escalation. Oracle VirtualBox rounds out this category with a prize of $40,000.

There’s an add-on bonus in this category as well. If a contestant can escape the guest OS, then escalate privileges on the host OS through a Windows kernel vulnerability (excluding VMware ESXi), they can earn an additional $50,000 and 5 more Master of Pwn points. That could push the payout on a Hyper-V bug to $300,000. Here’s a detailed look at the targets and available payouts in the Virtualization category:

Back to top

Enterprise Applications Category

Enterprise applications return as targets with Adobe Reader and various Office components on the target list once again. Attempts in this category must be launched from the target under test. For example, launching the target under test from the command line is not allowed. Prizes in this category run from $50,000 for a Reader exploit with a sandbox escape or a Reader exploit with a kernel privilege escalation and $100,000 for an Office 365 application. Word, Excel, and PowerPoint are all valid targets. Microsoft Office-based targets will have Protected View enabled where applicable. Adobe Reader will have Protected Mode enabled where applicable. Here’s a detailed view of the targets and payouts in the Enterprise Application category:

Back to top

Server Category

The Server Category for 2025 focuses solely on the server components we’re most interested in. These servers are often targeted by everyone from ransomware crews to nation/state actors, so we know there are exploits out there for them. The only question is whether we’ll see any of the competitors bring one of those exploits to Pwn2Own. SharePoint has been exploited in the wild, and in one case, part of that exploit chain was demonstrated at Pwn2Own. Microsoft Exchange has been a popular target for some time, and it returns as a target this year as well, with a payout of $200,000. This category is rounded out by Microsoft Windows RDP/RDS, which also has a payout of $200,000. Here’s a detailed look at the targets and payouts in the Server category:

Back to top

Local Escalation of Privilege Category

This category is a classic for Pwn2Own and focuses on attacks that originate from a standard user and result in executing code as a high-privileged user. A successful entry in this category must leverage a kernel vulnerability to escalate privileges. We’ve swapped Ubuntu Desktop for Red Hat Enterprise Linux for Workstations, while Apple macOS, and Microsoft Windows 11 return as targets in this category. Last year, an exploit demonstrated at Pwn2Own won the Pwnie Award for Best Privilege Escalation. It would be interesting if a Pwn2Own bug could go back-to-back. Here’s a detailed look at the targets and payouts in this category:

Back to top

Automotive Category

Since adding the Automotive Category in 2019, we’ve seen some amazing and creative research displayed – so much so that we expanded to holding a Pwn2Own Automotive event. Still, we’re happy to have Tesla return as a target for this event. As previously mentioned, we’ve streamlined the rules for this category this year, but that doesn’t mean it’s any easier to win. We’ll have both the 2024 Tesla Model 3 and 2025 Tesla Model Y bench-top units available as targets. We conduct all tests on the bench-top units as attempting the exploits on an actual vehicle could prove hazardous to bystanders and other vehicles in the area. Here are this year’s awards for the Automotive Category:

Back to top

Conclusion

The complete rules for Pwn2Own 2025 are found here. As always, we encourage entrants to read the rules thoroughly if they choose to participate. If you are thinking about participating but have specific configuration or rule-related questions, email us. Questions asked over X (nee Twitter), BlueSky, Instagram, or other means will not be answered. Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at pwn2own@trendmicro.com to begin the registration process. Registration for onsite participation closes at 5 p.m. Central European Time on May 8, 2025.

Be sure to stay tuned to this blog and follow us on Twitter, Mastodon, LinkedIn, or Bluesky for the latest information and updates about the contest. We look forward to seeing everyone in Germany, and we hope someone has a new car to drive home from this year’s Pwn2Own competition.

With special thanks to our Pwn2Own 2025 partner Tesla

©2025 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, TREND ZERO DAY INITIATIVE, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

We’ve survived Pwn2Own Automotive and made it to the second Patch Tuesday of 2025. As always, Microsoft and Adobe have released their latest security patches. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for February 2025

For February, Adobe released seven bulletins addressing 45 CVEs in Adobe InDesign, Commerce, Substance 3D Stager, InCopy, Illustrator, Substance 3D Designer, and Adobe Photoshop Elements. The largest by far is the update for Commerce with 31 CVEs addressed. While there are some cross-site scripting (XSS) bugs addressed, there are also some security feature bypasses and Critical-rated code execution bugs, too. The update for InDesign fixes seven bugs, four of which are rated Critical. The three bugs in Illustrator are also rated Critical and could lead to arbitrary code execution when opening a malicious file.

The patch for Substance 3D Stager fixes a single DoS bug. The fix for InCopy is also a single bug, but this one is a Critical-rated code execution. That’s the same case of the Substance 3D Designer patch. The final Adobe patch for February covers an Important-rated privilege escalation in Photoshop Elements.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for February 2025

This month, Microsoft released 57 new CVEs in Windows and Windows Components, Office and Office Components, Azure, Visual Studio, and Remote Desktop Services. Two of these were submitted through the Trend ZDI program. With the addition of the third-party CVEs, the entire release tops out at 67 CVEs.

Of the patches released today, four are rated Critical, 52 are rated Important, and one is rated Moderate in severity. After a couple of record-breaking releases, this volume of fixes is more in line with expectations. Let’s hope this trend, rather than monster releases, remains the norm for 2025.

Two of these bugs are listed as publicly known, and two others are listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bugs currently being exploited:

-  CVE-2025-21391 - Windows Storage Elevation of Privilege Vulnerability
This is one of the bugs being exploited in the wild receiving a patch in this month’s release, and it’s a type of bug we haven’t seen exploited publicly. The vulnerability allows an attacker to delete targeted files. How does this lead to privilege escalation? My colleague Simon Zuckerbraun details the technique here. While we’ve seen similar issues in the past, this does appear to be the first time the technique has been exploited in the wild. It’s also likely paired with a code execution bug to completely take over a system. Test and deploy this quickly.

-   CVE-2025-21418 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
This is the other bug being actively exploited, but it’s a more traditional privilege escalation than the other one. In this case, an authenticated user would need to run a specially-crafted program that ends up executing code with SYSTEM privileges. That’s why these types of bugs are usually paired with a code execution bug to take over a system. Microsoft doesn’t provide any information on how widespread these attacks are, but regardless of how targeted the attacks may be, I would test and deploy these patches quickly.

-   CVE-2025-21376 - Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
This vulnerability allows a remote, unauthenticated attacker to run their code on an affected system simply by sending a maliciously crafted request to the target. Since there’s no user interaction involved, that makes this bug wormable between affected LDAP servers. Microsoft lists this as “Exploitation Likely”, so even though this may be unlikely, I would treat this as an impending exploitation. Test and deploy the patch quickly.

-  CVE-2025-21387 - Microsoft Excel Remote Code Execution Vulnerability
This is one of several Excel fixes where the Preview Pane is an attack vector, which is confusing as Microsoft also notes that user interaction is required. They also note that multiple patches are required to address this vulnerability fully. This likely can be exploited either by opening a malicious Excel file or previewing a malicious attachment in Outlook. Either way, make sure you get all the needed patches tested and deployed.

Here’s the full list of CVEs released by Microsoft for February 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.
† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the other Critical-rated bugs, there’s a code execution bug in the DHCP server, but it can only be accessed by Adjacent attackers. It also requires a machine-in-the-middle (MITM) exploit, so this bug is definitely unlikely to be exploited in the wild. The other Critical-rated bug is in Microsoft Dynamics 365 and has already been addressed by Microsoft, so there’s no action here.

Looking at the other code execution bugs, many patches impact Excel and other Office components. Many of the Excel bugs have the Preview Pane as an attack vector as well, but again, Microsoft notes that user interaction is required. Some of these updates require multiple patches, so please pay attention when you’re deploying updates. The bug in SharePoint does require special privileges, but anyone who can create a site in SharePoint has the appropriate privileges. Two bugs in Digest Authentication can be hit remotely, but they do require authentication. The Telephony Service and Routing and Remote Access Service (RRAS) have several fixes, but none of these are likely to be exploited. The final RCE bug is in the High Performance Compute (HPC) Pack that could allow attackers the ability to perform RCE on other clusters or nodes connected to the targeted head node. HPC Clusters are often complex, but there’s just a single patch to test and deploy here.

There are a handful of privilege escalation bugs receiving fixes in this month’s release, and most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. One of these was reported by Trend ZDI’s Simon Zuckerbraun. CVE-2025-21373 is a link-following bug. Though the “msiserver” service is protected by the Redirection Guard mitigation, the mitigation can be bypassed if the attacker can mount an NTFS-formatted removable drive such as a USB drive. In this case, a low-privileged user can use this vulnerability to escalate privileges and execute code as SYSTEM.

There are some exceptions to this style of privilege escalation bugs. The vulnerability Windows Setup Files could allow a file deletion, similar to the bug being actively exploited. The bug in NTFS could list folder contents, but it’s not clear how this could lead to an escalation. The bug in AutoUpdate is only in the macOS version and leads to root permissions. Microsoft doesn’t provide details about the bug in Azure Network Watcher other than to say an attack would need Contributor or Owner permissions. Finally, the bugs in Visual Studio would allow an attacker to gain the rights of the user running the affected application.

There are two security feature bypass (SFB) bugs included in this release, and the bug in Microsoft Surface is listed as publicly known. This could allow an attacker to avoid UEFI protections, but there are a mountain of caveats to exploitation. The bug in the kernel is interesting from a policy perspective. The vulnerability allows an attacker to bypass the user access control (UAC) prompt. Microsoft used to not fix bugs of this nature as they claimed UAC was not a security boundary – therefore, UAC bypasses weren’t a security bug. With this fix, Microsoft quietly announces it has changed its mind about this policy.

There’s only one information disclosure bug this month, and that’s for Excel. It only results in info leaks consisting of unspecified memory contents. There’s also a single Tampering bug in Remote Desktop, but Microsoft doesn’t say what is being tampered with. They do note it requires a MITM attack.

There are nine different Denial-of-Service (DoS) bugs getting fixed this month, and as usual, details are sparse. The bugs in the DHCP server and Internet Connection Sharing (ICS) service require a network adjacent attacker. Others require attackers to send specially crafted messages to the target. However, the bug in Windows Deployment Services is different. To begin with, it’s a local bug and requires authentication. The attacker could overwrite file contents and cause the service to be unavailable.

Finally, there are three spoofing bugs fixed in the release. The first is a publicly known bug in NTLM. As expected, NTLM spoofing means relaying an NTLMv2 hash. The spoofing bug in Outlook impacts your Junk folder and could make it appear as though the sender is someone else. Microsoft provides no information about the bug in Edge for iOS and Android. If you’re one of the dozens out there using Edge on iOS or Android, go to your respective app store and download the updates.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on March 11, and I’ll return with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

It’s a new year, but before we look forward to breaking all of our resolutions, let’s pause to take a look at the year that was for Trend Zero Day Initiative™ (ZDI).

Pwn2Own Competitions Keep Exceeding Expectations

Even though we just completed Pwn2Own Automotive 2025, we would be remiss if we didn’t mention the inaugural edition that occurred in January 2024. That contest brought together some of the best automotive researchers around the globe to the biggest (literally) Pwn2Own stage in history. The event garnered more participation than expected, as we awarded a record-setting amount of $1,323,750 for the discovery of 49 unique zero-day vulnerabilities across the three days of competition. From there, we moved on to Vancouver, where Manfred Paul wowed us all by hacking Chrome, Edge, Firefox, and Safari on his way to winning Master of Pwn. That event awarded $1,132,500 for 29 unique 0-days and also saw the first Docker escape at a Pwn2Own event. We ended by moving to Ireland and our Cork offices. This contest also saw the end of remote participation and required all contestants to be onsite. Over the four days of the contest, we awarded $1,066,625 for over 70 0-day vulnerabilities. That means Pwn2Own awarded over $3,500,000 in 2024 for 148 unique 0-days.

Figure 1 - Ken Gannon exploiting the Samsung Galaxy S24 at Pwn2Own Ireland

By the Numbers

In 2024, Trend ZDI published 1,741 advisories, which is down slightly from last year’s record high of 1,913 (more on that in a bit). While not a record-setting year, we’re just fine with that total. We don’t need to set a new mark every year – it’s just not sustainable. And while we do work with some of the best researchers from around the globe, our own researchers had a great year, too. Just over 40% of all published advisories were reported by Trend ZDI security researchers. Here’s how those numbers of advisories stack up year-over-year. 

Figure 2 - Published advisories over the lifetime of the program

Coordinated disclosure of vulnerabilities continues to be a priority for our program, and it continues to be a success as well. While 2020 saw our largest percentage of 0-day disclosures, the number declined over the next two years. However, while this number grew in 2023, it was down slightly in 2024. It decreased from 10.2% of disclosures to 9.7% - so not too much of a change at all.

Figure 3 - 0-day disclosures per year

Here’s a breakdown of advisories by vendor. While the top vendor (AutoDesk) may surprise you, we’ve worked with them extensively this year to improve their products. They’ve actually been a great partner to work with. The number two vendor, Delta Electronics, should also indicate to you the state of ICS/SCADA security, which we believe is still not up to par with their enterprise counterparts. This also marks the first year that we reported more Apple bugs than Adobe bugs, but something tells me that the trend won’t continue in 2025. Speaking of Adobe, PDF parsing remains a security challenge for vendors beyond just Acrobat and Reader. Foxit, Kofax/Tungsten Automation, and PDF-XChange all had a significant number of file parsing bugs reported by Trend ZDI.

Figure 4 - Vendor distribution of published advisories in 2024

Of course, we’re always looking to acquire impactful bugs, and here’s an interesting comparison from 2023. Even though we published fewer bugs in 2024, we disclosed more Critical and High severity bugs in 2024 than we did in 2023. We put quality over quantity.

Figure 5 - CVSS distribution of published advisories in 2024

Here’s how that compares to previous years:

Figure 6 - Distribution of CVSS scores from 2015-2024

When it comes to the types of bugs we’re buying, here’s a look at the top 10 Common Weakness Enumerations (CWEs) from 2024:

Figure 7 - Top CWEs of published advisories in 2024

It’s a bit disconcerting to see so many “simple” bugs, such as stack overflows and SQL injections, still account for so many bugs. Let’s hope that changes in 2025.

Looking Ahead

Moving into the new year, we anticipate staying just as busy. We just completed Pwn2Own Automotive 2025 and have a special announcement about our next Pwn2Own contest coming up soon. Don’t worry if you can’t attend in person. We’ll be streaming and posting videos of the event to just about every brand of social media available. We also have more than 350 cases waiting to be patched, and our incoming queue is overflowing as we’re still catching up.

We’re also looking to update our website and blog at some point this year. I know – I said that last year as well, but this time, I mean it. When that occurs, I promise I’ll do everything possible to ensure you will be able to choose between a light and dark theme. We’re also hoping to expand our video offerings, and I’ll continue offering the Patch Report on Patch Tuesdays and hope to tweak the format a bit in the coming year.

As always, we look forward to refining our outreach and acquisition efforts by further aligning with the risks our customers are facing to ensure the bugs we squash have the biggest impact on our customers and the broader ecosystem. In other words, 2025 is shaping up to be another exciting year with impactful research, great contests, and real information you can use. We hope you come along for the ride. Until then, be well, stay tuned to this blog, subscribe to our YouTube channel, and follow us on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Welcome to the third and final day of Pwn2Own Automotive 2025. Over the past two days, we have awarded $718,250 for 39 unique 0-days. Sina Kheirkhah has a commanding lead for Master of Pwn, but anything can happen. Here’s a look at today’s results…

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a single bug to exploit the ChargePoint EV charger. He earns himself another $25,000 and 5 Master of Pwn points.

SUCCESS - The Synacktiv (@Synacktiv) team used a single integer overflow to exploit the Sony IVI. Their work earns them another $10,000 and 2 Master of Pwn points.

SUCCESS - The Synacktiv (@Synacktiv) team used a single buffer overflow to exploit the Autel MaxiCharger. They were also able to demonstrate signals being transmitted via the Charging Connector for the add on. This work earns them $35,000 and 6 Master of Pwn points.

SUCCESS/COLLISION - Bongeun Koo (@kiddo_pwn) of STEALIEN used three bugs to exploit the Ubiquiti charger, but two were already known. He still wins $26,750 and 4.5 Master of Pwn points.

SUCCESS - Thanh Do (@nyanctl) of Team Confused was able to confuse the Alpine iLX-507 with a single stack buffer overflow. The unique bug earns him $10,000 and 2 Master of Pwn points.

SUCCESS - The PHP Hooligans again show their expertise by using a single OS command injection bug to exploit the Kenwood DMX958XR. Their final attempt of the contest earns them another $10,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io used a two bug chain - including an uninitialized variable - to exploit the WOLFBOX EV charger. However, one of these bugs was previously known. The earn $18,750 and 2 Master of Pwn points.

COLLISION - Rob Blakely and Andres Campuzano of the Technical Debt Collectors successfully exploited the Tesla Wall Connector, but they used a previously known bug. They still earn $12,500 and 2.5 Master of Pwn points.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a command injection bug for his last exploit of the contest. He was able to pop the Alpine iLX-507 and earn himself another $10,000 and 2 more Master of Pwn points.

SUCCESS - The final attempt of the contest was the Pwn2Own debut of Evan Grant (@stargravy). He successfuly used an OS command injection bug to exploit the Kenwood DMX958XR. His unique approach earns him $10,000 and 2 Master of Pwn points.

And that’s a wrap! Pwn2Own Automotive 2025 is complete. In total, we awarded $886,250 for 49 0-days over the three day competition. With 30.5 points and $222,250 awarded, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) is our Master of Pwn. Here’s the top five standings:

Thanks to all of the researchers and vendors who attended. Without their hard work and dedication, none of this would be possible. Thanks also to our partners at VicOne and our sponsor Tesla. Their partnership has been invaluable. Stay tuned for upcoming announcements about future Pwn2Own competitions. We have a lot in store. See you then!

Welcome to the second day of Pwn2Own Automotive 2025. Yesterday, we awarded more than $380,000 for 16 unique 0-days - and we had several bug collisions as well. Today looks to be even better, with the WOLFBOX and Tesla EV chargers making their Pwn2Own debut. Here’s how the Master of Pwn standings look at the beginning of Day Two:

We’ll see how they look at the end of the day. Here are the Day Two results, which we will be updating throughout the competition.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) combined a couple of bugs to exploit the WOLFBOX charger and introduce it to the world of Pwn2Own. His efforts earn him $50,000 and 5 Master of Pwn points.

SUCCESS - The Tesla Wall Connector has been christened by the PHP Hooligans. They used a Numeric Range Comparison Without Minimum Check bug (CWE-839) to take over the machine and crash it. They earn $50,000 and 5 Master of Pwn points.

SUCCESS/COLLISION - The team of @vudq16, @tacbliw, and @_q5ca from Viettel Cyber Security (@vcslab) used a command injection combined with a known bug to exploit the ChargePoint HomeFlex. They earn $18,750 and 3.75 Master of Pwn points.

SUCCESS - We were definitely thrilled to see Cong Thanh (@ExLuck99) and Nam Dung (@greengrass19000) of ANHTUD use a command injection bug to exploit the Alpine iLX-507 and leave us a special message. Their round 2 win earns them $10,000 and 2 Master of Pwn points.

COLLISION - The ZIEN, Inc. (@zien_security) of HANRYEOL PARK (@hanR0724), HYOJIN LEE (@meixploit), HYEOKJONG YUN (@dig06161), HYEONJUN LEE (@gul9ul), DOWON KWAK (@D0uneo), YOUNGMIN CHO (@ZIEN0621) successfully exploited the Kenwood DMX958XR, but they used a known bug. They still win $5,000 and 5 Master of Pwn points.

SUCCESS - The folks from HT3 Labs (@ht3labs) used a missing authentication bug combined with an OS command injection to exploit the Phoenix Contact CHARX. Their 2nd round win nets them $25,000 and 5 Master of Pwn points.

COLLISION - Although the team of Radu Motspan (@moradek), Polina Smirnova (@moe_hw) and Mikhail Evdokimov (@konatabrk) from PCAutomotive successfully exploited the Tesla Wall Connector, the bug they used was previously known. The still earn $22,500 and 3.5 Master of Pwn points.

FAILURE - Unfortunately, the team o Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io could not get their exploit of the ChargePoint HomeFlex working within the time allotted.

SUCCESS/COLLISION - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) combined six different bugs, improper access control and stack-based buffer overflows, to exploit the Autel MaxiCharger. However, one of the bugs he used was previously known. He still earns $23,000 and 4.75 Master of Pwn points.

COLLISION - Although the Pony 74 team successfully exploited the Kenwood DMX958XR, the bug they used was previously known. They still earn $5,000 and 1 Master of Pwn point.

SUCCESS - The GMO Cybersecurity by Ierae, Inc. team combined an improper certificate validation bug to a path traversal to exploit the Alpine iLX-507. Their second round win earns them $10,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - Rafal Goryl of PixiePoint Security used a 2 bug chain to exploit the WOLFBOX Level 2 EV Charger, but one of the bugs was previously known. He earns himself $18,750 and 3.75 Master of Pwn points.

SUCCESS - Radu Motspan (@moradek), Polina Smirnova (@moe_hw) and Mikhail Evdokimov (@konatabrk) of PCAutomotive chained three different bugs (a heap overflow, an authentication bypass, and an improper isolation bug) to exploit the Sony XAV-AX8500 with 0 clicks. Their third round win nets them $10,000 and 2 Master of Pwn points.

SUCCESS - Sina Kheirkhah (@SinSinology) of the Summoning Team (@SummoningTeam) continues his successful run at the contest continues as he uses a command injection bug to exploit the Kenwood DMX958XR. His second round win earns him another $10,000 and 2 Master of Pwn points.

SUCCESS - The team from Synacktiv used a logic bug as a part of their chain to exploit the Tesla Wall Connector via the Charging Connector. Their outstanding (and inventive) research earns them $45,000 and 7 Master of Pwn points.

COLLISION - The CIS Team exploited the Alpine IVI but used a known bug. The ghost of CVE-2024-23924 rears its head as the specter of "shared risk" lingers. The unfixed Alpine bug from last year strikes again. The CIS Team still earns $5,000 and 1 Master of Pwn points.

FAILURE - Unfortunately, the PHP Hooligans could not get their exploit of the WOLFBOX Level 2 EV Charger working within the time allotted.

COLLISION - The Viettel Cyber Security (@vcslab) successfully exploited the Sony XAV-AX8500, but the bug they used was previously know. They earn $5,000 and 1 Master of Pwn point.

FAILURE - Unfortunately, the fuzzware.io could not get their exploit of the EMPORIA EV Charger Level 2 EV Charger working within the time allotted.

COLLISION - In his final attempt of the day, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a two bug chain to exploit the Tesla Wall Connector. However, both were already known by the vendor. This bug collision still earns him $12,500 and 2.5 Master of Pwn points.

FAILURE - Unfortunately, Compass Security (@compasssecurity) could not get their exploit of the Alpine iLX-507 working within the time allotted.

SUCCESS - Our final entry of Day Two saw Juurin Oy, Elias Ikkelä-Koski and Aapo Oksman export the Kenwood DMX958XR with a command injection bug. They earn $10,000 and 2 Master of Pwn points.

That brings our Day Two total to $335,500 and the total for the event to $718,250. The teams demonstrated 23 unique 0-days today, and Sina Kheirkhah has a commanding lead for Master of Pwn. We’ll see what the final day of the contest brings.

Welcome to the first day of Pwn2Own Automotive 2025. We have 18 entries to go through today, and we will be updating the results here as we have them.

SUCCESS - The team from PCAutomotive used a stack-based buffer overflow to gain code execution on the Alpine IVI. They earn $20,000 and two Master of Pwn points.

SUCCESS - The team from Viettel Cyber Security used an OS command injection bug to exploit the Kenwood IVI for code execution. They win $20,000 and 2 Master of Pwn points.

SUCCESS - Cong Thanh (@ExLuck99) and Nam Dung (@greengrass19000) of ANHTUD used an integer overflow to gain code execution on the Sony XAV-AX8500. The earn themselves $20,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a 3 bug combo to exploit the Phoenix Contact CHARX SEC-3150, but one was publicly known. He still earns $41,750 and 4.25 Master of Pwn points.

SUCCESS/COLLISION - It took a while for us to confirm, but confirm we did! The team from Synacktiv used a stack-based buffer overflow plus a known bug in OCPP to exploit the ChargePoint with signal manipulation through the connector. They earn $47,500 and 4.75 Master of Pwn points.

SUCCESS - The PHP Hooligans used a heap-based buffer overflow to exploit the Autel charger. They earn $50,000 and 5 Master of Pwn points.

SUCCESS - The team from GMO Cybersecurity by Ierae, Inc. used a stack-based buffer overflow to to confirm their second round exploit of the Kenwood IVI. They earn $10,000 and 2 Master of Pwn points.

SUCCESS - The Viettel Cyber Security (@vcslab) team used a stack-based buffer overflow to exploit the Alpine IVI. This second round win earns the $10,000 and 2 Master of Pwn points.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) proves he's never going to give us up or let us down by using a hard-coded cryptographic key bug in the Ubiquiti charger. He earns himself $50,000 and 5 Master of Pwn points - putting him in the early lead.

SUCCESS - It may have take 3 attempts, but it's confirmed! Thanh Do (@nyanctl) of Team Confused used a heap-based buffer overflow to exploit the Sony IVI. His round 2 win nets him $10,000 and 2 Master of Pwn points.

SUCCESS - After accessing an open port via power drill, Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io leveraged a stack-based buffer overflow on the Autel MaxiCharger. Their second round win nets them $25,000 and 5 Master of Pwn points.

COLLISION - Well that's awkward. SK Shieldus (@EQSTLab) used a OS command injection bug, but it was one demonstrated in last year's contest. Alpine chose not to patch it since "in accordance with ISO21434...the vulnerability is classified as 'Sharing the Risk'." Yikes. The SK Shieldus team earns $5,000 and 1 Master of Pwn point. Check out ZDI-24-846 for details on the original bug report.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) could not get his exploit of the Sony IVI working within the time allotted. He still ends Day One of #Pwn2Own Automotive with $91,750 and 9.25 Master of Pwn points.

SUCCESS - The Synacktiv (@Synacktiv) team used an OS command injection bug to exploit the Kenwood DMX958XR and play a video of the original Doom game. Their second round win earns them $10,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - Rob Blakely and Andres Campuzano of the Technical Debt Collectors used multiple bugs to exploit Automotive Grade Linux, but one of the bugs was previously known. They still earn $33,500 and 3.5 Master of Pwn points in the 1st PwnOwn attempt.

SUCCESS - In our first Pwn2Own After Dark submission, Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io leveraged an origin validation error bug to exploit the Phoenix Contact CHARX SEC-3150. The round 2 win earns them $25,000 and 5 Master of Pwn points.

FAILURE - Unfortunately, Riccardo Mori of Quarkslab (@quarkslab) could not get his exploit of the Autel MaxiCharger AC Wallbox Commercial working within the time allotted.

COLLISION - Bongeun Koo (@kiddo_pwn) of STEALIEN also used the bug exploited in the Alpine last year. He earns $5,000 and 1 Master of Pwn point - plus lots of style points for the Nyan Cat display.

That wraps up Day 1 of #Pwn2Own Automotive 2025! In total, we awarded $382,750 for 16 unique 0-days. The team of Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io is current in the lead for Master of Pwn, but Sina Kheirkhah (@SinSinology) is right on their heels. Stay tuned tomorrow for more results and surprises. #P2OAuto

こんにちは and welcome to the second annual Pwn2Own Automotive competition. We are at Automotive World in Tokyo, and we’ve brought together some of the best researchers in the world to test the latest automotive components. We had our random drawing for the order of events earlier today, and from that, we have put together the following schedule. Please note that all times are local to Tokyo and may change at any point.

Jump to:    Day One           Day Two           Day Three

Wednesday, January 22 – 1100 

Synacktiv (@Synacktiv) targeting the ChargePoint Home Flex in the Electric Vehicle Chargers category with the Charging Connector Protocol/Signal Manipulation addon for $60000 and 6 Master of Pwn Points. 

Wednesday, January 22 – 1130 

Viettel Cyber Security (@vcslab) targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Radu Motspan (@_moradek_), Polina Smirnova (@moe_hw) and Mikhail Evdokimov (@konatabrk) of PCAutomotive targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Wednesday, January 22 – 1200 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Phoenix Contact CHARX SEC-3150 in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Wednesday, January 22 – 1230 

Cong Thanh (@ExLuck99) and Nam Dung (greengrass19000) of ANHTUD targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Wednesday, January 22 – 1300 

PHP Hooligans targeting the Autel MaxiCharger AC Wallbox Commercial in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Wednesday, January 22 – 1330 

GMO Cybersecurity by Ierae, Inc. targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Viettel Cyber Security (@vcslab) targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points.  

Wednesday, January 22 – 1400  

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Ubiquiti Connect EV Station in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Wednesday, January 22 – 1430 

Thanh Do (@nyanctl) of Team Confused targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Wednesday, January 22 – 1500 

Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io targeting the Autel MaxiCharger AC Wallbox Commercial in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Wednesday, January 22 – 1530 

Synacktiv (@Synacktiv) targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

SK Shieldus(@EQSTLab) targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Wednesday, January 22 – 1600 

Rob Blakely and Andres Campuzano of the Technical Debt Collectors targeting the Automotive Grade Linux in the Operating System category for $40000 and 4 Master of Pwn Points. 

Wednesday, January 22 – 1630 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Pwn2Own After Dark 

Wednesday, January 22 – 1700 

Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io targeting the Phoenix Contact CHARX SEC-3150 in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Riccardo Mori of Quarkslab (@quarkslab) targeting the Autel MaxiCharger AC Wallbox Commercial in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Wednesday, January 22 – 1730 

Bongeun Koo(@kiddo_pwn) of STEALIEN targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Back to top

Thursday, January 23 – 1100 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the WOLFBOX Level 2 EV Charger in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

PHP Hooligans targeting the Tesla Wall Connector in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Viettel Cyber Security (@vcslab) targeting the ChargePoint Home Flex in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Thursday, January 23 – 1200 

The ZIEN, Inc. (@zien_security) [HANRYEOL PARK (@hanR0724), HYOJIN LEE (@meixploit), HYEOKJONG YUN (@dig06161), HYEONJUN LEE (@gul9ul), DOWON KWAK (@D0uneo), YOUNGMIN CHO (@ZIEN0621)] targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Cong Thanh (@ExLuck99) and Nam Dung (greengrass19000) of ANHTUD targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Thursday, January 23 – 1300 

HT3 Labs (@ht3labs) targeting the Phoenix Contact CHARX SEC-3150 in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Radu Motspan (@_moradek_), Polina Smirnova (@moe_hw) and Mikhail Evdokimov (@konatabrk) of PCAutomotive targeting the Tesla Wall Connector in the Electric Vehicle Chargers category with the Charging Connector Protocol/Signal Manipulation addon for $60000 and 6 Master of Pwn Points. 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Autel MaxiCharger AC Wallbox Commercial  in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Thursday, January 23 – 1400 

Pony 74 targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

GMO Cybersecurity by Ierae, Inc. targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Thursday, January 23 - 1500 

Rafal Goryl of PixiePoint Security targeting the WOLFBOX Level 2 EV Charger in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Radu Motspan (@_moradek_), Polina Smirnova (@moe_hw) and Mikhail Evdokimov (@konatabrk) of PCAutomotive targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io targeting the ChargePoint Home Flex in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Thursday, January 23 – 1600 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Synacktiv (@Synacktiv) targeting the Tesla Wall Connector in the Electric Vehicle Chargers category with the Charging Connector Attack addon for $70000 and 7 Master of Pwn Points. 

CIS Team targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Pwn2Own After Dark 

Thursday, January 23 – 1700  

PHP Hooligans targeting the WOLFBOX Level 2 EV Charger in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Viettel Cyber Security (@vcslab) targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io targeting the EMPORIA EV Charger Level 2 in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Thursday, January 23 – 1800 

Juurin Oy, Elias Ikkelä-Koski and Aapo Oksman targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Tesla Wall Connector in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Compass Security (@compasssecurity) targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Back to top

Friday, January 24 – 1100  

Bongeun Koo(@kiddo_pwn) of STEALIEN targeting the Ubiquiti Connect EV Station in the Electric Vehicle Chargers category with the Charging Connector Protocol/Signal Manipulation addon for $60000 and 6 Master of Pwn Points. 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the ChargePoint Home Flex in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Friday, January 24 – 1130 

Synacktiv (@Synacktiv) targeting the Sony XAV-AX8500 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Friday, January 24 – 1200 

PHP Hooligans targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Thanh Do (@nyanctl) of Team Confused targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Friday, January 24 – 1230 

Tobias Scharnowski (@ScepticCtf), Felix Buchmann (@diff_fusion), and Kristian Covic (@SeTcbPrivilege) of fuzzware.io targeting the WOLFBOX Level 2 EV Charger in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Friday, January 24 – 1300 

Rob Blakely and Andres Campuzano of the Technical Debt Collectors targeting the Tesla Wall Connector in the Electric Vehicle Chargers category for $50000 and 5 Master of Pwn Points. 

Synacktiv (@Synacktiv) targeting the Autel MaxiCharger AC Wallbox Commercial in the Electric Vehicle Chargers category with the Charging Connector Protocol/Signal Manipulation addon for $60000 and 6 Master of Pwn Points. 

Friday, January 24 – 1400 

Evan Grant (@stargravy) targeting the Kenwood DMX958XR in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points. 

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting the Alpine iLX-507 in the In-Vehicle Infotainment (IVI) category for $20000 and 2 Master of Pwn Points.

The Results

We’ll be blogging and tweeting results in real-time throughout the competition. Be sure to keep an eye on the blog for the latest information. We’ll also be posting live results on Twitter, Mastodon, LinkedIn, and Bluesky, so follow us on your favorite social platform for the latest news, and keep an eye on the #P2OAuto hashtag for continuing coverage.

©2025 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

For the upcoming Pwn2Own Automotive contest, a total of four in-vehicle infotainment (IVI) head units have been selected as targets. One of these is the single-DIN Pioneer DMH-WT7600NEX. This unit offers a variety of functionality, such as wired and wireless Android Auto and Apple CarPlay, USB media playback, and more.

This blog post aims to detail some of the attack surfaces of the DMH-WT7600NEX unit as well as provide information on how to extract the software running on this unit for further vulnerability research.

Software Extraction

The initial effort to locate a serial console in the hope of easy software extraction bore no fruit. This left only a handful of options:

·      Work with the software update package instead. However, the package was found to be encrypted, making this approach a dead end initially; more on that below.
·      Attempt to desolder the eMMC chip and dump its contents using a programmer. This necessitates reballing and resoldering the eMMC chip, which is risky without proper SMD rework equipment.
·      Attempt to extract eMMC contents in-system. This does not require any SMD rework, but the signal locations must be known, and the system must be powered and held in reset while dumping is in progress.

The researchers chose the last option. Connecting to the eMMC chip could be performed via (thankfully labeled) test points on the board. The missing MMC_CLK signal was probed for using an oscilloscope; here is where it was found after numerous attempts.

In addition to that, the main SoC was held in reset by pulling the test point labelled RSTN to ground via a 220 Ohm resistor and a switch.

Note that when the SoC is held in reset, the 3.3V power line is cycled periodically by some other component, which powers off the eMMC chip. This is likely some watchdog component attempting to bring the system out of a hung state. Finding that component and persuading it not to do that was deemed too time consuming, and the 3.3V power rail was instead powered directly through a bench power supply.

Data at Rest

After the eMMC chip was successfully “backed up,” it was time for Trend ZDI researchers to have a look at the 8 gigabytes of its contents. The image was found to sport a GPT partition table, with the following partitions defined after mounting the image via the loopback interface on a test system:

There are two sets of bootable images, consisting of the header, boot, system, dtb, hirtos, bootloader, chips, and backup partitions. It is likely this is to safeguard against failed software updates, so there is a known good set of bootable images. Let’s have a closer look at what is contained in each partition:

·      The header partition contains what looks like to be a description of other partitions in the set.
·      The bootloader partition contains the bootloader as described, which seems to be a version of fastboot.
·      The boot partition contains the Android/Linux kernel version 3.18.24.
·      The dtb partition contains the DTB blob as described.
·      The system partition contains the root file system.
·      The hirtos partition contains a firmware image with ARM instructions. The exact purpose of this code is not currently known. The image consists of several chunks of code/data; some of it is obvious ARM code while others appear to be bitmap images. The following string was found inside the first chunk: “T-Monitor/triton_TCC897x Version 2.01.00” This suggests the code is to be executed on the main SoC but likely on a separate core.
·      The chips partition contains the firmware for the GNSS daughter board.
·      The backup partition contains some kind of binary data, rather sparsely organized.

Interestingly enough, the system itself appears to be a Linux-based one; none of typical Android infrastructure could be located there. All the custom software is concentrated in /usr/local/ subdirectories.

Software Updates

Obtaining an image of the code running on the device allowed a second look at the software update format. The latest update file can be obtained from the manufacturer; unfortunately, they do not seem to list previous versions. This is justified, as downgrading the software is not officially supported anyway—as the team found out firsthand.

The software update package is structured like this:

·      A header of 0x100 bytes describing the file, specifically the header size and the total size of the image, software version in this update, plus which model the update is for.
·      An RSA signature block of 0x100 bytes, which can be verified by a certain public key hardcoded in the software. The signature covers the described header only.
·      An RSA signature block of 0x100 bytes, which can be decrypted by the same key, and which carries an AES-256 key instead of the digest.
·      Update data, encrypted with AES-256-CBC using the all-zero IV. This decrypts into a gzipped “raw” update image.

The raw update image in turn consists of headers very similar to what can be found in the header partitions followed by a series of images for each partition mentioned in the headers. The image(s) can be processed further to extract the content of interest like the root file system.

Serial Console

Armed with some knowledge of the unit’s software, it was time to revisit the search for the serial console.

By studying the contents of the bootloader partitions, Trend ZDI researchers discovered the bootloader may use values from the backup partitions to decide which values to pass via the `console` and `login` kernel parameters, among other things. Specifically, the sector at byte offset 0x800800 contains that data. The format which this data is in can be reverse engineered both from the bootloader and the NPSystemDebug class implementation. 

Notably, it appears that manipulation of these values could be performed via the UI as the code flow can be traced all the way to the `UI_UIEB_MM_99_018` class which implements two buttons changing the state of the values. However, at the moment of writing it was unknown how to reach that specific UI screen.

Thus, the direct manipulation of the flags was chosen instead. The contents of the backup partition were altered to enable both serial console and the login prompt. After probing the board connectors for any semblance of serial data, it was discovered on CN3603 pin 7.

Connecting a UART-to-USB dongle to that pin confirmed that indeed, console output is present, as well as the login prompt. Only three signals are routed to that connector; however, the RX signal was not immediately identified among those.

Studying the bottom layer of the board showed a single installed passive among several missing ones; this was one resistor pulling up a line otherwise not connected to any connector pin. Probing that line for being the missing RX line resulted in a success. Likely, one of the missing passives should connect that line to a connector pin.

Now it was possible to communicate with the device—and log in locally. Having console access is always a big boon in vulnerability research.

Bluetooth

The vendor lists the following supported Bluetooth profiles:

·      Advanced Audio Distribution Profile (A2DP)
·      Hands-Free Profile
·      Serial Port Profile
·      Audio/Video Remote Control Profile (AVRCP) v1.6

Given the rich history of bugs in Bluetooth-related functionality, this could be an interesting attack vector 

Wi-Fi

The unit can be set up in both the client and access point modes for Wi-Fi.

When in the AP mode, the unit allows using the WPS setup in addition to entering the PSK. This could potentially be an interesting attack angle as WPS flows were historically weak to attacks.

After connecting to the unit in AP mode and running a network scan, the following TCP ports were found to be open: 5000, 38000, 38001, 42000, 43000, and 60000. Nmap script scan only showed that port 5000 uses TLS with a self-signed certificate; other services were not recognized. Using the console access, it is possible to map out the open ports to the corresponding processes (only ports allowed through the iptables are shown here for brevity):

Given the abundance of what looks like non-standard services, Wi-Fi connectivity presents a potenially rewarding target for vulnerability research.

USB

The unit is equipped with a single USB-C port that provides the necessary interface for wired Android Auto and Apple CarPlay. The USB port also supports playback of audio files from a USB flash drive. The supported audio filetypes are 

·      MP3
·      WMA
·      WAV
·      AAC
·      FLAC
·      DSD

The unit also supports video playback with the following formats listed as supported:

·      AVI
·      MPEG
·      DivX
·      MP4
·      3GP
·      MKV
·      FLV
·      WMV/ASF
·      M4V
·      H.263, H.264

In addition, it is also possible to view images in BMP, JPEG, and PNG formats. Parsing complex file formats is error-prone and has been a rich source of exploitable bugs since time immemorial.

Android Auto and Apple CarPlay

Both wired and wireless Android Auto and Apple CarPlay are supported without the need for a third-party application to be installed on the paired mobile phone. When using the wireless versions, the paired phone connects to the aforementioned Wi-Fi network to establish a high-bandwidth channel for data to be sent and received. When connecting using a USB cable, the Wi-Fi network isn't used by Android Auto or Apple CarPlay and can be disabled in Settings. As evidenced above, the `Media` process is likely responsible for handling both.

Pwn2Own Automotive 2024 didn’t see any entries that leveraged Android Auto or Apple CarPlay functionality to compromise a head unit. We will have to wait and see if Pwn2Own Automotive 2025 does!

Summary

We hope that this blog post has provided enough information about the Pioneer DMH-WT7600NEX attack surface to guide vulnerability research. Not every attack surface has been mentioned, and we encourage researchers to investigate further. 

We are looking forward to Automotive Pwn2Own, again to be held in January 2025 at the Automotive World conference in Tokyo. We will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions or register! We hope to see you there.

You can find me on Mastodon at @InfoSecDJ, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Previously, we covered the internals of the Autel MaxiCharger where we highlighted each of the main components. In this post, we aim to outline the attack surface of the MaxiCharger in the hopes of providing inspiration for vulnerability research.

All information has been obtained through reverse engineering, experimenting, and combing through the Autel MaxiCharger manual (PDF).

At the time of writing the following software versions were applicable:

·      Autel Charge app v3.0.7
·      Autel Config app v2.1.0
·      Autel MaxiCharger modules:
·      Charge Control v1.36.00
·      Power Control v1.21.00
·      LCD Control v0.99.31
·      LCD Information v0.99.08
·      LCD Resources v0.99.08
·      LCD Languages v0.04.04

Mobile Applications

Autel has published two mobile applications for both Android and iOS. The main app is called Autel Charge and contains functionality intended for end users. Some of the features include:

·      Defining charging schedules
·      Load balancing
·      Providing Wi-Fi credentials for the charger to use
·      Forcing firmware updates
·      OCPP server selection (including custom servers)
·      Current limiting
·      Finding other chargers on a map
·      Checking charger version information

Upon loading the app on a rooted Android device a superuser request can be seen. This was unexpected and points towards the app employing anti-reversing measures. Denying the request loads the app normally.

Figure 1: Autel Charge superuser request

After denying the superuser request a new Autel account can be created using an email address.

The second app is named Autel Config and allows installers / technicians to configure chargers and manage tickets. Unlike the Autel Charge app, there is no option to register for an account and providing Autel Charge account credentials doesn't work. This suggests that installers / technicians have some other way of obtaining valid credentials.

Further research into these apps could be valuable to better understand how the apps and charger communicate.

Network Traffic Analysis

Using the Autel Charge app the MaxiCharger was configured to connect to a researcher controlled Wi-Fi network in order to monitor the network traffic. The app and charger were then left idling whilst the traffic was captured.

A few DNS requests were sent out from the charger (192.168.200.66) for Autel related infrastructure.

Figure 2: Charger DNS queries

The first query was for gateway-eneprodus.autel.com which is an alias of eneprodus-alb-internet-2014464356.us-west-2.elb.amazonaws.com. This resolved to the following IP addresses (shown in the order received):

       • 54.185.127.160
       • 52.36.153.97
       • 44.240.206.177
       • 34.215.58.124

Straight after the first DNS query response a TLS session was set up and encrypted data was sent by the charger on port 443 to 54.185.127.160. Data was sent back and forth between the charger and server a few times before another DNS query was sent. The charger issued another query for gateway-eneprodus.autel.com which, as before, is an alias and returned the same IP addresses but in a different order presumably due to load balancing. This time the DNS query returned the IP addresses:

       • 34.215.58.124
       • 44.240.206.177
       • 54.185.127.160
       • 52.36.153.97

Like previously, the charger used the first IP address that was returned but this time no TLS session was set up. Plain HTTP was used.

Figure 3: HTTP traffic

Looking a bit closer showed the charger periodically sending log data to the Autel server. The server always responded with JSON that had a null data value, a 200 code value and a message value of OK.

Figure 4: HTTP POST traffic

After a while the charger made another DNS request for gateway-eneprodus.autel.com, this time the 44.240.206.177 IP address was returned first. The charger then sent a HTTP POST to /api/app-version-manager/version/upgrade/ota with device related details such as the serial number and current firmware version. The server responded with JSON containing firmware update related information including a URL to download the latest version.

Figure 5: HTTP firmware related traffic

The charger then proceeded to send a DNS request for s3.us-west-2.amazonaws.com and directly downloaded the firmware update over HTTP.

The same pattern was observed multiple times as the device downloaded firmware updates for each of its modules. A list of these modules and their versions can be viewed in the Autel Charge app by navigating to the Charger Info page.

Figure 6: MaxiCharger module versions

After the firmware was updated and the charger rebooted no further HTTP traffic was observed to the logging or firmware update endpoint, instead only HTTPS was used.

Port scanning the charger over Wi-Fi showed no open TCP or UDP ports however UDP ports 6000 and 6666 appear to be listening over the Ethernet interface. The Ethernet interface is a valid target for the competition so these 2 listening services may be worth researching further.

Bluetooth Low Energy

By default the MaxiCharger uses the device serial number as the device name when advertising over Bluetooth. Once connected there are 4 available services that offer a total of 14 characteristics. Autel Charge uses these endpoints to communicate with the charger. A dump of each service and associated characteristics is shown below.

Further research into Autel Charge and Autel Config will likely assist in understanding the bluetooth services better.

Firmware

As mentioned in the previous blog the main microcontroller has readout protection enabled however this can be bypassed using techniques covered in Jonathan Andersson's and Thanos Kaliyanakis' Blackhat EU talk. Keep an eye out for future blog posts that will cover these techniques. One of which doesn't require glitching!

The main firmware can also be acquired by sniffing the charger update process (as described in the Network Traffic Analysis section) or by reversing the app to figure out the download URLs.

The firmware of ESP32 WROOM 32D module can be dumped using the standard esptool.py from Espressif. During research it was noted that the esptool.py would sometimes fail to dump the full firmware image. To mitigate this the firmware can be dumped in smaller chunks and then stitched back together into a single blob.

Other Potential Attack Surfaces

There are a few other attack surfaces that are considered in scope and are worth mentioning. One of these is the undocumented USB C port that can be found behind a small panel on the side of the unit. There is no publicly available information about what this USB port is used for.

Also, next to the USB port is the SIM card tray. Attacks that utilize a SIM card are also considered to be in scope.

And finally, there is the RFID (NFC) reader.

Summary

Hopefully this blog post provides enough information to kickstart vulnerability research against the Autel MaxiCharger.

We are looking forward to Pwn2Own Automotive again in Tokyo in January 2025 at Automotive World, and we will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions and register! We hope to see you there.

You can find me on Twitter at @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

For the upcoming Pwn2Own Automotive contest a total of 7 electric vehicle chargers have been selected. One of these is the Autel MaxiCharger AC Wallbox Commercial (MAXI US AC W12-L-4G) which also made an appearance at the inaugural Pwn2Own Automotive last January. 

We have previously posted internal photos of the MaxiCharger in 2023 so the goal of this blog post is to present up to date internal photos of the main boards and provide additional information.

Internals

Opening the MaxiCharger is easy and involves removing a few Torx T10 screws and then prying open the edges of the housing.

The metrology board is mounted on the back part of the housing and is responsible for power monitoring, handling the input mains power and providing power to the charging cable. Most of the components mounted on the lower voltage part of the board (towards the top) are covered in conformal coating.

Figure 1: Power board

Towards the top right of the power board is the STM32F407ZGT6, which is a general purpose ARM Cortex-M4 microcontroller. Many of the pins are broken out surrounding the STM32 and are not covered in conformal coating allowing for easy probing.

UART output can be viewed using the broken-out pins above the STM32 with a baud rate of 921600bps. SWD pins are also broken out which allows for full access to the STM32 including dumping the internal flash. A cursory glance of the flash dump shows references to FreeRTOS.

The power board connects to the main board which is mounted on the top part of the housing. The main board is responsible for most of the heavy lifting, including handling Bluetooth, Wi-Fi, ethernet and more. This board isn't covered in conformal coating but quite a few of the components are under metal shielding that was removed for the following photos.

Figure 2: Main board (top)

The main board contains many labelled test points that make for easy probing.

In the top left is the Barrot BR8041A01 bluetooth module. There isn't much publicly available information about this module. The test points nearby suggest that this module is operated over UART (BT_RX, BT_TX) however sniffing these points doesn't show much other than very basic initialization even when attempting to pair a new device.

Towards the center of the board is a IS65WV10248EBLL (PDF) SRAM chip.

Flipping the main board over reveals the main processor and an ESP32. Again, there are many labelled test points.

Figure 3: Main board (underside)

The MCU is the GD32F407ZGT6 (PDF) ARM Cortex-M4. Interestingly it has been noted that Autel occasionally swap out the GD32F407ZGT6 for the STM32F407ZGT6 for unknown reasons, presumably due to supply. To the left of the battery is the broken out SWD pins for the MCU. Connecting to these pins shows that the MCU has been configured with readout protection level 1 (or "Security Protection Code low" to use GigaDevice's terminology).

Figure 4: Secured GD32 device detected

This prevents tools such as ST-Link and J-Link from dumping the internal flash, however Jonathan Andersson and Thanos Kaliyanakis Blackhat EU talk details a few very interesting bypasses that circumvent this readout protection! One such method doesn’t require glitching.

To the right of the MCU is a Winbond W25Q128JV (PDF) serial flash chip. Below is an RJ45 jack for ethernet communications. This is one of the ways the charger can connect to the internet, the other methods are Wi-Fi and over a mobile network.

There is a mysterious USB C port to the left of the MCU which doesn't have a documented use. This isn't the only USB port on the Autel that has an unknown use, but it is the only one that can be accessed without dismantling the charger.

The ESP32 module in the top left is the ESP32 WROOM 32D (PDF) which has Bluetooth and Wi-Fi capabilities. Internally the module uses the ESP32-D0WD dual core Xtensa MCU and a 4MB SPI flash chip.

Directly above the USB C port one of the GD32 UARTs is broken out. Connecting with a baud rate of 921600bps shows a lot of debugging information. Interestingly, during initialization the string "UART_WIFI_BT" is printed alongside AT commands that are sent to the ESP32 from the GD32.  When pairing a new device, many of these messages are logged.

Combining this information with the very little traffic sniffed to/from the Barrot bluetooth module over the test points hints towards the Barrot bluetooth module being redundant. It seems as though the ESP32 is used for the bluetooth operations.

To the right of the ESP32 are more broken out pins, this time for one of the ESP32 UARTs and the IO0 pin which is used for the ESP32 boot mode selection. Connecting to the UART header at 115200 baud will show the usual ESP32 boot log.

Stacked underneath the main board is the 4G board that has a SIM card tray and a mobile communications module.

Figure 5: 4G mobile communications board

The 4G module is the Quectel EC25AFXDGA (PDF) that internally uses the Qualcomm MDM9207 LTE modem which itself contains an ARM Cortex-A7 core. The SIM card tray sits to the left of the 4G module. Connecting the Autel to a mobile network is optional.

The top right of the 4G board has a micro USB port with no known use. The charger must be disassembled to access this port. Presumably this is for some kind of debugging of the 4G module.

A few pins are broken out from the 4G module along the left side of the board. Connecting to RXD and TXD at 115200 baud prints a Linux boot log which ultimately drops to a login prompt for the Quectel module.

Above the UART connection is what's labelled as "BOOT". Shorting these unpopulated headers together and then booting the charger changes the behavior of the 4G module. Notably, the UART connection doesn’t print out the Linux boot log anymore. This behavior may be linked to the aforementioned USB port but this wasn't investigated further.

Interestingly, under the 4G board is yet another unused micro USB port. This is attached to the back of the LCD board and is likely used for debugging LCD related functionality. The silkscreen also shows SWD related text.

Figure 6: Unused USB port

The final board of interest is the NFC and LED board which is connected to the main board. There is an unused 4 pin connector on the back of the board which is likely for debugging purposes.

Figure 7: NFC and LED board (top)

Flipping the board over reveals the NFC chip.

Figure 8: Multi-protocol contactless transceiver

The NFC chip is a Fudan Microelectronics FM17660 multi-protocol contactless transceiver IC.

Summary

Overall, all the main components are the same as the previous MaxiCharger we tore down last year which is good news for any contestants who previously bought the MaxiCharger.

Hopefully this blog post provides enough information to kickstart vulnerability research against the Autel MaxiCharger. Keep an eye out for future posts that will cover the threat landscape of the MaxiCharger.

We are looking forward to Pwn2Own Automotive again in Tokyo in January 2025 at Automotive World, and we will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions and register! We hope to see you there.

You can find me on Twitter at @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Welcome to the first Patch Tuesday of the new year. Even while preparing for Pwn2Own Automotive, the second Tuesday still brings with it a bevy of security updates from Adobe and Microsoft. Take a break from avoiding your New Year’s resolutions and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for January 2025

For January, Adobe released five bulletins addressing 14 CVEs in Adobe Photoshop, Substance 3D Stager, Illustrator on iPad, Animate, and Substance 3D Designer. One of these bugs was reported through the Trend ZDI program. The patch for Substance 3D Stager is the largest with five Critical-rated bugs being fixed. The worst could lead to arbitrary code execution. The fix for Photoshop is also rated Critical and could result in code execution when opening malicious files. That’s also true for the patch for Adobe Illustrator on iPad. Note that this is specifically the iPad version and not the desktop version, which is interesting. The update for Substance 3D Designer addresses four Critical-rated bugs, all of which could lead to arbitrary code execution. Lastly, the patch for Adobe Animate fixes a single code execution bug.    

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for January 2025

This month, Microsoft released 159(!) new CVEs in Windows and Windows Components, Office and Office Components, Hyper-V, SharePoint Server, .NET and Visual Studio, Azure, BitLocker, Remote Desktop Services, and the Windows Virtual Trusted Platform Module. Three of these were submitted through the Trend ZDI program. With the addition of the third-party CVEs, the entire release tops out at 161 CVEs.

Of the patches released today, 11 are rated Critical, and the other 148 are rated Important in severity. This is the largest number of CVEs addressed in any single month since at least 2017 and is more than double the usual amount of CVEs fixed in January. This comes on the heels of a record number of December patches and could be an ominous sign for patch levels in 2025. It will be interesting to see how this year shapes up.

Five of these bugs are listed as publicly known, and three are listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bugs currently being exploited:

-       CVE-2025-21333/CVE-2025-21334/CVE-2025-21335 - Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability
These three bugs are listed as under active attack, and all have the same description. An authenticated user could use these to execute code with SYSTEM privileges. Although not specified, I would think that if the attacker were executing code at SYSTEM on the hypervisor from a guest, the CVSS would indicate a scope change. Microsoft doesn’t list that, but I’ve disagreed with their CVSS ratings in the past. If you are running Hyper-V, make sure these patches are at the top of your list for testing and deployment.

-       CVE-2025-21298 - Windows OLE Remote Code Execution Vulnerability
This bug rates a CVSS 9.8 and allows a remote attacker to execute code on a target system by sending a specially crafted mail to an affected system with Outlook. Fortunately, the preview pane is not an attack vector, but previewing an attachment could trigger the code execution. The specific flaw exists within the parsing of RTF files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. As a mitigation, you can set Outlook to read all standard mail as plain text, but users will likely revolt against such a setting. The best option is to test and deploy this patch quickly.

-       CVE-2025-21295 - SPNEGO Extended Negotiation (NEGOEX) Security Mechanism Remote Code Execution Vulnerability
Besides being a mouthful of a title, this bug impacts a security mechanism, which is never a good sign. It allows remote, unauthenticated attackers to execute code on an affected system without user interaction. The only good news is that there are some barriers to exploitation, but I wouldn’t rely on that fact. I would also consider this a Scope Change, but that’s splitting hairs at this point. Even if you don’t rely on the negotiation mechanism, I wouldn’t wait to test and deploy this patch.

-       CVE-2025-21297/CVE-2025-21309 - Windows Remote Desktop Services Remote Code Execution Vulnerability
Both of these bugs allow arbitrary code execution on affected Remote Desktop Gateway servers from remote, unauthenticated attackers. They just need to connect to the server and trigger a race condition to create a use-after-free bug. While race conditions are somewhat tricky to exploit, we see them used at Pwn2Own frequently. Considering that exploiting this requires no user interaction, I would prioritize this patch, especially if you have these gateways exposed to the Internet.

-       CVE-2025-21308 - Windows Themes Spoofing Vulnerability
This is one of the five publicly known vulnerabilities receiving fixes this month, and for a change, we know where this one is exposed publicly. It turns out that a previous patch (CVE-2024-38030) could be bypassed. The spoofing component here is NTLM credential relaying. Consequently, systems with NTLM restricted are less likely to be exploited. At a minimum, you should be restricting outbound NTLM traffic to remote servers. Fortunately, Microsoft provides guidance on setting this up. Enable those restrictions then patch your systems.

Here’s the full list of CVEs released by Microsoft for January 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the other Critical-rated bugs, the vulnerability in Visual Studio requires a user to load a malicious package file. The bug in BranchCache is restricted to adjacent systems only. The bug in RMCAST requires a program listening on a Pragmatic General Multicast (PGM) port. Since there’s no authentication in PGM, these systems should not be exposed to the internet. However, on these systems, this bug is technically wormable – just only between systems configured in this manner. The NTLM bug is disturbing since it can be reached from the internet, but it only affects NTLMv1. You have updated everything to v2 – right? If not, Microsoft provides some guidance on making that happen. The bug in the Digest Authentication works in the same manner as the Remote Desktop bugs mentioned above. Finally, there a couple of other Critical bugs documented, but there’s no action for the end user as Microsoft already mitigated them.

There are almost 60 code execution bugs receiving fixes this month, including several open-and-own bugs in Office components. This includes three publicly known bugs in Access. Only one of these bugs can be hit from the Preview Pane by previewing attachments, and that is for legacy versions of Outlook for Mac. The Windows Telephony Service receives 28 patches this month. However, these require user interaction and are unlikely to be exploited. The bug in Direct Show requires an authenticated user to click a malicious link. Beyond the open-and-own bug in .NET and Visual Studio, the other code execution vulnerability in .NET requires extensive user interaction. The bug in GDI+ also requires the attacker to be authenticated. Finally, the bug in the Line Printer Daemon reminds me of the PrintNightmare bugs from a few years ago. An attacker would just need to send a specially crafted request to an affected system to gain arbitrary code execution on the server. And yes, that is an update for Internet Explorer you see. No matter how hard we try, we can’t be rid of the thing. At least it requires user interaction.

The January release includes more than three dozen privilege escalation bugs. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. There are some notable exceptions. More than half of these are for the Digital Media component and require the attacker to plug in a USB drive into an affected system. This would lead to code execution as SYSTEM. The bug in the Recovery Environment also requires physical access, but Microsoft provides no further information on how it would be exploited. Several of the EoP fixes this month are related to container or sandbox escapes. For example, the bugs in the Brokering File System can be executed in a low-privileged AppContainer but result in access beyond what is intended. The bugs in PrintWorkflowUserSvc also result in sandbox escapes. The remaining bugs lead to access beyond what is intended, but these are not likely to be exploited due to their access complexity.

There are a dozen different security feature bypass (SFB) bugs receiving fixes this month, and the one that immediately jumps out is the bypass of Mark of the Web (MoTW) protections. We saw this technique used often in 2024 by ransomware and crypto scammers. The bug in Excel evades macro protections. Similarly, the SFB in Office bypasses Windows Defender Application Control (WDAC) enforcement. There are multiple updates for this one, too, so make sure you get them all. The bugs in Secure Boot bypass – you guessed it – Secure Boot. They list the title as Kerberos, but the Windows Defender Credential Guard Feature is really what’s being bypassed, which could leak Kerberos credentials. The bugs bypassing MapUrlToZone and HTML Platform Security protections require user interaction. Microsoft provides no information on what is being bypassed in the Virtualization-Based Security (VBS) component, so let the speculation begin.

This release includes fixes for multiple information disclosure bugs and most simply result in info leaks consisting of unspecified memory contents. There are a few that also lead to the disclosure of the ever-nebulous “sensitive information.” However, there are some significant information disclosure bugs receiving fixes this month. The first is in the SAP HANA SSO for On-Premises Data Gateway, which could disclose PowerBI data available from the dashboard. A few of the Kernel bugs are special as well. They only disclose random heap memory, but they require multiple patches to fully resolve the vulnerability. The bug in the Cryptographic component could leak the contents of encrypted PKCS1 information. The most troubling are the bugs in BitLocker. One could disclose unencrypted hibernation images in cleartext, while the other leaks the BitLocker key. Both of these require physical access, but since BitLocker is specifically designed to block attackers with physical access, it makes these bugs rather unfortunate.

Microsoft must have heard our pleas because there is actually a small amount of detail given for the 20 Denial-of-Service (DoS) bugs being fixed this month. The bugs in Message Queuing impact the availability of the service when an attacker sends specially crafted packets to the service. That’s the same for the Connected Devices Platform Service (Cdpsvc). The bug in the IP Helper results in an application crash if specially crafted packets are received by the app. The bug in the Security Account Manager (SAM) would cause the app to crash, but it’s not clear if it would automatically restart. The bug in the TPM could result in a total loss of availability. Alas, we will need to cry louder, for that is all of the detail Microsoft provides regarding the DoS fixes this month.

Finally, there are three spoofing bugs fixed in the release. The bug in SmartScreen looks awfully familiar, as the researcher credited has reported several spoofing bugs in SmartScreen. This always makes me think the previous patches were insufficient. The spoofing bug in SharePoint presents as a cross-site scripting (XSS) bug. No real information is given about the spoofing bug in Active Directory Federation Server other than to say that user interaction is required.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on February 11, and assuming I survive Pwn2Own Automotive, I’ll return with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

In our previous Sony XAV-AX8500 blog post, we detailed the internals of the head unit and provided annotated pictures of each PCB. In this post we aim to outline the threat landscape of the XAV-AX8500 in the hopes of providing inspiration for vulnerability research.

We will cover the main supported technologies that present potential attack surfaces such as USB, Bluetooth, Android Auto, Apple CarPlay, and more. We will also look at some of the open-source components the XAV-AX8500 claims to use.

All information has been obtained through reverse engineering, experimenting, and combing through the following resources:

·      Sony XAV-AX8500 Product Page
·      Sony XAV-AX8500 Help Guide (PDF)
·      Sony XAV-AX8500 Operating Instructions (PDF)

 USB

The XAV-AX8500 has a single USB-C port that provides the necessary interface for wired Android Auto and Apple CarPlay. The USB port also supports playback of audio files from a USB flash drive. The supported audio filetypes and their associated extensions are:

·      MP3 (.mp3)
·      WMA (.wma)
·      AAC (.m4a)
·      ALAC (.m4a)
·      WAV (.wav)
·      FLAC (.flac)
·      DSD (.dsf, .dff)

As well as audio, a USB flash drive can also be used to playback video files. The supported video filetypes and their associated extensions are:

·      ASF (.asf)
·      WMV (.wmv)
·      AVI (.avi)

Robustly parsing and decoding these file formats is notoriously complicated and error-prone, which makes for a potentially rewarding attack surface.

Another point of interest is that the XAV-AX8500 allows users to set the wallpaper by providing JPEG images on a flash drive and then selecting the desired images by navigating to Settings -> Customize -> Wallpaper Select -> Browse. Images must be less than 2048 x 1080 pixels and 6MB in size.

Image handling can be a complex task especially when it comes to image manipulation. Adding to this, the user controls the image filenames which further expands the potential attack surface especially since selected wallpaper images must be stored on disk.

Firmware updates can also be installed via a flash drive by navigating to Settings -> System -> Software Update. The next blog post in this series will cover the XAV-AX8500 firmware in more detail.

USB flash drives must be formatted as either FAT16, FAT32, or exFAT for the head unit to be able to read them.

Bluetooth

Bluetooth version 5 is supported by the head unit and is used for making phone calls, receiving phone calls and playing audio from a paired mobile phone. This functionality is offered natively by the head unit and operates using the following Bluetooth profiles:

·      Advanced Audio Distribution Profile (A2DP) v1.3.1
·      Audio/Video Remote Control Profile (AVRCP) v1.6.1
·      Hands Free Profile v1.7.1
·      Phonebook Access Profile v1.2

Android Auto and Apple CarPlay also utilize Bluetooth to varying degrees.

Wi-Fi

The head unit provides a Wi-Fi access point that is primarily used for wireless Android Auto and Apple CarPlay. There is no intention for the end user to directly connect to this access point and there is no officially documented way of acquiring the password. However, internal research has discovered a method to obtain the password.

Once connected to the access point a port scan was performed that only detected TCP port 30515 as being open.

There isn't much information about TCP port 30515 relating to automotive other than a vague comment in this Github repository and a slide NCC Group's Revving Up: The Journey to Pwn2Own Automotive 2024 (PDF slide 15).

Android Auto and Apple CarPlay

Both wired and wireless Android Auto and Apple CarPlay are supported without the need for a third-party app to be installed on the paired mobile phone. When using the wireless versions, the paired phone connects to the aforementioned secured Wi-Fi network to establish a high bandwidth channel for data to be sent and received.

When connecting using a USB cable the Wi-Fi network isn't used by Android Auto or Apple CarPlay but it is still active.

Android Auto and Apple CarPlay have yet to be used to gain control of a head unit at Pwn2Own Automotive, so we are looking forward to any entries that exploit these services!

Open Source Software

A list of open-source licenses can be viewed from the head unit by navigating to Settings -> System -> Open Source Licenses. Licenses of particular interest include:

·      Python
·      Boost (C++ library)
·      Dropbear
·      Lame (MP3 encoder)
·      mpg123 (MP3 decoder)
·      mpg123 has a fair number of published CVEs

There's no guarantee these open-source projects are actually used, but further information will be provided in the next blog post of this series.

Summary

We hope that this blog post has provided enough information about the XAV-AX8500 threat landscape to guide vulnerability research. Not every attack surface has been mentioned, and we encourage researchers to investigate further.

 The next post in this series will cover details of the XAV-AX8500 firmware.

We are looking forward to Pwn2Own Automotive again in Tokyo in January 2025 at Automotive World, and we will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions and register! We hope to see you there.

You can find me on Twitter at @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

For the upcoming Pwn2Own Automotive contest a total of 4 head units have been selected. One of these is the single DIN Sony XAV-AX8500 that offers a variety of functionality such as wired and wireless Android Auto and Apple CarPlay as well as USB media playback and more.

This blog post presents internal photos of the XAV-AX8500 boards and highlights each of the interesting components.

Internals

Accessing the internals of the XAV-AX8500 involves removing a few screws and metal plates. Once the main chassis is open 3 interconnected boards are exposed that are connected via flat flexible cables. The main board is shown below.

Figure 1: Main board (top)

The main application processor is an NXP i.MX 8M Mini with part number MIMX8MM6CVTKZAA. This is a powerful processor with 4 Cortex-A53 cores as well as a low power Cortex M4 that is used for lighter workloads and also security related functions.

To the left of the processor is the supporting SDRAM and eMMC the i.MX 8M Mini utilizes. The SDRAM is an 8Gb Nanya NT6AN256T32AV-J2 8Gb LPDDR4 chip and below that is a 16GB Samsung KLMAG1JETD eMMC chip.

To the right of the eMMC is the Rohm BD71847A PMIC and further right is an unused socket. There's also HDMI and USB-C inputs towards the bottom right of the board.

Above the unused socket is the Murata LBEE5ZZ1PJ radio module that handles Wi-Fi and Bluetooth operations.

The underside of the main board is shown below.

Figure 2: Main board (underside)

There isn't much to see other than the Analog Devices ADV7482 video decoder and HDMI receiver chip.

Next to the main board is a smaller board that receives GPS, iData Link and optional remote control input.

Figure 3: GPS, iData Link and remote control board (top)

The GPS module is the Unicorecomm UM220-INS NL which is advertised as a "High-end GNSS+MEMS Integrated Navigation and Positioning Module".

Under both of these boards sits a much larger PCB that handles power and various other inputs and outputs such as audio and video. A photo of this board is shown below.

Figure 4: Power, audio and video board (top)

Towards the bottom left is the LC88FC2H0A microcontroller from ON Semiconductor. This uses the obscure 16-bit Xstormy16 architecture and is suggested for use in white goods, home audio and car audio applications. To the left of the microcontroller is an unused 5 pin socket.

The other components are related to power handling and digital signal processing.

For completeness the underside of the board is shown below.

Figure 5: Power, audio and video board (underside)

There isn't much of interest on this side.

Summary

Hopefully, this blog post provides enough information to kickstart vulnerability research against the XAV-AX8500. Keep an eye out for future posts that will cover the threat landscape of the XAV-AX8500.

We are looking forward to Automotive Pwn2Own again in Tokyo in January 2025 at Automotive World, and we will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions and register! We hope to see you there.

You can find me on Twitter at @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Reflecting on 2024, it has been an eventful year for the Zero Day Initiative Threat Hunting team. Throughout the year, we identified numerous threat actor campaigns exploiting zero-day vulnerabilities, uncovered additional variants of these vulnerabilities, and discovered even more vulnerabilities through our in-the-wild research. In this blog, we will highlight some of the key achievements of the Zero Day Initiative Threat Hunting team, as well as discuss important in-the-wild vulnerability trends and industry challenges we encountered in 2024 which will continue into 2025

To safeguard Trend Micro customers, the Zero Day Initiative Threat Hunting team engages in comprehensive threat-hunting operations utilizing a variety of methodologies. These methodologies incorporate information collected from both customer telemetry and public sources. Several notable instances of zero-day exploits that were identified by the ZDI Threat Hunting team that were actively exploited in the wild during 2024 are presented below. Each of these vulnerabilities has been addressed and patched by the respective software vendors. Furthermore, Trend Micro customers have received additional protection from Trend’s virtual patches, which were often delivered several months before the official vendor patch releases.

CVE-2024-21412: Internet Shortcut Files Security Feature Bypass Vulnerability

On November 14th,  2023, Microsoft patched a SmartScreen bypass identified as CVE-2023-36025 which was quickly utilized in n-day attacks deployed across numerous campaigns including Phemedrone Stealer. Unfortunately, the patch for CVE-2023-36025 was quite narrow and by December 2023 the ZDI Threat Hunting team discovered that the Water Hydra APT group began exploiting CVE-2024-21412, a new SmartScreen bypass vulnerability, as a zero-day in attacks targeting crypto and financial traders. Water Hydra is an APT group we track with a known history of zero-day discovery and exploitation. The Water Hydra group was discovered when they exploited CVE-2023-38831 in a previous zero-day exploitation campaign. By mid-January, in addition to Water Hydra, we discovered that the operators behind the DarkGate malware had begun to use CVE-2024-21412 in campaigns targeting organizations across North America, Europe, Asia, and Africa. We reported our findings to Microsoft, who patched CVE-2024-21412 on February 13, 2024, as a partial fix to address the immediate in-the-wild threats.

CVE-2024-29988: SmartScreen Prompt Security Feature Bypass Vulnerability

In addition to the patch released on February 13, 2024, to address the immediate threats posed by exploitation of CVE-2024-21412, Microsoft issued a more comprehensive fix for this SmartScreen vulnerability on April 9th, 2024, identified as CVE-2024-29988.

The patching timeline of CVE-2024-21412 and CVE-2024-29988 highlights a significant issue within the industry: the urgent need to address threats promptly, even in the absence of a full patch solution. This situation underscores the challenge of balancing the need to tackle immediate, real-world threats with the necessity of implementing comprehensive systemic solutions. Trend Micro customers have benefited from protection against both CVE-2024-21412 and CVE-2024-29988 through virtual patching well before Microsoft released its official updates.

CVE-2024-38112: Microsoft Windows MSHTML Platform Spoofing Vulnerability

In May 2024, the ZDI Threat Hunting team began tracking a Void Banshee campaign that exploited CVE-2024-38112 to infect users with the Atlantida stealer via Internet Explorer, whose support officially ended on June 15, 2022. Although Internet Explorer has been disabled in later versions of Windows 10 and in all versions of Windows 11, the browser and its Trident engine have not been completely removed from the Windows operating system.

In this campaign, Void Banshee found a way to utilize crafted “MIME encapsulation of aggregate HTML documents”, or MHTML handlers, to effectively reactivate Internet Explorer. Microsoft released a patch for CVE-2024-38112 on July 9, 2024. This situation underscores the inconvenient truth that apparently disabled features in the Windows operating system may still be susceptible to exploitation by threat actors, leaving unsuspecting users vulnerable.

CVE-2024-43461: Windows MSHTML Platform Spoofing Vulnerability

As part of the Void Banshee campaign exploiting CVE-2024-38112, the threat actors also exploited CVE-2024-43461 in the same attack chain as a zero-day. This vulnerability allowed Void Banshee to spoof extensions by using encoded braille whitespace characters (%E2%A0%80)  to push the final extension off the screen. Using CVE-2024-38112, Void Banshee was able to revive Internet Explorer to download files and CVE-2024-43461 to spoof the extension of the downloaded file. This would trick users into thinking files were of a benign type. Microsoft officially patched CVE-2024-43461 on July 9, 2024.

A prevalent issue within the software industry is the phenomenon of narrow patching. Software vendors frequently concentrate on addressing immediate threats without adequately considering broader, systemic challenges that may necessitate a more comprehensive approach to patching. Threat actors are acutely aware of this narrow focus and often manage to circumvent these limited patches within minutes of their release, thereby exacerbating the problem.

At the Zero Day Initiative, we combat this issue by utilizing our findings related to in-the-wild zero-day vulnerabilities, along with vendor patches, to identify potential weaknesses and bypasses in existing security measures. The following outlines several significant discoveries from our research on zero-day vulnerabilities and their adjacent implications.

CVE-2024-38213: Windows Mark of the Web Security Feature Bypass Vulnerability

One of the adjacencies the Zero Day Initiative Threat Hunting team was able to uncover as a direct result of our in-the-wild findings is CVE-2024-38213. Using this vulnerability, threat actors are able to use a Copy2Pwn condition to bypass Windows SmartScreen protections. At the time we disclosed this vulnerability to Microsoft, TA571 had been using similar copy-and-paste operations to infect users with a variety of malware such as DarkGate. CVE-2024-38213 was patched by Microsoft on August 13, 2024.

CVE-2024-49041: Microsoft Edge (Chromium-based) Spoofing Vulnerability

During our discovery of CVE-2024-38112 and CVE-2024-43461 and subsequent disclosure with Microsoft, we additionally uncovered CVE-2024-49041. This vulnerability would allow threat actors to use similar spoofing techniques that Void Banshee deployed in their MHTML Internet Explorer campaign but through the Microsoft Edge browser. We uncovered this vulnerability through patch analysis and by analyzing how other Windows products handled similar vulnerabilities. Microsoft fixed CVE-2024-49041 on December 5, 2024.

Similar to our variant hunting initiatives, the ZDI Threat Hunting team will use in-the-wild exploitation data to find similar attack vectors across vendors with similar product portfolios. Security researchers already do work similar to this, take for example Adobe Acrobat Reader vs. Foxit Reader. This type of research makes products more secure across vendors and the software ecosystem. Some of our work has been included in the Microsoft Security baseline, highlighting our commitment to secure by design, secure by default principles.

CVE-2024-5924: Dropbox Desktop Folder Sharing Mark-of-the-Web Bypass Vulnerability

On June 25th we reported a mark-of-the-web bypass vulnerability in the Folder sharing feature of Dropbox. This vulnerability was not used in the wild to our knowledge. However it proved to be a clever potential vector in a threat actor campaign. Dropbox ultimately rejected this report, which we published as CVE-2024-5924.

Throughout 2024 the ZDI Threat Hunting team uncovered several trends and pain points within the software patching industry relating to zero-day in-the-wild exploitation.

Increase in Sophistication of Phishing

Recently, there has been a substantial focus and lots of speculation on artificial intelligence (AI) and Large Language Models (LLMs), particularly concerning new vulnerabilities and malware. A frequently posed question pertains to whether LLMs, such as GPT, have significantly contributed to the emergence of novel malware and vulnerabilities. To date, we have not identified any direct substantial contributions; however, we have observed a notable increase in both the volume and sophistication of phishing-related content and campaigns utilizing these emerging technologies.

Applications like ChatGPT enable threat actors to concentrate on the technical aspects of their campaigns while delegating the generation of phishing content to LLMs, which are highly proficient in language processing. This functionality empowers attackers to customize their communications more effectively for specific regions by producing content in local languages. Moreover, if threat actors gain access to security feature bypasses, such as zero-day vulnerabilities identified by the Zero-Day Initiative’s threat-hunting team, and combine these with advanced AI-generated phishing content, the risk to individuals and organizations escalates significantly.

The alarming aspect of this trend is that LLMs, which excel in producing human-like language, can generate extensive volumes of convincing phishing material. As AI capabilities continue to evolve and improve, distinguishing between phishing and legitimate content becomes increasingly challenging for individuals and organizations.

Narrow Patching

Inadequate patching, which fails to address a vulnerability’s root cause sufficiently, continues to pose significant challenges for software vendors. This oversight enables threat actors to bypass existing patches, sometimes within hours of their deployment. This impacts not only vulnerabilities identified as actively exploited but also those disclosed by security researchers and released as n-days.

Frequently, when proof-of-concept exploits are published following a patch release, both adversaries and researchers utilize, modify, and test against the patch, employing techniques such as patch diffing to uncover new vulnerabilities and incomplete patches. The ramifications of insufficient patching manifest clearly in instances such as Microsoft's handling of CVE-2023-36025, where a patch was circumvented within one month by exploiting CVE-2024-21412.

Not only do narrow patches pose a significant security risk, but they also waste company resources and give a false sense of security.

Siloed Product Teams

We have identified an additional challenge associated with larger software vendors that possess an extensive portfolio of products. These vendors often operate their product teams in silos, which results in a breakdown in communication regarding vulnerability remediation. Consequently, a specific product team may focus solely on addressing vulnerabilities within their designated product. While certain vulnerabilities may be resolved in one product, other products that exhibit a similar attack surface may remain unaddressed, leading to a significant overarching risk across the entire product suite.

This situation is further exacerbated by a narrow approach to patching and a lack of awareness regarding the interrelationships within the product ecosystem. Notably, vulnerabilities such as CVE-2024-49041 and CVE-2024-43461 serve as examples of instances where a particular product may successfully address a vulnerability, while another product fails to do so. These unaddressed vulnerabilities create critical blind spots that threat actors exploit daily. 

Attack Vectors Through Disabled System Artifacts

When a product or service reaches its end of life, it is commonly assumed that the responsibility for any associated security risks rests solely with the user. However, this perception neglects the potential dangers arising when a vendor disables a product or service while it remains present in the system. The existence of these disabled artifacts and dependencies can present significant security vulnerabilities. For instance, the case studies of CVE-2024-38112 and CVE-2024-43461 illustrate how threat actors can capitalize on disabled system resources, such as Internet Explorer, to gain complete control over a system.

Issues with Coordinated Vulnerability Disclosure (CVD)

Software vendors rely on security researchers to enhance the security of their products and protect their customers. This relationship is critical, as both parties must collaborate to foster a safer digital environment. However, there are instances in which security researchers are perceived as an inconvenience at best, or a hassle at worst, resulting in communication breakdowns and misunderstandings. My colleague Dustin Childs described one such misunderstanding in this blog.

When the relationship between security researchers and the vendor becomes strained, the vendor's reputation may suffer, which can adversely impact end users who depend on the security of the product. Furthermore, a lack of effective engagement with researchers can lead to the loss of valuable exploit information, potentially placing this knowledge in the hands of malicious entities who buy exploit information at a premium price, in some cases much higher than handed out by vendors. Therefore, it is imperative that software vendors actively listen to, communicate transparently, and foster a meaningful relationship with the broader security research community.

Flaws in CVSS Scoring

Organizations depend on the Common Vulnerability Scoring System (CVSS) to prioritize the vulnerabilities they address, rendering it a fundamental element in the management of organizational risk. This system not only assists organizations in patching their systems but also enables vendors to determine which vulnerabilities to triage first, if at all. Any flaw in these metrics can lead to inadequate response or wasted resources costing organizations millions of dollars.

A notable shortcoming identified by the ZDI Threat Hunting team is the insufficient attention placed on vulnerabilities that are likely to be exploited in real-world scenarios. Some of these vulnerabilities may or may not even make it past the triage process even though they match criteria sought after by threat actors as part of a phishing campaign for example. We’ve also noticed that many vulnerabilities rated as critical or high are not actively exploited; however, organizations frequently allocate extensive resources to address these CVEs as a priority. Such resources could be more effectively directed toward mitigating other security risks that are more pertinent to the specific context of the organization.

Furthermore, human judgment significantly influences CVSS scores, leading to frequent disagreements among security researchers and vendors regarding the appropriate scoring of vulnerabilities.

Secure by Design Shortcomings

One concerning challenge we’ve seen is the fact that some vectors, in particular mark-of-the-web bypasses have similar vulnerabilities across vendors. This allows threat actors to abuse these vulnerabilities across commonly used business and collaboration software. Many of these vulnerabilities remain in vendor triage ZDI-CAN-24741, ZDI-CAN-24742, ZDI-CAN-24425, ZDI-CAN-24433.

The Zero Day Initiative Threat Hunting team would like to thank the following team members, Trend Micro employees, and teams for their tireless contributions to ensuring the safety of our customers as well as the broader software industry: Aliakbar Zahravi (@AliakbarZahravi), Simon Zuckerbraun, Nicholas Zubrisky (@NZubrisky), Scott Graham, Abdelrahman Esmail, Ian Kenefick (@ian_kenefick), Trend DVLabs, Trend DSLabs, the Trend Marketing and content writing teams.

We look forward to the new year, and as always, we’ll bring you the latest in whatever threats and exploits as we find them. Until then, you can follow the ZDI team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploitation.

The Tesla Wall Connector is a Level 2 electric vehicle charge station designed for use by residential home users. The device has a minimal user interface in its hardware, providing a Wi-Fi based interface for configuration and an NFC reader for user authentication. The device does not come with a dedicated mobile application out of the box; the initial configuration—which is rather minimal—is performed via the web interface. After that, the device suggests the Tesla One app is to be used for further configuration. The Tesla app allows connecting to the device but apparently can only be used to perform a few functions such as scheduled charging and viewing information about the device. It does not offer options for further configuration.

At the moment of writing, the latest software version was reported as 24.36.3.

Trend ZDI researchers have performed an analysis of the discrete hardware components found in the device. The device itself is comprised of several printed circuit boards (PCBs) hosting the system; the “main” PCB contains power and communications electronics while the smaller flex core PCB carries the minimalistic human interface in the form of several LEDs and the NFC reader circuitry.

Below is a list of notable parts on the main PCB:

·      U1 AD ADE7854AACPZ, a 3-phase energy measurement IC,
·      U7 ST STM32L431RCT6, an ARM MCU with 256KB of Flash memory,
·      U20 NXP 7102 3105, an unknown device, but likely to be an I2C secure element,
·      U21 AzureWave AW-CU300, a WLAN module,
·      U27 GigaDevice 25Q128E, a 128MB serial Flash.

On the board itself, about half of the area is occupied by the power electronics, with low-current electronics being concentrated on the left in this photo. Of most interest, the STM32 MCU is at the top left in Figure one (below) and the comms module is at the middle left. The number of external connectors is kept at a minimum, with J3 in the middle providing connection for non-power signals in the charging cable.

Figure 1 - Tesla Wall Connector main PCB top

The bottom side of this board carries a variety of small components and the energy-metering IC. The green connector on the bottom left has an unknown purpose.

Figure 2 - Tesla Wall Connector main PCB bottom

Notably, many signals appear to be broken out on unpopulated pin headers. Once the varnish is removed, connecting to any MCU pin should be easy.

There are multiple unpopulated footprints on the top side of the board. Of these, J1 and J7 immediately stand out. Trend ZDI researchers have determined that J1 is wired to the STM32 MCU and has a standard ARM JTAG/SWD 10-pin connector pinout. Dealing with J7 was considerably more complicated, but it seems reasonable to assume a similar pinout, if not identical.

Unfortunately, rather little information was found regarding the communications module used in this device. It appears to be produced by AzureWave Technologies, Inc. On their website, the AW-CU300 modules are listed as carrying a MW320 SoC which appears to reference 88MW320, a SoC designed by Marvell and then acquired by NXP. In terms of software, however, the only mention made is that the module uses “Marvell Smart Connect”. No downloads of binary images or sources are provided by AzureWave.

Trend ZDI researchers look forward to discussing with the contestants the role the U20 IC plays in the overall system security.

Extracting the STM32 firmware proceeded without many obstacles. As the J1 connector pinout is known, just connecting an ST-Link V2 dongle proved to be sufficient to dump out the whole contents of the on-chip flash.

Extracting the firmware of the communication module, however, turned out to be more challenging. After attempting multiple approaches, Trend ZDI researchers were unable to interact with the interface over the J7 connector to get any meaningful results; only once, the device returned an IDCODE of all zeros in the JTAG mode when using a pinout corresponding to the ARM 10-pin connector. The unavailability of JTAG seems to be consistent with documented behavior when the MW320 SoC is in its secured mode: in this case, the JTAG interface is expected to be disabled by default and will not be enabled by the boot ROM.

Figure 3 - Tesla Wall Connector—detail of low-power electronics; both debugging headers installed

Another avenue of attack would be extracting contents of the GigaDevice serial flash device U26—after all, this is all the storage the communications module has available. The challenge here is two-fold: first, the Flash device is inconveniently positioned in a tight space between the module and the flat cable connector J6, posing considerable risk of damaging the connector while attempting to remove the Flash chip from the board; second, the Flash contents may be encrypted at rest with an unknown key, hindering further analysis. That said, Trend ZDI researchers found a way to dump the contents of this IC in-system.

Looking closely, all the signal pins of U26 are broken out through small vias and can be accessed on the bottom side; since those vias are not covered with solder mask, they probably double up as test points. By soldering to these points, it is possible to build an “adapter” good enough to connect the chip to a flash programmer such as the TL866+. Here is how vias correspond to the IC pins:

Figure 4 - Tesla Wall Connector—detail of the vias connection

Pin 8, VDD, is not directly accessible here but can be tapped off the debugging connector. The only issue is that the communications module CPU is simultaneously executing code, driving all the signals. This can be overcome by keeping the CPU in reset; experimentally, placing a 1 kΩ resistor between pins 3 and 10 of J7 achieved exactly that.

As a bonus, this interface enables experimenting on the system without having to resolder the flash chip every time.

The STM32 flash image is clearly partitioned into two parts, the bootloader and the application, with the latter starting at offset 0x5000.

The extracted STM32 firmware was found to be completely stripped of any useful ASCII strings. This made it very challenging for Trend Micro researchers to identify any specific software components in use. What could be said, however, is that the MCU does not appear to be in charge of handling any internet-facing communications. It does seem to use some kind of an RTOS, due to the presence of what looked like thread names in the few strings the image had: wifirx, wifitx, wifireltx, cantx, canrx, metertrx, leds, and IDLE. Based on that, we conclude that the MCU mostly deals with CAN, metering, and LEDs, while the communications module then handles the rest of the communications.

The communications module firmware is somewhat more involved, as code signing is supported and used. The image was inspected in a hex editor; the contents were not encrypted. The following interesting fragments were detected:

·      0x00000000: A secure boot header corresponding to what is described in SoC documentation is found there.
·      0x000002BA: A short code fragment, apparently a bootloader of sorts.
·      0x00004000: A short header marked with WMPT, which looks like a partition table for the rest of the flash.
·      0x00005000: A copy of the above.
·      0x00006000: The psm partition. This seems to contain some (encrypted?) configuration data.
·      0x00008000: The mcufw partition, storing the actual application firmware. The format of this image has been investigated before by others.
·      0x00288000: The second mcufw partition.
·      0x00508000: The fs partition, which is littlefs-formatted. This appears to contain mostly log data.

As a side note, the mcufw image appears to include the full STM32 image inside; likely, the comms module can reprogram the STM32 MCU directly.

The device provides its own Wi-Fi access point for configuration and management with the SSID starting with TeslaWallConnector and the passphrase comprised of 12 upper-case letters. Once connected to an AP, it is possible to interact with the web-based interface and configure the unit to connect itself to an internet-facing Wi-Fi network. This allows the user to monitor the unit, and the unit to communicate with remote endpoints and update itself when a new software version becomes available.

A network scan was performed with nmap, which discovered TCP ports 80 and 34578 as well as UDP ports 67 and 5353 open on the device. This set of ports remained the same independent of whether the device was configured to connect to a Wi-Fi access point or remained standalone; the same TCP ports were exposed over the client side when connected to the Wi-Fi AP.

When connected, the device communicated to the following servers:

·      hermes-prd.sn.tesla.services
·      wc-maestro-prd.sn.tesla.services
·      s3-us-west-2.amazonaws.com

Communications with the first two services were TLS-protected, and both client and server certificates were requested and provided by both sides. The server certificates were issued by Tesla Energy Services CA, while the client certificate came from NXP Plug Trust CA. MitM attacks were not attempted by Trend Micro researchers at this point.

The third endpoint, however, used plain HTTP. This allowed to snoop on the requested data, which turned out to be the software update bundle. The bundle was found to be encrypted; a cursory search on the web did not reveal any hints on the algorithm or the key.

Research on TCP port 34758 seems to indicate that this is an endpoint for load-sharing setup, requiring mutual TLS authentication before further access can be gained.

While these may not be the only attack surfaces available on the Tesla Wall Connector unit, they represent the most likely avenues a threat actor may use to exploit the device. We’re excited to see what research is displayed in Tokyo during the Pwn2Own Automotive event. Stay tuned to the blog for attack surface reviews for other devices, and if you’re curious, you can see all the devices included in the contest.

Until then, you can find me on Mastodon at @infosecdj, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.