Chapitre 1.2 Quiz - Renseignement sur les menaces et taxonomie des attaques

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Un analyste remarque que son SIEM genere 500 alertes par jour depuis un flux de menaces contenant 50 000 adresses IP. Le SOC bloque toutes les IP du flux au niveau du pare-feu perimetre. Le responsable de la securite qualifie cela d'"excellente operationnalisation du renseignement sur les menaces." Quel est le probleme fondamental avec cette approche, en referant a la Pyramide de la Douleur ?

Reveler la reponse et l'explication

Reponse : Bloquer des IPs est l'action de plus faible valeur possible - a la base de la Pyramide de la Douleur, triviale a contourner pour les attaquants.

Explication :

La Pyramide de la Douleur (David Bianco) decrit la douleur infligee a un attaquant lorsque chaque type d'indicateur est detecte et bloque :

Valeurs de hachage - trivial : modifier un octet, nouveau hachage
Adresses IP - trivial : utiliser un nouveau VPS, rotation via un hebergement pare-balles
Noms de domaine - facile : enregistrer un nouveau domaine, utiliser un DGA
Artefacts reseau/hote - modere : necessite de changer d'outillage
Outils - significatif : necessite de reecrire ou remplacer les outils
TTPs - difficile : necessite de changer fondamentalement de comportement

Problemes du blocage massif d'IPs :

Faux positifs massifs - les grands flux d'IPs incluent des IPs de CDN, des noeuds de sortie Tor et des hebergements partages utilises a la fois par des attaquants ET des entreprises legitimes. Bloquer 104.21.x.x (plage Cloudflare) casse le trafic legitime.
Valeur de detection quasi nulle - un attaquant sophistique utilise une infrastructure fraiche pour chaque campagne. Au moment ou une IP figure dans un flux de menaces, l'attaquant est probablement deja passe a autre chose.
Fatigue des alertes - 500 alertes par jour generates par les blocages d'IP cree du bruit qui noie les vraies detections. Les analystes s'y habituent et les ignorent.
Manquer l'attaquant - un attaquant determine bloque au perimetre pivote vers une nouvelle IP. Il n'est pas arrete ; il est contrarie pendant quelques minutes.

A quoi ressemble une bonne operationnalisation :

Faible valeur (arreter de surinvestir ici) :
  -> Listes de blocage d'IPs, listes de blocage de hachages

Valeur moyenne (automatiser cela) :
  -> Reputation de domaine, blocage de domaines C2 connus
  -> Analyse de reputation des fichiers

