On 17 Jul 2018, at 20:00 (-0400), Chip M. wrote:
There's a new morph of the porn extortion campaign, with some
interesting under-the-hood changes.
The previous ones were always:
- two "quoted-printable" parts (plain text, html)
- "From" Outlook accounts
- sent via Outlook/Hotmail/MS IPs (no other IPs in route)
- passed both DKIM and SPF
The new version has:
- one base64 html part
- pure numeric "From" domain&account (same address in SMTP & header)
Why would anyone accept mail with a SMTP sender domain that is purely
numeric? Checking that the sender domain exists is a fundamental
necessity in operating an Internet-facing MTA.
- sent via compromised computers (and typically 3 or 4 Received IPs)
Or not. The Received headers in your sample beyond the top one are
entirely ridiculous, obviously fake.They are not even internally
consistent.
- bogus domains so neither DKIM nor SPF possible
So what? Bogus domains are bogus. If you can't resolve an A or MX for an
envelope sender domain, nothing else (including SA) needs be done. It's
bogus mail.
[...]
Three other unusual things (all demonstrated in this spample):
1. 9 of the 13 had a two part pure numeric claimed host (see below).
I don't recall seeing that before.
** Is that a botnet fingerprint?
Probably not in a strict sense. Obviously it is a fingerprint of a
particular stream of spam, but it is not a behavior that is widespread,
such as claiming to be "User" or "ylmf-pc" or the IP of the server
being spammed. My guess is that it's one spammer with a severe clue
shortage.
2. 9 of the 13 lacked a trailing "=".
I don't recall seeing that before.
That's slightly more common than normal, but not spectacularly more when
considering that the input data isn't random. The encoded version of 1/3
of all inputs will not end with '=' and 1/3 will end with '==' while
none should ever end with '==='.
It's probably worth a quick test, if easy to implement.
Nope. Absolutely NOT spamsign, unless you consider having an even
multiple of 3 bytes in the unencoded data to be spamsign. :)
3. 4 of the 13 failed to hit "MIME_BASE64_TEXT".
I'm curious what the issue is.
The trailing "=" was not a factor.
The main thing that stood out is that the hits all had this CT:
Content-Type: text/html;
charset="us-ascii"
The misses all had:
Content-Type: text/html;
charset="iso-8859-1"
I have not traced the code to be sure, but as I understand it, it
shouldn't be possible to hit MIME_BASE64_TEXT unless the character set
is US-ASCII. Since iso-8859-1 is an 8-bit character set, it is entirely
proper and frequently essential that either Base64 or QP be used to
encode it.
[...]
I've just added the above suggested SA metas, and a
low level (non-regex) pure numeric TLD test.
I would not expect the numeric TLD test to hit much in the submitted
corpora, since NO_DNS_FOR_FROM is not hitting enough to have a
meaningful score and a pure numeric TLD in the envelope sender would
always hit NO_DNS_FOR_FROM.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
