<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mimikatz on edermi's Blog</title><link>https://edermi.github.io/tags/mimikatz/</link><description>Recent content in Mimikatz on edermi's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 02 Mar 2026 21:55:17 +0100</lastBuildDate><atom:link href="https://edermi.github.io/tags/mimikatz/index.xml" rel="self" type="application/rss+xml"/><item><title>Vulnerabilities on vmwareidentity.de (XSS) and in VMware UEM (exportable authentication certificate)</title><link>https://edermi.github.io/post/2021/vmware_vulnerabilities/</link><pubDate>Sun, 29 Aug 2021 00:00:00 +0000</pubDate><guid>https://edermi.github.io/post/2021/vmware_vulnerabilities/</guid><description>&lt;p&gt;This post is a short notice about vulnerabilities in VMware products I found earlier this year.
During a penetration test of a freshly built environment, I took a closer look at VMware Unified Access Gateway (UAG) in combination with devices enrolled and managed via VMware Unified Endpoint Management (UEM).
I found a reflected XSS vulnerability on VMware&amp;rsquo;s authenticator &lt;code&gt;vmwareidentity.de&lt;/code&gt; that can be abused by sending links to unauthenticated victims.
Also, I found it possible to export a user&amp;rsquo;s authentication certificate, which allows to access zero trust protected resources without access to the user&amp;rsquo;s device or account on a trusted system.
There has been no advisory or notification for affected customers I am aware of.
The disclosure deadline was already a few weeks ago and VMware did not respond to multiple attempts of contacting them as well as offering an extension of the responsible disclosure timeframe, therefore I am releasing the vulnerability details to the public.&lt;/p&gt;</description></item><item><title>Passing the hash with native RDP client (mstsc.exe)</title><link>https://edermi.github.io/post/2018/native_rdp_pass_the_hash/</link><pubDate>Sun, 06 May 2018 00:00:00 +0000</pubDate><guid>https://edermi.github.io/post/2018/native_rdp_pass_the_hash/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;TL;DR:&lt;/strong&gt; If the remote server allows Restricted Admin login, it is possible to login via RDP by passing the hash using the native Windows RDP client &lt;code&gt;mstsc.exe&lt;/code&gt;. (You&amp;rsquo;ll need mimikatz or something else to inject the hash into the process)&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;On engagements it is usually only a matter of time to get your hands on NTLM hashes.
These can usually be directly used to authenticate against other services / machines and enable lateral movement.
Powershell / PSExec, SMB and WMI are usual targets to pass the hash to, but it is also possible to use it to establish a RDP session on a remote host.
Searching the Internet on how to do this unfortunately always leads to &lt;a href="https://www.kali.org/penetration-testing/passing-hash-remote-desktop/"&gt;using xfreerdp&lt;/a&gt;, but I wasn&amp;rsquo;t able to find anything on the Internet regarding how to do this directly using the provided RDP client &lt;code&gt;mstsc.exe&lt;/code&gt;, so I had to find out on my own.&lt;/p&gt;</description></item></channel></rss>