Haute valeur (investir l'ingenierie ici) :
  -> Regles de detection comportementale (Sigma pour les TTPs)
  -> YARA pour les patterns de familles de malware (pas seulement les hachages)
  -> Lignes de base d'anomalie pour le comportement reseau
  -> Detections cartographiees avec ATT&CK

La bonne metrique n'est pas le "nombre d'alertes generees" - c'est le taux de vrais positifs, le temps moyen de detection (MTTD), et la couverture des tactiques ATT&CK dans votre bibliotheque de detection.

Question 2

Un rapport de renseignement sur les menaces indique qu'APT41 (un groupe etato-national chinois) cible les entreprises de telecommunications en utilisant la technique suivante : T1190 - Exploitation d'une application exposee publiquement pour l'acces initial, suivie de T1505.003 - Web Shell. Votre organisation exploite une application web publique sur Apache Tomcat 9.0.50. Quelles sont les actions immediates et strategiques a prendre, et comment le Modele Diamant aide-t-il a enqueter si une compromission est suspectee ?

Reveler la reponse et l'explication

Reponse : Corriger et durcir immediatement l'application + deployer la detection de web shells ; utiliser le Modele Diamant pour pivoter depuis tout indicateur decouvert.

Explication :

Actions techniques immediates :

# 1. Verifier la version Tomcat et les CVEs connus pour 9.0.50
# CVE-2022-34305 (XSS), CVE-2021-33037 (Contrebande de requetes) affectent 9.0.x
# Consulter NVD : https://nvd.nist.gov/vuln/search/results?query=tomcat+9.0.50

# 2. Rechercher des web shells existants sur le serveur
# Les web shells sont typiquement des fichiers PHP/JSP avec des capacites eval/exec
# Chercher des fichiers JSP suspects (web shells Tomcat)
find /var/lib/tomcat/webapps -name "*.jsp" -newer /var/lib/tomcat/webapps/ROOT/index.jsp
find /var/lib/tomcat/webapps -name "*.jspx" -o -name "*.war"

# Chercher des indicateurs communs de web shells dans les fichiers existants
grep -r "Runtime.exec\|ProcessBuilder\|getRuntime\|cmd.exe\|/bin/sh" \
  /var/lib/tomcat/webapps/ --include="*.jsp"

# 3. Verifier les journaux d'acces pour les patterns d'acces aux web shells
# Les web shells sont accedes via GET/POST avec des parametres cmd= ou similaires
grep -E "(cmd=|exec=|command=|shell=|pass=)" /var/log/tomcat/localhost_access_log.*.txt

# 4. Rechercher des requetes POST anormales vers des fichiers .jsp hors de l'application
awk '$6 == "\"POST" {print $7}' /var/log/tomcat/localhost_access_log.*.txt | \
  sort | uniq -c | sort -rn | head -20

# 5. Activer la surveillance de l'integrite des fichiers pour le repertoire webapps
apt install aide
aide --init
# Executer regulierement et alerter sur les fichiers JSP nouveaux ou modifies

Actions strategiques :

Deployer une regle WAF bloquant les patterns courants d'interaction avec les web shells
Activer la journalisation au niveau applicatif (journaux d'acces et d'erreurs Tomcat -> SIEM)
Corriger vers la derniere version Tomcat 9.x
Implementer le filtrage sortant - les web shells initient typiquement un C2 sortant ; bloquer le trafic sortant sur le serveur applicatif previent la connexion

Investigation avec le Modele Diamant (si compromission suspectee) :

Connu : Capacite (web shell, backdoor JSP)
         |
         v Pivot 1 : Trouver le hachage specifique du fichier
                     -> Recherche VirusTotal, MalwareBazaar
                     -> Pivoter vers la famille de malware connue
         |
         v Pivot 2 : De la famille de malware -> infrastructure C2
                     -> DNS passif : vers quelles IPs le domaine C2 a-t-il resolu ?
                     -> Shodan : quels autres services tournent sur cette IP C2 ?
         |
         v Pivot 3 : De l'infrastructure C2 -> autres victimes
                     -> Partage de renseignements sur les menaces : qui d'autre a vu ce C2 ?
                     -> Communaute MISP, FS-ISAC, ISAC sectoriel
         |
         v Pivot 4 : Des victimes + techniques -> attribution de l'adversaire
                     -> Correspond aux TTPs d'APT41 ? (MITRE ATT&CK G0096)
                     -> Coherent avec le ciblage (secteur des telecommunications)

Ce pivotement systematique transforme un seul web shell en une image complete de l'intrusion, de l'acteur, et potentiellement d'autres organisations compromises.

Question 3

Examinez la regle YARA suivante et identifiez deux problemes techniques qui la feraient soit ne pas detecter le malware cible, soit generer un nombre excessif de faux positifs :

rule BadRule_Example
{
    strings:
        $str1 = "cmd.exe"
        $str2 = "powershell"
        $str3 = "http"
    condition:
        any of them
}

Reveler la reponse et l'explication

Reponse : Les chaines sont trop generiques (faux positifs massifs) et la condition any of them est beaucoup trop large.

Explication :

Probleme 1 - Chaines trop generiques -> taux de faux positifs catastrophique

"cmd.exe" apparait dans des milliers de binaires Windows legitimes, scripts batch, installateurs, fichiers de documentation et entrees de journaux
"powershell" apparait dans n'importe quel script, fichier journal ou outil qui reference PowerShell
"http" apparait dans pratiquement chaque application, bibliotheque et fichier texte sur internet

Cette regle signalerait presque chaque executable, script et document sur un systeme Windows. Elle a une specificite de detection quasi nulle.

Probleme 2 - La condition any of them est maximalement permissive

La condition se declenche si meme une seule des trois chaines extremement courantes est presente. Cela garantit des millions de faux positifs.

Problemes supplementaires :

Pas de modificateur wide ascii - manque les chaines Unicode (de nombreux fichiers PE stockent les chaines en wide/UTF-16)
Pas de contrainte de taille de fichier - analyser des fichiers journaux de 500 Mo pour "http" est couteux et produira des correspondances
Pas d'ancre de type de fichier (verification de l'en-tete MZ) - s'applique a tous les types de fichiers, pas seulement aux executables

