Long time no see! After 3 years of no new blog posts and also no conference talks from my side, I decided it’s time to write again. I’ll start easy with a fun story that happened a while ago. I gave a short lightning talk about this on Alligatorcon 2024, but as it may be of greater interest, ChatGPT and I wrote a little more elaborate version that consists of full sentences. If you prefer clicking through my original slides, you can find them here.

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’s authenticator vmwareidentity.de that can be abused by sending links to unauthenticated victims. Also, I found it possible to export a user’s authentication certificate, which allows to access zero trust protected resources without access to the user’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.

TL;DR: I’ll shine a light on Gophish and how to modify it to change behavior or introduce/remove functionality. At the end of this post, you’ll know how to host custom 404 pages in Gophish and how to abuse HTTP basic auth instead of login forms embedded on the landing page to obtain juicy creds.

A few days ago I tweeted one of my modifications to Gophish:

After low click rates in my last phishing campaign due to staff being extremely well trained for this kind of attack, I modded gophish to show an HTTP Basic auth request instead of a phishing site. Once data is entered, users are redirected to a legit site: pic.twitter.com/LncsgT8OSE

[Read More]

TL;DR: In some circumstances, you may find usable Kerberos TGTs on a system you compromised - these allow you to impersonate a user that already changed its password (e.g. because the user got suspicious or a PAM solution is in place).

Intro

On a recent project, I was tasked with the usual goal: Start from the ground and find a way to take over the company - in the end, if possible, somehow become Domain Admin. Getting started was tough, but after some time I got my hands on a few admin accounts and had a way to take control of the Domain Admins - but the way involved resetting the password of a service account. Unless I do not have a very good reason to perform the password change or the explicit “Do it!” from the customer, I prefer finding another way. Lurking for a few days on the machines I gained access so far, I discovered two accounts that logged on recently. They both provided a simpler way to become Domain Admin because they were allowed to write the Domain Admin group directly - Jackpot!

TL;DR: 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 mstsc.exe. (You’ll need mimikatz or something else to inject the hash into the process)

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 using xfreerdp, but I wasn’t able to find anything on the Internet regarding how to do this directly using the provided RDP client mstsc.exe, so I had to find out on my own.