Invoker – Narzędzia do automatyzacji testów penetracyjnych w Burp Suite (na przykładzie dosfiner)

Rozszerzenie Invoker do Burp Suite – co to takiego?

Invoker to rozszerzenie dla Burp Suite, które automatyzuje testy penetracyjne z użyciem zewnętrznych narzędzi. Integruje popularne programy, takie jak dosfiner, sqlmap, nuclei, ffuf i tplmap bezpośrednio z interfejsem Burpa. Dzięki temu pentesterzy mogą uruchamiać te narzędzia jednym kliknięciem, przekazując dane z aktualnego żądania HTTP.

Rozszerzenie rozwiązuje powszechny problem ręcznego kopiowania adresów URL, nagłówków czy ciasteczek sesyjnych do konsoli – zamiast tego automatycznie buduje odpowiednie komendy. Pozwala to oszczędzić czas i zminimalizować ryzyko błędów, usprawniając cały workflow testera. Podobnie jak „Invoke Applications” z OWASP ZAP, Invoker znacząco przyspiesza proces wykrywania podatności.

W trakcie moich badań natknąłem się na inne rozszerzenie o nazwie the-burp-extension-no-one-told-you-about. Jednak Invoker wyróżnia się prostą konfiguracją oraz możliwością masowego generowania poleceń CLI (z uwzględnieniem ważnej sesji) bezpośrednio z poziomu Burpa.

Konfiguracja InvokerConfig.json

Sercem działania Invokera jest plik konfiguracyjny w formacie JSON o nazwie InvokerConfig.json. Każdy wpis definiuje:

• tool – nazwę narzędzia (np. dosfiner, sqlmap),
• name – etykietę wyświetlaną w menu kontekstowym Burpa,
• template – wzorzec komendy z tzw. placeholderami (np. {{URL}}, {{BODY}}).

Te znaczniki w podwójnych nawiasach klamrowych są automatycznie zastępowane danymi z wybranego żądania HTTP. Do najczęściej używanych placeholderów należą:

• {{HOST}}, {{URL}} – host lub pełny adres URL,
• {{PROTOCOL}} – zwraca „http” lub „https”,
• {{PORT}} – numer portu,
• {{RAW_PATH}} – ścieżka do zapisanego żądania RAW,
• {{HEADERS[-H]}} – wszystkie nagłówki z prefiksem (np. -H),
• {{BODY}} – treść żądania (np. w metodzie POST),
• {{FORCE_SSL}} – np. --force-ssl do wymuszenia HTTPS,
• {{FFUF_URL}} – specjalny adres z placeholderem FUZZ dla ffuf,
• {{OUTPUT}} – plik wyjściowy dla wyników,
• {{METHOD_SWITCH}} – np. -g dla GET lub -p dla POST.

Dzięki temu można zdefiniować polecenie o praktycznie dowolnej strukturze. Przykładowy fragment InvokerConfig.json może wyglądać następująco:

[
  {
    "global_raw_folder": "/tmp/{{HOST}}"
  },
  {
    "name": "dosfiner auto GET/POST",
    "tool": "dosfiner",
    "template": "go run dosfiner.go {{METHOD_SWITCH}} -u \"{{URL}}\" -d \"{{BODY}}\" {{FORCE_SSL}} {{HEADERS[-H]}} -t 999 -proxy \"http://127.0.0.1:8080\""
  },
  {
    "name": "dosfiner raw (-r) Best for Other methods and File Uploads",
    "tool": "dosfiner",
    "template": "go run dosfiner.go -r \"{{RAW_PATH}}\" -t 500 -proxy \"http://127.0.0.1:8080\" {{FORCE_SSL}}"
  },
  {
    "name": "dosfiner raw (-r) in Bash loop (1000x)",
    "tool": "dosfiner",
    "template": "for i in {1..1000}; do\n  go run dosfiner.go -r \"{{RAW_PATH}}\" -t 9999 {{FORCE_SSL}} \n done"
  },
  {
    "name": "sqlmap auto",
    "tool": "sqlmap",
    "template": "sqlmap -u \"{{URL}}\" {{HEADERS[-H]}} --batch --level=5 --risk=3 --tables"
  },
  {
    "name": "sqlmap -r raw request",
    "tool": "sqlmap",
    "template": "sqlmap -r \"{{RAW_PATH}}\" --level 5 --risk 3 {{FORCE_SSL}} --batch --tables"
  },
  {
    "name": "FFUF fuzz",
    "tool": "ffuf",
    "template": "ffuf -u \"{{FFUF_URL}}\" -w /path/to/wordlist.txt -mc 200,403"
  },
  {
    "name": "nuclei normal",
    "tool": "nuclei",
    "template": "nuclei -target \"{{URL}}\" -o \"{{OUTPUT}}\""
  },
  {
    "name": "tplmap basic",
    "tool": "tplmap",
    "template": "tplmap -u \"{{URL}}\" --random-agent"
  },
  {
    "name": "nikto http/https",
    "tool": "nikto",
    "template": "nikto -host \"{{HOST}}\" -port \"{{PORT}}\""
  },
  {
    "name": "nmap basic",
    "tool": "nmap",
    "template": "nmap -p- -sV -sC -Pn --script vuln {{HOST}} -oA \"{{OUTPUT}}\""
  },
  {
    "name": "nikto protocol-based",
    "tool": "nikto",
    "template": "nikto -host \"{{PROTOCOL}}://{{HOST}}:{{PORT}}\""
  }
]Code language: JSON / JSON with Comments (json)