Regle corrigee :

rule BetterRule_SuspiciousDropper
{
    meta:
        description = "Detecte un dropper avec une berceau de telechargement PowerShell et execution"
        author = "EquipeSecurite"
        date = "2024-01-15"
        mitre_attack = "T1059.001, T1105"

    strings:
        // Patterns specifiques de berceaux de telechargement PowerShell - pas seulement "powershell"
        $ps_download1 = "IEX(New-Object Net.WebClient).DownloadString" wide ascii nocase
        $ps_download2 = "Invoke-Expression" wide ascii nocase
        $ps_enc       = " -encodedcommand " wide ascii nocase

        // Patterns cmd suspects specifiques - pas seulement "cmd.exe"
        $cmd_bypass   = "cmd.exe /c powershell" wide ascii nocase
        $cmd_hidden   = "-WindowStyle Hidden" wide ascii nocase

        // Pattern C2 specifique - pas seulement "http"
        $c2_pattern   = /https?:\/\/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\/[a-z]{4,8}\.php/ ascii

    condition:
        uint16(0) == 0x5A4D   // Doit etre un fichier PE (en-tete MZ)
        and filesize < 5MB    // Contrainte de taille raisonnable
        and (
            2 of ($ps_download1, $ps_download2, $ps_enc, $cmd_bypass, $cmd_hidden)
            or $c2_pattern
        )
}

Ameliorations cles : patterns specifiques a plusieurs mots, modificateur wide ascii, ancre de fichier PE, limite de taille de fichier, seuil de confiance plus eleve (2 sur N), expression reguliere pour la specificite du pattern C2.

Question 4

Vous effectuez une chasse aux menaces et remarquez le pattern de requetes DNS suivant dans vos journaux reseau sur une periode de 24 heures :

14:23  src=10.0.1.55  requete=aGVsbG8.updates.microsoft-patch[.]net  type=A
44:31  src=10.0.1.55  requete=d29ybGQ.updates.microsoft-patch[.]net  type=A
14:18  src=10.0.1.55  requete=dGhpcw.updates.microsoft-patch[.]net   type=A
44:52  src=10.0.1.55  requete=aXMgYQ.updates.microsoft-patch[.]net   type=A

Identifiez la technique d'attaque, decodez ce qui est transmis, expliquez le pattern de balise, et decrivez comment vous enqueteriez et remedieriez a cette situation.

Reveler la reponse et l'explication

Reponse : Balise C2 par tunneling DNS - donnees encodees en Base64 dans les sous-domaines a des intervalles de 30 minutes. Le domaine usurpe l'identite de Microsoft.

Explication :

Etape 1 - Identifier la technique

Il s'agit de T1071.004 - Protocole de couche applicative : DNS (tunneling DNS). L'attaquant encode des donnees dans les sous-domaines de requetes DNS pour exfiltrer des donnees ou maintenir une communication C2, contournant les controles reseau qui inspectent uniquement HTTP/HTTPS.

