Analyse – Sur la piste d’un botnet universitaire

Mon université est en ce moment ciblée par une campagne de phishing ciblant directement les fonctionnaires et universitaires, et visant à récupérer les identifiants de boîte mail. Depuis deux mois, j’ai reçu une quarantaine de mails similaires, provenant – en apparence, de professeurs, maîtres de conférence, personnels d’université ou d’administrations locales en poste. Leur nombre allant croissant, j’ai décidé de m’y intéresser.

Cas

En voici un reçu récemment :

Cher utilisateur, votre boîte aux lettres a dépassé la limite de >stockage 2GB
Lt est déterminé par l’administrateur actuellement 2.40 Go, ne peut >pas
Envoyez ou recevez de nouveaux messages jusqu’à ce que vous validiez à nouveau votre courrier électronique
Cliquez sur le lien ci-dessous pour compléter votre boîte aux lettres jusqu’à 2,40 Go.
Cliquez ici
Je vous remercie
Administrateur du système

Première remarque : l’adresse expéditeur est celle d’un fonctionnaire d’une administration du sud-ouest. Pas d’utilisation ici d’une adresse imitant celle d’un administrateur ou d’un service type Office 365, ce qui devrait déjà susciter la méfiance des utilisateurs. Pourquoi un simple fonctionnaire gascon se préoccuperait-il de l’espace restant dans ma boîte mail ?

Peu importe : ne jamais s’appuyer sur les capacités de discernement des utilisateurs si ceux-ci n’ont pas été spécialement formés pour réagir à ces situations, ce qui n’est pas le cas à l’Université. Rien dans ce mail n’est crédible (à commencer par le joyeux mélange GB/Go), mais il est inévitable qu’un utilisateur – très fatigué, tombe un jour dans le panneau.

Analyse

C’est derrière le bouton « cliquez ici » que réside la charge utile du mail, qu’il est intéressant d’explorer.

Il faut impérativement, dans ces situations, éviter de survoler le lien, ce qui pourrait déjà conduire à une infection par un malware (cf. le vecteur utilisé par le trojan OTLARD ou par GOOTKIT).

Le lien copié est ouvert dans une machine virtuelle pour éviter toute contamination. Peu de risque ici, il ne s’agit ici que d’un lien vers un formulaire Formcrafts. Renseignement utile : ce site, qui offre une formule gratuite autorisant 50 remplissage du formulaire par mois, est très utilisé par les phishers qui ne veulent même pas prendre la peine de compromettre un autre système pour y héberger une page dédiée. Dans une telle situation, il aurait été nécessaire de fouiller les DNS pour remonter jusqu’au domaine d’origine du site de phishing, afin de les blacklister.

Il est temps de jeter un oeil au header (anonymisé) dans la source du mail :

