Hopefully you have arrived here having read the part one of this guide which walks you through developing a strategy and those all important macro embedded documents. If not, you can find the article here.
So in this article we are going to cover a little bit about crafting a successful email and then get into the rather complicated topic of getting these emails to your users.
Crafting an enticing email
Okay so I always find this the “easy” bit. The aim of the email is to convince the reader that it is not obviously spam AND make then want to open that malicious attachment. Enterprise users are receiving documents and spreadsheets all the time so they are more than comfortable opening these attachments. The difficulty comes in getting those users to enable the use of macros in these documents but hopefully you have already thought of a convincing reason in Part I. The easiest place to seek inspiration for an email is often your own inbox which will undoubtedly be full of spam itself. In a corporate environment I’ve had plenty of success with simple plain text emails but you do have HTML available should you want to enrich it with pictures. If you do decide to go down the HTML route, here is a quick bit of code you can copy and swap bits to make it work for you. Importantly every time I need to quote something I use ‘ as if you use this with my PowerShell email sender then “ are out of bounds (kinda!). All those pesky <br> tags cause a new line as simply putting things on a new line doesn’t work in HTML.
<html> <center> <img src='http://www.website.com/image.extension'> </center><br> Hi,<br> <br> You really should open that attachment you know!<br> <br> Regards,<br> TheHakkor </html>
Sending the emails
The first few times I executed a macro malware campaign I went through a rather convoluted process which I will share with you here as it’s a good bit of background information before we move onto an automated process. So the challenge we have to overcome is to be able to send the email with a spoofed originator, otherwise we would be leveraging any trust the user has with emails from your own email address and that isn’t going to be helpful. We also need to be able to craft the email to look professional and send it, which sounds obvious but means we have little hope of simply opening a connection to an email server and composing a basic email. Fortunately SMTP is a plain text protocol; so what we can do is create our email in a mail application, send it via insecure SMTP and intercept it en route with Wireshark. We can then simply copy the commands we captured and swap out some of the email content. Easy right? Let’s see an SMTP capture to get a better idea.
Note: This capture is from the Wireshark samples, a great resource.
Okay so here we have a snip of the traffic from Wireshark. We are only really interested in the red text as that is what our mail application has sent. We also don’t need to worry about authentication as we will either control the server (and turn it off) or be sending to the users mail server which is expecting unauthenticated inbound mail. So whats happening in this conversation.
We send a EHLO to open the conversation before providing a MAIL FROM: and a RCPT TO: command. We can then provide the DATA command and our email content with yet more headers, a lot of which we can trim out. So if we intercepted this email, we should be able to simply copy this conversation, telnet to the server and paste it in to send the same email again right? Actually no, a second email with the same Message-ID header will be dropped so we would need to modify that at the least.
Still with me? Good, let’s trim this “conversation” down so we can understand it. I’ll remove all the content that doesn’t apply to us. The other thing to note at this point is the use of boundaries to denote the different parts of the email. As you will see, these can be used to separate elements of the email i.e. a html body followed by a pdf attachment but also can be used to provide alternative content (usually to provide a html email with a plain text fallback body in case html isn’t supported by the recipient).
EHLO GP MAIL FROM: <[email protected]> RCPT TO: <[email protected]> DATA From: "Gurpartap Singh" <[email protected]> To: <[email protected]> Subject: SMTP Date: Mon, 5 Oct 2009 11:36:07 +0530 Message-ID: <[email protected]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01CA45B0.095693F0" ------=_NextPart_000_0004_01CA45B0.095693F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01CA45B0.095693F0" ------=_NextPart_001_0005_01CA45B0.095693F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello ------=_NextPart_001_0005_01CA45B0.095693F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = ... html content removed ... </html> ------=_NextPart_001_0005_01CA45B0.095693F0-- ------=_NextPart_000_0004_01CA45B0.095693F0 Content-Type: text/plain; name="NEWS.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="NEWS.txt" Version 220.127.116.11 * Many bug fixes * Improved editor ------=_NextPart_000_0004_01CA45B0.095693F0-- . QUIT
So hopefully from looking at that trimmed conversation, you can see that actually we haven’t got to swap a great deal to change the sender and recipient of this email. This was my initial solution; craft an email, capture it in transit, copy the conversation, drop it into PowerShell (and sprinkle in some variables), then churn out hundreds using NetCat (which a simple but brilliant utility to send text over the network) to send them. You could do this same process with Wireshark, notepad and telnet / NetCat and then even automate bits of it with your favourite programming language.
One last thing to note, if you intercept your emails they will have their content Base64 encoded. This encoding ensures that whatever binary data needs to be transmitted it can be sent as a string of one of 64 characters. As you will be sending binary files and each byte doesn’t have a readable ASCII representation, it gets encoded into Base64. Your “conversation” will also be a lot longer as the Base64 can be huge!
This bring us on nicely to…
Sending the emails the easy way
You already know of one reliable (albeit laborious) process to send those emails. An alternative is to use an off the shelf solution or to create a script that will generate those emails for you.
As it happens after a few run throughs of that earlier process I got rather fed up of it and created a PowerShell script to take in all the necessary information, craft the email “conversation”, connect to an SMTP server and conduct that “conversation”. As this script is rather long though, I have given its own article which covers how to use it and then at the bottom a whole lot of information about how it all works. You can find that here.
So if you launch PowerShell ISE, paste that script in and fill in all the required content you will be ready to send!
One last note, for your own network you should be able to deliver all of your emails into a given SMTP server (Exchange or Postfix maybe?), however if you are external you may want to comment the SMTP server line out and send to the targets mail server. If you go down this route, you will have very limited success unless you are using a static, non-domestic IP address due to spam filtering.
Update: I have created another really short script to run on a domain controller to extract all those user emails you need to populate the email sending script. It is pre-configured ready to go, just paste it into PowerShell ISE and run it. It will create an emails.txt file which you can copy and paste into the $targetEmailAddresses array.
That’s it for now, I may do a part three at some point and cover how to make something a little more malicious as I do love a good PoC to show to management ;).
Thanks for reading,