auth and burn commands ignore --socks flag

[ForkAndForget]

I have encountered through testing that the auth and burn commands ignore the --socks flag and will attempt to reach directly to the target IP/Domain Controller.

The burn command appears act in two stages. The first stage is to acquire the ccache and NTLM and will attempt to reach directly to the target IP/Domain Controller. And the second half, which is to authenticate and connect to LDAP to modify the AD object, will respect the --socks flag and proxy the network traffic correctly.

First half of the traffic going Directly to the DC:

Second half of the traffic coming out of the host with the proxy on it:

Auth command ignoring the --socks flag:

The burn command also makes 2 separate AS-REQ/REP's, 1 in the first half to output for the user and for the first service ticket (to retrieve NTLM with U2U?), then again in the second half through the socks proxy for an additional TGT. The second TGT is then used to get an LDAP ticket in the second TGS-REQ/REP. Would it be possible to reuse the first TGT retrieved for requesting the LDAP ticket instead of requesting another?

[rtpt-erikgeiser]

Thanks for reporting this detailed issue. I can't look into it today, but our underlying library adauth supports SOCKS5 for Kerberos, so I probably only forgot to configure it in auth and burn. I originally implemented PKINIT in adauth specifically for the UnPAC-the-Hash technique and re-used it here in keycred. You are probably right that we can get rid of one of the requests, but to prioritize this correctly I would be interested in why it is important for you? Is it just that doing something unnecessary just feels wrong or is there something more to it?

[ForkAndForget]

Thanks for quickly responding. In regards to the burn command getting multiple TGT's, I thought only requesting one instead and reusing it would put it more in line with normal kerberos behavior, eliminate a potential IOC, and would help limit any unnecessary network traffic. Then again, tickets are not reused between commands ran that interact with the target environment, triggering new AS-REP/REQ's and TGS-REP/REQ's that are sent to the target domain controller. Most of this can be largely mitigated by using the --ccache flag with an ldap service ticket anyways for those who are concerned about kerberos request generation and signatures that may be written to flag on them.

That being said, do you think it would make sense for keycred to have the capability to request different types of service tickets with the auth command? Something like --service 'ldap/host.local.net' and saving that to a file for further usage? Along with the ability to specify an optional TGT, like a --tgt flag or something similar, in lieu of a pfx for follow on service ticket requests. I think would be handy, a good fit for the command, and doesn't seem like it would be a lot of effort to implement given what's already there. Please feel free to correct me if I am wrong or this feature isn't suited for this tool.

For example, in the initial PKINIT request:
keycred auth --pfx-password password --pfx user_pfx.pfx --service 'ldap/PC.test.local' --dc dc.test.local

Or for follow on requests:
keycred auth --tgt 'user@test.local.ccache' --service 'ldap/PC.testl.local' --dc dc.test.local

Multiple at once:
keycred auth --tgt 'user@test.local.ccache' --service 'ldap/PC.test.local,host/PC.test.local' --dc dc.test.local

[rtpt-erikgeiser]

I can't really test it right now, but I added SOCKS5 support in this PR: #3
Could you confirm that it works so I can merge it?

The auth command is actually a bit of a misnomer because it was intended as a pure PKINIT+UnPAC-the-Hash command like certipy auth (thats where the name comes from). This is also the reason why it requests two tickets (for the UnPAC-the-Hash part). The auth options you are proposing sound cool, but I don't think its a good match for keycred because it expands its scope to functionality of impacket's getST.py, getTGT.py. I'd like to have a Go implementation for that, but I'd rather not put it into keycred.

[ForkAndForget]

I was thinking that suggestion may have teetered on scope creep a bit, but I thought I would ask anyways to get your thoughts. With more context, the auth command being a misnomer puts it into perspective for me so thank you for explaining that. I was able to confirm that the changes you've made to auth and burn are now properly respecting the --socks flag. Thank you for fixing it!

I have one more suggestion. for readability, would it be possible to clean up the Linux ANSI formatting in keycred's command output when the target operating system for compilation is windows?

[rtpt-erikgeiser]

I welcome these kinds of suggestions and thought about it quite a bit. It is always good to know how people use these tools and how they want to use them.

I already saw the unparsed ANSI escape codes in our screenshots. I can probably fix them in a way that you actually get colored output. Here's the background behind the ANSI sequences in keycred:

• I think colored output is quite important for guiding the eyes, not just as eye candy.
• I anticipated that it would not work on Windows with the old conhost terminal emulator. However, I figured that after support for Win 10 is dropped, most people use Win 11 where the new terminal is pre-installed afaik. I thought that most people that actually use the terminal probably changed the default to the new one because it is much better. The new one should render these ANSI sequences by default.
• If I remember correctly, I made ANSI colored work in old conhost in https://github.com/RedTeamPentesting/pretender by switching the terminal in a different mode. I did that because back then there was no alternative.

So I can probably implement this here, too. However, I would ask you to make a case for using the old conhost so I can get an idea of how likely it is for users to work with keycred in the old terminal emulator.

[ForkAndForget]

I thought it would be nice from a convenience perspective. One could simply up arrow and get any other corresponding tickets of their choosing without having to fiddle with python dependencies, virtual environments, configuring socks infrastructure for socks unaware tools, etc... but thank you for considering my suggestion and giving it so much thought.

I agree that colored output can help guide one's eye. That said, I think there are a couple of use cases where the ANSI coloring may benefit from being toggleable. I could see people still running keycred in older environments, CI systems, or when piping output to files, logging framework ingestion, etc... There are some other smaller use cases as well like colorblind folks, file greppability, and different colored background/terminal themes. I could imagine how in some circumstances ANSI sequences may end up making the output harder to read/ingest/process rather than clearer, albeit they may be edge cases.

While the new terminal is overall better, I can see how some people would stick new what they know (people are habitual and like what they like) vs switching over to a new thing. A more robust feature set in the new terminal and Microsoft's update cycle also presents the possibility of updates breaking things (There has been a number of reports of Win11 updates breaking even simple features like task manager, start menu, and file explorer) or behaving strangely vs an older, more stable and known terminal.

Maybe something like a --no-color flag would work? Or TTY detection for colored output coupled with what you've suggested, implementing ANSI coloring like you have in pretender for old conhost?