I recently had a client get an interesting phishing message.   They had received a fake message from their CEO to their Controller - a "start the conversation" email to end up with a wire transfer.  This sort of email is not common, but is frequent enough in Sr Management circles, especially if you are in the middle of merger or acquisition discussions with another company.

Some technical warning signs in that note were:

• While the "From" field in Outlook showed the CEO's email, the "Reply-To:" field was not to the organisation's domain at all, it was to a bogus inbox at "workmail.com".  
• The message ID and the path showed that the original mail exchanger was at smtpcorp.com  (again, not the organisation).

So the discussion quickly moved from "I'm glad our execs came to us, we really dodged a bullet there" to "just how did this get in the door past our spam filter anyway?"

This is where things got interesting.  Their SPAM filter does use the SPF (Sender Policy Framework) DNS TXT record, and a quick check on the SPF indicated that things looked in order there.
However, after a second look, the problem jumped right out.  A properly formed SPF will end with a "-", which essentially means "mail senders in this SPF record are valid for this domain, and no others".  However, their SPF had a typo - their record ended in a "~" instead.  What the tilde character means to this spam filter is "the mail senders in this SPF record are valid for this domain, but YOLO, so is any other mail sender".

From the RFC (RFC7208), the ~ means "softfail", "A "softfail" result is a weak statement by the publishing ADMD that the host is probably not authorized".  More detail appears later in the RFC:
"A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none".  The ADMD believes the host is not authorized but is not willing to make a strong policy statement.  Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal."  This same reasoning applies to the ~all and -all directives in the SPF (which I see more often).

You'd think that a lot has changed since 2006 (the date of the original SPF spec, RFC4408), that in 2017 a spam filter should fail on that result, but apparently not (sad panda). Kinda makes you wonder what the actual use case is for that tilde character in the definition - I can't think of a good reason to list permitted mail senders, then allow any and every other server too.

That being said, their filter *should* still have caught the mismatch between the "from" and "reply-to" fields, especially since it involved an external source and internal domains.  Or at least paired that up with the domain mismatch to weight this email towards a SPAM decision. But that's another rant altogether.

Long story short - this type of attack was pretty popular (and widely reported) about a year ago, but successful methods never (never ever) go away.  A little bit of research can make for a really well-formed phish, right down to using the right people in the conversation, good grammar, and phrasing appropriate to the people involved.  So a bit of homework can get an attacker a really nice payday, especially if their campaign targets a few hundred companies at a time (and they put more work into their email than the example above)

So in this case, a typo in a DNS record could have cost millions of dollars.  Good security training for the end users and vigilant people made all the difference - a phone call to confirm is a "must-do" step before doing something irrevocable like a wire transfer.

===============
Rob VandenBrink
Compugen