Nous pouvons voir que nous parvenons à envoyer un ping à notre hôte à partir de la machine cible. Le point important à noter ici est que nous ne sommes pas obligés de nous limiter au ping. En effet, toute requête du système d’exploitation à ce stade est une charge virale valide. Tout attaquant mal intentionné peut ouvrir un reverse shell ou exécuter toute autre commande disponible sur l’hôte.

Comme démontré ci-dessous, nous avons un shell efficace sur l’hôte.

Détection de Text4shell à l’aide de Logpoint

Sources de log nécessaires

• Pare-feu
• Serveur exécutant la bibliothèque Apache Commons Text
  • Sysmon pour Linux
  • Auditd
  • Logs d’accès au serveur Apache
• Apache s’exécutant sous Windows
  • Logs d’événement natif
  • Sysmon

Comme l’exploitation nécessite l’utilisation de l’une de ces méthodes de recherche supplémentaires mentionnées ci-dessus, nous pouvons rechercher ces fonctions dans les URL pour détecter toute tentative d’exploitation.

(url=* OR resource=*) 
| process eval("decoded_resource=urldecode(resource)") 
| process eval("decoded_url=urldecode(url)") 
| rename decoded_resource as resource, decoded_url as url 
| search ( resource IN ["*${script:*","*${url:*","*${dns:*","*script*java.lang.Runtime.getRuntime*"] 
OR url IN ["*${script:*","*${url:*","*${dns:*","*script:*:java.lang.Runtime.getRuntime*"])

Détection de l’activité post-compromission

En plus de la détection des tentatives d’exploitation, il est également très important de détecter l’activité post-compromission. Nous pouvons passer à côté de la détection de tentatives d’exploitation pour diverses raisons, nous devons donc rechercher des traces d’activités suspectes telles que la création d’un shell, une connexion sortante suspecte à un hôte distant ainsi que d’autres activités suspectes pouvant indiquer une compromission. Nous avons commencé notre chasse aux activités suspectes en se focalisant sur la détection d’activités de découverte initiale d’informations système ainsi que sur les tentatives suspectes de création de processus et d’exécution de commandes.

Après avoir obtenu un shell inversé ou un accès au système, les adversaires peuvent essayer de mener une activité de découverte d’informations système que nous pouvons détecter en utilisant la requête suivante :

Pour les systèmes Unix qui utilisent auditd pour la journalisation (logging) :

norm_id=Unix "process"=audit (event_type="EXECVE" argument_0 IN ["uname", "uptime"]) 
OR (event_type="PATH" path IN ["/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", "/proc/scsi/scsi", "/proc/ide/hd0/model", "/proc/version", "/etc/*version", "/etc/*release", "/etc/issue"])     

Pour Windows:

label="Process" label=Create ("process"="*\systeminfo.exe" OR command="*net config*") -user IN EXCLUDED_USERS   

Nous pouvons également rechercher une création de processus suspect dans les systèmes Windows. Il peut y avoir des faux positifs que l’analyste doit filtrer en fonction de son environnement.

label="Process" label=Create 
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"] 
-command="cmd.exe /c set" 
| chart count() by host, parent_process, "process", command 

Pour les systèmes Linux exécutant sysmon, surveillez l’apparition de processus suspects:

norm_id=UnixSysmon label="Process" label=Create 
(user="confluence" OR path="*/Atlassian/Confluence/bin") 
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"] 
| chart count() by host, image, command 

Appliquez les mesures d’atténuation dès que possible

Nous conseillons aux administrateurs d’évaluer et de mettre à jour leur bibliothèque Apache Commons Text avec la dernière version dès que possible. Les analystes doivent surveiller les traces de post-exploitation et rechercher toute activité suspecte liée à une potentielle tactique que nous n’avons pas forcément couverte ci-dessus. Des alertes pour détecter les activités suspectes sont déjà créées par l’équipe Logpoint, nous conseillons donc aux analystes de les utiliser et de rechercher en permanence les activités malveillantes. La recherche active d’indicateurs de compromission et le test de diverses hypothèses peuvent aider à découvrir les vulnérabilités zero-day. Enfin, en utilisant Logpoint SOAR, un analyste pourra automatiser le processus de suivi, de détection et d’atténuation de la menace en question.

Nous mettrons à jour cet article de blog en fonction de l’évolution de la situation.