Analiza złośliwego oprogramowania z użyciem AI wymaga pakietów dowodowych

Zane St. John kupił tani projektor z Androidem, zauważył podejrzany ruch DNS i wykorzystał Claude Code jako asystenta do inżynierii wstecznej, aby sprawdzić aplikacje preinstalowane na urządzeniu.¹

Najciekawsze nie jest to, że agent AI pomógł w analizie złośliwego oprogramowania. To twierdzenie szybko przestanie robić wrażenie. Ważniejszy jest kształt artefaktu: zaobserwowane zachowanie sieciowe, nazwy pakietów, zdekompilowane ścieżki kodu, wyniki poleceń, notatki i wskaźniki, które człowiek może samodzielnie sprawdzić. Analiza złośliwego oprogramowania z użyciem agentów staje się godna zaufania dopiero wtedy, gdy wynik mniej przypomina odpowiedź, a bardziej akta sprawy.

Analiza złośliwego oprogramowania z użyciem AI wymaga pakietów dowodowych. Agenci mogą przyspieszyć rozpakowywanie, dekompilację, wyszukiwanie, streszczanie i generowanie hipotez. Zanim jednak analityk zaufa wnioskowi, nadal potrzebne są hashe, wersje narzędzi, polecenia, wyodrębnione wskaźniki, ścieżki źródłowe, oznaczenia niepewności oraz ścieżki od twierdzenia do dowodu.

W skrócie

Microsoft Research opisuje Project Ire jako autonomicznego agenta do klasyfikacji złośliwego oprogramowania, który wykonuje inżynierię wsteczną oprogramowania i tworzy łańcuch dowodowy, zanim walidator zdecyduje, czy istnieje wystarczające uzasadnienie dla werdyktu o złośliwości.² Dochodzenie Zane’a dotyczące projektora z Androidem pokazuje ten sam wzorzec w mniejszej skali: agent może pomóc pojedynczemu analitykowi przejść przez pliki APK, logi, ciągi znaków i podejrzane ścieżki kodu.¹

Wniosek produktowy jest wąski. Analityka złośliwego oprogramowania oparta na AI należy traktować jak stanowisko pracy, a nie jak autorytet. Takie stanowisko może wydobywać, porządkować i łączyć dowody. Nie powinno kontaktować się z aktywną infrastrukturą, pisać klientów do wykorzystania podatności, uruchamiać nieznanych ładunków na zwykłej stacji roboczej ani zastępować ludzkiego osądu dotyczącego skutków. Użytecznym wynikiem jest pakiet dowodowy, który recenzent może odtworzyć.

Najważniejsze wnioski

Dla zespołów bezpieczeństwa: - Należy prosić agentów o pakiety dowodowe, a nie o werdykty. - Tożsamość próbki, logi poleceń, wersje narzędzi, wyodrębnione wskaźniki i uzasadnienia twierdzeń należy trzymać razem. - Przed jakimkolwiek wykonaniem dynamicznym, kontaktem sieciowym lub analizą z użyciem danych uwierzytelniających wymagana powinna być akceptacja człowieka.

Dla twórców agentów: - Domyślnym trybem przepływów pracy do analizy złośliwego oprogramowania powinna być statyczna analiza tylko do odczytu. - Wyodrębnianie, hipotezy, weryfikację i raportowanie należy rozdzielić na osobne kroki. - Surowe artefakty i lokalizacje źródłowe trzeba zachowywać tak, aby człowiek mógł skontrolować cały łańcuch.

Dla zespołów produktowych: - Nie należy sprzedawać „autonomicznej analizy złośliwego oprogramowania” jako magii. - Trzeba pokazać, co agent sprawdził, co wywnioskował, czego nie zweryfikował i co nadal musi rozstrzygnąć człowiek. - Pakiety przeglądowe warto zbudować wcześniej niż efektowne pulpity.

Co pokazuje przypadek projektora z Androidem

