Sending mail in powershell (poor man's ssmtp in Windows)

A lot of times in a server you want to have a service be able to send and email. Sometimes this service is nothing but a script you wrote. As mentioned in a previous post, sometimes you just want a lightweight solution. In Linux I like to use ssmtp, but it is not available in Windows. So let's see if we can come up with the next best thing.

If you know me or my posts long enough, this is usually the cue for Powershell. And you would be right: it does provide the function send-mailmessage that allows you to craft an email which can then be sent to a proper SMTP.

Here's a quick proof of concept that I called mailtest.ps1:

$touser = "That guy <80sguy@email.example.com>"
$hostname = hostname
$SMTP = "smtp.example.com"
$fromuser = "Me "
$body = "Nothing to see. Move along"

send-mailmessage -to $touser `
                 -from $fromuser `
                 -subject "Test mail from $($hostname)" `
                 -body $body `
                 -SmtpServer $SMTP

All it does is send a test mail to that guy from the machine we are currently at. It does grab the hostname and creates a return address based on that. I did that because in a production script I like to know where my email came from. How would I used it in a production system? Let's say I have a script that monitors the default gateway and let's me know if it changed (long story). In that script I might have something like

$touser = "Me "
$hostname = hostname
$SMTP = "smtp.example.com"
$fromuser = "Gateway monitoring on $hostname "

function Send-Mail ($message) {
    send-mailmessage -to $touser `
                     -from $fromuser `
                     -subject "Default Gateway on $($hostname) Changed!!!" `
                     -body $message `
                     -SmtpServer $SMTP 
}

Now, we have a function that sends an email to Me indicating the default gateway has changed. It could be called by something like this

function Verify-Gateway($originalGateway){
    [...]
        if( $currentGateway -ne $originalGateway ){
            $Card.SetGateways($originalGateway)
            $message = @"
$hostname lost its default gateway. 
It thinks it is $currentGateway, but it should 
be $originalGateway. So, we changed it back.
"@
            # Let's write to a log
            Log-Msg ($message)
            # Then email message
            Send-Mail($message)
        }
    }
}

Makes sense? You can add more features to it, but the above works fine to me including my multiline string. Noticed in my example the smtp server does not require me to authenticate since I am in a "blessed" network. If that was not the case, fear not since send-mailmessage has a way to use authentication. I will leave that as an exercise to you.

Comments on a better than average Phishing Expedition

I take quite a few of you have received phishing emails. You know, some email that tries to compel the reader to click on a link to a site where for whatever reason they enter all their information so their identity, and credit card, can be stolen. And, maybe also get infected with a trojan in the process.

Some, with all respect, are rather lame. By that I mean the authors could not be bothered to

1. Spell and grammar check the letter. Yes, I know that those phishers might not speak natively the language of their target audience, but can't you be bothered to find someone to check it out for you?
   
2. Read it and make sure it make sense. I have received some that I read it 10 times and cannot figure out what is the point. There is nothing relating the text in the paragraphs and the reason to click on the link.
   
3. Take a few moments to study the target. Chances are our phisher phriend wants to hit a corporation or someone who is using a corporate service like facebook or microsoft or gmail. If you are trying to impersonate them, why not try to find out what the real letter you are trying to fake looks like?

Come on! I know it is harder than run the "EZ-Phisher" program and hit a button, but please try to make me feel pleased to see the phishing email instead of insulted. The fact those badly crafted phishing attacks work tells more about the target than the phisher, and what it tells is not pretty. If it comes as a shock to you that I

So this morning I received an impressive-looking phishing email that claimed to be from google. You probably want to know how it looks like, so I did a screen capture and put it here to the left. Don't panic, it is safe: you can click on it until you get a sore finger and it will not take you anywhere.

Now, this one I think is much better than your everyday phishing email. I mean, it is in a totally different timezone. Let's examine the phishing email and see what they did right and wrong:

What went right

1. Got the corporate colours right. The email claims to be coming from google, so they took the time to get the google icons and colours and even layout close enough to look credible.
   
   
2. Used knowledge of the official corporate website to hide their real url. If you hover the button, it would show the following link (am allowing it to overflow):
   
   Note they crafted their link so it is hidden after a few proper -- from the company they claim the email is coming from, google -- links. The link is long since our phisher phriends hope the real link will fall off the screen. Also, the last link, the one the probably points to their fake site, is behind a goo.gl link: you would need to click on it to first see what the link is, and then you are attacked. Specially if you use Internet Explorer a browser that does like to be cross site scripting vulnerable.
   
   
