k0nsult.cloud / ai-truth / ipIII / playbook-reverse
Playbook — analiza malware / reverse engineering / deobfuskacja
Metodyka defensywna (IR / vuln-research / threat-intel) prowadzona wyłącznie po podpisanym RoE. To playbook dowodowy: opisuje kolejność kroków analizy oraz jaki artefakt dowodowy powstaje w ipIII na każdym etapie. Zero payloadów, zero instrukcji ofensywnych, zero technik łamania zabezpieczeń — to analiza i dowód, nie atak.
Pozycjonowanie — czym ipIII NIE jest. ipIII nie jest disassemblerem, deobfuscatorem, debuggerem ani sandboxem.
ipIII to warstwa EVIDENCE-FIRST nad warsztatem reverse engineeringu analityka
(Ghidra, IDA Pro, radare2/rizin, Binary Ninja, x64dbg, YARA, CAPA, FLOSS, PEiD / Detect-It-Easy).
ipIII orkiestruje dowody pochodzące z tych narzędzi: custody próbki (hash sha256/md5, chain-of-custody),
import findingów z narzędzi RE, rejestr IOC/YARA, mapowanie MITRE ATT&CK, log kroków deobfuskacji,
custody artefaktów (rozpakowana binarka), evidence-package + legal triggers (NIS2 / DORA dla incydentów malware).
Praca defensywna / IR / vuln-research wyłącznie po podpisanym RoE. Overclaim-lint zabrania fraz
„certyfikacja / 100% bezpieczny / produkcyjny bankowy" bez jawnego zaprzeczenia. Doktryna claim ≤ proof.
Reverse engineering nie kończy się na zrozumieniu binarki — kończy się na dowodzie z zachowanym łańcuchem custody.
Analityk pracuje w swoim warsztacie RE (Ghidra, IDA, radare2, x64dbg, YARA, CAPA, FLOSS, DIE). ipIII przyjmuje z tego warsztatu dowody: hashe, findingi, IOC, techniki ATT&CK, log deobfuskacji, artefakty rozpakowania — i wiąże je w evidence-package z chain-of-custody oraz mapą obowiązków prawnych. Bez RoE nie ma analizy; bez custody nie ma dowodu.
Warsztat analityka vs. warstwa dowodowa ipIII
| Funkcja | Narzędzie RE analityka (poza ipIII) | Dowód wiązany w ipIII |
|---|
| Disasembler / dekompilacja | Ghidra, IDA Pro, Binary Ninja, radare2/rizin | finding (import) + odwołanie do artefaktu, nie sam kod |
| Debugger dynamiczny | x64dbg, WinDbg, gdb | obserwacje behawioralne → IOC + log kroków |
| Sandbox / detonacja | izolowany lab (offline VM), sandbox behawioralny | IOC (C2/mutex/pliki/klucze) + capture w custody |
| Identyfikacja / entropia | Detect-It-Easy (DIE), PEiD, file | metadane próbki + wskaźnik pakowania (finding) |
| Sygnatury / capabilities | YARA, CAPA, FLOSS | rejestr YARA/IOC + mapowanie capabilities → ATT&CK |
ipIII nie uruchamia disassemblera ani sandboxa — przyjmuje i wiąże dowody, które analityk wytwarza w swoim warsztacie. To rozdział ról: narzędzie RE = analiza; ipIII = custody, rejestr, mapowanie, pakiet dowodowy, obowiązki prawne.
Metodyka — 8 kroków (0–7)
0 RoE + CUSTODY→1 TRIAGE→2 STATYCZNA→3 DEOBFUSKACJA→4 DYNAMICZNA→5 KLASYFIKACJA→6 DOWÓD + LEGAL→7 ZAMKNIĘCIE
Krok 0 — Warunki wstępne: RoE + izolacja + custody próbki.
Podpisany
Rules of Engagement i jasny zakres. Środowisko
izolowane: offline VM / lab bez dostępu do sieci produkcyjnej i realnych celów. Rejestracja custody próbki:
hash sha256 + md5, znacznik czasu, kto/kiedy przejął, źródło pochodzenia.
Narzędzia: sha256sum / md5sum, izolowana VM (snapshot), rejestr custody. Dowód w ipIII: rekord custody próbki (sha256 + md5 + timestamp + operator) → POST /api/ip3/v1/evidence, chain-of-custody zainicjowany. Bez RoE krok nie startuje.
Krok 1 — Triage: identyfikacja pliku i wstępne wskaźniki.
Rozpoznanie typu (magic bytes / DIE / PEiD), pomiar entropii (wskaźnik pakowania/kompresji/szyfrowania), odczyt metadanych formatu (nagłówki PE / ELF / Mach-O, sekcje, kompilator, timestamp). Bez uruchamiania próbki.
Narzędzia: Detect-It-Easy (DIE), PEiD, file, pehashng / narzędzia entropii. Dowód w ipIII: finding „identyfikacja + entropia + metadane" dowiązany do custody próbki; wysoka entropia = flaga „prawdopodobne pakowanie" (do kroku 3).
Krok 2 — Analiza statyczna (bez uruchamiania).
Ekstrakcja stringów (w tym zaciemnionych — FLOSS), przegląd importów/eksportów, sekcji, dopasowanie reguł YARA, wykrycie zdolności (CAPA → capabilities mapowane na ATT&CK). Wszystko statycznie, próbka pozostaje nieuruchomiona.
Narzędzia: FLOSS (strings), YARA, CAPA, Ghidra / IDA / radare2 (przegląd importów, sekcji, dekompilacja). Dowód w ipIII: findingi statyczne + trafienia YARA do rejestru IOC/YARA; capabilities CAPA → wstępne mapowanie MITRE ATT&CK.
Krok 3 — Deobfuskacja / unpacking (w izolacji).
Rozpoznanie techniki zaciemnienia (packer typu UPX, kodowanie XOR / base64 / RC4 na warstwie stringów, control-flow flattening, string encryption). Rozpakowanie w izolowanym labie, custody artefaktu rozpakowanego (nowy hash sha256/md5 osobno od próbki źródłowej), log kolejnych kroków deobfuskacji (co, czym, z jakim wynikiem). Metodyka, nie recepta ofensywna.
Narzędzia: UPX (unpack), x64dbg (dump po rozpakowaniu w pamięci), Ghidra / radare2 (analiza po deobfuskacji), skrypty dekodujące w labie. Dowód w ipIII: log kroków deobfuskacji + custody artefaktu rozpakowanego (nowy hash) jako osobny rekord evidence powiązany z próbką źródłową.
Krok 4 — Analiza dynamiczna (opcjonalnie, izolowany sandbox).
Obserwacja zachowania w izolowanym środowisku: IOC — adresy C2, mutexy, tworzone/modyfikowane pliki, klucze rejestru, przechwycenie ruchu sieciowego (network capture) w labie. Wyłącznie w labie, zero realnych celów, sieć symulowana/odcięta.
Narzędzia: izolowany sandbox behawioralny, x64dbg / WinDbg, monitor procesów/rejestru, przechwytywanie ruchu w labie. Dowód w ipIII: IOC (C2 / mutex / pliki / klucze rejestru) do rejestru IOC; capture i obserwacje w custody. Krok opcjonalny — pomijany, gdy RoE nie dopuszcza detonacji.
Krok 5 — Klasyfikacja i mapowanie.
Werdykt:
malicious / suspicious / benign + poziom pewności (confidence). Mapowanie zachowań i zdolności na
MITRE ATT&CK (taktyki/techniki). Nadanie severity
P0–
P3.
Narzędzia: macierz MITRE ATT&CK, korelacja findingów statyczno-dynamicznych, opcjonalnie judge-panel dla werdyktu adwersaryjnego. Dowód w ipIII: klasyfikacja + confidence + techniki ATT&CK dowiązane do incydentu; severity determinuje zegary prawne kroku 6.
Krok 6 — Dowód i raport: evidence-package + legal triggers.
Złożenie
evidence-package: artefakty + hashe + chain-of-custody + manifest (
package_sha256). Uruchomienie
Legal Trigger Engine: jeśli malware wiąże się z
incydentem operacyjnym — obowiązki
NIS2 (24h / 72h) i
DORA z zegarami (deadline liczony od stwierdzenia). Wpis IOC do threat-intel.
Narzędzia: ipIII evidence-package (GET /reports/evidence-package/:id), Legal Trigger Engine (/incidents/:id/legal-triggers), rejestr IOC/threat-intel. Dowód w ipIII: pakiet dowodowy PDF/JSON z manifestem i hashem + mapa obowiązków NIS2/DORA (DECISION-SUPPORT, nie porada prawna).
Krok 7 — Zamknięcie: retest, lessons learned, zachowanie custody.
Weryfikacja / retest wniosków (np. potwierdzenie sygnatur YARA na nowej próbce, powtarzalność deobfuskacji), lessons learned, trwałe zachowanie chain-of-custody wszystkich artefaktów. Zamknięcie zgodnie z regułą
close-with-evidence — bez potwierdzonego dowodu incydent nie zostaje zamknięty.
Narzędzia: retest YARA/CAPA, weryfikacja hashy custody, procedura Response & Retest. Dowód w ipIII: retest → CONFIRMED → close; evidence-package odzwierciedla stan końcowy (nowy package_sha256), custody nienaruszony.
Techniki zaciemnienia — rozpoznanie (nie recepta)
Poniższa tabela służy rozpoznaniu techniki na potrzeby analizy defensywnej i logu deobfuskacji. Nie zawiera instrukcji tworzenia zaciemnienia ani obchodzenia zabezpieczeń.
| Technika | Wskaźnik przy analizie | Rola w dowodzie ipIII |
|---|
| Packer (np. UPX) | wysoka entropia, mała liczba importów, charakterystyczne sekcje | flaga „pakowane" → log unpackingu + custody artefaktu rozpakowanego |
| Kodowanie stringów (XOR / base64 / RC4) | brak czytelnych stringów, FLOSS ujawnia zdekodowane | log kroków dekodowania (co → wynik), bez publikacji klucza jako recepty |
| Control-flow flattening | spłaszczony graf przepływu, dispatcher-switch w dekompilacji | obserwacja w findingu statycznym, notatka metodyczna |
| String encryption / anti-analysis | szyfrowane zasoby, wykrywanie debuggera/VM | finding + wpływ na wybór ścieżki (statyczna vs. izolowana dynamiczna) |
Obowiązki prawne — kiedy malware = incydent
| Warunek | Flaga | Obowiązek (ramka / norma) |
|---|
| Malware wywołał incydent u podmiotu kluczowego/ważnego | NIS2_RELEVANT | Wczesne ostrzeżenie do CSIRT w 24h → zgłoszenie 72h → raport końcowy |
| Incydent ICT w podmiocie finansowym | DORA_RELEVANT | Klasyfikacja i zgłoszenie wg DORA art. 19 (major ICT-related incident) |
| Dostęp/eksfiltracja danych osobowych | GDPR_BREACH | Art. 33 — zgłoszenie do PUODO w 72h; art. 34 przy wysokim ryzyku |
| Przestępstwo komputerowe | LAW_ENFORCEMENT | Zawiadomienie organów ścigania, zabezpieczenie dowodów (chain-of-custody) |
Uwaga: ramki NIS2 / DORA / RODO to treść regulacji (norma), nie konkretny incydent. Legal Trigger Engine działa w trybie DECISION-SUPPORT — terminy orientacyjne, nie porada prawna. Zegar liczony od momentu stwierdzenia (krok 5 klasyfikacja / krok 6).
Granica etyczna — co ten playbook robi i czego nie robi
Robi DEFENSYWNE
Analiza próbki, custody, deobfuskacja w izolacji dla zrozumienia zagrożenia, IOC do obrony, mapowanie ATT&CK, evidence-package, obowiązki prawne. Wszystko po RoE.
Nie robi OFENSYWNE
Zero payloadów, zero instrukcji „jak złamać zabezpieczenie", zero tworzenia malware, zero detonacji wobec realnych celów, zero działań poza RoE.
Rozdział ról
Warsztat RE (Ghidra/IDA/x64dbg/YARA/CAPA/FLOSS/DIE) = analiza po stronie analityka. ipIII = custody + rejestr + mapowanie + dowód.
Reguła dowodu
claim ≤ proof. Bez custody nie ma dowodu; bez potwierdzonego dowodu incydent nie zostaje zamknięty (close-with-evidence).
Powiązane strony
Reverse / RE — moduł
Warstwa dowodowa RE w ipIII. → /reverse
Rules of Engagement
Warunek startu analizy. → RoE
Disclaimer. Playbook opisuje metodykę defensywną reverse engineeringu i analizy malware prowadzoną wyłącznie po podpisanym RoE w izolowanym środowisku. Nie zawiera payloadów, instrukcji ofensywnych ani technik łamania/obchodzenia zabezpieczeń. ipIII nie jest disassemblerem, deobfuscatorem, debuggerem ani sandboxem — jest warstwą evidence-first (custody, rejestr IOC/YARA, mapowanie ATT&CK, evidence-package, legal triggers) nad warsztatem RE analityka. Overclaim-lint zabrania deklaracji „certyfikacja / 100% bezpieczny / produkcyjny bankowy" bez zaprzeczenia.