Kilka słów o narzędziu Dosfiner

Dosfiner – narzędzie do testowania wrażliwości na ataki DoS

Dosfiner to narzędzie zaprojektowane w celu identyfikacji podatności typu Denial of Service (DoS), poprzez automatyzację różnych technik tego typu ataków. Umożliwia testerowi symulowanie różnych scenariuszy DoS i obserwację, jak aplikacja docelowa zachowuje się pod wpływem dużego obciążenia lub złośliwego ruchu. Dosfiner obsługuje zarówno ataki wolumetryczne (np. zalewanie ruchem HTTP), jak i ataki na warstwę aplikacji, wykorzystujące konkretne słabości. Oto kilka przykładów testów możliwych do przeprowadzenia przy użyciu Dosfiner:

Flooding

To klasyczna forma ataku DoS – polega na zalaniu serwera ogromną liczbą żądań w krótkim czasie. Dosfiner potrafi generować setki, a nawet tysiące żądań HTTP na sekundę (GET lub POST) do wskazanego endpointu, symulując atak typu HTTP Flood.

Celem testu jest sprawdzenie, czy serwer przestaje odpowiadać, znacząco się spowalnia lub zaczyna odrzucać żądania pod dużym obciążeniem. Jeśli aplikacja nie posiada mechanizmów kontroli przepustowości lub nie jest odpowiednio skalowalna, taki test może doprowadzić do wzrostu czasów odpowiedzi lub nawet awarii. Dosfiner raportuje m.in. liczbę żądań zakończonych sukcesem, błędem lub timeoutem – co pomaga określić moment, w którym usługa została przeciążona.

Atak na powolne endpointy

Niektóre funkcjonalności aplikacji webowych są z natury powolne (np. generowanie raportów lub złożone zapytania do bazy danych). Wykorzystując te operacje można wywołać DoS. Dosfiner potrafi zidentyfikować wolno działające endpointy i wysłać do nich równoległe żądania, potęgując efekt przeciążenia.

Jeśli jedno żądanie zajmuje serwerowi 5 sekund, to wysłanie 10–20 takich żądań jednocześnie może wyczerpać pulę wątków lub zasobów CPU. Takie atak powoduje wyczerpanie zasobów wykorzystując do tego legalne operacje .

Nadużycie uploadu plików

Popularnym wektorem ataku DoS jest masowe przesyłanie dużych plików. Dosfiner może zautomatyzować wysyłanie serii uploadów, by sprawdzić jak system sobie z nimi radzi. Na przykład, może wielokrotnie próbować wysłać plik tuż poniżej dopuszczalnego limitu rozmiaru, by zapełnić pamięć lub przestrzeń dyskową.

Możliwe jest również przeprowadzanie prób uploadu przekraczających limity, by sprawdzić, czy aplikacja odpowiednio reaguje (np. zwracając kod 413 Payload Too Large). Jeśli w odpowiedzi pojawi się np. błąd 500 – to już potencjalna podatność.

