SOCKS functionality no longer working

[stephenbradshaw]

Hi

Looks like the SOCKS functionality is no longer working properly in poseidon as tested on x86_64 Linux Ubuntu 16.06.6 LTS kernel 4.4.0-121-generic when using the http communication profile.

This was reproduced using poseidon commits 029d1526bb46651fb9d859e9c5a57479aefe2d49 and 7c2349da41144e52670447b099b4db31917dd3a0 .

Steps to reproduce involve:

1. Generating a poseidon binary payload communicating using http
2. Running the payload on a system with the previously mentioned architecture and linux release and getting a callback in Mythic
3. Setting the sleep interval to 0 to provide a usable communications channel for the proxying
4. Starting the socks server on port 7000
5. Attempting to do a simple netcat comms check on the Mythic server using proxychains-ng configured for socks 5 to a machine/port accessible from the host running the agent, e.g.: proxychains4 -f proxychains_7000.conf nc -vv 192.168.1.2 445
6. The connection then dies with socket error or timeout! from proxychains-ng and Connection refused from netcat

This is something I have had working previously on poseidon on this same testing host. I tested reverting to commit 5eb93dc681a8b1fbf0e2fe3390d18e3cd475e580 and SOCKS works using the above mentioned steps.

Let me know if any more detail is required

[its-a-feature]

Are you sure that the firewall is open to allow that connection? I just cloned down and tested poseidon against a Windows machine and got:

# Firewall on for Windows host
its-a-feature@ubuntu:~$ proxychains nc -vvv 192.168.53.133 445
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-192.168.53.149:7000-<><>-192.168.53.133:445-<--timeout
nc: connect to 192.168.53.133 port 445 (tcp) failed: Connection refused

# Firewall off for Windows host
its-a-feature@ubuntu:~$ proxychains nc -vvv 192.168.53.133 445
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-192.168.53.149:7000-<><>-192.168.53.133:445-<><>-OK
Connection to 192.168.53.133 445 port [tcp/microsoft-ds] succeeded!

What if you try something else that's more likely to work, like curl www.google.com through the SOCKS proxy?

[stephenbradshaw]

I performed the exact same steps using the newer and older revisions of poseidon mentioned above on the exact same hosts (e.g. the same Mythic server, the same Linux system running poseidon and the same Windows host and port (445) to test connect to with netcat). I didn't touch the Windows firewall on the destination host at any point, and if I try the netcat connect test directly from the Linux host running poseidon via ssh it works. As previously mentioned, the connect attempt ALSO works when using SOCKS in the older revision of poseidon from February 25, but does not work in the commits I have tested after that point. Its definitely not the Windows Firewall.

The payloads were also generated the same way, using the http communications profile connecting directly to the Mythic server using http (no ssl), with all settings but for the communications profile set as default. Im using a saved instance for the http communications profile settings so those settings will have also been identical, and also all default apart from the destination URL (which uses an IP address not a hostname due to minimal resolution DNS in the test environment). I haven't tested this using any other communications profile. The poseidon implants were all executed the same way on the host, ssh in and run it backgrounded from the /tmp directory. All revisions of the implant connected back to Mythic successfully, all returned success responses when changing the sleep parameters and starting the proxy service, and the proxy service was shown to be running in the SOCKS window in Mythic when I expected it to be. Other simple commands such as ls are working in the implant and returning results, so a working communications channel is definitely present.

The particular environment I am testing this in doesn't have outbound Internet access, so I haven't been able to test something like curl www.google.com - the netcat test is the "basic" one I use in this case, as it is simple TCP, directed at a port I know is open and doesn't need DNS resolution or to connect outside of the internal network. This port is also one I cant connect to WITHOUT the SOCKS proxy routing the traffic, so also has the benefit of confirming that the proxy is routing the traffic through the correct endpoint.

Ive tried other ports I know are open in the internal network too (confirmed by trying to connect directly from the Linux host running poseidon) with similar results. Ive tried curl requests to web servers running in the internal network, including one running on the host with the poseidon implant, and those also didnt work.

The only difference between the test working and not working was the revisions of poseidon installed on Mythic when generating the poseidon payload. The difference in the revisions is apparent when generating the payloads, as the non working ones provide an extra communications profile choice of posiedon_tcp when creating the payload. I currently have three different versions of the poseidon implant on my test host, with the commit revision used to generate them in the description, and have been able to switch between them and reproduce this result consistently.

Apologies for not providing more of this relevant detail straight up, I made a bad assumption that this problem would be easy to reproduce on your end, but apparently I have something unique going on in my test environment. Are there any other specific tests you would like me to try here? Perhaps testing poseidon on a different revision of Linux, or testing a different comms profile? (I havent done either yet as it will require a bit of additional setup)

[stephenbradshaw]

FYI, I did a little bit more testing by running tcpdump on the Linux host running poseidon as well as the Mythic server while trying to proxy a connection to the open port 445 on the Windows box.

I see the three way handshake to port 445 successfully complete in the packet capture on the poseidon box for both the working (5eb93dc681a8b1fbf0e2fe3390d18e3cd475e580) and non working (029d1526bb46651fb9d859e9c5a57479aefe2d49) revisions of the payload.

However in the packet dump on the Mythic server side for the SOCKS connection that works (5eb93dc681a8b1fbf0e2fe3390d18e3cd475e580) I see an additional packet being returned from the SOCKS server during the connection attempt. When decoded in Wireshark, this was revealed to contain a SOCKS v5 "Succeeded" message. This SOCKS "Succeeded" message was not present in the packet capture for a payload with revision 029d1526bb46651fb9d859e9c5a57479aefe2d49.

So it looks like on my test instance the SOCKS proxy in revisions later than 5eb93dc681a8b1fbf0e2fe3390d18e3cd475e580 is not returning a SOCKS "Succeeded" message on successful TCP connections.

[eddiezab]

Just as a point of confirmation, while I haven't conducted the level of debugging as the reporter has, we started using poseidon just a few weeks back and the SOCKS proxying was not working for us. We switched to the 5eb93dc681a8b1fbf0e2fe3390d18e3cd475e580 commit, and now SOCKS is working.

[its-a-feature]

What version of Mythic are you using with the latest version of poseidon? I just installed the latest poseidon on the latest Mythic and was able to use SOCKS for web browsing and ssh, so I'm just having a hard time reproducing what you're seeing so I can troubleshoot.

[eddiezab]

We're using the tagged 2.3.7 version of Mythic. Unfortunately, I cannot pinpoint the version of poseidon I had prior to installing the specific commit listed above.

[its-a-feature]

I really should tag a new release... let me do that and then if you can try again with the latest Mythic, that'll help me track down a bit more where the issue might be coming from.

[its-a-feature]

https://github.com/its-a-feature/Mythic/releases/tag/v2.3.9

[eddiezab]

Thanks for this. I'll be investigating in the next few days.

[stephenbradshaw]

Ive lost access to the test environment I was using to reproduce this issue. Will see what I can do about creating a new one to try and test the new tagged release

[stephenbradshaw]

Ive just retested this on a newly built Ubuntu 16.04.7 machine with poseidon c63e0f5 and Mythic 2.3.13 and cant reproduce it - SOCKS is now working just fine.

Not sure what the problem was here, maybe something subtly wrong with the original test box I dont have access to any more, but given I cant reproduce it any more and the lack of recent updates I figure this can now be closed.