Etape 2 - Decoder les sous-domaines (Base64)

echo "aGVsbG8" | base64 -d    # -> "hello"
echo "d29ybGQ" | base64 -d    # -> "world"
echo "dGhpcw" | base64 -d     # -> "this"
echo "aXMgYQ" | base64 -d     # -> "is a"
# Message decode complet : "hello world this is a..." (exfiltration en cours)

Etape 3 - Identifier le pattern de balise

Horodatages : 08:14, 08:44, 09:14, 09:44 -> exactement 30 minutes d'intervalle. C'est un intervalle de sommeil de balise C2 classique. Le malware se reveille toutes les 30 minutes, encode un bloc de donnees ou une balise de statut comme sous-domaine, et interroge le serveur DNS de l'attaquant. L'attaquant recoit les donnees dans ses journaux de serveur DNS.

Etape 4 - Analyse du domaine

microsoft-patch[.]net - c'est un domaine de typosquatting imitant Microsoft. Les domaines legitimes de Microsoft sont microsoft.com - ils n'utilisent pas .net pour l'infrastructure de correctifs. Le registrant controle le serveur DNS, donc toutes les requetes (donnees) vont directement a l'attaquant.

Etape 5 - Investigation

# 1. Identifier l'hote compromis
# src=10.0.1.55 - obtenir le nom d'hote et le proprietaire
nslookup 10.0.1.55
# Interroger les journaux AD/DHCP pour l'historique des baux

# 2. Verifier l'historique complet des requetes DNS pour cet hote
# Dans votre SIEM (exemple Splunk) :
# index=dns src_ip="10.0.1.55" | stats count by query | sort -count

# 3. Verifier si le domaine est connu comme malveillant
dig microsoft-patch.net        # Est-ce qu'il resout ?
curl "https://www.virustotal.com/api/v3/domains/microsoft-patch.net" \
  -H "x-apikey: VOTRE_CLE"

# 4. Calculer l'entropie des sous-domaines pour confirmer l'encodage
python3 -c "
import math, base64
sous_domaines = ['aGVsbG8', 'd29ybGQ', 'dGhpcw', 'aXMgYQ']
for s in sous_domaines:
    p = [s.count(c)/len(s) for c in set(s)]
    e = -sum(x*math.log2(x) for x in p)
    try:
        decoded = base64.b64decode(s + '==').decode()
    except:
        decoded = '?'
    print(f'{s} -> entropie={e:.2f}, decode={decoded}')
"

# 5. Isoler l'hote immediatement
# Bloquer 10.0.1.55 au niveau reseau
iptables -A FORWARD -s 10.0.1.55 -j DROP
# Ou quarantaine VLAN via configuration du commutateur

# 6. Rediriger le domaine vers un sinkhole sur votre resolveur DNS
# Bind9 : rediriger vers 0.0.0.0
echo 'zone "microsoft-patch.net" { type redirect; masters { 127.0.0.1; }; };' \
  >> /etc/bind/named.conf.local

Remediation :

Deployer la securite DNS (filtrage des sous-domaines de type DGA, limites de longueur de requetes)
Alerter sur les requetes DNS avec des sous-domaines encodes en Base64 de plus de 20 caracteres
Bloquer les requetes DNS vers des resolveurs non approuves (forcer tout le DNS via votre resolveur controle)
Deployer la securite au niveau DNS (Cisco Umbrella, Cloudflare Gateway, Pi-hole avec flux de menaces)

Regle de detection SIEM :

# Sigma : tunneling DNS via sous-domaine long
title: Tunneling DNS potentiel - Sous-domaine long
detection:
  selection:
    dns.question.name|re: '^[A-Za-z0-9+/]{20,}\.[a-z0-9-]+\.[a-z]{2,}$'
  condition: selection
level: high

Question 1​

Question 2​

Question 3​

Question 4​

Question 1

Question 2

Question 3

Question 4