Spamowanie kosztownymi operacjami (np. wysyłanie e-maili)

Niektóre endpointy wywołują kosztowne operacje, np. wysyłanie e-maili lub generowanie raportów PDF. Jeśli nie są odpowiednio limitowane, atakujący może je masowo uruchamiać. Dosfiner pozwala symulować takie zachowania, np. wykonując dziesiątki lub setki żądań do API.

Tester może wtedy obserwować, czy aplikacja nadal zwraca poprawne odpowiedzi (co oznacza, że próbowała zrealizować każdą akcję), czy zaczyna zwracać błędy (np. 429 Too Many Requests) lub się spowalniać. Taki test pozwala wykryć brak mechanizmów kontroli, takich jak limity użytkownika (np. „maksymalnie 5 e-maili na minutę”) lub przeciążalność usług działających w tle.

Najważniejsze flagi w Dosfinerze

• -g / -p – tryb GET lub POST,
• -u <URL> – adres celu,
• -t <threads> – liczba wątków (równoległość),
• -r <file> – żądanie RAW z pliku,
• -proxy <host:port> – przekierowanie ruchu przez proxy,
• -d <data> – body żądania POST,
• --force-ssl – wymusza użycie HTTPS, nawet jeśli oryginalne żądanie było HTTP.

W zależności od scenariusza testowego, korzystanie z Dosfinera polega na odpowiednim doborze flag. Na przykład, aby zasymulować atak DoS za pomocą żądania GET na publiczny endpoint, wystarczy użyć flagi -g, parametru -u do określenia adresu URL oraz dużej liczby wątków przy pomocy flagi-t.

Aby przetestować odporność endpointów POST, należy użyć flagi -p, dołączyć ciało żądania za pomocą -d i, analogicznie, zwiększyć liczbę wątków (-t). W obu przypadkach rozszerzenie Invoker znacznie upraszcza cały proces – po zaznaczeniu konkretnego żądania HTTP w Burpie (np. z historii Proxy lub zakładki Repeater) i wybraniu Invoker → Dosfiner, narzędzie automatycznie wypełnia wszystkie potrzebne flagi i wartości.

W rezultacie pentester może szybko sprawdzić, czy dany endpoint może doprowadzić do przeciążenia serwera lub awarii aplikacji przy dużym obciążeniu.

Podczas korzystania z Dosfinera należy zachować szczególną ostrożność – testy powinny być prowadzone wyłącznie w środowisku testowym, kontrolowanym i zatwierdzonym przez właściciela aplikacji. Generowany ruch może być intensywny i potencjalnie doprowadzić do realnego scenariusza Denial of Service. W kontrolowanych warunkach Dosfiner staje się jednak wartościowym narzędziem do wykrywania wąskich gardeł wydajnościowych i potencjalnych podatności DoS.

Dlaczego aplikacje w Go/Rust wykonują żądania szybciej niż Turbo Intruder?

Choć Turbo Intruder jest zaimplementowany w Kotlinie i działa na platformie JVM (Java Virtual Machine), to aplikacje napisane w Go lub Rust nadal oferują lepszą wydajność w zakresie wysyłania żądań HTTP. Poniżej przedstawiono kluczowe powody, dla których np. dosfiner.go (napisany w Go) lub jego odpowiednik w Rust mogą działać szybciej niż Turbo Intruder w kontekście wysokowydajnych testów.

Kompilacja natywna vs. narzut JVM

Go i Rust są kompilowane bezpośrednio do kodu maszynowego, eliminując potrzebę uruchamiania w środowisku wykonawczym (runtime). Z kolei Turbo Intruder działa w JVM, co powoduje m.in.:

• dodatkowe zużycie pamięci,
• przerwy związane z Garbage Collection (GC), co może powodować nieprzewidywalne opóźnienia,
• opóźnienia wynikające z kompilacji JIT (Just-In-Time), która co prawda poprawia wydajność w dłuższej perspektywie, ale opóźnia start i fazę rozgrzewki.

Aplikacje w Go i Rust uruchamiają się natychmiastowo i efektywniej wykorzystują CPU w porównaniu do aplikacji JVM.

Współbieżność i równoległość

