Laat me raden, IP adres van de enige PC die gekoppeld kan worden was van putin persoonlijk?
Tien domeinnamen registeren en dan toch precisietools gebruiken klinkt meer als NSA dan wat anders... beetje als pen uitvinden die in zero gravity werkt op zijn kop... dat is amerikaans.. russen pakken gewoon een potlood.

Wat is dat voor een warrig verhaal op ThreatConnect? Het lijkt erop dat de schijver ergens een klok heeft horen luiden maar niet weet waar de klepel hangt.

"Building Out ProtonMail Spoofed Infrastructure with Creation Timestamp Pivoting"

Iemand probeert interessant te doen om een simpel phishing incident te beschrijven op een verkeerde manier, zonder onderscheid te maken tussen wat headers zijn en (E)SMTP commands.

Mail.de verzenders kunnen in principe alles wat ze willen via SMTP en IMAP sturen naar de mail.de mail servers. Het enige wat daar voor nodig is, is een mail.de account.

Bellingcat......
Is dit dan een zogenaamde "catphish"?

Ziet er niet uit als een geavanceerde phishing:

From: ProtonMail Team <support@protonmail.ch>, ProtonMail Team <support@mail.de>

Dat laatste email adres wijst op phishing.

Rijke voeding voor speculaties. Degenen die deze aanval hebben opgezet, of de opdracht hebben gegeven, zullen zich misschien na een gesmoorde vloek kort achter de oren krabben hoe effectief een eventuele wijzende vinger hen raakt. Bellingcat is beroemd èn... berucht.

Het lijkt erop dat er ook pro-russische trollen actief zijn op dit forum.

Mij verbaast het meer dat er twee "From:" afzenders zijn. Normaal kan dat niet. Is dat iets van protonmail, dat dit een soort geforwarde mail is waarbij beide adressen in de header komen?

Blijkbaar heeft de redactie daar al op geanticipeerd. Ik merk bij de vorige post dat nu ook de berichten van geregistreerde gebruikers eerst gemodereerd worden, voordat ze zichtbaar worden.

Was Bellingcat aanvankelijk niet die huisvader die op zolder het internet afstruinde op zoek naar....

Dat van die pen en het potlood is een hardnekkige urban legend die maar door blijft gaan.
Niet zo verwonderlijk als je je commentaar begint met: Laat me raden.
Echt weer natte-vinger-werk, zoals zo vaak in dit forum.

Meer dan 1 afzenderadres is vermoedelijk gebruikt om DMARC te omzeilen (vette opmaak halverwege toegevoegd door mij), uit https://tools.ietf.org/html/rfc7489#section-6.6.1:

De DMARC ontwerpers hebben overwogen om in zo'n situatie het Sender field te evalueren (dat in zo'n situatie zou moeten bestaan, zie https://tools.ietf.org/html/rfc5322#section-3.6.2), maar aangezien MUA's dat meestal niet tonen, gebeurt dat niet (zie https://tools.ietf.org/html/rfc7489#appendix-A.3).

De regel "are typically rejected because the sorts of mail normally protected by DMARC do not use this format" is m.i. belachelijk; vanzelfsprekend houden phishers en spammers zicht niet aan de regels! We hebben protocollen nodig die nepmails als zodanig herkennen en deze ofwel droppen, ofwel met een flinke waarschuwing doorlaten (als je niet kunt aantonen dat iemand niet is wie hij zegt dat hij is, heeft het weinig zin om aan te tonen dat iemand wel is wie hij zegt dat hij is).

Helaas bestaan er veel te veel manieren om SPF, DKIM en DMARC te omzeilen...

postfix zeroday ;)

Leuk uit je duim gezogen, slaat inhoudelijk werkelijk nergens op.


Leuk uit je duim gezogen, slaat inhoudelijk wederom nergens op. Alsof enkel de NSA aanvallen uit kunnen voeren.


Tuurlijk.....

Maakt het iets uit, zolang de aanval maar succesvol is ? Of denk je dat geavanceerdheid een doel op zich is ?

Waarom zou het hen boeien ? Maakt het iets uit of er succesvolle attribution wordt verricht ? Belangrijker zal de vraag zijn of de aanval succesvol was, en of ze de informatie in handen hebben gekregen waar ze op uit waren.

je zit te veel op dumpert als je denkt dat deze reactie past op security.nl

maar wel leuk op maandag ochtend.

Afgezien de zero day vulnerability waar nog geen fix voor is?

Blijkbaar bekijkt niet iedereen de code helemaal goed. Anders was deze allang bekend. Maar dat is het mooie van OS. Hackers hebben direct al toegang tot de code, en kunnen dus gemakkelijk bugs vinden en misbruiken.