Dochodzenie St. Johna zaczęło się od zaobserwowanego zachowania: żądań DNS wysyłanych przez projektor jeszcze przed normalnym użyciem.¹ To ważne, ponieważ źródłem podejrzenia było urządzenie, a nie model. Agent pojawił się dopiero wtedy, gdy analityk miał już pytanie warte zbadania.

Dalszy przepływ pracy przeszedł przez typowe powierzchnie inżynierii wstecznej:

Artykuł wymienia popularne narzędzia do inżynierii wstecznej Androida, takie jak adb i jadx.¹ Same narzędzia nie sprawiają, że wniosek staje się prawdziwy. Sprawiają, że artefakt da się sprawdzić. jadx opisuje się jako dekompilator z interfejsem wiersza poleceń i GUI, który konwertuje pliki Android Dex i APK na kod źródłowy Java oraz potrafi dekodować zasoby Androida.³ Apktool opisuje się jako narzędzie do inżynierii wstecznej plików Android APK, obejmujące manifest, zasoby, smali i przepływy odbudowy.⁴

Przewaga agenta pojawia się pośrodku procesu. Może przeszukiwać nieznane pakiety, streszczać kod, proponować prawdopodobne obszary do inspekcji i prowadzić listę zadań. Analityk nadal musi zweryfikować każde twierdzenie względem pierwotnego artefaktu.

AI zmienia inżynierię wsteczną w zarządzanie sprawą

Tradycyjna analiza złośliwego oprogramowania już teraz tworzy akta sprawy. Mogą się w nich znaleźć hashe, pochodzenie próbki, ciągi znaków, domeny, adresy IP, mutexy, klucze rejestru, ścieżki plików, zrzuty ekranu, notatki z dezasemblacji, wynik z sandboxa i końcowy werdykt.

Agenci zmieniają tempo i skalę tej pracy. Mogą czytać więcej plików, pisać więcej notatek i tworzyć więcej hipotez, niż pojedynczy analityk wpisałby ręcznie. Bez mocniejszego kontraktu na wynik ta prędkość tworzy problem zaufania. Pewne siebie streszczenie może ukryć błędne wnioskowanie, pominiętą gałąź albo zmyśloną nazwę API.

Project Ire Microsoftu wskazuje lepszy kierunek. Microsoft twierdzi, że system autonomicznie analizuje i klasyfikuje oprogramowanie oraz buduje łańcuch dowodowy dla swoich ustaleń.² Projekt obejmuje narzędzia do inżynierii wstecznej oraz walidator, który sprawdza, czy dowody wspierają werdykt.² Sama idea walidatora jest ważniejsza niż nazwa marki. Analiza złośliwego oprogramowania potrzebuje osobnego sędziego dla dowodów, a nie tylko płynnego narratora wniosku.

Taki sam podział warto stosować w mniejszych przepływach pracy:

Agent może zrobić dużo. Bramka decyduje, czemu warto uwierzyć.

Android ma użyteczne powierzchnie statyczne

Analiza złośliwego oprogramowania na Androidzie ma praktyczną przewagę: APK udostępniają kilka powierzchni statycznych, zanim ktokolwiek uruchomi aplikację.

Dokumentacja bezpieczeństwa Androida wymienia kategorie ryzyka takie jak komunikacja jawnym tekstem, dynamiczne ładowanie kodu, niebezpieczne broadcast receivery, zahardkodowane sekrety i błędy związane z uprawnieniami.⁵ MITRE ATT&CK for Mobile obejmuje techniki takie jak Broadcast Receivers oraz pobieranie nowego kodu w czasie działania, co daje analitykom słownik do mapowania zaobserwowanego zachowania na techniki atakujących.⁶

Dlatego pakiet dowodowy zaczynający od analizy statycznej jest wartościowy:

Tabela unika ważnego błędu: nie prosi modelu, aby najpierw zdecydował „złośliwe czy nie”. Prosi system o zachowanie dowodów, dzięki którym werdykt będzie później możliwy do sprawdzenia.