• Go posiada natywną obsługę goroutines, pozwalając na tysiące równoległych żądań przy minimalnym narzucie zasobów.
• Rust wykorzystuje async/await oraz wysoce zoptymalizowane pętle zdarzeń i bezpieczne wątki.

Turbo Intruder (bazujący na JVM) wspiera wielowątkowość, ale:

• Przełączanie kontekstu jest wolniejsze niż w Go/Rust,
• Garbage Collection może wstrzymywać wykonanie w nieprzewidywalnych momentach.

Go i Rust efektywniej obsługują wiele połączeń jednocześnie, co czyni je idealnymi do szybkich ataków typu HTTP flood lub ataków brute-force.

Efektywność pamięci i zasobów

• Goroutines w Go zużywają zaledwie kilka kilobajtów pamięci na wątek, w przeciwieństwie do wątków JVM, które potrzebują znacznie więcej RAM-u.
• Rust nie korzysta z garbage collectora, co sprawia, że zużycie pamięci jest jeszcze bardziej przewidywalne.
• Turbo Intruder wymaga znacznie więcej pamięci przy dużej liczbie żądań.

Niższe zużycie pamięci = więcej żądań równocześnie bez utraty wydajności.

Niskopoziomowe optymalizacje sieciowe

• Wbudowana biblioteka net/http w Go jest zoptymalizowana do wysokowydajnych operacji sieciowych, z bezpośrednimi wywołaniami systemowymi.
• W Rust bardzo szybka biblioteka hyper należy do najszybszych klientów HTTP dostępnych na rynku.
• Turbo Intruder opiera się na stosie sieciowym JVM, który wprowadza dodatkowe warstwy abstrakcji.

Aplikacje Go i Rust komunikują się z systemem operacyjnym bardziej bezpośrednio, umożliwiając niższe opóźnienia przy wysyłaniu żądań.

Mechanizmy ochrony przed atakami DoS

Rate limiting (ograniczenie liczby żądań)

Jednym z najprostszych i najczęściej stosowanych mechanizmów ochrony przed DoS jest ograniczenie liczby żądań od pojedynczego klienta w określonym czasie. Przykład: API może zezwalać na 100 żądań na minutę z jednego adresu IP – po przekroczeniu limitu kolejne żądania są odrzucane z kodem HTTP 429 Too Many Requests.

Technika ta jest bardzo skuteczna wobec prostych ataków typu flood. Zwykle jest implementowana na poziomie serwera webowego lub load balancera (np. dyrektywa limit_req_zone w Nginx może narzucać limity i opóźniać lub odrzucać nadmiarowe żądania). Dobrze ustawiony rate limiting imituje ludzkie tempo korzystania z aplikacji, więc zwykli użytkownicy rzadko go przekraczają, podczas gdy zautomatyzowane ataki szybko się na nim zatrzymują.

Dla testera, pojawienie się odpowiedzi 429 lub nagłówków typu Retry-After to sygnał, że system ma aktywne mechanizmy throttlingu. W takich przypadkach, aby przeprowadzić test DoS, konieczne może być użycie wielu adresów IP (symulacja rozproszonego ataku – DDoS). Obecność limitów warto uwzględnić w raporcie jako skuteczne zabezpieczenie – a jeśli ich brak, wskazać to jako ryzyko.

WAF – Web Application Firewall

WAF działa na warstwie aplikacji (HTTP/HTTPS), analizując ruch pod kątem złośliwych wzorców. W kontekście DoS, zaawansowane WAF-y potrafią wykryć i zablokować znane schematy ataków. Przykładowo, WAF może zauważyć klienta generującego nienaturalną liczbę żądań lub utrzymującego długo otwarte połączenia – i zablokować go prewencyjnie.

WAF-y często mają wbudowane reguły ograniczające DoS – np. mod_security (open-source’owy WAF) potrafi wykryć ataki typu Slowloris poprzez monitorowanie niekompletnych nagłówków HTTP. Usługi chmurowe, jak Cloudflare czy AWS WAF, umożliwiają ustawienie reguł opartych na tempie (np. maksymalnie X żądań z IP w ciągu Y sekund) oraz identyfikację i odpieranie botów. Niektóre WAF-y stosują analizę zachowań i reputacji ruchu, porównując je do znanych wzorców „normalnego” korzystania z aplikacji.

