🧵 (2/x) So that now the execution hangs like follows ⏬
🧵 (3/x) But guess what, there’s another super cool tool – Coercer (by @podalirius_) – which can be used to trigger the authentication with a different API that is not affected by the ad-hoc check provided in the patch ⏬
🧵 (4/x) And now *tada* I can get my machine account certificate on a fully patched Windows 10 ⏬
🧵 (5/x) Check out @Flangvik’s stream to know more about ADCSPwn usage:
• • •
Missing some Tweet in this thread? You can try to
force a refresh
[#HackStory 🧵] (1/4) Here’s a generic case of reaching a locked-down PC from a firewalled segment in AD. The background is: 172.16.66.6 (the target) can talk to 192.168.1.11 (a PWNed server) but not vice versa and to no one else in the foreseeable network 👀
(2/4) Being a DA an adversary can create an evil GPO that will coerce Immediate Scheduled Task execution on the target. The task downloads and executes a PS cradle pointing to the PWNed server. Sure, there’re fancy (py|Sharp)GPOAbuse, etc… But when it’s a pentest, who cares 😒
(3/4) Meanwhile, some v4tov4 port proxies are configured on the pivot point by the adversary via netsh 😈
Yo, ho, was doing a bit of pentesting today. Inspired by @ippsec I shall give you my short story of 3 different paths to DA in 5 hours of work (hot pics are inside). Enjoy!
Path 1. DHCPv6 poisoning for initial access (thx to @_dirkjan)➡️authenticated PetitPotam to grab NTLMv1-SSP (thx to @topotam77)➡️ntlmv1-multi (thx to @Evil_Mog) + crack.sh to crack the response and get NT hash of DC➡️DCSync (thx to @SecureAuth)
(1/2) Path 2. Scan the network to discover an MS17-010 unpatched system ➡️ Use AutoBlue-MS17-010 to perform the exploitation with an x86 shellcode ➡️ Dump LSASS via comsvcs.dll LOLBAS technique ➡️ Exfiltrate the dump with PowerShell ➡️ Parse it to get credz of a privileged user