mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/basic-forensic-meth
This commit is contained in:
parent
5d5c132399
commit
68c2486c64
@ -37,6 +37,7 @@
|
||||
- [Mobile Phishing Malicious Apps](generic-methodologies-and-resources/phishing-methodology/mobile-phishing-malicious-apps.md)
|
||||
- [Phishing Files & Documents](generic-methodologies-and-resources/phishing-methodology/phishing-documents.md)
|
||||
- [Basic Forensic Methodology](generic-methodologies-and-resources/basic-forensic-methodology/README.md)
|
||||
- [Adaptixc2 Config Extraction And Ttps](generic-methodologies-and-resources/basic-forensic-methodology/adaptixc2-config-extraction-and-ttps.md)
|
||||
- [Baseline Monitoring](generic-methodologies-and-resources/basic-forensic-methodology/file-integrity-monitoring.md)
|
||||
- [Anti-Forensic Techniques](generic-methodologies-and-resources/basic-forensic-methodology/anti-forensic-techniques.md)
|
||||
- [Docker Forensics](generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.md)
|
||||
@ -130,6 +131,7 @@
|
||||
- [Seccomp](linux-hardening/privilege-escalation/docker-security/seccomp.md)
|
||||
- [Weaponizing Distroless](linux-hardening/privilege-escalation/docker-security/weaponizing-distroless.md)
|
||||
- [Escaping from Jails](linux-hardening/privilege-escalation/escaping-from-limited-bash.md)
|
||||
- [Posix Cpu Timers Toctou Cve 2025 38352](linux-hardening/privilege-escalation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
|
||||
- [euid, ruid, suid](linux-hardening/privilege-escalation/euid-ruid-suid.md)
|
||||
- [Interesting Groups - Linux Privesc](linux-hardening/privilege-escalation/interesting-groups-linux-pe/README.md)
|
||||
- [lxd/lxc Group - Privilege escalation](linux-hardening/privilege-escalation/interesting-groups-linux-pe/lxd-privilege-escalation.md)
|
||||
@ -771,7 +773,7 @@
|
||||
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
|
||||
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
|
||||
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
|
||||
- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
|
||||
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
|
||||
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
|
||||
@ -840,6 +842,7 @@
|
||||
- [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md)
|
||||
- [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
|
||||
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
|
||||
- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
|
||||
- [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
|
||||
- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
|
||||
- [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md)
|
||||
@ -937,6 +940,4 @@
|
||||
- [Stealing Sensitive Information Disclosure from a Web](todo/stealing-sensitive-information-disclosure-from-a-web.md)
|
||||
- [Post Exploitation](todo/post-exploitation.md)
|
||||
- [Investment Terms](todo/investment-terms.md)
|
||||
- [Cookies Policy](todo/cookies-policy.md)
|
||||
|
||||
- [Posix Cpu Timers Toctou Cve 2025 38352](linux-hardening/privilege-escalation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
|
||||
- [Cookies Policy](todo/cookies-policy.md)
|
@ -0,0 +1,243 @@
|
||||
# AdaptixC2 Extraction de configuration et TTPs
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
AdaptixC2 est un framework modulaire et open‑source de post‑exploitation/C2 avec des beacons Windows x86/x64 (EXE/DLL/service EXE/raw shellcode) et prise en charge de BOF. Cette page documente :
|
||||
- Comment sa configuration chiffrée RC4 est intégrée et comment l'extraire des beacons
|
||||
- Indicateurs réseau/profil pour les listeners HTTP/SMB/TCP
|
||||
- TTPs courants de loader et de persistence observés dans la nature, avec des liens vers des pages de techniques Windows pertinentes
|
||||
|
||||
## Profils et champs des beacons
|
||||
|
||||
AdaptixC2 prend en charge trois types principaux de beacons :
|
||||
- BEACON_HTTP: C2 web avec serveurs/ports/SSL configurables, méthode, URI, headers, user‑agent, et un nom de paramètre personnalisé
|
||||
- BEACON_SMB: C2 peer‑to‑peer via named‑pipe (intranet)
|
||||
- BEACON_TCP: sockets directs, éventuellement avec un marqueur préfixé pour obfusquer le démarrage du protocole
|
||||
|
||||
Champs de profil typiques observés dans les configs HTTP des beacons (après déchiffrement) :
|
||||
- agent_type (u32)
|
||||
- use_ssl (bool)
|
||||
- servers_count (u32), servers (array of strings), ports (array of u32)
|
||||
- http_method, uri, parameter, user_agent, http_headers (length‑prefixed strings)
|
||||
- ans_pre_size (u32), ans_size (u32) – used to parse response sizes
|
||||
- kill_date (u32), working_time (u32)
|
||||
- sleep_delay (u32), jitter_delay (u32)
|
||||
- listener_type (u32)
|
||||
- download_chunk_size (u32)
|
||||
|
||||
Example default HTTP profile (from a beacon build):
|
||||
```json
|
||||
{
|
||||
"agent_type": 3192652105,
|
||||
"use_ssl": true,
|
||||
"servers_count": 1,
|
||||
"servers": ["172.16.196.1"],
|
||||
"ports": [4443],
|
||||
"http_method": "POST",
|
||||
"uri": "/uri.php",
|
||||
"parameter": "X-Beacon-Id",
|
||||
"user_agent": "Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0",
|
||||
"http_headers": "\r\n",
|
||||
"ans_pre_size": 26,
|
||||
"ans_size": 47,
|
||||
"kill_date": 0,
|
||||
"working_time": 0,
|
||||
"sleep_delay": 2,
|
||||
"jitter_delay": 0,
|
||||
"listener_type": 0,
|
||||
"download_chunk_size": 102400
|
||||
}
|
||||
```
|
||||
Profil HTTP malveillant observé (attaque réelle) :
|
||||
```json
|
||||
{
|
||||
"agent_type": 3192652105,
|
||||
"use_ssl": true,
|
||||
"servers_count": 1,
|
||||
"servers": ["tech-system[.]online"],
|
||||
"ports": [443],
|
||||
"http_method": "POST",
|
||||
"uri": "/endpoint/api",
|
||||
"parameter": "X-App-Id",
|
||||
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.160 Safari/537.36",
|
||||
"http_headers": "\r\n",
|
||||
"ans_pre_size": 26,
|
||||
"ans_size": 47,
|
||||
"kill_date": 0,
|
||||
"working_time": 0,
|
||||
"sleep_delay": 4,
|
||||
"jitter_delay": 0,
|
||||
"listener_type": 0,
|
||||
"download_chunk_size": 102400
|
||||
}
|
||||
```
|
||||
## Empaquetage de la configuration chiffrée et chemin de chargement
|
||||
|
||||
Lorsque l'opérateur clique sur Create dans le builder, AdaptixC2 intègre le profil chiffré en tant que tail blob dans le beacon. Le format est :
|
||||
- 4 bytes: taille de la configuration (uint32, little‑endian)
|
||||
- N bytes: données de configuration chiffrées par RC4
|
||||
- 16 bytes: RC4 key
|
||||
|
||||
Le beacon loader copie la key de 16 bytes depuis la fin et RC4‑decrypts le bloc de N bytes en place:
|
||||
```c
|
||||
ULONG profileSize = packer->Unpack32();
|
||||
this->encrypt_key = (PBYTE) MemAllocLocal(16);
|
||||
memcpy(this->encrypt_key, packer->data() + 4 + profileSize, 16);
|
||||
DecryptRC4(packer->data()+4, profileSize, this->encrypt_key, 16);
|
||||
```
|
||||
Implications pratiques :
|
||||
- L'ensemble de la structure se trouve souvent dans la section .rdata du PE.
|
||||
- L'extraction est déterministe : lire la taille, lire le ciphertext de cette taille, lire la clé de 16 octets placée immédiatement après, puis déchiffrer avec RC4.
|
||||
|
||||
## Flux de travail d'extraction de configuration (défenseurs)
|
||||
|
||||
Écrire un extracteur qui imite la logique du beacon :
|
||||
1) Localisez le blob dans le PE (généralement .rdata). Une approche pragmatique consiste à scanner .rdata à la recherche d'une mise en page plausible [size|ciphertext|16‑byte key] et tenter RC4.
|
||||
2) Lire les 4 premiers octets → size (uint32 LE).
|
||||
3) Lire les N=size octets suivants → ciphertext.
|
||||
4) Lire les 16 derniers octets → clé RC4.
|
||||
5) Déchiffrer le ciphertext avec RC4. Puis analyser le profil en clair comme suit :
|
||||
- scalaires u32/boolean comme indiqué ci‑dessus
|
||||
- chaînes préfixées par la longueur (u32 length suivi des octets ; un NUL terminal peut être présent)
|
||||
- tableaux : servers_count suivi de autant de paires [string, u32 port]
|
||||
|
||||
Preuve de concept Python minimale (autonome, sans dépendances externes) fonctionnant avec un blob pré‑extrait :
|
||||
```python
|
||||
import struct
|
||||
from typing import List, Tuple
|
||||
|
||||
def rc4(key: bytes, data: bytes) -> bytes:
|
||||
S = list(range(256))
|
||||
j = 0
|
||||
for i in range(256):
|
||||
j = (j + S[i] + key[i % len(key)]) & 0xFF
|
||||
S[i], S[j] = S[j], S[i]
|
||||
i = j = 0
|
||||
out = bytearray()
|
||||
for b in data:
|
||||
i = (i + 1) & 0xFF
|
||||
j = (j + S[i]) & 0xFF
|
||||
S[i], S[j] = S[j], S[i]
|
||||
K = S[(S[i] + S[j]) & 0xFF]
|
||||
out.append(b ^ K)
|
||||
return bytes(out)
|
||||
|
||||
class P:
|
||||
def __init__(self, buf: bytes):
|
||||
self.b = buf; self.o = 0
|
||||
def u32(self) -> int:
|
||||
v = struct.unpack_from('<I', self.b, self.o)[0]; self.o += 4; return v
|
||||
def u8(self) -> int:
|
||||
v = self.b[self.o]; self.o += 1; return v
|
||||
def s(self) -> str:
|
||||
L = self.u32(); s = self.b[self.o:self.o+L]; self.o += L
|
||||
return s[:-1].decode('utf-8','replace') if L and s[-1] == 0 else s.decode('utf-8','replace')
|
||||
|
||||
def parse_http_cfg(plain: bytes) -> dict:
|
||||
p = P(plain)
|
||||
cfg = {}
|
||||
cfg['agent_type'] = p.u32()
|
||||
cfg['use_ssl'] = bool(p.u8())
|
||||
n = p.u32()
|
||||
cfg['servers'] = []
|
||||
cfg['ports'] = []
|
||||
for _ in range(n):
|
||||
cfg['servers'].append(p.s())
|
||||
cfg['ports'].append(p.u32())
|
||||
cfg['http_method'] = p.s()
|
||||
cfg['uri'] = p.s()
|
||||
cfg['parameter'] = p.s()
|
||||
cfg['user_agent'] = p.s()
|
||||
cfg['http_headers'] = p.s()
|
||||
cfg['ans_pre_size'] = p.u32()
|
||||
cfg['ans_size'] = p.u32() + cfg['ans_pre_size']
|
||||
cfg['kill_date'] = p.u32()
|
||||
cfg['working_time'] = p.u32()
|
||||
cfg['sleep_delay'] = p.u32()
|
||||
cfg['jitter_delay'] = p.u32()
|
||||
cfg['listener_type'] = 0
|
||||
cfg['download_chunk_size'] = 0x19000
|
||||
return cfg
|
||||
|
||||
# Usage (when you have [size|ciphertext|key] bytes):
|
||||
# blob = open('blob.bin','rb').read()
|
||||
# size = struct.unpack_from('<I', blob, 0)[0]
|
||||
# ct = blob[4:4+size]
|
||||
# key = blob[4+size:4+size+16]
|
||||
# pt = rc4(key, ct)
|
||||
# cfg = parse_http_cfg(pt)
|
||||
```
|
||||
Tips:
|
||||
- Lors de l'automatisation, utilisez un parseur PE pour lire .rdata puis appliquez une fenêtre glissante : pour chaque offset o, essayez size = u32(.rdata[o:o+4]), ct = .rdata[o+4:o+4+size], candidate key = next 16 bytes; RC4‑decrypt et vérifiez que les champs string se décodent en UTF‑8 et que les longueurs sont cohérentes.
|
||||
- Analysez les profils SMB/TCP en suivant les mêmes conventions préfixant la longueur.
|
||||
|
||||
## Empreintes réseau et chasse
|
||||
|
||||
HTTP
|
||||
- Fréquent : POST vers des URI choisies par l'opérateur (par ex., /uri.php, /endpoint/api)
|
||||
- Paramètre d'en‑tête personnalisé utilisé pour l'ID du beacon (par ex., X‑Beacon‑Id, X‑App‑Id)
|
||||
- User‑agents imitant Firefox 20 ou des builds Chrome contemporains
|
||||
- Cadence de sondage visible via sleep_delay/jitter_delay
|
||||
|
||||
SMB/TCP
|
||||
- Listeners de named‑pipe SMB pour C2 intranet lorsque la sortie web est limitée
|
||||
- Les beacons TCP peuvent préfixer quelques octets avant le trafic pour obscurcir le début du protocole
|
||||
|
||||
## TTPs de loader et de persistance observés dans des incidents
|
||||
|
||||
Chargeurs PowerShell en mémoire
|
||||
- Téléchargent des payloads Base64/XOR (Invoke‑RestMethod / WebClient)
|
||||
- Allouent de la mémoire non gérée, copient le shellcode, changent la protection en 0x40 (PAGE_EXECUTE_READWRITE) via VirtualProtect
|
||||
- Exécutent via invocation dynamique .NET : Marshal.GetDelegateForFunctionPointer + delegate.Invoke()
|
||||
|
||||
Consultez ces pages pour l'exécution en mémoire et les considérations AMSI/ETW :
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/av-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
Mécanismes de persistance observés
|
||||
- Raccourci dans le dossier Startup (.lnk) pour relancer un loader au logon
|
||||
- Clés Run du registre (HKCU/HKLM ...\CurrentVersion\Run), souvent avec des noms à consonance bénigne comme "Updater" pour démarrer loader.ps1
|
||||
- DLL search‑order hijack en déposant msimg32.dll sous %APPDATA%\Microsoft\Windows\Templates pour des processus susceptibles
|
||||
|
||||
Approfondissements et vérifications techniques :
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/windows-local-privilege-escalation/privilege-escalation-with-autorun-binaries.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/windows-local-privilege-escalation/dll-hijacking/README.md
|
||||
{{#endref}}
|
||||
|
||||
Idées de chasse
|
||||
- Transitions RW→RX initiées par PowerShell : VirtualProtect vers PAGE_EXECUTE_READWRITE dans powershell.exe
|
||||
- Schémas d'invocation dynamique (GetDelegateForFunctionPointer)
|
||||
- .lnk dans les dossiers Startup utilisateur ou communs
|
||||
- Clés Run suspectes (ex., "Updater"), et noms de loader comme update.ps1/loader.ps1
|
||||
- Chemins DLL inscriptibles par l'utilisateur sous %APPDATA%\Microsoft\Windows\Templates contenant msimg32.dll
|
||||
|
||||
## Notes sur les champs OpSec
|
||||
|
||||
- KillDate : horodatage après lequel l'agent s'auto‑expire
|
||||
- WorkingTime : heures pendant lesquelles l'agent doit être actif pour se fondre dans l'activité professionnelle
|
||||
|
||||
Ces champs peuvent être utilisés pour le clustering et pour expliquer des périodes d'inactivité observées.
|
||||
|
||||
## YARA et pistes statiques
|
||||
|
||||
Unit 42 a publié des YARA basiques pour les beacons (C/C++ et Go) et des constantes de hachage d'API du loader. Envisagez de compléter avec des règles cherchant la mise en page [size|ciphertext|16‑byte‑key] près de la fin de .rdata du PE et les chaînes du profil HTTP par défaut.
|
||||
|
||||
## References
|
||||
|
||||
- [AdaptixC2: A New Open-Source Framework Leveraged in Real-World Attacks (Unit 42)](https://unit42.paloaltonetworks.com/adaptixc2-post-exploitation-framework/)
|
||||
- [AdaptixC2 GitHub](https://github.com/Adaptix-Framework/AdaptixC2)
|
||||
- [Adaptix Framework Docs](https://adaptix-framework.gitbook.io/adaptix-framework)
|
||||
- [Marshal.GetDelegateForFunctionPointer – Microsoft Docs](https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.marshal.getdelegateforfunctionpointer)
|
||||
- [VirtualProtect – Microsoft Docs](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect)
|
||||
- [Memory protection constants – Microsoft Docs](https://learn.microsoft.com/en-us/windows/win32/memory/memory-protection-constants)
|
||||
- [Invoke-RestMethod – PowerShell](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod)
|
||||
- [MITRE ATT&CK T1547.001 – Registry Run Keys/Startup Folder](https://attack.mitre.org/techniques/T1547/001/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
@ -1,8 +1,8 @@
|
||||
# Analyse de malware
|
||||
# Analyse de Malware
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Fiches CheatSheets d'informatique légale
|
||||
## Forensics CheatSheets
|
||||
|
||||
[https://www.jaiminton.com/cheatsheet/DFIR/#](https://www.jaiminton.com/cheatsheet/DFIR/)
|
||||
|
||||
@ -22,10 +22,10 @@
|
||||
```bash
|
||||
sudo apt-get install -y yara
|
||||
```
|
||||
#### Préparez les règles
|
||||
#### Préparer les règles
|
||||
|
||||
Utilisez ce script pour télécharger et fusionner toutes les règles yara malware depuis github: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\
|
||||
Créez le répertoire _**rules**_ puis exécutez le script. Cela créera un fichier appelé _**malware_rules.yar**_ qui contient toutes les règles yara pour malware.
|
||||
Utilisez ce script pour télécharger et fusionner toutes les règles yara malware depuis github : [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)
|
||||
Créez le répertoire _**rules**_ et exécutez le script. Cela créera un fichier nommé _**malware_rules.yar**_ qui contient toutes les règles yara pour malware.
|
||||
```bash
|
||||
wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py
|
||||
mkdir rules
|
||||
@ -36,16 +36,16 @@ python malware_yara_rules.py
|
||||
yara -w malware_rules.yar image #Scan 1 file
|
||||
yara -w malware_rules.yar folder #Scan the whole folder
|
||||
```
|
||||
#### YaraGen: Détecter le malware et créer des règles
|
||||
#### YaraGen: Vérifier la présence de malware et créer des règles
|
||||
|
||||
Vous pouvez utiliser l'outil [**YaraGen**](https://github.com/Neo23x0/yarGen) pour générer des yara rules à partir d'un binaire. Consultez ces tutoriels : [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
|
||||
Vous pouvez utiliser l'outil [**YaraGen**](https://github.com/Neo23x0/yarGen) pour générer des règles yara à partir d'un binaire. Consultez ces tutoriels : [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
|
||||
```bash
|
||||
python3 yarGen.py --update
|
||||
python3.exe yarGen.py --excludegood -m ../../mals/
|
||||
```
|
||||
### ClamAV
|
||||
|
||||
#### Installer
|
||||
#### Installation
|
||||
```
|
||||
sudo apt-get install -y clamav
|
||||
```
|
||||
@ -57,26 +57,26 @@ clamscan folderpath #Scan the whole folder
|
||||
```
|
||||
### [Capa](https://github.com/mandiant/capa)
|
||||
|
||||
**Capa** détecte des **capacités** potentiellement malveillantes dans les exécutables : PE, ELF, .NET. Il trouvera donc des éléments tels que les tactiques Att\&ck, ou des capacités suspectes telles que :
|
||||
**Capa** détecte des **capabilities** potentiellement malveillantes dans les exécutables : PE, ELF, .NET. Il trouvera donc des éléments tels que les tactiques Att\&ck, ou des capabilities suspectes telles que :
|
||||
|
||||
- vérifier la présence d'une erreur OutputDebugString
|
||||
- s'exécuter en tant que service
|
||||
- créer un processus
|
||||
- check for OutputDebugString error
|
||||
- run as a service
|
||||
- create process
|
||||
|
||||
Récupérez-le dans le [**Github repo**](https://github.com/mandiant/capa).
|
||||
|
||||
### IOCs
|
||||
|
||||
IOC signifie Indicateur de compromission. Un IOC est un ensemble de **conditions qui identifient** un logiciel potentiellement indésirable ou un **malware** confirmé. Les Blue Teams utilisent ce type de définition pour **rechercher ce type de fichiers malveillants** dans leurs **systèmes** et **réseaux**.\
|
||||
Partager ces définitions est très utile : lorsqu'un **malware** est identifié sur un ordinateur et qu'un IOC pour ce malware est créé, d'autres Blue Teams peuvent l'utiliser pour identifier le malware plus rapidement.
|
||||
IOC signifie Indicator Of Compromise. Un IOC est un ensemble de **conditions qui identifient** un logiciel potentiellement indésirable ou un **malware** confirmé. Les Blue Teams utilisent ce type de définition pour **rechercher ce type de fichiers malveillants** dans leurs **systèmes** et **réseaux**.\
|
||||
Partager ces définitions est très utile : lorsqu'un malware est identifié sur un ordinateur et qu'un IOC pour ce malware est créé, d'autres Blue Teams peuvent l'utiliser pour identifier le malware plus rapidement.
|
||||
|
||||
Un outil pour créer ou modifier des IOC est [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\
|
||||
Vous pouvez utiliser des outils tels que [**Redline**](https://www.fireeye.com/services/freeware/redline.html) pour **rechercher des IOC définis sur un appareil**.
|
||||
Un outil pour créer ou modifier des IOCs est [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html).\
|
||||
Vous pouvez utiliser des outils comme [**Redline**](https://www.fireeye.com/services/freeware/redline.html) pour **chercher des IOCs définis sur un appareil**.
|
||||
|
||||
### Loki
|
||||
|
||||
[**Loki**](https://github.com/Neo23x0/Loki) est un scanner pour les Simple Indicators of Compromise.\
|
||||
La détection est basée sur quatre méthodes de détection :
|
||||
[**Loki**](https://github.com/Neo23x0/Loki) est un scanner pour des Simple Indicators of Compromise.\
|
||||
La détection se base sur quatre méthodes de détection :
|
||||
```
|
||||
1. File Name IOC
|
||||
Regex match on full file path/name
|
||||
@ -92,41 +92,41 @@ Compares process connection endpoints with C2 IOCs (new since version v.10)
|
||||
```
|
||||
### Linux Malware Detect
|
||||
|
||||
[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) est un scanner de malware pour Linux, publié sous licence GNU GPLv2, conçu pour les menaces rencontrées dans les environnements d'hébergement mutualisé. Il utilise des données de menace provenant de systèmes de détection d'intrusion en périphérie réseau pour extraire les malware activement utilisés dans des attaques et génère des signatures pour leur détection. De plus, des données de menace sont également dérivées des soumissions d'utilisateurs via la fonctionnalité de checkout de LMD et des ressources communautaires sur les malware.
|
||||
[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) est un scanner de malware pour Linux publié sous la licence GNU GPLv2, conçu autour des menaces rencontrées dans les environnements d'hébergement mutualisé. Il utilise des données de menace issues de systèmes de détection d'intrusion en périphérie réseau pour extraire les malware utilisés activement dans des attaques et génère des signatures pour leur détection. De plus, les données de menace proviennent également des soumissions d'utilisateurs via la fonctionnalité LMD checkout et des ressources communautaires sur les malware.
|
||||
|
||||
### rkhunter
|
||||
|
||||
Des outils comme [**rkhunter**](http://rkhunter.sourceforge.net) peuvent être utilisés pour vérifier le système de fichiers à la recherche de possibles **rootkits** et malware.
|
||||
Des outils comme [**rkhunter**](http://rkhunter.sourceforge.net) peuvent être utilisés pour vérifier le système de fichiers à la recherche de rootkits et de malware possibles.
|
||||
```bash
|
||||
sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress]
|
||||
```
|
||||
### FLOSS
|
||||
|
||||
[**FLOSS**](https://github.com/mandiant/flare-floss) est un outil qui tente de trouver des chaînes obfusquées à l'intérieur des exécutables en utilisant différentes techniques.
|
||||
[**FLOSS**](https://github.com/mandiant/flare-floss) est un outil qui va tenter de trouver des chaînes obfuscated à l'intérieur des exécutables en utilisant différentes techniques.
|
||||
|
||||
### PEpper
|
||||
|
||||
[PEpper ](https://github.com/Th3Hurrican3/PEpper) vérifie quelques éléments basiques dans l'exécutable (données binaires, entropie, URLs et IPs, quelques règles yara).
|
||||
[PEpper ](https://github.com/Th3Hurrican3/PEpper) vérifie certaines informations de base à l'intérieur de l'exécutable (binary data, entropy, URLs and IPs, some yara rules).
|
||||
|
||||
### PEstudio
|
||||
|
||||
[PEstudio](https://www.winitor.com/download) est un outil qui permet d'obtenir des informations sur des exécutables Windows tels que imports, exports, headers, mais vérifie aussi virus total et identifie des techniques potentielles d'Att\&ck.
|
||||
[PEstudio](https://www.winitor.com/download) est un outil qui permet d'obtenir des informations sur les exécutables Windows telles que imports, exports, headers, mais il vérifiera aussi virus total et trouvera de potentielles Att\&ck techniques.
|
||||
|
||||
### Detect It Easy(DiE)
|
||||
|
||||
[**DiE**](https://github.com/horsicq/Detect-It-Easy/) est un outil pour détecter si un fichier est **chiffré** et aussi pour trouver des **packers**.
|
||||
[**DiE**](https://github.com/horsicq/Detect-It-Easy/) est un outil pour détecter si un fichier est **encrypted** et aussi trouver des **packers**.
|
||||
|
||||
### NeoPI
|
||||
|
||||
[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) est un script Python qui utilise diverses **méthodes statistiques** pour détecter du contenu **obfusqué** et **chiffré** dans des fichiers texte/script. Le but de NeoPI est d'aider à la **détection de code web shell caché**.
|
||||
[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) est un script Python qui utilise une variété de **méthodes statistiques** pour détecter du contenu **obfuscated** et **encrypted** dans des fichiers texte/script. Le but prévu de NeoPI est d'aider à la **detection of hidden web shell code**.
|
||||
|
||||
### **php-malware-finder**
|
||||
|
||||
[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) fait de son mieux pour détecter du code **obfusqué**/**suspect** ainsi que des fichiers utilisant des fonctions **PHP** souvent utilisées dans des **malwares**/webshells.
|
||||
[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) fait de son mieux pour détecter des **obfuscated**/**dodgy code** ainsi que des fichiers utilisant des fonctions **PHP** souvent utilisées dans des **malwares**/webshells.
|
||||
|
||||
### Apple Binary Signatures
|
||||
|
||||
Lorsque vous examinez un **malware sample**, vous devriez toujours **vérifier la signature** du binaire car le **developer** qui l'a signé peut déjà être **lié** au **malware.**
|
||||
Lors de l'analyse d'un **échantillon de malware** vous devriez toujours **vérifier la signature** du binaire car le **développeur** qui l'a signé peut déjà être **lié** à des **malware**.
|
||||
```bash
|
||||
#Get signer
|
||||
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
|
||||
@ -139,25 +139,25 @@ spctl --assess --verbose /Applications/Safari.app
|
||||
```
|
||||
## Techniques de détection
|
||||
|
||||
### Empilement de fichiers
|
||||
### File Stacking
|
||||
|
||||
Si vous savez qu'un dossier contenant les **fichiers** d'un serveur web a été **mis à jour pour la dernière fois à une certaine date**, **vérifiez** la **date** de création et de modification de **tous les fichiers** du **serveur web** et si une date est **suspecte**, examinez ce fichier.
|
||||
Si vous savez qu'un dossier contenant les **files** d'un **web server** a été **last updated on some date**, vérifiez la **date** de création et de modification de tous les **files** du **web server** ; si une **date** semble **suspicious**, examinez ce file.
|
||||
|
||||
### Lignes de base
|
||||
### Baselines
|
||||
|
||||
Si les fichiers d'un dossier **n'auraient pas dû être modifiés**, vous pouvez calculer le **hash** des **fichiers originaux** du dossier et les **comparer** avec ceux **actuels**. Tout élément modifié sera **suspect**.
|
||||
Si les **files** d'un dossier **shouldn't have been modified**, vous pouvez calculer le **hash** des **original files** du dossier et **compare** ceux-ci avec les versions **current**. Tout élément modifié sera **suspicious**.
|
||||
|
||||
### Analyse statistique
|
||||
### Statistical Analysis
|
||||
|
||||
Lorsque l'information est enregistrée dans des logs, vous pouvez **vérifier des statistiques**, par exemple combien de fois chaque fichier d'un serveur web a été accédé — un web shell peut être parmi les plus accédés.
|
||||
Lorsque l'information est enregistrée dans des **logs**, vous pouvez **check statistics** comme le nombre de fois où chaque **file** du **web server** a été accédé — un **web shell** peut être l'un des plus fréquents.
|
||||
|
||||
---
|
||||
|
||||
### Android in-app native telemetry (no root)
|
||||
|
||||
Sur Android, vous pouvez instrumenter du code natif à l'intérieur du processus de l'application cible en préchargeant une petite librairie de logging avant l'initialisation des autres libs JNI. Cela donne une visibilité précoce sur le comportement natif sans hooks système ni root. Une approche populaire est SoTap : placez libsotap.so pour l'ABI appropriée dans l'APK et injectez un appel System.loadLibrary("sotap") tôt (par ex. initialiseur statique ou Application.onCreate), puis collectez les logs à partir des chemins internes/externes ou en fallback via Logcat.
|
||||
On **Android**, vous pouvez instrumenter du code natif à l'intérieur du processus de l'app cible en préchargeant une petite bibliothèque de logging avant l'initialisation des autres libs **JNI**. Cela offre une visibilité précoce sur le comportement natif sans hooks système globaux ni root. Une approche populaire est **SoTap** : déposer **libsotap.so** pour le bon **ABI** dans l'**APK** et injecter un appel System.loadLibrary("sotap") tôt (p.ex. initialiseur statique ou Application.onCreate), puis collecter les logs depuis des chemins internes/externes ou en fallback via **Logcat**.
|
||||
|
||||
Voir la page Android native reversing pour les détails de configuration et les chemins des logs :
|
||||
See the Android native reversing page for setup details and log paths:
|
||||
|
||||
{{#ref}}
|
||||
../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
|
||||
@ -165,11 +165,11 @@ Voir la page Android native reversing pour les détails de configuration et les
|
||||
|
||||
---
|
||||
|
||||
## Déobfuscation du contrôle de flux dynamique (JMP/CALL RAX Dispatchers)
|
||||
## Deobfuscating Dynamic Control-Flow (JMP/CALL RAX Dispatchers)
|
||||
|
||||
Les familles de malware modernes abusent fortement de l'obfuscation du Control-Flow Graph (CFG) : au lieu d'un jump/call direct, elles calculent la destination à l'exécution et exécutent un `jmp rax` ou `call rax`. Un petit *dispatcher* (typiquement neuf instructions) définit la cible finale en fonction des drapeaux CPU `ZF`/`CF`, rompant complètement la récupération statique du CFG.
|
||||
Modern **malware** families heavily abuse Control-Flow Graph (CFG) obfuscation: instead of a direct jump/call they compute the destination at run-time and execute a `jmp rax` or `call rax`. A small *dispatcher* (typically nine instructions) sets the final target depending on the CPU `ZF`/`CF` flags, completely breaking static CFG recovery.
|
||||
|
||||
La technique — mise en évidence par le loader SLOW#TEMPEST — peut être contrecarrée par un workflow en trois étapes qui ne s'appuie que sur IDAPython et l'émulateur CPU Unicorn.
|
||||
The technique – showcased by the **SLOW#TEMPEST** loader – can be defeated with a three-step workflow that only relies on **IDAPython** and the **Unicorn CPU emulator**.
|
||||
|
||||
### 1. Localiser chaque jump / call indirect
|
||||
```python
|
||||
@ -213,7 +213,7 @@ return mu.reg_read(UC_X86_REG_RAX)
|
||||
```
|
||||
Exécutez `run(code,0,0)` et `run(code,1,1)` pour obtenir les cibles de branche *false* et *true*.
|
||||
|
||||
### 4. Patch back a direct jump / call
|
||||
### 4. Rétablir un jump / call direct
|
||||
```python
|
||||
import struct, ida_bytes
|
||||
|
||||
@ -222,28 +222,37 @@ op = 0xE8 if is_call else 0xE9 # CALL rel32 or JMP rel32
|
||||
disp = target - (ea + 5) & 0xFFFFFFFF
|
||||
ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack('<I', disp))
|
||||
```
|
||||
Après le patch, forcez IDA à ré-analyser la fonction afin que le CFG complet et la sortie Hex-Rays soient restaurés :
|
||||
Après patching, forcez IDA à réanalyser la fonction afin que le CFG complet et la sortie Hex-Rays soient restaurés:
|
||||
```python
|
||||
import ida_auto, idaapi
|
||||
idaapi.reanalyze_function(idc.get_func_attr(ea, idc.FUNCATTR_START))
|
||||
```
|
||||
### 5. Étiqueter les appels API indirects
|
||||
|
||||
Une fois que la destination réelle de chaque `call rax` est connue, vous pouvez indiquer à IDA de quoi il s'agit afin que les types de paramètres et les noms de variables soient récupérés automatiquement :
|
||||
Une fois que la véritable destination de chaque `call rax` est connue, vous pouvez indiquer à IDA ce dont il s'agit afin que les types de paramètres et les noms de variables soient récupérés automatiquement :
|
||||
```python
|
||||
idc.set_callee_name(call_ea, resolved_addr, 0) # IDA 8.3+
|
||||
```
|
||||
### Avantages pratiques
|
||||
|
||||
* Restaure le vrai CFG → la decompilation passe de *10* lignes à des milliers.
|
||||
* Permet string-cross-reference & xrefs, rendant la reconstruction du comportement triviale.
|
||||
* Les Scripts sont réutilisables : déposez-les dans n'importe quel loader protégé par le même trick.
|
||||
* Restaure le vrai CFG → la décompilation passe de *10* lignes à des milliers.
|
||||
* Permet le string-cross-reference & les xrefs, rendant la reconstruction du comportement triviale.
|
||||
* Les scripts sont réutilisables : placez-les dans n'importe quel loader protégé par la même astuce.
|
||||
|
||||
---
|
||||
|
||||
## AdaptixC2: Extraction de configuration et TTPs
|
||||
|
||||
Voir la page dédiée :
|
||||
|
||||
{{#ref}}
|
||||
adaptixc2-config-extraction-and-ttps.md
|
||||
{{#endref}}
|
||||
|
||||
## Références
|
||||
|
||||
- [Unit42 – Evolving Tactics of SLOW#TEMPEST: A Deep Dive Into Advanced Malware Techniques](https://unit42.paloaltonetworks.com/slow-tempest-malware-obfuscation/)
|
||||
- SoTap: Lightweight in-app JNI (.so) behavior logger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
|
||||
- SoTap : enregistreur léger de comportement JNI in-app (.so) – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
|
||||
- [Unit42 – AdaptixC2: A New Open-Source Framework Leveraged in Real-World Attacks](https://unit42.paloaltonetworks.com/adaptixc2-post-exploitation-framework/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user