Return-Path: <expediteur@administration.fr>
Received: from zimbra-mta2.univ-lille.fr (LHLO zimbra-mta2.univ-lille.fr)
(10.140.10.71) by zimbra-store01.univ-lille.fr with LMTP; Mon, 5 Nov 2018
12:22:05 +0100 (CET)
Received: from mx1.univ-lille.fr (unknown [10.140.21.254])
by zimbra-mta2.univ-lille.fr (Postfix) with ESMTPS id 67EA1B03E0;
Mon, 5 Nov 2018 12:22:05 +0100 (CET)
Received: from smtp.univ-lille2.fr (mx1.univ-lille2.fr [194.254.117.4])
by mx1.univ-lille.fr (LA PUISSANCE) with ESMTP id C7BA846C54;
Mon, 5 Nov 2018 12:22:03 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2.129.23.58; helo=mx.starxpert.fr; envelope-from=expediteur@administration.fr; receiver=user2@univ-lille2.fr
X-Greylist: delayed 482 seconds by postgrey-1.34 at mx1; Mon, 05 Nov 2018 12:20:57 CET
Received: from mx.starxpert.fr (mx.libon.com [222.121.23.58])
by smtp.univ-lille2.fr (Postfix) with ESMTPS id AD42F2D5400;
Mon, 5 Nov 2018 12:20:57 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mx.starxpert.fr (Postfix) with ESMTP id 42pVRk6gWbzHrTm;
Mon, 5 Nov 2018 12:13:54 +0100 (CET)
X-Amavis-Modified: Mail body modified (using disclaimer) - mx.starxpert.fr
Received: from mx.starxpert.fr ([127.0.0.1])
by localhost (mx.starxpert.fr [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id NH1r74bevo7O; Mon, 5 Nov 2018 12:13:48 +0100 (CET)
Received: from zimbra.administration.fr (unknown [37.58.5.134])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx.starxpert.fr (Postfix) with ESMTPS id 42pRnH2srvzJ4MH;
Mon, 5 Nov 2018 10:13:53 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
by zimbra.administration.fr (Postfix) with ESMTP id C680C206D0A;
Mon, 5 Nov 2018 10:13:52 +0100 (CET)
Received: from zimbra.grand-dax.fr ([127.0.0.1])
by localhost (zimbraproxy.acqs.local [127.0.0.1]) (amavisd-new, port 10032)
with ESMTP id fDjtwKTQLsw0; Mon, 5 Nov 2018 10:13:52 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
by zimbra.administration.fr (Postfix) with ESMTP id 4A76420370B;
Mon, 5 Nov 2018 10:13:52 +0100 (CET)
Received: from zimbra.administration.fr ([127.0.0.1])
by localhost (zimbraproxy.acqs.local [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id ecwVIs7ODpK; Mon, 5 Nov 2018 10:13:52 +0100 (CET)
Received: from dell-PC.domain.name (unknown [3.206.19.17])
by zimbra.administration.fr (Postfix) with ESMTPSA id A0F7E20FFAC;
Mon, 5 Nov 2018 10:12:55 +0100 (CET)

Content-Type: multipart/alternative; boundary="===============0980237493=="
MIME-Version: 1.0
Subject: =?utf-8?q?=C3=89tatd=27avancement?=
To: Recipients <expediteur@administration.fr>
From: "WebMaster"<expediteur@administration.fr>
Date: Mon, 05 Nov 2018 14:41:53 +0530
Message-Id: <20181105091255.A0F7E20FFAC@zimbra.administrationx.fr>
X-Virus-Scanned: clamav-milter 0.98.1 at mx1
X-Virus-Status: Clean
X-UDL-MailScanner-Information: Please contact the ISP for more information
X-UDL-MailScanner-ID: C7BA846C54.A921D
X-UDL-MailScanner: Found to be clean
X-UDL-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached,
score=2.054, requis 6, BAYES_00 -1.90, FROM_MISSP_SPF_FAIL 1.00,
HTML_MESSAGE 0.00, RAZOR2_CF_RANGE_51_100 1.89, RAZOR2_CHECK 0.92,
RCVD_IN_DNSWL_NONE -0.00, RCVD_IN_SBL 0.14, SPF_FAIL 0.00,
TO_EQ_FM_DOM_SPF_FAIL 0.00, TO_EQ_FM_SPF_FAIL 0.00,
URIBL_BLOCKED 0.00)
X-UDL-MailScanner-SpamScore: ss
X-UDL-MailScanner-From: expediteur@administration.fr
X-Spam-Status: No

You will not see this in a MIME-aware mail reader.
--===============0980237493==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Description: Mail message body

Cher utilisateur, votre bo=EEte aux lettres a d=E9pass=E9 la limite de stoc=
kage 2.GB
Lt est d=E9termin=E9 par l'administrateur actuellement 2.40 Go, ne peut pas
Envoyez ou recevez de nouveaux messages jusqu'=E0 ce que vous validiez =E0=
nouveau votre courrier =E9lectronique
Cliquez sur le lien ci-dessous pour compl=E9ter votre bo=EEte aux lettres =
jusqu'=E0 2,40 Go.
=

Cliquez ici
=

Je vous remercie
Administrateur du syst=E8me

Un header mail commence toujours par indiquer un return path, c’est à dire l’adresse à laquelle renvoyer le message s’il échoue à atteindre le destinataire. C’est ce champ qui indique par la même occasion l’adresse de l’expéditeur. Il est facilement modifiable, et il ne faut donc pas lui accorder trop de crédit.

A la suite, le header comporte toutes les informations relatives au routage du mail pour parvenir jusqu’au destinataire. Chaque point de routage démarre avec « received from:« . Il faut lire cette séquence dans le sens inverse pour une chronologie du chemin parcouru par le mail. Si l’on simplifie :
1. Le mail a été envoyé par un poste utilisateur Dell sur le réseau de l’administration
2. Il a été traité par Zimbra (une solution mail open source très utilisée en France) via un intégrateur (starxpert)
3. Il a été directement envoyé au serveur SMTP de l’Université

Nous ne sommes donc pas face à un mail de phishing qui aurait été routé une demi-douzaine de fois via des serveurs SMTP tiers (c’est à dire différents de celui du receveur et acceptant des connexions externes en mode open relay). C’est notamment ce qui a conduit Spamassassin (un logiciel côté serveur de détection du spam) à considérer ce mail comme légitime, ce dont nous informe la séquence suivante :

X-Virus-Scanned: clamav-milter 0.98.1 at mx1
X-Virus-Status: Clean
X-UDL-MailScanner-Information: Please contact the ISP for more information
X-UDL-MailScanner-ID: C7BA846C54.A921D
X-UDL-MailScanner: Found to be clean
X-UDL-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (cached,
score=2.054, requis 6, BAYES_00 -1.90, FROM_MISSP_SPF_FAIL 1.00,
HTML_MESSAGE 0.00, RAZOR2_CF_RANGE_51_100 1.89, RAZOR2_CHECK 0.92,
RCVD_IN_DNSWL_NONE -0.00, RCVD_IN_SBL 0.14, SPF_FAIL 0.00,
TO_EQ_FM_DOM_SPF_FAIL 0.00, TO_EQ_FM_SPF_FAIL 0.00,
URIBL_BLOCKED 0.00)

Plus le score est élevé, plus les chances qu’il s’agisse d’un spam le sont aussi. Ici, le score n’est qu’un minuscule 2, ce qui correspond à un mail certainement légitime.

Un autre passage est très important :

Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2.129.23.58; helo=mx.starxpert.fr; envelope-from=expediteur@administration.fr; receiver=user@univ-lille2.fr

En effet, il est trivial de faire apparaître une fausse adresse expéditeur dans un mail, il suffit pour cela de modifier le champ MAIL FROM de la requête SMTP, c’est à dire souvent le return path. De même que le protocole HTTP n’a jamais inclu à l’origine de couche d’authentification, le protocole SMTP n’effectue aucune vérification sur « l’enveloppe » (c’est à dire les adresses de l’expéditeur et du destinataire). Autrement dit, le serveur SMTP ne vérifie pas que vous êtes autorisés à envoyer un mail en utilisant telle adresse expéditeur. Les débuts de l’existence de SMTP ont donc été marqués par le spoofing, au service de tentatives de phishing ou autres formes d’ingénierie sociale.

Aujourd’hui, plusieurs mécanismes sont disponibles pour se protéger d’une telle usurpation d’identité. L’un d’entre eux est le Sender Policy Framework qui utilise les registres DNS pour permettre aux échangeurs mails de s’assurer que les mails proviennent bien d’une adresse préalablement autorisée par l’administrateur du domaine. Simple, le SPF est pourtant efficace au point d’avoir été promu proposed standard par l’IETF. D’autres mécanismes existent, le format S/MIME, la méthode DKIM (Domain Keys Identified Mail) ou le système DMARC (Domain-based Message Authentication, Reporting and Conformance), plus élaboré. Pour davantage garantir l’authenticité de l’expéditeur, chaque mail peut en outre être signé cryptographiquement.

Les serveurs mails utilisant le SPF vont donc procéder à une première validation de l’adresse expéditeur. Le résultat est indiqué dans l’en-tête, ici Pass.

Ces éléments en tête, il est donc possible d’affirmer avec un degré raisonnable de certitude que ce mail a bien été envoyé par la messagerie du-dit fonctionnaire, sans usurpation. Cela nous renseigne sur le modèle d’attaque : le poste de cet utilisateur, ou tout du moins sa boîte mail, a été compromis.

Un peu de footprinting s’impose.

Une rapide recherche permet de retrouver l’identité exacte de l’expéditeur, sa fonction dans l’administration, et de vérifier qu’il est toujours en poste. Pas question donc pour l’administrateur de simplement désactiver le compte. Cette étape de reconnaissance permet également de trouver les coordonnées de l’administrateur réseau et idéalement du DSI.

Cette analyse menée, les éléments en notre possession permettent d’affirmer que la messagerie de ce fonctionnaire envoie des emails de phishing, suite à sa compromission ou à celle du poste entier, dans le but de récupérer d’autres identifiants et de constituer un phishing botnet visant les fonctionnaires/enseignants.

Réponse

D’abord, puisqu’il a été établi que c’est bien la messagerie qui avait été compromise – a minima, et pas simplement l’adresse qui a été usurpée, commençons par nous servir des coordonnées du DSI glanées plus tôt en reconnaissance pour avertir ce dernier. Lui seul pourra déterminer l’ampleur de la compromission, prendre les mesures correctives qui s’imposent (réinitialiser les identifiants, dératiser le poste…) et envisager des contre-mesures pour éviter que ce cas se reproduise. Il sera de bon ton d’interroger le fonctionnaire en question pour déterminer les conditions dans lesquelles il a été infecté. On peut se douter qu’il a lui-même été victime de cette même campagne dont il est désormais acteur malgré lui.

Ensuite, prévenir son propre DSI, pour que lui aussi puisse déterminer l’ampleur de la campagne de phishing, détecter si des utilisateurs sont tombés dans le piège et effectuer les ajustements qui s’imposent en terme de SSI. Nul doute que des paramétrages additionnels seront requis côté serveur (blacklister les liens Formcrafts notamment) et côté personnel. Ce serait, pourquoi pas, l’occasion de simuler une campagne de phishing en interne pour déterminer le taux de succès et, s’il est trop élevé, accroître les moyens de formation à destination du personnel.

C’est ce que j’ai fait en l’espèce, comme les fois précédentes. Depuis le début de cette campagne, j’ai contacté 9 DSI/RSSI et 6 fonctionnaires-victimes directement, dans des Préfectures, des administrations décentralisées et jusqu’à la Mairie de Paris. Aucun ne s’était rendu compte d’une quelconque compromission.

A force de passer des coups de fil, peut-être est-il possible de ralentir la progression de ce botnet en pleine croissance, et qui pourrait un jour servir à des attaques plus graves visant spécifiquement la communauté universitaire ou nos administrations.

Comments are closed, but trackbacks and pingbacks are open.