Vanuit IT gedacht OK maar boeit mij in deze context niet.
Speculaties - en daar quote je me nu net niet - is de allerheetste brij. Die kunnen door heetgebakerde politici als bron van zwartmaken > polarisatie > (diplomatieke) conflicten op internationale schaal worden misbruikt.
Denk aan Salvini, Putin, Trump, Johnson (nieuwe Britse premier) om enkele als het hen uitkomt naar populisme riekende (regerings)leiders te noemen.
Kijk naar: US/Noord-Korea, Iran/US, Rusland/Oekraïne.
Dit soort verwikkelingen zijn een risico voor instandhouding van vreedzame intenationale verhoudingen. En daar mag je gerust reëel bevreesd om zijn.

Om te voorkomen dat je tijd verspilt met een bijdrage waarin je schrijft wat hier de vermoedelijke "zero day" is: mijn reactie van tegen 8 uur vanochtend is niet geplaatst (best frustrerend als je ziet dat vervolgens anonieme reacties wel worden geplaatst).

Achteraf vermoed ik dat om dezelfde reden een eerdere reactie van Briolet niet is geplaatst.

Ik zie mijn reactie inderdaad nog steeds niet. Die van twee minuten erna kon ik wel zo plaatsen. Zelf vermoedde ik dat de reactie voor moderatie achtergehouden werd doordat ik de reactie van "29-7-'19, 14:47" quote die een e-mail adres bevatte.

Ja, natuurlijk maakt het uit. Hoe geavanceerder de phishing aanval en hoe overtuigender de mail er uit ziet, hoe groter de kans van slagen. Dus nee, het is geen doel op zich, maar een middel om tot het gewenste resultaat te komen. Waarom stuur je anders dit soort mails.

Ja. Bellingcat is tegenwoordig gewoon een anti-Russische lobbyclub.

Dit is niveau van 1480 toen heksenjachten nog normaal waren. Bellingcat is ontzettend pro anglicaans/amerikaans dat is gewoon een feit. Met informatie die ze op internet vinden beweren ze feiten te fabriceren. Want immers wat op internet staat is waar. En vervolgens iedereen die nuchter na denkt met het niveau van meer dan een amoebe (wie zegt wat en wat hebben zij daar aan en wie geeft ze geld en op welke punten hebben ze al eerder laten zien niet betrouwbaar te zijn) kom je bij bellingcat al snel op het spoor van Amerikaanse sponsoring. Dus wanneer je roept "russische trollen" ben je ongeveer op het niveau van boeren in de 15de eeuw die eerst een vrouw aanranden of verkrachten en dan wanneer ze miepen ga je roepen "heks!!!"... wil je dat niveau uit blijven dragen of ga je onderbouwde bijdragen leveren?

Voor mij is het een stelling. Bewijs het maar!

Als het 'typycally rejected' wordt, is het toch goed. Het is geen normaal mail formaat. Waarschijnlijk is dit de zero day waar ze op doelen, dat dit niet volgens het protocol verworpen was door de gebruikte software. Software schrijvers hebben er een handje van om geen rekening te houden met uitzonderingen die ze in de praktijk nog nooit gezien hebben, ook al staan ze in het protocol.

Eigenlijk heb ik niet meer zoveel zin om actief te zijn op security.nl (aangezien mijn bijdrage bijna een dag werd tegengehouden, terwijl politiek gekleurde crap bijdragen - zonder onderbouwing - wel werden geplaatst). Lastig discussiëren zo, en zonde van m'n tijd.

DMARC lijkt zich niet verantwoordelijk te voelen voor deze situatie (zie mijn onderbouwing hieronder). Het lijkt er sterk op dat DMARC zo'n mail niet afkeurt en ervan uit gaat dat een ander protocol of service dat maar moet doen.