Pakiet dowodowy

Użyteczny pakiet analizy złośliwego oprogramowania z użyciem AI powinien mieć przewidywalny kształt:

Sercem pakietu jest mapa twierdzeń:

Ostatni wiersz chroni analityka. Werdykty dotyczące złośliwego oprogramowania mają konsekwencje. Fałszywy alarm może zaszkodzić dostawcy albo utrudnić reakcję na incydent. Fałszywie negatywny wynik może zostawić użytkownika narażonego. Model nie powinien dostawać skrótu omijającego dowody.

Czego agent powinien odmówić

Praca ze złośliwym oprogramowaniem wymaga granic odmowy nawet wtedy, gdy cel jest defensywny.

Agent powinien odmówić albo wymagać jednoznacznej autoryzacji człowieka przed:

• kontaktem z aktywną infrastrukturą command-and-control;
• napisaniem klienta dla podejrzanego backdoora lub mechanizmu aktualizacji;
• pobieraniem ładunków drugiego etapu z infrastruktury kontrolowanej przez atakującego;
• uruchomieniem nieznanej próbki poza izolowanym laboratorium;
• użyciem prawdziwych danych uwierzytelniających użytkownika, kont osobistych lub sieci produkcyjnych podczas analizy;
• publikacją aktywnych wskaźników, które mogą zidentyfikować ofiarę przed odpowiedzialnym ujawnieniem;
• przekształceniem defensywnego dochodzenia w instrukcje wykorzystania podatności.

Dokumentacja OpenAI dotycząca lokalnej powłoki ostrzega, że pozwalanie agentom na uruchamianie dowolnych poleceń powłoki może być niebezpieczne, i zaleca sandboxing albo ścisłe listy dozwolonych i zabronionych działań przed przekazaniem poleceń do powłoki.⁷ Przewodnik Anthropic z najlepszymi praktykami dla Claude Code podkreśla kryteria weryfikacji i zarządzanie kontekstem w pracy agentów.⁸ Analiza złośliwego oprogramowania potrzebuje obu elementów: limitów poleceń przed działaniem i limitów dowodowych przed wiarą w wniosek.

Granica odmowy powinna pojawić się już w samym zadaniu:

Przeanalizuj ten APK statycznie.
Nie uruchamiaj go.
Nie kontaktuj się ze zdalną infrastrukturą.
Nie pisz kodu exploita ani klienta.
Zwróć wyłącznie dowody ze ścieżkami plików, poleceniami i oznaczeniami pewności.
Oznacz każde niepoparte twierdzenie jako niezweryfikowane.

Taka instrukcja sama w sobie nie czyni przepływu pracy bezpiecznym. Daje jednak punkt zaczepienia, który mechanizmy egzekwujące, sandboxy i recenzenci mogą konkretnie sprawdzać.

Werdykt nadal należy do człowieka

Agent AI może oszczędzić wiele godzin w sesji analizy złośliwego oprogramowania. Może przejść od sterty plików APK do krótkiej listy podejrzanych pakietów. Może streszczać klasy, rozpakowywać filtry intentów, identyfikować ciągi konfiguracyjne i przygotować szkic raportu. Te zyski mają znaczenie.

Werdykt nie powinien należeć do agenta.

Do analityka należą:

• autoryzacja analizy próbki;
• decyzja o uruchomieniu czegokolwiek dynamicznie;
• interpretacja intencji i skutków;
• komunikacja z dotkniętymi dostawcami, użytkownikami lub platformami;
• decyzje dotyczące naprawy i ujawnienia;
• ostateczne brzmienie raportu.

Taki podział utrzymuje użyteczność agenta. Model wykonuje męczącą pracę łączenia faktów. Człowiek zachowuje odpowiedzialność etyczną, prawną i kontekstową.

Jak zbudować przepływ pracy

Warto zacząć od małej pętli analizy statycznej:

