Une agence gouvernementale du Chili a subi une cyberattaque dans laquelle les cybercriminels sont parvenus à chiffrer les machines virtuelles sur les hôtes VMware ESXi ! Que s'est-il passé ?
Le CSIRT du Chili affirme que cette attaque a débuté le jeudi 25 août 2022 et que les attaquants ont ciblé les serveurs Windows et VMware ESXi de l'agence gouvernementale. Lors de cette attaque, les pirates sont parvenus à compromettre les hyperviseurs VMware ESXi, arrêter l'ensemble des machines virtuelles et à les chiffrer avec un ransomware. Résultat, tous les fichiers associés aux machines virtuelles ont l'extension ".crypt" suite à l'action de chiffrement.
Toujours d'après le CSIRT, le ransomware a chiffré de nombreux types de fichiers différents, parmi lesquels les disques durs virtuels (.vmdk), les fichiers journaux (.log), les fichiers exécutables (.exe), les bibliothèques (.dll), les fichiers de SWAP (.vswp), etc...
Les cybercriminels ont appliqué le principe de la double extorsion, donc ils ont communiqué au CSIRT du Chili comment négocier le paiement d'une rançon afin d'empêcher la fuite des fichiers sur le Dark Web et bénéficier d'une clé pour déchiffrer les données.
Qui est à l'origine de cette attaque ?
Une attaque par ransomware, d'accord, mais lequel ? L'annonce du CSIRT chilien ne désigne pas le groupe de ransomware responsable de l'attaque, et compte tenu du peu de détails fournis, l'identification du ransomware n'est pas aisée. On ne peut pas non plus s'appuyer sur le fait que l'extension utilisée est ".crypt", car c'est fréquent.
D'après le site Bleeping Computer, les indicateurs de compromission laissent penser qu'il pourrait s'agir du groupe Conti, déjà à l'origine d'une cyberattaque contre l'agence de santé du Costa Rica. Néanmoins, Germán Fernández, un analyste chilien affirme que la souche malveillante semble être nouvelle et que les chercheurs à qui il a parlé n'ont pas pu associer le malware à une famille connue. Le mystère reste entier.
Suite à cette attaque, le CSIRT chilien a mis en ligne des recommandations à destination de toutes les entités et organisations du pays : vérifier que les systèmes soient bien à jour, vérifier les sauvegardes, etc.
Microsoft a mis en ligne un nouvel article pour rappeler à ses clients d'Exchange Online que l'authentification basique (Auth Basic) va commencer à être désactivée à partir du 1er octobre 2022. Cette opération sera réalisée sur des tenants sélectionnés aléatoirement.
À compter du 1er octobre 2022, Microsoft va passer à l'action malgré qu'il y ait encore de nombreux tenants qui ne soient pas prêts à ce changement. Dans ce nouvel article, Microsoft précise : "Nous reconnaissons que, malheureusement, il y a encore de nombreux tenants non préparés à ce changement. Malgré de nombreux articles sur le blog, des messages sur le Centre de messages d'Office 365, des interruptions de service et une couverture par des tweets, des vidéos, des présentations et autres, certains clients ne sont toujours pas au courant de l'arrivée de ce changement. Il y a également de nombreux clients conscients de la date limite qui n'ont tout simplement pas fait le travail nécessaire pour éviter une panne." - en effet, Microsoft a déjà communiqué à plusieurs reprises sur ce sujet, et sur IT-Connect, nous en parlons également (ici et ici).
L'entreprise américaine va sélectionner des tenants aléatoirement et 7 jours avant de désactiver l'authentification basique sur un tenant, un message sera mis en ligne dans le Centre des messages d'Office 365 : à surveiller ! La désactivation de l'Auth Basic s'applique aux accès MAPI, RPC, Offline Address Book (OAB), Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), et Remote PowerShell. Microsoft ne va pas effectuer de changement ni désactiver le SMTP AUTH. Cette décision impacte également Outlook, puisque vous devez utiliser au minimum Outlook 2013 Service Pack 1 pour continuer à vous connecter à Microsoft 365.
31 Décembre 2022 : la deadline
Microsoft a conscience que cette manipulation va perturber certaines entreprises non préparées, et donc pour limiter les effets de bord, la firme de Redmond va mettre à disposition de ses clients un outil de diagnostic qui servira à analyser les besoins du client et à réactiver l'authentification basique sur une ou plusieurs méthodes, et cela une seule fois. Sur son site, Microsoft explique comment fonctionne cette phase de diagnostic, disponible à partir de l'interface Office 365.
Cette réactivation temporaire sera effective uniquement jusqu'au 31 décembre 2022, car à partir de janvier 2023, l'authentification basique sera désactivée de manière permanente et l'outil de diagnostic ne sera plus disponible. Si ce n'est pas déjà fait, c'est un sujet à traiter dès maintenant pour être tranquille d'ici le 31 décembre 2022 et éviter les mauvaises surprises.
En résumé, voici comment cela va se passer :
Au fait, pourquoi Microsoft désactive l'authentification basique ?
La méthode Auth Basic n'est pas suffisamment sécurisée et elle est vulnérable à certaines attaques (man-in-the-middle, par exemple). Pour être plus précis, lors d'une connexion via la méthode d'authentification basique, l'identifiant et le mot de passe de l'utilisateur sont transmis en clair, même si la connexion en elle-même est protégée par du HTTPS.
Microsoft recommande de basculer sur la méthode d'authentification moderne, plus sécurisée, et qui s'appuie sur un jeton OAuth qui a une durée de vie limitée et qui ne peut pas être réutilisé pour s'authentifier sur d'autres ressources autres que celle pour laquelle il a été généré initialement.
Entre septembre et décembre 2022, la CNIL va organiser 6 webinaires de 45 minutes sur le sujet du RGPD. L'occasion de se mettre à jour sur le sujet et d'en apprendre plus les enjeux liés à la protection des données.
Ces webinaires au sujet du RGPD (Règlement Général sur la Protection des Données) sont ouverts à tout le monde, même s'ils s'adressent particulièrement aux professionnels en charge de la protection des données, aux DPO, et aux chefs de projet IA. L'un des webinaires concerne les nouvelles recommandations liées aux mots de passe, donc il s'adresse aussi aux RSSI. Le premier webinaire traitera de la question de l'intelligence artificielle et du respect du RGPD, notamment en répondant à la question suivante : "Comment s’assurer en pratique du respect des grands principes du RGPD et mettre en œuvre un système d’IA en conformité ?".
Chaque webinaire aura une durée approximative de 45 minutes, avec 30 minutes de présentation et 15 minutes de questions-réponses avec les experts de la CNIL. Selon le webinaire, la répartition dut temps entre la présentation et les questions-réponses sera différente. Voici le programme des webinaires de la CNIL :
Vendredi 23 septembre, à 12h : « IA et données personnelles : principes et outils pour la conformité »
Mardi 11 octobre, à 12h : « Établissements de santé : les référentiels en santé et la « gouvernance » de la protection des données »
Mardi 18 octobre, à 12h : « Recommandation sur les mots de passe : quels sont les principaux changements ? »
Vendredi 21 octobre, à 12h : « Sécurité des systèmes d’IA : enjeux et bonnes pratiques »
Mardi 15 novembre, à 12h : « La prospection commerciale : quelles sont les règles ? »
Vendredi 2 décembre, à 12h : « Techniques d’IA protectives de la vie privée : tous d’horizon et perspectives »
Des replays seront disponibles pour chaque webinaire, ce qui est une bonne nouvelle, car il y a un nombre de places limitées pour chaque webinaire : le premier, prévu le 23 septembre 2022 affiche déjà complet ! Pour les autres, les inscriptions ne sont pas encore ouvertes. La CNIL précise : "Les inscriptions seront ouvertes environ 15 jours avant la date du webinaire.". Disons qu'il faudra être rapide ou plutôt compter sur les replays.
Pour obtenir le programme détaillé de chaque webinaire et réserver sa place (quand ce sera possible), voici la page à visiter : CNIL - Webinar RGPD
Dans ce tutoriel, nous allons apprendre à modifier des documents Word (Microsoft Office) via PowerShell par l'intermédiaire de signets que l'on va utiliser comme repère. Il s'agit d'une astuce qui permet de gagner du temps dans bien des situations ! Les manipulations effectuées dans ce tutoriel n'impliquent pas d'utiliser un module PowerShell complémentaire.
II. Office : les signets dans Word
Pour commencer, faisons un rapide rappel sur les signets dans Office Word. Un signet dans Word permet de marquer un endroit que vous souhaitez retrouver facilement. Vous pouvez créer autant de signets que vous le souhaitez dans votre document, et vous pouvez leur donner un nom unique afin de les identifier facilement. Dans notre contexte, nous allons utiliser les signets pour marquer l'endroit où notre script/commande PowerShell devra insérer une information précise.
Nous utiliserons par exemple un signet AUTEUR qui sera présent dans plusieurs documents, notre script sera en mesure d'ouvrir ces documents, de trouver le signet et d'y insérer la donnée souhaitée, le tout automatiquement. Pour manipuler les signets efficacement, il est dans un premier temps préférable de les rendre visibles dans Word. Pour cela, il faut se rendre dans "FICHIER" puis "Options", aller dans l'onglet "Options avancées" et cocher "Afficher les signets" :
Rendre les signets visibles dans Office Word.
Ajoutons maintenant un signet au bout d'une ligne AUTEUR. Après avoir placé notre curseur à l'endroit où nous souhaitons ajouter le signet, il faut se rendre dans "INSERTION" puis "Signet", donner le nom que l'on souhaite à notre signet (et ne pas l'oublier) puis cliquer sur "Ajouter" :
Ajouter un signet dans Office Word.
À présent, nous pouvons voir notre signet par un marquage spécifique dans notre document. Nous pouvons également retourner dans notre menu "Signet" et utiliser le bouton "Atteindre" pour retrouver un signet spécifique (cas d'un grand document ou plusieurs signets sont utilisés). Sachez également qu'un même signet peut être inséré à plusieurs endroits d'un document, ce qui permettra de modifier la même information plusieurs fois sans erreur.
III. Ouvrir et fermer un document Word via PowerShell
Maintenant que notre signet est positionné, nous allons apprendre à manipuler un document Word dans PowerShell. Il faut pour commencer, ouvrir un document et le fermer en y sauvegardant des modifications, voici les lignes de code en question, commentées :
# Chemin vers notre fichier Word $docfile = "C:\Users\audit\Documents\Docs\Doc-02.docx" # Création d'un objet COM de type Word.Application $Word = New-Object -comobject Word.Application $Word.Visible = $False
# Ouverture du document Word $document = $Word.Documents.Open($docfile)
#[Code de manipulation/lecture/modification]
# Sauvegarde des modifications dans le fichier indiqué $document.SaveAs($docfile) # Fermeture du document $document.Close() # Fermeture de l'application $Word.Quit()
Si vous insérez ces lignes dans un script .ps1, vous constaterez qu'il ne se passe pas grand-chose. Rien d'étonnant pour l'instant :).
IV. Word : insérer du texte dans un signet via PowerShell
À présent, nous allons insérer entre les instructions précédentes quelques lignes permettant d'insérer une donnée à l'endroit du signet nommé AUTEUR :
# Contenu de la donnée à insérer $data="Mickael"
# Nom du signet à modifier $signet = "AUTEUR" # Suppression d'éventuels sauts de ligne $data = $data.Trim() # Recherche du signet à modifier dans le document $bookmark = $document.Bookmarks | Where-Object -FilterScript { $_.Name -eq $signet } $bookmarkToModify = $bookmark.Range # Insertion de la donnée à l'endroit du signet $bookmarkToModify.Text = $data
Pour rappel, ces instructions sont à insérer à l'endroit du [Code de manipulation/lecture/modification] dans le bout de code vu précédemment (III. Ouvrir et fermer un document Word via PowerShell).
Après exécution du script, si vous consultez le document Word ciblé, le contenu souhaité aura été inséré à l'endroit du signet AUTEUR. Cette valeur correspond à la variable $data du code ci-dessus.
Constat de l'insertion du contenu voulu dans le signet AUTEUR.
Si vous avez plusieurs signets différents dans votre document, il vous suffit de répéter l'opération avec un nom de signet (variable $signet) différent.
V. Générer des documents Word à partir de modèles
Maintenant que nous savons faire cela, nous pouvons envisager des cas d'utilisation plus réalistes. Par exemple, lorsqu'un nouveau projet est créé dans une entreprise, plusieurs documents doivent être initialisés :
un document de présentation du projet (presentation.docx),
un document listant les intervenants sur le projet (intervenants.docx),
un document listant les achats à faire pour débuter le projet (achats.docx).
Tous ces documents auront un contenu différent, mais certaines informations seront communes :
l'auteur : le chef de projet,
la date : la date de création du projet,
le destinataire : le nom de notre client.
Saisir ces informations manuellement dans plusieurs documents est chronophage et source d'erreur. Nous devons créer un script qui va générer une arborescence pour un nouveau projet et insérer dans chaque document les informations qui peuvent l'être. Nous allons donc créer une petite arborescence de fichier dans un dossier nommé "modeles" et un script qui va prendre en entrée :
le nom du projet,
la date de création souhaitée,
le nom de l'auteur,
le nom du client.
Ce script PowerShell va ensuite initialiser l'ensemble des documents de notre projet et y insérer les données dans les signets prévus :
# Fonction d'écriture de données dans le signet dans l'objet "$doc" passé en paramètre function modifySignet{ param($doc,$key,$value) # Nom du signet à modifier $signet = $key # Recherche du signet à modifier dans le document $bookmark = $document.Bookmarks | Where-Object -FilterScript { $_.Name -eq $signet } $bookmarkToModify = $bookmark.Range # Insertion de la donnée à l'endroit du signet $bookmarkToModify.Text = $value.Trim() return $doc }
# Fonction de génération du document à partir du modèle function createDoc { param ($i, $o, $d, $c, $a) # Création d'un objet COM de type Word.Application $Word = New-Object -comobject Word.Application $Word.Visible = $False
# Ouverture du fichier $document = $Word.Documents.Open($i) Write-host " [+] Insertion de données dans les signets" # Appel de notre fonction d'insertion de données dans le signet $document = modifySignet -doc $document -key "AUTEUR" -value $a $document = modifySignet -doc $document -key "DATE" -value $d $document = modifySignet -doc $document -key "CLIENT" -value $c
# Sauvegarde des modifications dans le fichier indiqué $document.SaveAs($o) # Fermeture du document $document.Close() # Fermeture de l'application $Word.Quit() }
# Création du répertoire projet Write-Host "[+] Génération du répertoire projet"$nom New-Item -itemtype directory -name $nom | Out-Null
# Pour chaque fichier du répertoire "modele" Get-ChildItem .\modeles\ |foreach { Write-host "[+] Génération du fichier"$_.Name"à partir du modèle" # Chemin vers notre fichier Word $infile = (Resolve-Path ".").Path.Replace('Microsoft.PowerShell.Core\FileSystem::', '') +"\modeles\"+$_.Name $outfile= (Resolve-Path ".").Path.Replace('Microsoft.PowerShell.Core\FileSystem::', '') +"\"+$nom+"\"+$_.Name # Appel de la fonction de modification des signets createDoc -i $infile -o $outfile -d $date -c $client -a $auteur }
En plus du code déjà présenté, nous avons en plus dans ce projet les lignes de code concernant la création du répertoire projet et le parcours du dossier "modèle" pour y trouver l'ensemble des documents à copier dans notre répertoire projet et enfin, les lignes relatives à la gestion des paramètres. L'utilisation du script sera fera comme suivant :
> generer-projet.ps1 -nom project342 -auteur "Mickael" -date "14/08/2022" -client "IT-Connect" [+] Génération du répertoire projet project342 [+] Génération du fichier achats.docx à partir du modèle [+] Insertion de données dans les signets [+] Génération du fichier intervenants.docx à partir du modèle [+] Insertion de données dans les signets [+] Génération du fichier presentation.docx à partir du modèle [+] Insertion de données dans les signets
Suite à l'exécution de ce script, j'aurai dans un répertoire project342 avec les documents souhaités préremplis aux signets indiqués :
Création et remplissage automatique des fichiers docx via Powershell.
Il ne s'agit bien sûr que d'un exemple qui vise à montrer ce qui est réalisable dans des contextes plus proches de la réalité :).
Les chercheurs en sécurité de McAfee ont identifié 5 extensions pour Google Chrome qui se montrent particulièrement curieuses. En effet, ces extensions collectent des informations sur l'activité des utilisateurs dans le navigateur dans un but bien précis. Au total, ces extensions comptabilisent plus de 1,4 million de téléchargements !
L'objectif de ces extensions malveillantes est de générer de l'argent en abusant du principe de l'affiliation. Le principe est le suivant : l'extension surveille l'activité de l'utilisateur sur Internet, et quand il visite un site de e-commerce, l'extension modifie les cookies afin de faire croire que l'utilisateur est arrivé sur le site en utilisant un lien d'affiliation. Ainsi, si l'utilisateur effectue un achat, les auteurs de ces extensions touchent une commission.
Cette manipulation est assurée par le script "B0.js" qui envoie les données de navigation de l'internaute vers un domaine contrôlé par les attaquants ("langhort[.]com"). Si le site web visité est dans la liste des sites pour lesquels l'auteur de l'extension est affilié, le serveur répond à B0.js avec l'une des deux fonctions possibles.
La première fonction "Result['c'] - passf_url" ordonne au script d'insérer l'URL fournie (lien de référence associé à l'affiliation) sous forme d'iframe sur le site web visité.
Le seconde fonction "Result['e'] setCookie" ordonne à B0.js de modifier le cookie ou de le remplacer pour activer le processus d'affiliation.
Les chercheurs de McAfee ont mis en ligne une vidéo de démo :
AutoBuy Flash Sales (ID : gbnahglfafmhaehbdmjedfhdmimjcbed) – 20 000 téléchargements
À première vue, ces extensions semblent légitimes, car elles fonctionnent réellement, en respectant les fonctionnalités annoncées. Par contre, en tâche de fond, elle effectue des actions douteuses et non respectueuses de la vie privée des utilisateurs. Si vous êtes un utilisateur de l'une de ces extensions, il est préférable de la supprimer. Pour éviter d'être détectées, certaines extensions vont jusqu'à attendre 15 jours avant d'entrer en action.
Pour le moment, les extensions "Full Page Screenshot Capture – Screenshotting" et "FlipShope – Price Tracker Extension" sont toujours disponibles sur le Chrome Web Store, tandis que les autres sont supprimées du magasin d'extension (ce qui n'empêche pas de les utiliser si elles sont déjà installées).
