This is my reading of it. - You may have received an e-mail addressed to someone-else. I do not know your setup, but this is what it looks like from my seat. (Sent "To" [@puffin.net](mailto:bait_sa_e3npnogbtq1d4...@puffin.net), but "Received: from" futurequest.net.) We have a custom rule for this junk. In general, if you domain is example.com and your server receives e-mail to whatever.com, then you can reject it by local policy.
header __LOCAL_DOMAIN To:raw =~ /\@yourdomain\.com/ meta T_FD ( !__LOCAL_DOMAIN ) describe T_FD To: foreign domain score T_FD 5.0 - From:domain mismatches Received:domain - Return-Path: missing header These are not a hard symptom of spam, but we give them a 0.5 penalty anyway. - Received: from domain literal Well-behaved servers, with state-of-the-art DNS and well implemented SPF, DKIM and DMARC, they have domain name. They also cut out the first hop, from the client to the server. We give a full 1.0 penalty here. - Body: attachment without introductory text I do not have a rule for this, yet. The default SA returns the following: 0.0 TVD_SPACE_RATIO No description available. 0.0 TVD_SPACE_RATIO_MINFP Space ratio Our SA returns a big fat spam flag. RG Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: spample: Microsoft Office DDE exploit (in OpenXML attachment) > Local Time: 31 October 2017 7:10 AM > UTC Time: 31 October 2017 06:10 > From: sa_c...@iowahoneypot.com > To: users@spamassassin.apache.org > > Starting Monday late pm (Iowa time), I've been seeing my first DDE > exploits, with significant volume. > Here's a spample, with only the account part of the To header munged: > http://puffin.net/software/spam/samples/0056_dde_auto.txt > > The MIME part Content Types are all of the same form, with only the > nine (9) digit long invoice number being different (same as used in > the Subject). The date part is changing correctly. > So far, there's enough consistency there that it may be worth some > quick rules. > > Here's a few of the Message-IDs: > adr12896529648910347634474919b240d844eabec6a20f80...@canadianchemistry.ca > adr7620524563497929668713350304233e03d64b1f8e8170...@rapidtest.ca > adr68345885946016552575674219fe1b08f91debc7cfbb00...@allaharassociates.com > adr876830136506609450916689649c89a27b537895370760...@imed-deltona.com > adr426090832862978264036549945af7e4fe88b447543d90...@nationaleducationcouncil.com > adr99440411731938631057549731c1c2a892fde297bf3f20...@wmacsolutions.com > adr81956121236541247090766988290f5afbfdda13822ad0...@sofiamartindecoracion.es > adr67473153783778389876391568ca7d883cc6de0610e100...@radiantsolutions.net > adr26027147591253901902363379be430bba9cf219fd34a0...@aard.nl > adr131945596038997342794846233353a6ec4959eaf2ab90...@zwart-holding.nl > adr9656904421970779346632739481be4f2cff28e0788560...@edusophia.org > adr73468520213265525945855867cfcfcd9887a98f9244f0...@osasgranitbutik.se > In all cases, the domain matches the domain in the From header. > > So far, the From has always been in the form: > Invoicing invoic...@example.com > > The only SA rules that they're all hitting are: > TVD_SPACE_RATIO > TVD_SPACE_RATIO_MINFP > > Internally, these were NOT as I was expecting. > When the buzz about DDE first broke, I was expecting old style doc, > rtf, and ics (calendar) files, and restricted my rules to those. > Today's wave are all OpenXML, and the payload is in file > "word/document.xml". > > If you take a close look at just the contents of "<w:instrText>" > tag pairs, it appears they can easily obfuscate the payload. :( > > I need to do a LOT more reading, but for now, I've added > seat-of-my-pants rules for exact word matches on: > DDE > instrText > AUTO > gfxdata > > So far, using an older (v3.4.1) plain vanilla SA setup, my > killrate with Bayes is 48% (without Bayes, it would have been > about 30.4%). > > My post SA filter has been killing them all, but that's due to my > aggressive rules and a bit of luck. > I've asked one of my people with less aggressive rules and more > diverse ham to run some ham-only MassChecks using the above rules. > I'll share the results. > > Has anyone seen the RTF or Calendar/.ics forms of this exploit? > If so, please-please-please post a spample. > - "Chip"
