Feature Request: Socks Session Manager - out of file handles

[ad0nis]

When relaying on especially noisy networks, I've run into multiple situations that completely exhausted file handles on my attacking system due to the number of authenticated sessions I've collected in ntlmrelayx.py. It would be great if there was some way to manage connected sessions, such as disconnecting specific users/machines, adding users/machines to a list of principals not to be relayed... My situation right now is that I have so many useless machine relays that I cannot collect any more privileged user relays, effectively stopping my attack until ntlmrelayx.py is restarted, losing time and effort for the earlier caught valid sessions. Would be wonderful if this could delete sessions matched by a regular expression/wildcard for removing many system sessions at once.

[asolino]

Wow.. amazing... Looks like the SOCKs relaying is working well ;) How many sessions you have till handles are exhausted? Will look into adding a close session command into the shell

…

On Fri, Mar 29, 2019, 12:27 ad0nis ***@***.***> wrote: When relaying on especially noisy networks, I've run into multiple situations that completely exhausted file handles on my attacking system due to the number of authenticated sessions I've collected in ntlmrelayx.py. It would be great if there was some way to manage connected sessions, such as disconnecting specific users/machines, adding users/machines to a list of principals not to be relayed... My situation right now is that I have so many useless machine relays that I cannot collect any more privileged user relays, effectively stopping my attack until ntlmrelayx.py is restarted, losing time and effort for the earlier caught valid sessions. Would be wonderful if this could delete sessions matched by a regular expression/wildcard for removing many system sessions at once. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#594>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALCp5FXUFUPcLcZGuxGgxKGbWu0LXZkCks5vbjDpgaJpZM4cSpRv> .

[ad0nis]

I don't have an exact count for how many sessions I was up to before hitting this error, but I could see that the error had been hit in the ntlmrelayx.py socks console because errors were being thrown like the following:
"[-] SMBCLient error: [Errno Connection Error (10.1.2.3:445)] [Errno 24] Too many open files"

[ad0nis]

I don't have a good example of it on hand, but this problem got to the point where even running "socks" in the socks console would fail to list the authenticated sessions until a file handle opened... (Just adding more detail, hoping that helps.)

[dirkjanm]

In the meanwhile, there is a startservers and stopservers command so you can (temporarily) turn off the listening part for new relay connections while continuing using the SOCKS features, which was added exactly for this reason.

[ad0nis]

OK - It's been a while since I've had this crop up, but it still happens on especially noisy networks, or in situations where I get lazy and target every system without SMB signing required... At one point, I did a little debugging and realized that this may actually just be hitting max open file descriptors/handles defaults in kali... If you run ulimit -a on kali, you'll find a maximum open file descriptors of 1024. I believe this is the limit I was running up against... What I would propose as a solution would be to get that count at start time, and then relay up to that count minus two, to ensure there is always one remaining file handle to run socks with, and one remaining file handle to relay an attacker connection through the proxy. From there, adding a warning once that max count is hit so that the user knows that no further relayed sessions would be ideal, perhaps even telling them that they can increase this limit, and warning of instability if the limit is increased...

[mpgn]

check #1113 @ad0nis

[ad0nis]

@mpgn: Responded in #1113.