Error in brand new lab domain
ThisGuyNeedsABeer opened this issue · comments
We found in testing one of our domains was vulnerable so we spun up a mimic'd lab environment.
The new user is getting access denied during relay:
`C:\Users\labuser>KrbRelayUp.exe relay -d demolab.com -c -cn evilhost$ -cp pass123
KrbRelayUp - Relaying you to SYSTEM
[+] Computer account "evilhost$" added with password "pass123"
[+] Rewriting function table
[+] Rewriting PEB
[+] Init COM server
[+] Register COM server
[+] Forcing SYSTEM authentication
[+] Got Krb Auth from NT/SYSTEM. Relying to LDAP now...
System.UnauthorizedAccessException: Access is denied.
Access is denied.
at KrbRelayUp.Relay.Ole32.CoGetInstanceFromIStorage(COSERVERINFO pServerInfo, Guid& pclsid, Object pUnkOuter, CLSCTX dwClsCtx, IStorage pstg, UInt32 cmq, MULTI_QI[] rgmqResults)
at KrbRelayUp.Relay.Relay.Run(Object aDomain, Object aDomainController, Object aComputerSid, String aPort)`
If I go back to our production domain, I do not get the same error. Demo lab is hosted in AWS, however we have a private subnet of 10.50.50.0/24 and all traffic is allowed back and forth (0.0.0.0/0).
Could it be that your new testing domain is configured with LDAP signing enforced (which mitigates this attack path)?
If not, could you test this attack path manually using this guide and let me know the results so I can narrow down the possible causes of this error?
Manual attack guide by @an0n_r0:
https://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9
Yes, I may not be able to get to this today but I will as soon as possible. My source machine for attack was a domain joined W10 21H2 machine in EC2 (the entire lab is EC2 hosted). I found that running the same attack against our demo 2019 DC from a server 2016 endpoint did NOT encounter the issue. The AMI for W10 was not a Microsoft official build, so that may also have had something to do with it. Another bit of interest was that the attack would sometimes fail from source 2016 server, but after a reboot it would be successful.
I will continue testing and report back as my work day allows.
是不是您的新测试域配置了强制执行 LDAP 签名（这缓解了这种攻击路径）？ 如果没有，您能否使用本指南手动测试此攻击路径并让我知道结果，以便我可以缩小此错误的可能原因？
@an0n_r0的手动攻击指南： https ://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9
Hey @ThisGuyNeedsABeer did you get any further with your testing/findings? I found this issue having a near identical error on a pentest. The victim box I'm trying to escalate on is a Server 2016 RDS box. I got krbrelayup past EDR and ran the "relay" portion, and everything goes fine in the tool output until I hit "Forcing SYSTEM authentication" and then I basically get what you have with the "Access is denied" message. I verified LDAP signing is not enforced.
Anything else to do/test/try?