3. Hid the return email behind corporate-looking address. I like to see the source of the email, what gmail would call "Show Original". That usually is the 4th item from the bottom:
   
   When I tried to open it, the return address overwhelmed the menu bar, hiding all other options:
   
   Note that also worked when the email showed the return address (first picture on this article). That is good for a phishing email as it would make most users to not bother examining the email. Since we know what is the location of the option -- Show Original -- we want, we can use it regardless.
   
   
4. Avoided whenever possible relaying emails across too many non-corporate sites. The email looks like this:
   

   Delivered-To: phishing-victim@gmail.com
   Received: by 10.112.204.33 with SMTP id kv1csp2118911lbc;
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   X-Received: by 10.180.108.35 with SMTP id hh3mr31922715wib.48.1439282133631;
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   Return-Path: <perry_rhodan@interplanetary.edu>
   Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com. [209.85.212.194])
           by mx.google.com with ESMTPS id bl10si2265464wib.9.2015.08.11.01.35.33
           for <phishing-victim@gmail.com>
           (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   Received-SPF: pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) client-ip=209.85.212.194;
   Authentication-Results: mx.google.com;
          spf=pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) smtp.mailfrom=perry_rhodan@interplanetary.edu
   Received: by mail-wi0-f194.google.com with SMTP id p15so26093395wij.0
           for <phishing-victim@gmail.com>; Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
           d=1e100.net; s=20130820;
           h=x-gm-message-state:mime-version:from:date:message-id:subject:to
            :content-type;
           bh=LsemyedQTWVhfKEpSMfhlXsF9zPIYwDrlKawPrrmsog=;
           b=XAxoOiKIC3vJ4RIxmejkhdVXXBox3/I4nQYeu5Ml9F8Rq0Sjh+QKaY5M26FkPjX0fa
            Fu/v9fj+a451Aoc5AijUjqtrLEL8vH3Rhx7Kln7m6XrDo1P17HRVSDQCpoc7PlLZicSQ
            Mrnh6AFmYJ7PDCf1RuiJ8ACBZZ7+RwLLYtyEHnwxphUkCglVnJn75Vd8GDEBBv+G/BZw
            PISTui9PGA/jET733HHcLyA1FdYmYjJfWnOkM7oQBQv2/uR/xx9N06k21hbXKvYdOkkN
            oUafnLsuWnI8yBzJUaw2YpCr2HB2vw+ap9kTa4EkCzRntOhuBlpwzg60ukF6J+bdvbVf
            TpgQ==
   X-Gm-Message-State: ALoCoQmFD3lES/88ZcNCZQPJfj+ifiEDNpX5k0tRWJ0tphpzP282BDg6hmsHzb7Cf5n0u26AsTME
   X-Received: by 10.180.84.72 with SMTP id w8mr23619994wiy.71.1439282133247;
    Tue, 11 Aug 2015 01:35:33 -0700 (PDT)
   MIME-Version: 1.0
   Received: by 10.28.48.198 with HTTP; Tue, 11 Aug 2015 01:35:13 -0700 (PDT)
   From: "Google <no-reply@accounts.google.com> Google<no-reply@accounts.google.com> Google<no-reply@ac..." <perry_rhodan@interplanetary.edu>
   Date: Tue, 11 Aug 2015 09:35:13 +0100
   Message-ID: 
   Subject: Our Final Report
   To: undisclosed-recipients:;
   Content-Type: multipart/alternative; boundary=f46d044403ba48b9da051d04fc2f
   Bcc: phishing-victim@gmail.com
   
   --f46d044403ba48b9da051d04fc2f
   Content-Type: text/plain; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable
   
   =E2=80=8B

   One of the classic telltales that an email is scam or phishing is found in by following the Received: headers. So, this email pretends to be from Google. A lousily put together phishing one might have the last hop on google, but then the previous hops would bounce all over the place. This one, however, came from Google. We even know it was submitted directly to a google SMTP server and when.
   

   Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com. [209.85.212.194])
           by mx.google.com with ESMTPS id bl10si2265464wib.9.2015.08.11.01.35.33
           for <phishing-victim@gmail.com>
           (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
           Tue, 11 Aug 2015 01:35:33 -0700 (PDT)

   And we know who supposedly submitted it:

   Received-SPF: pass (google.com: domain of perry_rhodan@interplanetary.edu designates 209.85.212.194 as permitted sender) client-ip=209.85.212.194;

   It was someone from an university. Now, why would this person use gmail from SMTP? Well, let's ask the university itself:
   

   bash-3.2$ dig interplanetary.edu MX
   
   ; <<>> DiG 9.8.5-P1 <<>> interplanetary.edu MX
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21325
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 6, ADDITIONAL: 7
   
   ;; QUESTION SECTION:
   ;interplanetary.edu.                     IN      MX
   
   ;; ANSWER SECTION:
   interplanetary.edu.     3077    IN      MX      5 alt2.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      5 alt1.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      1 aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      10 alt4.aspmx.l.google.com.
   interplanetary.edu.     3077    IN      MX      10 alt3.aspmx.l.google.com.
   
   ;; AUTHORITY SECTION:
   edu.                    46983   IN      NS      a.edu-servers.net.
   edu.                    46983   IN      NS      c.edu-servers.net.
   edu.                    46983   IN      NS      f.edu-servers.net.
   edu.                    46983   IN      NS      d.edu-servers.net.
   edu.                    46983   IN      NS      g.edu-servers.net.
   edu.                    46983   IN      NS      l.edu-servers.net.
   
   ;; ADDITIONAL SECTION:
   a.edu-servers.net.      46983   IN      A       192.5.6.30
   c.edu-servers.net.      46983   IN      A       192.26.92.30
   d.edu-servers.net.      46983   IN      A       192.31.80.30
   f.edu-servers.net.      46983   IN      A       192.35.51.30
   g.edu-servers.net.      46983   IN      A       192.42.93.30
   g.edu-servers.net.      46983   IN      AAAA    2001:503:cc2c::2:36
   l.edu-servers.net.      46983   IN      A       192.41.162.30
   
   ;; Query time: 34 msec
   ;; SERVER: 10.0.0.10#53(10.0.0.10)
   ;; WHEN: Tue Aug 11 08:55:08 EDT 2015
   ;; MSG SIZE  rcvd: 380
   
   bash-3.2$

   So, this university uses gmail to send its emails. I guess that means it decided to move to the cloud by outsourcing its emails. I know a lot of people who are rabbid avocates to pushing as much of the IT infrastructure to be hosted by commercial vendors in the cloud. I wonder how many did the due diligence, but I digress. The upshot is that it makes it easier for a careful phisher to do research on targets: instead of having to go to many different sites, the eggs of many business are now literally being held in few baskets. For instance, if the target companies are, say, using the Microsoft cloud, a Microsoft-looking email to all the users in the target corportations would look legit. And that allows phishers and other hackers with criminal intents to concentrate their efforts.
5. Email passed DKIM and SPF, which adds to its legit feel.
   

What went Wrong

Unfortunatley this phishing email was not perfect. The issues are few and far between but are there.

1. Grammar. It is not horrible, but it does made me stop too long to see it was spam/phishing. The We always protect you and Our Final Report did sound a bit odd. The first one was close to what Google might have written but no cigar. Still, since it does not have the usual chicken little warning messages bad phishing uses, I honestly passed through it without noticing much. And besides, We always protect you gives a warm and fuzzy feeling, not as much as a box of kittens but you get my point.

   The first paragraph is a different story. It does not sound like what a native English speaker would say -- it is too wordy and convoluted -- and Google would have spent the money to put their message in nice clear 8th grade English. The second paragraph started with a lowercase; don't know any language that has upper and lower cases that would do so.
   

2. No spaces between paragraphs. The paragraphs are short as they would in a Google announcement -- keep it simple and fast so user won't lose interest -- but because of the lack of spaces between them they look too cluttered. Still from a distance it looks clean and pleasant.
   

Overall I would give it a 7/10: good effort, better than average delivery, and took some time to know target. But, this phishing attempt could be better.

Keep up with the good work!

Finding the file format of Microsoft Outlook attachment.

Couple of days ago I was asked by one of my customers to help her with her email. Over there they use Exchange (they are a big Microsoft shop) so her mail client is Outlook. She received an email regarding some appointment she had, and it included an attachment and she could not open it.

I have to say I froze. Usually they are careful about not opening suspicious attachments; I hope this was legit and her computer was not infected.
When I got to her office, she showed me the email, which looks proper. And then showed that the attachment was being presented in Outlook as a file called

Appointment Info Jul2015.save

which Outlook thought was an Adobe Acrobat document(?). Maybe Outlook was setup not to show extensions, like Windows does by default. So, I decided that we should contact the sender; he did say he sent the file and even read out the filename of the attachment. Next step was to save the file and see what's what. The quickest way I had to find the extension extension of the saved file was checking its properties. It did show it to me, but it was not .pdf. It was

Appointment Info Jul2015.save.copy

Ookay. As you know I am not a Windows guru; I just am someone who understand linux and Unix in general who happens to dabble with Windows at times. So, I tried to treat it as a linux problem.

Well, we do not have the command file in Windows by default as far as I know. So, how about if we open the file in Notepad and look at the header? Here is what I saw:

PK^C^D
^@^@^@^@^@^Nc▒F^@^@^@^@^

I guess we need to find which file uses that header. A bit of search indicates it is probably a .zip file. I renamed it as

Appointment Info Jul2015.save.zip

and unzipped it. It then created a new directory with a file inside it. And that file was a pdf:

%PDF-1.4
%▒▒▒▒
1 0 obj
<%lt/Type/XObject/Subtype/Image/Width 1602/Height 1037/Mask [252 252 ]/Length 65127/ColorSpace[/Indexed/DeviceRGB 255(^@^@^@^@^@

Thoughts

1. Notepad is not like one of those helpful programs that try to detect and process and file you leave too close to them. And that is good. All I wanted is to see the top of the file without something running without my consent. Kinda like running vi
   
2. Don't let outlook open attachments using any program by default. If you do not know what it is, it should not try to open it.
   
3. I really do not like how Windows by default hides file extensions. Really hate that. Great way to camouflage a bad program from your average user.
   
4. Sometimes you might not have a program that you can click on and will do something. You need to be creative. Hackers do that all day and twice on Sunday.
   
5. Finding out the contents of a mysterious file inside another and so on is a classic event in hacking competition. Sometimes those tasks become very Rudy Goldbergish ina completely new and frustrating level.
   

Email fun: 8BITMIME and DKIM body authentication failure

Like most of you who decided to read this post, we use DomainKeys Identified Mail (DKIM) in an attempt to keep email spoofing down. . We noticed that some of the emails we were receiving were marked as spam by spamassassin when they shouldn't. Looking at the email header we saw they were failing the DKIM body integrity test. The entries in the header file looks something like

Authentication-Results mail.example.com (amavisd-new); dkim=softfail 
(fail, body has been altered) header.i=@example.com

or

dkim=neutral (body hash did not verify).
dkim=fail (message has been altered) domainkeys=pass

That would increase the score of those legitimate emails just above the threshold, causing spamassassin to flag them as spam. After some investigating, we found out emails that contained characters above the original ASCII character set, such as Olivenöl, in the body of the message were failing. In other words, DKIM really does not like 8bit (specifically 8BITMIME) encoding.

I was able to duplicate that by sending an email to myself or to a gmail test account using our default mail client, Thunderbird. So I tried to manually (using netcat; telnet would have worked fine) create a properly configured 8Bit email using our SMTP server (As you can clearly see, our MX server (postfix) is setup to handle 8BITMIME):

raub@desktop:/tmp$ nc -t mail.example.com 25
220 mail.example.com Test Mail Server
EHLO desktop.example.com
250-mail.example.com
250-PIPELINING
250-SIZE
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:<raub@desltop.example.com> BODY=8BITMIME
250 2.1.0 Ok
RCPT TO:<raub@example.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Mauricio Tavares" 
Subject: 8bit test
Date: Mon, 30 Jun 2014 11:10:05 -0400
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Olivenöl

.
250 2.0.0 Ok: queued as 2BA1F80041
QUIT
221 2.0.0 Bye
raub@desktop:/tmp$

The above would work while using Thunderbird didn't. After setting Thunderbird to debug mode, we noticed it was not properly indicating the email was 8BITMIME, so postfix would treat it as a 7bit ASCII email and then DKIM would fail. The DKIM signatures of 8BITMIME mail may break unless all SMTP servers in the path implement and announce 8BITMIME support, and as shown above the mail clients do not lie. Since we cannot guarantee that is the case, it is better to down-convert to quoted-printable before DKIM signing.

Solution is to force the MTA to downconvert to 7bit. That can be done in postfix by creating a null filter in master.cf that is called before the rest of the filters. In other words, something like

smtp      inet  n       -       n       -       -       smtpd
   -o content_filter=smtp-downconvert:127.0.0.1:10027
[...]
smtp-downconvert  unix    -       -       -       -       2       smtp
   -o smtp_discard_ehlo_keywords=8bitmime,silent-discard
127.0.0.1:10027 inet  n       -       n       -       -       smtpd
   -o smtpd_authorized_xforward_hosts=127.0.0.1
   -o smtpd_client_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_relay_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject

should do the trick. If we restart the MX (postfix reload will do the trick) and send the test email again, the email now should show something like

Authentication-Results mail.example.com (amavisd-new); dkim=pass header.i=@example.com

in the header, which means DCKIM is successful and life is good... for now

I would like to thank Wietse Venema for pointing me on the right direction regarding downconverting.

Note: HELO vs EHLO

• HELO: Standard/Original SMTP (7-bit ASCII email) (RFC 821, 5321)
  
• EHLO: ESMTP (RFC 1869). Think Enhanced HELO; supports MIME and other exciting extensions. A quick discussion is found at http://cr.yp.to/smtp/ehlo.html.