Przy ataku rozproszonym WAF może również uruchomić mechanizmy weryfikacji, takie jak JavaScript challenge lub CAPTCHA, które zautomatyzowane narzędzia rzadko potrafią obejść. Dla pentestera oznacza to, że automatyczne testy mogą być nagle blokowane. Zamiast odpowiedzi aplikacji można wtedy zobaczyć np. stronę wyzwania Cloudflare. Jak sobie z tym radzić? Jeśli test WAF-a jest w zakresie testów, można próbować go obejść (np. poprzez zaciemnianie parametrów albo dzielenie ataku na mniejsze sesje).

W przypadku testów DoS chodzi jednak nie o pojedyncze żądanie (jak w XSS czy SQLi), ale o ich masę – dlatego zazwyczaj najlepszą praktyką jest poinformowanie klienta, że WAF jest aktywny i przetestowanie jego skuteczności, a nie obchodzenie go.

Czasem klient może tymczasowo wyłączyć WAF lub dodać adres IP testera do whitelisty, by umożliwić pełne testy obciążeniowe. W przeciwnym razie raport zazwyczaj zawiera informację: „WAF zablokował nasze testy dużego natężenia, co potwierdza obecność mechanizmów ochronnych.”

Monitorowanie ruchu i wykrywanie anomalii

Nawet jeśli organizacja nie korzysta z zaawansowanego WAF-a, wiele firm monitoruje swoje serwery i sieć pod kątem nietypowej aktywności. Systemy wykrywania i zapobiegania włamaniom (IDS/IPS) mogą wykrywać wzorce ataków DoS – np. nagły wzrost ruchu ICMP (przy ataku sieciowym) lub zalew żądań HTTP.

Administratorzy systemów często dysponują dashboardami pokazującymi liczbę żądań na minutę, wskaźniki błędów itp. Nagły, skokowy wzrost ilości błędów z przedziału 5xx lub wzrost opóźnień może wywołać alert. Narzędzia do analizy logów mogą oznaczyć adres IP, który znacznie częściej niż zwykle odpytuje dany endpoint.

W niektórych przypadkach system może zareagować automatycznie – np. IPS może tymczasowo zablokować adres IP, który zbyt szybko nawiązuje wiele połączeń. Jako tester możesz zauważyć to w formie nagłego „milczenia” serwera (żadne żądania nie dochodzą), zamiast otrzymywania błędów typu 429 – co oznacza, że zostałeś zablokowany na firewallu.

Jeśli podejrzewasz takie zabezpieczenia, możesz spróbować kontynuować test z innego adresu IP lub odczekać, aż blokada wygaśnie. W dobrze monitorowanym środowisku możliwe jest również zaangażowanie człowieka – administrator może zauważyć atak w czasie rzeczywistym i zareagować ręcznie, np. restartując usługi lub blokując ruch z konkretnego IP. W prawdziwym scenariuszu testowym bardzo ważna jest koordynacja – testy DoS należy uzgadniać wcześniej, by uniknąć nieporozumień i nie wywołać paniki. Najlepiej, gdy zespół odpowiedzialny za obronę wie o planowanym teście lub przynajmniej może szybko otrzymać informację, że wzmożony ruch to zaplanowana aktywność.

Jeśli chodzi o ukrywanie śladów – w przypadku ataków DoS jest to praktycznie niemożliwe. Sam charakter testu sprawia, że generowany ruch jest głośny. Można jednak próbować modelować wzorce ruchu tak, aby nie wyglądały od razu na atak. Przykład: zamiast jednego IP wysyłającego 1000 żądań, 10 adresów IP wysyła po 100 – co może wyglądać bardziej naturalnie, zwłaszcza jeśli adresy te pasują do geolokalizacji zwykłych użytkowników. Wkracza to już w obszar działań Red Teamu, jednak warto mieć taką świadomość.

Ograniczenia na poziomie aplikacji

Wiele aplikacji implementuje własne mechanizmy ochronne – np. zezwala tylko na jedno kosztowne działanie jednocześnie na użytkownika, albo wymaga ważnego tokena CSRF dla niektórych akcji, co spowalnia automatyczne ataki. CAPTCHA przy formularzach (logowanie, rejestracja) również stanowi zabezpieczenie przed nadużyciami skryptowymi i jednocześnie utrudnia ataki DoS (nie sposób zalać serwer rejestracjami, jeśli każda wymaga rozwiązania CAPTCHA).