Het wordt misschien zelden gebruikt, maar het is (helaas wat mij betreft) een geldig e-mail formaat. Uit de link die ik in mijn eerste bijdrage in deze draad noemde (https://tools.ietf.org/html/rfc5322#section-3.6.2):

Je kunt in dit geval software schrijvers niet de schuld geven, want het DMARC protocol is inconsistent - in elk geval met RFC 5322.

Als je in https://dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html#part-l15 onder 11.1 kijkt (beide zijn voorlopers van de huidige standaard) zie je in beide versies staan:
waarbij [MAIL] verwijst naar RFC 5322 (https://tools.ietf.org/html/rfc5322).

Dat "multiple RFC5322.From fields" forbidden zijn is onjuist; kennelijk hadden de bedenkers van DMARC die standaard niet goed gelezen. En kennelijk is dit slechts deels (zie onder) "gecorrigeerd" voordat de standaard gepubliceerd werd.

Na mijn eerste bijdrage in deze draad heb ik verder onderzoek gedaan en kwam de volgende tekst tegen in de DMARC standaard, een stukje naar beneden in https://tools.ietf.org/html/rfc7489#page-9:
Hier staat dus nog dat volgens RFC 5322 een RFC5322.From veld precies 1 afzender zou moeten kennen, en dat klopt niet.

Met andere woorden, de bedenkers van DMARC vinden dat opzettelijk gemanipuleerde e-mails (die wel aan RFC5322 voldoen) "out of scope" zijn en lijken daarom te specificeren dat DMARC er niets mee moet doen (niet afkeuren dus). Vandaar mijn eerdere opmerking "We hebben protocollen nodig die nepmails als zodanig herkennen en deze ofwel droppen, ofwel met een flinke waarschuwing doorlaten (als je niet kunt aantonen dat iemand niet is wie hij zegt dat hij is, heeft het weinig zin om aan te tonen dat iemand wel is wie hij zegt dat hij is)".

Misschien wel inconsistent, maar als laatste alinea van https://tools.ietf.org/html/rfc7489#section-6.6.1 lees ik:


Daar staat dat elk veld gecontroleerd moet worden en de strengste controle te gebruiken. Dus als één of meerdere from niet voldoen de strengste regel te hanteren die deze domeinen ingesteld hebben.

In dit geval heeft "mail.de" een dmarc policy van 'none' en waarschijnlijk is alleen deze afzender gecheckt door de software.

Weet ik (heb ik bewust opgenomen in m'n eerste bijdrage).

Dat vind ik een onzin-oplossing. Sowieso is er maar 1 return-path-domein dat door SPF gecheckt wordt, dus wat is "het strengste"?

Als daarop gecheckt zou zijn, hadden deze phishers heus wel een "sender-domein" gekozen waar dat wel goed geregeld is. Sterker, wellicht hebben ze die optie bewust nog niet ingezet om nog een kans te hebben zodra protonmail (of hun software-leverancier) de "fix" implementeert die jij voorstelt.

In de DMARC spec had m.i. moeten staan dat mails met meer dan 1 RFC5322.From veld, en alle andere "non-compliant" mails, als kwaadaardig moeten worden beschouwd - door DMARC zelf dus. Een aanvaller heeft maar één gat nodig, dus zul je ze allemaal moeten dichten.

Dat klopt niet. De SPF check op het returnpath is een andere dan de SPF check door DMARC. Die kijkt naar de domeinnaam in het From veld.

Op mijn server zijn dat ook twee onafhankelijke checks. DMARC kan voor elk From domein de SFP controleren. En omdat de kans groot is dat het afzender IP niet in beide SPF records staat, zal een van beide waarschijnlijk falen. De mail is dan nog steeds geldig als hij voor alle From adressen een DKIM ondertekening heeft.

Een DMARC implementatie conform RFC 7489 voert geen SPF check(s) uit. In de DMARC standaard is uitsluitend sprake van "identifier alignment".

M.a.w., bij de volgende gegevens (uitgaande van geen DKIM, en apestaart vervangen door _at_ om moderatie te voorkomen):
gebeurt, als ik mij niet vergis, het volgende:

1) SPF checkt (onmiddelijk nadat RFC5321.MailFrom is ontvangen) of IP-adres A.B.C.D namens het domein in RFC5321.MailFrom e-mail mag verzenden;

2) DMARC checkt of de domeinen in RFC5321.MailFrom en RFC5322.From geheel (of gedeeltelijk) overeenkomen (de identifier alignment).

Dat is dan een implementatie die afwijkt van de standaard.

Waarschijnlijk zo groot dat het onzinnig is om mails te sturen met meerdere RFC5322.From afzenders uit verschillende domeinen. Je kunt je de lookups besparen en de mail al tijdens ontvangst rejecten (mocht het om een fake afzender gaan, dan voorkom je zo in elk geval backscatter; is de afzender legitiem, dan weet hij of zij zo snel mogelijk dat de mail niet kon worden afgeleverd).

Wat als voor één afzenderdomein SPF klopt, en voor het andere DKIM: wat is dan de strengste check? Of kan het dan niet om phishing gaan?

Anyway, mooi dat jouw server een uitbreiding heeft op DMARC waardoor jouw gebruikers mogelijk niet kwetsbaar zijn voor het type phishing in het redactie-artikel, maar dat betekent nog steeds dat de DMARC standaard niet voorziet in dit type phishing - en dat is wat ik probeerde aan te geven.