Guest Post: An Update on You Snooze, You Lose: Winning LPEs by Racing Services for RPC Endpoints
Authors: Ron Ben Yizhak, SafeBreach Security Researcher
Last August, I shared a blog on my most recent research project called You Snooze, You Lose: RPC-Racer Winning RPC Endpoints Against Services, which I presented at DEF CON 33 (2025). In it, I demonstrated a novel attack technique I developed called Endpoint Mapper (EPM) poisoning—a method of registering a rogue remote procedure protocol (RPC) server ahead of a legitimate one to intercept client connections. I showed how it could be exploited to force a protected process to authenticate a machine account against an attacker-controlled server, enabling domain-wide privilege escalation.
Following that research, I continued investigating the boundaries of EPM poisoning to answer a question I had left open: could the technique be used to escalate from an even weaker starting point? Specifically, could a low integrity process leverage EPM poisoning to break out of its sandbox entirely? The answer turned out to be yes—and the path there involved an obscure scheduled task, a bypassed Windows security mechanism, and an XML injection hidden inside a toast notification.
Below, I’ll first provide a high-level overview of the original research. Next, I’ll explain how I expanded the attack surface to low integrity processes, describe the new vulnerability I discovered in the Data Sharing Service, and share additional EPM poisoning impact discovered by Microsoft. Finally, I’ll cover the vendor response, detection guidance, and directions for further research.
Background on the Original Research
NOTE: This section provides an overview of the original You Snooze, You Lose: RPC-Racer Winning RPC Endpoints Against Services research; readers already familiar with it can skip to the following section.
The Windows RPC protocol is one of the core building blocks of inter-process communication on Windows. When an RPC client needs to find a server by interface universally unique identifier (UUID)—without knowing a specific endpoint—it queries the EPM, which functions similarly to a DNS server: it resolves a UUID to a registered endpoint and connects the client to the first matching server.
This design became the foundation of my research. I set out to determine whether an attack analogous to DNS poisoning could be applied to the EPM—a technique I came to call EPM poisoning. The key discovery was that there is no verification mechanism preventing an unprivileged process from registering a built-in, well-known RPC interface. As long as a rogue server registers an interface before the legitimate service does, the EPM will route clients to the attacker.
To operationalize this finding, I developed two tools:
RPC-Recon: Maps RPC interfaces that are not registered at boot and identifies services with delayed or manual startup that could be raced.
RPC-Racer, a toolset that registers rogue RPC interfaces and exploits the clients that connect to them.
The primary exploit chain I demonstrated targeted the Storage Service (StorSvc). Because StorSvc is set to delayed start, a scheduled task launched at user log-on can register its interface before the legitimate service. The Delivery Optimization service—which runs as a Protected Process Light (PPL)—connects to StorSvc to retrieve a storage path via the `GetStorageDeviceInfo` method. By controlling the response, I was able to return a network share pointing to an attacker-controlled SMB server, causing the Delivery Optimization service to authenticate to it using the machine account credentials.
This vulnerability can be utilized to execute the attack ESC8. I launched RPC-Racer on a domain controller as a non-administrative user to force it to authenticate with the machine account credentials. From there, I relayed the authentication to the Active Directory Certificate Services (ADCS) web enrollment endpoint, requested a ticket granting tickets (TGT) for the domain controller’s machine account, and used it to dump all domain controller secrets—achieving full domain compromise from a medium integrity process with no administrative privileges.
Microsoft assigned this vulnerability CVE-2025-49760. They fixed it in a patch released on July 8, 2025, that added a security Quality of Service (QOS) check to the StorSvc RPC client so it would only connect to servers running as the local system account.
Taking It Further: Low Integrity Processes as an Attack Surface
After completing the original research, I returned to a question I had set aside: what if we started from an even more restricted position? Most of my original research began as a medium integrity process. But many widely-used applications—browsers, code editors, sandboxed apps—run at low integrity. This is an intentional security design; Microsoft’s documentation explicitly states that escaping low integrity is especially difficult because low integrity processes are prevented from writing to most registry keys, folders, and system components.
To my surprise, however, low integrity processes can still register RPC servers. That alone opened a path worth exploring. The challenge I ran into was that many of the techniques I used in my original research didn’t work from low integrity. Low integrity processes cannot create scheduled tasks, cannot write to the startup folder, and therefore cannot reliably race delayed services at boot. I needed to find a different target—ideally a manual service (not launched at startup) whose RPC interface could be registered at any time, with a client that could be triggered on-demand, and that was unlikely to rigorously validate data received from an assumed-trusted server.
Identifying the Target: Data Sharing Service
After filtering built-in RPC servers based on startup type, the complexity of their interfaces, and the types of data their methods return, one candidate stood out: the Data Sharing Service (DsSvc).
DsSvc acts as a broker for file-path sharing between applications. If we simplify its actions, it holds a basic dictionary of paths to tokens.
When two apps need to exchange a file path, the first app calls `DSSCreateSharedFileToken` to request a token representing the path.
Finally, the second app calls `DSSGetSharedFileName` to retrieve the path the token represents.
.Searching for files that import `dsclient.dll`—the RPC client for DsSvc—led me to several programs. One stood out immediately: PerformanceTraceHandler.dll. This is the core component of the built-in scheduled task RequestTrace.
The RequestTrace Task and the UIPI Bypass
RequestTrace collects diagnostic information from the machine and—unlike most scheduled tasks—it can be started in several ways: via the Task Scheduler COM object, via a Windows Notification Facility (WNF) state change, or by pressing the hotkey combination Win+Shift+Control+T.
The first two methods are blocked for low integrity processes. The Task Scheduler COM object is inaccessible to low integrity, and the `NtUpdateWnfStateData` API call required for the WNF trigger is also restricted. The hotkey, however, presented an interesting opportunity.
Windows uses a security mechanism called User Interface Privilege Isolation (UIPI) to prevent low integrity processes from sending input messages, setting Windows hooks, or injecting keystrokes into higher-integrity processes. UIPI is a critical sandbox boundary. But UIPI blocks input messages—does that include hotkeys? Maybe a combination would work.
I called `SendInput` from a low integrity process to send the Win+Shift+Control+T key combination, and the RequestTrace scheduled task launched successfully using an RPC client connecting to me. This is a meaningful finding in itself: low integrity processes can trigger any scheduled task that has a hotkey-based trigger, which is worth investigating independently as an attack surface.
XML Injection via Toast Notification
This task depends on an option that is turned on by default when installing Windows: the send optional diagnostic data under the Diagnostics & Feedback settings. Once the task starts, it pops a notification to the user indicating data is being collected. This type of notification is called “toast.”
After a short duration, a second toast is presented with actions the user can take.
Once RequestTrace launches—and the second toast is presented—PerformanceTraceHandler assembles a zip file of diagnostic data and prepares to share it with the Feedback Hub application. To do this, it calls `DSSCreateSharedFileToken` on what it believes is the legitimate DsSvc server—but since I registered the interface first, it connects to my rogue server instead. The token I return is appended to a Feedback Hub URI, which is then formatted into an XML document defining the properties of a toast notification shown to the user.
The XML document defines exactly how many buttons will be shown and what will happen when they are clicked. After appending the token we return, the entire URI is formatted into the arguments property between two double quotes, as highlighted.
<toast scenario=”systemDialog”>
<visual lang=”en-US”>
<binding template=”ToastGeneric”>
<text id=”1″>A trace has been successfully saved to
Formatting an attacker controlled string into quotes is very interesting and dangerous. We can close the original double quotes in the format string where the URI is inserted using the highlighted characters. After closing the original double quotes, we can append arbitrary XML data and still keep the XML document valid.
Below is an example of a payload I could inject.
NOTE: On vulnerable builds of Windows, there was a bug that prevented me from setting the action of a button to an executable file. This is why I used a Python script. Since then, however, this bug has been fixed—you can read more about it in our recent research post: Click Or Trick (CVE-2025-59199): Escaping the Sandbox with Windows URIs.
This adds a button to the toast notification and sets the action to point to any file I want. When the user clicks the injected button, the file is executed with medium integrity—breaking out of the low integrity sandbox entirely.
It’s unbelievable that I could do that! The URI of the Feedback Hub isn’t verified at all before it is formatted into the XML. There is no check for special XML characters because this program completely trusts its RPC server. We just achieved a one-click local privilege escalation from low integrity to medium integrity.
To recap the attack flow:
The attacker starts as a low integrity process and registers a rogue RPC server mimicking DsSvc.
They send Win+Shift+Control+T to indirectly start the RequestTrace scheduled task.
RequestTrace’s PerformanceTraceHandler requests a token from the rogue server.
The attacker returns a crafted token containing the XML injection payload.
PerformanceTraceHandler launches a toast notification based on that XML.
The user sees a notification with a button; clicking it executes the attacker’s file at medium integrity.
When it comes to our original research, SafeBreach is deeply committed to responsible disclosure. In line with that commitment, I disclosed the Data Sharing Service vulnerability to Microsoft on July 14, 2025. It was issued CVE-2025-59200 and a fix was released on October 14th, 2025. As with the StorSvc fix from my previous research, the patch adds a security QOS check to `dsclient.dll,` so the RPC client verifies the server is running with elevated privileges before establishing a connection.
Key Take Aways & Broader Impact
This research exposed some serious security issues, and I believe there are a few lessons that should be noted:
The first is that the integrity of servers should be checked in every protocol. Just like SSL-pinning verifies that the certificate is not only valid but uses a specific public key, the identity of an RPC server should be checked. The current design of the EPM doesn’t perform this verification, therefore it must be done by the client.
The second is that there is a danger in setting services to delayed start. Software developers of RPC servers should be aware of the implications of launching their programs late in the boot process. Services are often set to delayed start to make the boot process faster, but performance cannot come at the expense of security. Any stage where untrusted code can be executed should be considered unsafe.
In publishing the original EPM poisoning research at DEF CON 33 in August 2025, I described several directions for further investigation—including the Windows Security Center and Windows Defender, both of which interact with RPC interfaces that may be vulnerable to EPM poisoning.
Shortly after the talk, Microsoft independently identified another vulnerable RPC interface: the **Windows Remote Access Connection Manager (RasMan). Hijacking the RPC interface of `rasmans.dll` via EPM poisoning could lead to SYSTEM-level privilege escalation. Microsoft patched this vulnerability (CVE-2025-59230) in October 2025, applying the same fix pattern: adding a security QOS check to the RPC client so that it verifies the server is running with elevated privileges before connecting.
The rapid identification of a third vulnerable component—just months after the original research was published—suggests that EPM poisoning is a productive avenue for finding privilege escalation vulnerabilities across the Windows RPC ecosystem. So far, the patches have addressed specific clients rather than the root cause in the EPM itself, leaving more avenues for manipulation.
For example, an attacker could:
Perform man in the middle by forwarding the requests they receive to the original service and filtering out calls to hide their foothold on the machine.
Cause a much more sophisticated denial of service. By registering many interfaces and denying the requests, many functionalities will be disabled. Instead of terminating processes or spamming them with packets, an attacker could just register their RPC interface first.
Steal credentials. While I reviewed a few services that might be exploited for that, there are probably many more.
Detection
Because these patches address specific RPC clients rather than the EPM itself, EPM poisoning remains a viable technique against other interfaces. Organizations can take steps to detect it, specifically:
Monitor RpcEpRegister calls. Security products can use hooking to monitor processes that call `RpcEpRegister` to register known, built-in interfaces. If an unexpected process attempts to register a well-known interface, it should be flagged and blocked.
Use Event Tracing for Windows (ETW). The `Microsoft-Windows-RPC` ETW provider logs correlation between process IDs, interface UUIDs, and procedure numbers for RPC connections. These events can be used to detect cases where an unknown process receives an RPC connection on a known interface—the hallmark of EPM poisoning in action.
Further Research
The UIPI bypass demonstrated in this research—triggering a scheduled task via hotkey from a low integrity process—warrants further investigation. Microsoft maintains documentation listing many key combinations and the programs they trigger; it is worth exploring how many of those programs interact with RPC services and whether they can be similarly exploited.
Beyond hotkeys and low integrity, the broader EPM poisoning attack surface remains largely unexplored. There are many delayed and manual services across the Windows RPC ecosystem—this research has only scratched the surface. One particularly interesting target remains the Windows Security Center, which is set to delayed start and is used by Windows Defender. A malicious response to Defender from a rogue RPC server could potentially neutralize it entirely.
Conclusion
This research extended the EPM poisoning technique to low integrity processes, demonstrating that even heavily sandboxed applications can be weaponized to escalate privileges if they can trigger an RPC client connecting to an attacker-controlled server. The Data Sharing Service vulnerability, exploited through an XML injection hidden in a toast notification, shows how trust in RPC server identity—when unverified—can cascade into unexpected and impactful security failures.
To help mitigate the potential impact of these vulnerabilities:
All users should apply the patches provided by Microsoft for CVE-2025-49760, CVE-2025-59200, and CVE-2025-59230.
Security teams should implement the detection capabilities described above to identify EPM poisoning attempts against unpatched interfaces.
We have also:
Provided an updated RPC-Racer toolset via the SafeBreach GitHub repository to enable further research and development.
Added original attack content to the SafeBreach platform that enables our customers to validate their environment against the EPM poisoning techniques outlined in this research to significantly mitigate their risk.
For more in-depth information about this research, please:
Contact your customer success representative if you are a current SafeBreach customer
Ron Ben Yizhak (@RonB_Y) is a security researcher at SafeBreach with 10 years of experience. He works in vulnerability research and has knowledge in forensic investigations, malware analysis, and reverse engineering. He previously worked in the development of security products and has been invited to share his research at DEF CON several times.
This entry was posted on July 1, 2026 at 8:00 am and is filed under Commentary. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Guest Post: An Update on You Snooze, You Lose: Winning LPEs by Racing Services for RPC Endpoints
Authors: Ron Ben Yizhak, SafeBreach Security Researcher
Last August, I shared a blog on my most recent research project called You Snooze, You Lose: RPC-Racer Winning RPC Endpoints Against Services, which I presented at DEF CON 33 (2025). In it, I demonstrated a novel attack technique I developed called Endpoint Mapper (EPM) poisoning—a method of registering a rogue remote procedure protocol (RPC) server ahead of a legitimate one to intercept client connections. I showed how it could be exploited to force a protected process to authenticate a machine account against an attacker-controlled server, enabling domain-wide privilege escalation.
Following that research, I continued investigating the boundaries of EPM poisoning to answer a question I had left open: could the technique be used to escalate from an even weaker starting point? Specifically, could a low integrity process leverage EPM poisoning to break out of its sandbox entirely? The answer turned out to be yes—and the path there involved an obscure scheduled task, a bypassed Windows security mechanism, and an XML injection hidden inside a toast notification.
Below, I’ll first provide a high-level overview of the original research. Next, I’ll explain how I expanded the attack surface to low integrity processes, describe the new vulnerability I discovered in the Data Sharing Service, and share additional EPM poisoning impact discovered by Microsoft. Finally, I’ll cover the vendor response, detection guidance, and directions for further research.
Background on the Original Research
NOTE: This section provides an overview of the original You Snooze, You Lose: RPC-Racer Winning RPC Endpoints Against Services research; readers already familiar with it can skip to the following section.
The Windows RPC protocol is one of the core building blocks of inter-process communication on Windows. When an RPC client needs to find a server by interface universally unique identifier (UUID)—without knowing a specific endpoint—it queries the EPM, which functions similarly to a DNS server: it resolves a UUID to a registered endpoint and connects the client to the first matching server.
This design became the foundation of my research. I set out to determine whether an attack analogous to DNS poisoning could be applied to the EPM—a technique I came to call EPM poisoning. The key discovery was that there is no verification mechanism preventing an unprivileged process from registering a built-in, well-known RPC interface. As long as a rogue server registers an interface before the legitimate service does, the EPM will route clients to the attacker.
To operationalize this finding, I developed two tools:
The primary exploit chain I demonstrated targeted the Storage Service (StorSvc). Because StorSvc is set to delayed start, a scheduled task launched at user log-on can register its interface before the legitimate service. The Delivery Optimization service—which runs as a Protected Process Light (PPL)—connects to StorSvc to retrieve a storage path via the `GetStorageDeviceInfo` method. By controlling the response, I was able to return a network share pointing to an attacker-controlled SMB server, causing the Delivery Optimization service to authenticate to it using the machine account credentials.
This vulnerability can be utilized to execute the attack ESC8. I launched RPC-Racer on a domain controller as a non-administrative user to force it to authenticate with the machine account credentials. From there, I relayed the authentication to the Active Directory Certificate Services (ADCS) web enrollment endpoint, requested a ticket granting tickets (TGT) for the domain controller’s machine account, and used it to dump all domain controller secrets—achieving full domain compromise from a medium integrity process with no administrative privileges.
Microsoft assigned this vulnerability CVE-2025-49760. They fixed it in a patch released on July 8, 2025, that added a security Quality of Service (QOS) check to the StorSvc RPC client so it would only connect to servers running as the local system account.
Taking It Further: Low Integrity Processes as an Attack Surface
After completing the original research, I returned to a question I had set aside: what if we started from an even more restricted position? Most of my original research began as a medium integrity process. But many widely-used applications—browsers, code editors, sandboxed apps—run at low integrity. This is an intentional security design; Microsoft’s documentation explicitly states that escaping low integrity is especially difficult because low integrity processes are prevented from writing to most registry keys, folders, and system components.
To my surprise, however, low integrity processes can still register RPC servers. That alone opened a path worth exploring. The challenge I ran into was that many of the techniques I used in my original research didn’t work from low integrity. Low integrity processes cannot create scheduled tasks, cannot write to the startup folder, and therefore cannot reliably race delayed services at boot. I needed to find a different target—ideally a manual service (not launched at startup) whose RPC interface could be registered at any time, with a client that could be triggered on-demand, and that was unlikely to rigorously validate data received from an assumed-trusted server.
Identifying the Target: Data Sharing Service
After filtering built-in RPC servers based on startup type, the complexity of their interfaces, and the types of data their methods return, one candidate stood out: the Data Sharing Service (DsSvc).
DsSvc acts as a broker for file-path sharing between applications. If we simplify its actions, it holds a basic dictionary of paths to tokens.
When two apps need to exchange a file path, the first app calls `DSSCreateSharedFileToken` to request a token representing the path.
Finally, the second app calls `DSSGetSharedFileName` to retrieve the path the token represents.
.Searching for files that import `dsclient.dll`—the RPC client for DsSvc—led me to several programs. One stood out immediately: PerformanceTraceHandler.dll. This is the core component of the built-in scheduled task RequestTrace.
The RequestTrace Task and the UIPI Bypass
RequestTrace collects diagnostic information from the machine and—unlike most scheduled tasks—it can be started in several ways: via the Task Scheduler COM object, via a Windows Notification Facility (WNF) state change, or by pressing the hotkey combination Win+Shift+Control+T.
The first two methods are blocked for low integrity processes. The Task Scheduler COM object is inaccessible to low integrity, and the `NtUpdateWnfStateData` API call required for the WNF trigger is also restricted. The hotkey, however, presented an interesting opportunity.
Windows uses a security mechanism called User Interface Privilege Isolation (UIPI) to prevent low integrity processes from sending input messages, setting Windows hooks, or injecting keystrokes into higher-integrity processes. UIPI is a critical sandbox boundary. But UIPI blocks input messages—does that include hotkeys? Maybe a combination would work.
I called `SendInput` from a low integrity process to send the Win+Shift+Control+T key combination, and the RequestTrace scheduled task launched successfully using an RPC client connecting to me. This is a meaningful finding in itself: low integrity processes can trigger any scheduled task that has a hotkey-based trigger, which is worth investigating independently as an attack surface.
XML Injection via Toast Notification
This task depends on an option that is turned on by default when installing Windows: the send optional diagnostic data under the Diagnostics & Feedback settings. Once the task starts, it pops a notification to the user indicating data is being collected. This type of notification is called “toast.”
After a short duration, a second toast is presented with actions the user can take.
Once RequestTrace launches—and the second toast is presented—PerformanceTraceHandler assembles a zip file of diagnostic data and prepares to share it with the Feedback Hub application. To do this, it calls `DSSCreateSharedFileToken` on what it believes is the legitimate DsSvc server—but since I registered the interface first, it connects to my rogue server instead. The token I return is appended to a Feedback Hub URI, which is then formatted into an XML document defining the properties of a toast notification shown to the user.
The XML document defines exactly how many buttons will be shown and what will happen when they are clicked. After appending the token we return, the entire URI is formatted into the arguments property between two double quotes, as highlighted.
<toast scenario=”systemDialog”>
<visual lang=”en-US”>
<binding template=”ToastGeneric”>
<text id=”1″>A trace has been successfully saved to
%%LOCALAPPDATA%%\Traces.</text>
</binding>
</visual>
<actions>
<action id=”1″ activationType=”Protocol” arguments=”%ws”
content=”Launch Feedback Hub”/>
<action id=”2″ activationType=”Background“
arguments=”verbNotOk” content=”Dismiss”/>
</actions>
</toast>
Formatting an attacker controlled string into quotes is very interesting and dangerous. We can close the original double quotes in the format string where the URI is inserted using the highlighted characters. After closing the original double quotes, we can append arbitrary XML data and still keep the XML document valid.
Below is an example of a payload I could inject.
NOTE: On vulnerable builds of Windows, there was a bug that prevented me from setting the action of a button to an executable file. This is why I used a Python script. Since then, however, this bug has been fixed—you can read more about it in our recent research post: Click Or Trick (CVE-2025-59199): Escaping the Sandbox with Windows URIs.
This adds a button to the toast notification and sets the action to point to any file I want. When the user clicks the injected button, the file is executed with medium integrity—breaking out of the low integrity sandbox entirely.
It’s unbelievable that I could do that! The URI of the Feedback Hub isn’t verified at all before it is formatted into the XML. There is no check for special XML characters because this program completely trusts its RPC server. We just achieved a one-click local privilege escalation from low integrity to medium integrity.
To recap the attack flow:
Watch the demo.
Vendor Response
When it comes to our original research, SafeBreach is deeply committed to responsible disclosure. In line with that commitment, I disclosed the Data Sharing Service vulnerability to Microsoft on July 14, 2025. It was issued CVE-2025-59200 and a fix was released on October 14th, 2025. As with the StorSvc fix from my previous research, the patch adds a security QOS check to `dsclient.dll,` so the RPC client verifies the server is running with elevated privileges before establishing a connection.
Key Take Aways & Broader Impact
This research exposed some serious security issues, and I believe there are a few lessons that should be noted:
In publishing the original EPM poisoning research at DEF CON 33 in August 2025, I described several directions for further investigation—including the Windows Security Center and Windows Defender, both of which interact with RPC interfaces that may be vulnerable to EPM poisoning.
Shortly after the talk, Microsoft independently identified another vulnerable RPC interface: the **Windows Remote Access Connection Manager (RasMan). Hijacking the RPC interface of `rasmans.dll` via EPM poisoning could lead to SYSTEM-level privilege escalation. Microsoft patched this vulnerability (CVE-2025-59230) in October 2025, applying the same fix pattern: adding a security QOS check to the RPC client so that it verifies the server is running with elevated privileges before connecting.
The rapid identification of a third vulnerable component—just months after the original research was published—suggests that EPM poisoning is a productive avenue for finding privilege escalation vulnerabilities across the Windows RPC ecosystem. So far, the patches have addressed specific clients rather than the root cause in the EPM itself, leaving more avenues for manipulation.
For example, an attacker could:
Detection
Because these patches address specific RPC clients rather than the EPM itself, EPM poisoning remains a viable technique against other interfaces. Organizations can take steps to detect it, specifically:
Further Research
The UIPI bypass demonstrated in this research—triggering a scheduled task via hotkey from a low integrity process—warrants further investigation. Microsoft maintains documentation listing many key combinations and the programs they trigger; it is worth exploring how many of those programs interact with RPC services and whether they can be similarly exploited.
Beyond hotkeys and low integrity, the broader EPM poisoning attack surface remains largely unexplored. There are many delayed and manual services across the Windows RPC ecosystem—this research has only scratched the surface. One particularly interesting target remains the Windows Security Center, which is set to delayed start and is used by Windows Defender. A malicious response to Defender from a rogue RPC server could potentially neutralize it entirely.
Conclusion
This research extended the EPM poisoning technique to low integrity processes, demonstrating that even heavily sandboxed applications can be weaponized to escalate privileges if they can trigger an RPC client connecting to an attacker-controlled server. The Data Sharing Service vulnerability, exploited through an XML injection hidden in a toast notification, shows how trust in RPC server identity—when unverified—can cascade into unexpected and impactful security failures.
To help mitigate the potential impact of these vulnerabilities:
We have also:
For more in-depth information about this research, please:
About the Researcher
Ron Ben Yizhak (@RonB_Y) is a security researcher at SafeBreach with 10 years of experience. He works in vulnerability research and has knowledge in forensic investigations, malware analysis, and reverse engineering. He previously worked in the development of security products and has been invited to share his research at DEF CON several times.
Share this:
Like this:
Related
This entry was posted on July 1, 2026 at 8:00 am and is filed under Commentary. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.