Innym rozwiązaniem jest przekierowanie ciężkich operacji do kolejki zadań w tle – zamiast kazać użytkownikowi czekać np. na wysłanie maila, aplikacja od razu odpowiada, a sam mail trafia do kolejki. To utrudnia bezpośredni atak DoS – spamowanie żądaniami jedynie powiększa kolejkę zadań, które są przetwarzane z ograniczoną szybkością przez workerów. Systemy te mogą mieć własne ograniczenia – np. odrzucanie nowych zadań po przekroczeniu limitu.

Z punktu widzenia testera: jeśli widzisz np. CAPTCHA albo zauważysz, że odpowiedzi przychodzą szybko, ale faktyczna akcja jest opóźniona – zanotuj te informacje. Często świadczą one o świadomym podejściu projektowym, które zmniejsza ryzyko DoS. Aby „obejść” takie mechanizmy, należałoby np. masowo rozwiązywać CAPTCHA (co jest mało realistyczne bez AI/ML) albo zapełnić kolejkę zadań realizowanych w tle – co może wymagać innego podejścia (np. równoczesnego zajęcia wszystkich dostępnych slotów).

Inne mechanizmy obronne

Poza wspomnianymi wyżej, istnieje wiele innych technik chroniących przed atakami DoS. Należą do nich:

• Ograniczenia na poziomie aplikacji – np. maksymalna liczba operacji na użytkownika na minutę, limity rozmiaru żądań (np. odrzucanie payloadów o rozmiarze powyżej 50 MB bez ich przetwarzania).
• Zabezpieczenia systemowe i serwerowe – jak limity TCP backlog, które ograniczają liczbę półotwartych połączeń TCP w danym momencie, co utrudnia ataki typu Slowloris.

Rozproszone architektury zapewniają bardzo silną ochronę. Duże usługi internetowe (np. Google, Amazon) korzystają z globalnych systemów dystrybucji ruchu, takich jak Anycast, które rozpraszają atak na wiele węzłów brzegowych jeszcze zanim dotrze on do głównej infrastruktury. Atakujący musiałby przeciążyć całą globalną sieć – co jest skrajnie trudne.

Firmy specjalizujące się w ochronie przed DDoS (np. Cloudflare, Akamai) oferują usługi tzw. scrubbing centers – przechwytują ruch od klientów podczas ataku, filtrują go i „oczyszczony” przepuszczają do aplikacji docelowej. Takie mechanizmy potrafią zneutralizować ataki liczące miliony żądań na sekundę. Przykład: w 2022 roku Google Cloud Armor zneutralizował największy dotąd zarejestrowany atak warstwy aplikacji – osiągający 46 milionów żądań HTTP na sekundę. Pokazuje to, że najwięksi gracze dysponują ogromnymi możliwościami obronnymi. Dla porównania – zwykły, niezabezpieczony serwer HTTP może mieć trudności z obsługą zaledwie kilkuset żądań na sekundę, a z pewnością z obsługą kilku tysięcy.

Korzystanie z Invokera w Burp Suite

Repeater (pojedyncze żądanie)

• W zakładce Repeater wybierz interesujące żądanie → kliknij prawym przyciskiem myszy → Invoker Extension → wybierz narzędzie (np. “dosfiner auto GET/POST” lub inne zdefiniowane).
• Invoker automatycznie uzupełnia wszystkie znaczniki (takie jak {{URL}}, {{BODY}} itd.).
• Wygenerowana komenda jest kopiowana do schowka, dzięki czemu możesz ją od razu wkleić do terminala.

Przykład skopiowanej komendy:

go run dosfiner.go -g -u "http://myhost:80/cities" -d ""  -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=mySessionCookie" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -t 999 -proxy "http://127.0.0.1:8080"Code language: JavaScript (javascript)

Targets (masowe generowanie żądań)

