> Research, learnings, and ramblings from someone cosplaying an offensive security professional
It's important to know if your NTLM relay will be prevented by integrity protections such as EPA, before setting up for and attempting the attack. In this post, we share how to solve this problem for additional protocols (MSSQL and HTTP), as well as publish RelayInformer tools to automate the solution.
Even within organizations that have achieved a mature security posture, targeted NTLM relay attacks are still incredibly effective after all these years of abuse. This technique eases the abuse of several popular NTLM relay primitives by allowing attackers to control inbound 445/tcp traffic without loading a driver, loading a module into LSASS, or requiring a reboot of the target Windows machine.
With the barrier to entry for initial access ever increasing, we spent some time digging into potentially lesser-known weaponization options for ClickOnce deployments, extending its value for offensive use cases by abusing the trust of third-party applications.
Leveraging SOCKS to proxy tools from a Windows attacker machine through a compromised host is a topic that contains some nuance and room for confusion. This nuance stems from protocol requirements of common network traffic being proxied into a target network, as well as the tools (or lack thereof) available for Windows to facilitate proxying network traffic via SOCKS.
Check for LDAP protections regarding the relay of NTLM authentication
BOF and Python3 implementation of technique to unbind 445/tcp on Windows via SCM interactions
Python and BOF utilities to determine EPA enforcement levels of popular NTLM relay targets
Golang search engine scraper intended for identification of published ClickOnce deployments
CVE-2020-0688 PoC