1. Wyliczyć hash próbki i zapisać jej pochodzenie.
2. Wyodrębnić manifest, zasoby, ciągi znaków i zdekompilowany kod do katalogu roboczego tylko do odczytu.
3. Poprosić agenta o utworzenie listy ustaleń z lokalizacjami źródłowymi.
4. W drugim przebiegu poprosić o zakwestionowanie każdego ustalenia i oznaczenie twierdzeń bez poparcia.
5. Zbudować pakiet dowodowy.
6. Zdecydować, czy pakiet uzasadnia analizę dynamiczną w laboratorium.

Polecenie dla agenta powinno wymagać uporządkowanego wyniku:

Dla każdego ustalenia podaj:
- twierdzenie
- ścieżkę artefaktu
- polecenie, które wytworzyło artefakt
- fragment źródłowy lub symbol
- poziom pewności
- co obaliłoby twierdzenie
- czy wymagana jest analiza dynamiczna

Taki wynik brzmi mniej efektownie niż „projektor ma złośliwe oprogramowanie”. Jest za to znacznie bardziej użyteczny.

Próg dowodowy ma tu bezpośrednie zastosowanie. Twierdzenie bez dowodu nie powinno trafiać do końcowej odpowiedzi. Pakiety przeglądowe są nową odpowiedzią końcową także pasują do tego problemu: rezultatem nie jest streszczenie prozą, lecz pakiet, który pozwala innej osobie zweryfikować pracę.

FAQ

Czy agenci AI potrafią analizować złośliwe oprogramowanie?

Tak, w określonych granicach. Agenci mogą pomagać w analizie statycznej, streszczaniu, poruszaniu się po dekompilacji, wyodrębnianiu wskaźników i szkicowaniu raportów. Nie powinni jednak stać się ostatecznym autorytetem dla werdyktów dotyczących złośliwego oprogramowania bez odtwarzalnych dowodów i przeglądu człowieka.

Czy używanie Claude Code albo Codex do analizy złośliwego oprogramowania jest bezpieczne?

Tylko w kontrolowanym defensywnym przepływie pracy. Nie należy uruchamiać nieznanych próbek na zwykłej stacji roboczej, kontaktować się z aktywną infrastrukturą ani dawać agentowi danych uwierzytelniających czy nieograniczonego dostępu do powłoki lub sieci. Bezpieczniejszym punktem startowym jest analiza statyczna w izolowanym katalogu roboczym.

Co powinien zawierać pakiet dowodowy analizy złośliwego oprogramowania?

Co najmniej: hashe, źródło próbki, wersje narzędzi, polecenia, fakty z manifestu, wyodrębnione wskaźniki, lokalizacje kodu, mapę twierdzeń do dowodów, oznaczenia pewności i listę pracy niezweryfikowanej.

Czy werdykt AI liczy się jako dowód?

Nie. Wypowiedź modelu jest interpretacją. Dowody pochodzą z artefaktów: hashy, logów, poleceń, ścieżek kodu, manifestów, zaobserwowanego zachowania sieciowego i odtwarzalnych kroków analizy.

Czy agenci powinni mapować ustalenia na MITRE ATT&CK?

Tak, gdy dowody wspierają takie mapowanie. Etykieta techniki bez wsparcia w artefaktach staje się dekoracją. ATT&CK Mobile należy traktować jako słownik, a nie zamiennik dowodu.⁶

Zakończenie

AI nie usuwa analityka z analizy złośliwego oprogramowania. Zmienia to, czego analityk powinien wymagać.

Słabym wynikiem jest pewny siebie werdykt. Mocnym wynikiem jest odtwarzalny pakiet: tożsamość próbki, polecenia, artefakty, wskaźniki, poparcie twierdzeń, niepewność i następne działanie.

Agenci mogą przyspieszyć inżynierię wsteczną. Pakiety dowodowe sprawiają, że staje się godna zaufania.

Źródła