• W zakładce Target zaznacz wiele żądań → kliknij prawym przyciskiem → Invoker → wybierz narzędzie (np. “nuclei normal”).
• Invoker utworzy plik .sh, w którym każde żądanie zostanie przekształcone w osobną komendę.
• Ścieżka do pliku .sh zostanie skopiowana do schowka. Wystarczy go uruchomić, aby sekwencyjnie wykonać wszystkie wygenerowane komendy.

Zawartość wygenerowanego pliku .sh:

Ustawianie żądania jako „uwierzytelnionego”

• Można oznaczyć wybrane żądanie (np. z Repeatera lub Proxy History) jako “authenticated”– co pozwala przechwycić ciasteczka sesyjne i tokeny.
• Wszystkie późniejsze komendy generowane przez Invokera będą zawierały odpowiednie nagłówki, umożliwiając skanowanie zewnętrznymi narzędziami z uwzględnieniem sesji uwierzytelnionego użytkownika.

W ten sposób w folderze global_raw_directory zostanie utworzony plik .sh zawierający poniższe wpisy (cookies i nagłówki będą zastąpione tymi z uwierzytelnionego żądania):

ffuf -u "http://myhost:80//FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/afine/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/folder/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/js/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 
ffuf -u "http://myhost:80/test/FUZZ" -w /path/to/wordlist.txt -H "Host: myhost:8080" -H "Accept-Encoding: gzip, deflate, br" -H "Accept: */*" -H "Cookie: sessionID=MyNewSuperSecretSession" -H "Accept-Language: en-US;q=0.9,en;q=0.8" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" -H "Connection: close" -H "Cache-Control: max-age=0" -mc 200,403 Code language: JavaScript (javascript)

Rozwiązywanie problemów

Domyślna konfiguracja Invokera została zaprojektowana z myślą o systemach Linux i macOS. Jeśli korzystasz z Windows, musisz zaktualizować ścieżkę global_raw_folder w pliku InvokerConfig.json tak, aby wskazywała na zapisywalny katalog. Dodatkowo, podczas uruchamiania zewnętrznych narzędzi pentesterskich może być konieczne podanie pełnej ścieżki do pliku wykonywalnego, wraz z rozszerzeniem, np.:

C:\\tools\\nuclei.exeCode language: CSS (css)

Podsumowanie

Rozszerzenie Invoker dla Burp Suite to potężne narzędzie, które stanowi wartościowe uzupełnienie arsenału każdego pentestera. Integruje Burpa z wieloma zewnętrznymi narzędziami ofensywnymi, automatyzując pracochłonne procesy testowe. Zamiast ręcznie kopiować parametry do terminala, Invoker generuje poprawne polecenia jednym kliknięciem – co pozwala testerom skupić się na analizie wyników i kreatywnym odkrywaniu podatności, a nie na powtarzalnych czynnościach. Rozszerzenie sprawdza się zarówno w indywidualnych, złożonych przypadkach (np. testach SQL injection z wieloma nagłówkami i ciasteczkami), jak i przy masowym skanowaniu wielu endpointów.

Konfiguracja Invokera oparta na pliku JSON jest przejrzysta i łatwa do modyfikacji – można dodawać nowe narzędzia i dostosowywać składnię flag do własnych potrzeb. Placeholdery zapewniają dużą elastyczność w przekazywaniu elementów żądań HTTP do narzędzi CLI. W artykule omówiono integrację z Dosfinerem, sqlmapem i Nuclei, ale Invoker równie dobrze może współpracować z innymi narzędziami linii poleceń, takimi jak własne skrypty, nmap, nikto, wfuzz i inne.

Podsumowując – Invoker automatyzuje żmudne czynności i integruje różne etapy testów penetracyjnych w ramach jednego, spójnego interfejsu Burp Suite. Wnioski z jego stosowania są jednoznacznie pozytywne: zwiększa wydajność pracy, redukuje ryzyko błędów (np. brakujących nagłówków czy literówek w URL-ach) i zachęca do częstszego korzystania ze specjalistycznych narzędzi dzięki znacznemu uproszczeniu ich uruchamiania. Dla specjalistów ds. bezpieczeństwa regularnie przeprowadzających zaawansowane testy penetracyjne, Invoker może szybko stać się nieodzownym elementem środowiska Burp Suite. Warto go przetestować już przy najbliższym projekcie – istnieje duża szansa, że po kilku użyciach trudno będzie wrócić do ręcznego podejścia.