SharpViewStateKing et l’anatomie d’un cadre d’implant indétectable
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
Le Centre canadien pour la cybersécurité a identifié SharpViewStateKing comme un cadre d’implantation modulaire conçu pour cibler discrètement les environnements ASP.NET. En abusant des paramètres ViewState compromis, le cadre exécute des plugins entièrement en mémoire, ce qui lui permet de fonctionner de manière effectivement sans état et d’échapper à la détection traditionnelle basée sur les fichiers. Son trafic HTTP et HTTPS chiffré aide en outre l’activité à se fondre dans les communications Web légitimes.
Investigation
L’enquête a commencé après que des analystes ont trouvé un web shell sur un serveur Microsoft IIS accessible au public. L’examen de la télémétrie des points d’extrémité et de la mémoire des processus a montré que l’implant utilisait des plugins C# générés dynamiquement pour effectuer des actions telles que le téléchargement de fichiers, l’exécution de commandes à distance et la reconnaissance de l’hôte. Les chercheurs ont utilisé la plateforme Assemblyline pour décompiler le bytecode C# et exposer la logique interne du cadre.
Atténuation
Les défenseurs devraient reconstruire tous les hôtes potentiellement affectés et remplacer les clés de chiffrement et de validation associées aux applications ASP.NET. Corriger les vulnérabilités pertinentes, y compris celles affectant SharePoint comme mentionné dans le rapport, est également crucial. La surveillance des processus enfants lancés par l’IIS w3wp.exe le processus de travail peut aider à découvrir une activité non autorisée liée à l’implant.
Réponse
Si une activité SharpViewStateKing est identifiée, les organisations doivent examiner la télémétrie EDR et NDR pour détecter des signes de mouvement latéral, y compris la création de nouveaux comptes ou le déploiement d’outils tels que SoftEther VPN. Tous les mots de passe et les identifiants liés au système compromis doivent être considérés comme exposés et immédiatement remplacés. Les équipes de sécurité doivent également vérifier si des exclusions de Microsoft Defender ont été modifiées sans autorisation.
Flux d’attaque
Détections
Activité possible Impacket SecretDump à distance (via zeek)
Voir
Exploitation possible d’un serveur ou d’une application Web [Windows] (via cmdline)
Voir
Modification suspecte des exclusions de Defender via WMIC (via cmdline)
Voir
Activité possible Impacket SecretDump (via audit)
Voir
Détection des plugins d’exécution à distance et d’effacement de trace [Windows Sysmon]
Voir
Détecter les anomalies de requêtes HTTP SharpViewStateKing [Serveur Web]
Voir
Détection de l’exécution furtive de commande par fenêtres cachées [Création de processus Windows]
Voir
Exécution de simulation
Préalable : la vérification pré-vol de télémétrie et de référence doit avoir réussi.
Raison : Cette section détaille l’exécution précise de la technique d’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTP identifiés et viser à générer la télémétrie exacte attendue par la logique de détection. Des exemples abstraits ou non liés entraîneront un diagnostic erroné.
-
Récit d’attaque et commandes : Un adversaire a identifié une application ASP.NET vulnérable et a l’intention de déployer le cadre SharpViewStateKing pour maintenir la persistance et intercepter les données de session. Pour ce faire, l’attaquant envoie une série de requêtes HTTP qui utilisent les
__VIEWSTATEand__SCROLLPATHparamètres pour livrer une charge d’exploitation. En utilisant ces paramètres spécifiques, l’attaquant tente de se fondre dans le trafic standard d’ASP.NET, espérant échapper à la détection basée sur les signatures qui ne cherche que des chemins de web shell traditionnels. -
Script de test de régression :
# Script de simulation pour déclencher la règle de détection SharpViewStateKing $targetUri = "http://localhost/Login.aspx" # Charge utile 1 : Test de détection du paramètre __VIEWSTATE Write-Host "[*] Simulation de tentative d'exploitation avec __VIEWSTATE..." $payload1 = "__VIEWSTATE=MZ................[Simulated_Malicious_Payload]" Invoke-WebRequest -Uri "$targetUri?$payload1" -Method Get # Charge utile 2 : Test de détection du paramètre __SCROLLPATH Write-Host "[*] Simulation de tentative d'exploitation avec __SCROLLPATH..." $payload2 = "__SCROLLPATH=/etc/passwd" Invoke-WebRequest -Uri "$targetUri?$payload2" -Method Get Write-Host "[+] Simulation terminée. Vérifiez SIEM pour les alertes." -
Commandes de nettoyage :
# Aucun nettoyage spécifique requis car ce sont des requêtes GET HTTP sans état. # Cependant, si des fichiers ont été déposés lors d'une attaque réelle, ils devraient être supprimés. Write-Host "[*] Nettoyage de simulation : aucun artefact persistant créé."