Jak wygląda praca hakera - opowiada nasz bojownik, który tym zarabia na życie

Większość normalnych ludzi, słysząc słowo "haker", wyobraża sobie gościa w masce i w bluzie z kapturem, który pisze coś bardzo szybko na klawiaturze i na ekranie musi być dużo niezrozumiałego zielonego tekstu na czarnym tle. Taki człowiek już na pierwszy rzut oka ma złe zamiary i chce zrobić komuś krzywdę. Smutne jest też to, że nawet szanujące się gazety i portale internetowe nadal karmią czytelników takimi stereotypami. Określenie "haker" jest zazwyczaj uznawane jako negatywne, dlatego "ci dobrzy" nazywają się etycznymi hakerami albo pentesterami.

Jaka jest różnica między dobrymi i złymi hakerami? Zły haker robi, co chce, gdzie chce i kiedy chce. Atakuje systemy innych, żeby wzbogacić się materialnie np. poprzez kradzież i sprzedaż informacji lub przez blokowanie systemów i dokumentów klienta dla okupu. Czasami robią to tylko dla sławy i rozgłosu, czasami z powodów politycznych lub religijnych. Niezależenie od idei, zawsze jest ktoś, kto jest poszkodowany.


Etyczny haker włamuje się tylko do systemów, do których ma pisemne zezwolenie ich właściciela. Jakiekolwiek dziury, podatności czy błędy w konfiguracji znalezione podczas testu, są zawarte w raporcie, który jest przekazywany tylko właścicielowi systemu po zakończonym teście.

Jeżeli ktoś jest zainteresowany teoretycznymi szczegółami dotyczącymi kategoryzacji hakerów i ich działań, można poczytać w internecie o tzw. kapeluszach (blackhat, greyhat, whitehat).

Granica między byciem zaawansowanym użytkownikiem komputera a hakerem nie jest jednoznaczna. Ludzie łatwo kategoryzują kogoś jako haker, kiedy widzą, że pisze szybko na klawiaturze i potrafi coś zrobić, czego nie rozumieją. W internecie jest bardzo dużo filmików pokazujących hakowanie, co w rzeczywistości jest na przykład tylko normalnym użytkowaniem jakiegoś narzędzia w systemie.

Jeżeli ktoś ma czas i łatwo pojmuje komputerowe zagadnienia, może bez problemu znaleźć jakiś system, do którego będzie w stanie się włamać bazując tylko na opisach "krok po kroku". Tacy użytkownicy są nazywani Script Kiddies – dzieci skryptów – wykorzystują oni skrypty i opisy innych bez ich zrozumienia. W dzisiejszych czasach jest dużo materiałów, programów i skryptów dostępnych w internecie, dlatego jest bardzo dużo początkujących hakerów, dzieci skryptów. Żeby stać się bardziej zaawansowanym hakerem, potrzeba dużo praktyki. Wielu zarówno początkujących jak i zaawansowanych hakerów w wolnym czasie bierze udział w tzw. bounty hunting, próbują swoich sił w zadaniach typu capture-the-flag lub na rożnego rodzaju laboratoriach testowych, gdzie bez zagrożenia mogą sobie testować i uczyć się wykorzystywania najnowszych podatności.

Jak się hakuje? W filmach pokazują hakerów, którzy szybko uderzając w klawiaturę włamują się do systemu w ciągu kilkunastu sekund i każde włamanie kończy się triumfalnym: "I’m in". W rzeczywistości jest bardzo dużo czekania na jakieś procesy, szukania informacji, czytania dokumentacji i próbowania raz po raz, wiele prób kończy się niepowodzeniem.

Jak to wygląda w rzeczywistości dla etycznego hakera?

Wszystko zaczyna się od papierkowej roboty. Najpierw zawsze jest umowa i dokument, tzw. Rules of engagement, który zawiera ważne informacje dotyczące zlecenia:

#1. Rodzaj testu

Black box, gray box lub white box. Black box jest testem bez posiadania informacji o testowanym systemie na starcie, trzeba najpierw zrobić rozpoznanie, znaleźć informacje dostępne w internecie i potem próbować się włamać. Ten rodzaj testu jest najbardziej realistyczny, ale jest też bardzo czasochłonny dla pentestera i co za tym idzie drogi dla klienta, dlatego bardzo rzadko jest zamawiany. W testach typu grey box, klient na starcie dostarcza część informacji o systemie i dokumentacje. Taki test pomija czasochłonną część rozpoznania. Ten rodzaj testu zamawiany jest najczęściej. White box, to test kiedy pentester otrzymuje dużo informacji o systemie i aplikacjach, które mają być testowane. Czasami zlecenie robione jest na zasadzie warsztatów – klient może nawet dać dostęp do kodu źródłowego, a po analizie systemu współpracuje się z programistami lub lokalnym IT wskazując dokładnie, gdzie jest problem itp. Ten rodzaj testu jest chyba najbardziej efektywny, ale nie symuluje prawdziwego ataku. Najczęściej zamawiany do aplikacji internetowych.

#2. Plan czasowy

Kiedy test ma być rozpoczęty i do kiedy ma trwać. Test może spowodować trochę "hałasu" w logach, jeżeli klient ma jakieś systemy typu SIEM czy IDS. Czasami klient musi skonfigurować jakieś wyjątki w swoim systemie na czas testu, żeby zostać zaspamowanym alarmami. Długość testu zależy od kryteriów klienta, jeżeli czas jest za krótki, test może nie dać oczekiwanego rezultatu. Jeżeli testowana ma być mała aplikacja, zazwyczaj wystarcza 1 dzień na test i kilka godzin na raport. Jeżeli zamówiony jest kompletny test całego systemu z social engineering włącznie, może to trwać kilka tygodni. Nie często zlecenia są ograniczone kryteriami jak np. testowanie do znalezienia pierwszej możliwości zapisania i uruchomienia pliku na serwerze. Wtedy test uznaje się jako zakończony i po naprawieniu tego klient zleca kolejny test.

#3. Zakres działania

Klient może mieć bardzo dużą infrastrukturę, kilkaset serwerów, tysiące aplikacji, ale jeżeli na umowie jest tylko kilka systemów, tylko one mają być testowane. Czasami można trafić na duże dziury, które otwierają drzwi do wielu innych systemów klienta, ale jeżeli nie są one ujęte w umowie, pentester nie ma prawa ich testować. W USA zdarzały się sytuacje, gdzie pentesterzy przekroczyli granice umowy przez zalogowanie się na jakiś system, na który nie powinni, klient chciał trochę zaoszczędzić i po zakończonej pracy pozwał ich do sądu i wygrał, bo logi z serwera mogły to potwierdzić.

#4. Sprzęt i narzędzia

Czasami klient wymaga podania listy narzędzi, które będą używane w teście. Jaki system będzie używany, czy sprzęt będzie podłączony do sieci bezprzewodowej, czy kablem, czy też test będzie wykonywany przez internet. Często trzeba też udokumentować adresy IP używane przez maszynę testującą, żeby później można było sprawdzić ślady w logach w celu przetestowania efektywności systemów SIEM i IDS/IPS. Ja zazwyczaj używam dedykowany laptop lub wirtualną maszynę z linuxem Kali, lub Commando VM. Czasami zdarza się, że test musi być wykonany z urządzenia dostarczonego przez klienta, bez możliwości instalacji narzędzi, wtedy jest trochę trudniej.

W trakcie testu pentester musi być wytrwały i nie powinien się poddawać zanim upłynie czas. Końcowym celem, jeżeli nie jest to ograniczone umową, jest zdobycie najwyższych uprawnień w testowanych systemach czy aplikacjach. W domenie z Active Directory jest to uprawnienie administratora domeny lub zdobycie tzw. złotego biletu. W systemach Linux, jest to na przykład dojście do uprawnień roota.

Jak przebiega test

Jest kilka różnych metod podejścia, zależnie od szkoły, mogą być różnice w terminologii i trochę inne podziały etapów hakowania. Proces hakowania można podzielić na kilka kroków:

1. Information gathering – zbieranie informacji, rekonesans
2. Network mapping – rozpoznanie sieci, skan portów
3. Vulnerability identification – identyfikacja podatności
4. Penetration – włamanie, penetracja
5. Privilege escalation – zdobycie wyższych uprawnień
6. Maintaining access – utrzymanie/stabilizacja dostępu
7. Cleanup – sprzątanie

Information gathering

Zależnie od zlecenia, jeżeli klient podaje wystarczająco dużo informacji, pierwszy krok nie zajmuje wiele czasu, czasami może być nawet pominięty. Jeżeli test ma zawierać interakcję z użytkownikami, wtedy potrzebne jest zgromadzenie informacji, żeby na przykład dobrze przygotować email do phishingu, który wyśle się do nieświadomego użytkownika w celu uzyskania dostępu do systemu. Korzysta się zazwyczaj z wyszukiwarek internetowych jak Google, Bing, Duckduckgo, archiwum Wayback Machine i różnego rodzaju social media. Najciekawsze znaleziska, na które trafiłem w tym kroku: backup bazy danych i hasła do testowanej aplikacji na publicznym koncie github jednego z programistów. Plik zip z kluczami SSL w folderze .old na serwerze firmy.

Network mapping

Mając informacje o serwerze, np adres IP lub nazwę domeny, trzeba przetestować co jest na nim, jakie porty są otwarte, czy na drodze do serwera stoi zapora ogniowa z IPSem albo reverse proxy itp. Do tego używa się różnych narzędzi. Jednym z najpopularniejszych skanerów portów jest np. Nmap. Nieduży program, ale bardzo skuteczny, jeżeli umie się go używać poprawnie. W tym kroku otrzymuje się listę możliwych punktów włamania, informacje o wersji systemu czy aplikacji.

Vulnerability identification

Bazując na informacji z poprzedniego kroku, należy sprawdzić, czy któryś z odkrytych systemów lub aplikacji ma znane podatności. Ten proces często jest automatyzowany za pomocą np. skanera Qualys, Tenable, OpenWAS czy innych bardziej ukierunkowanych do webaplikacji i frameworków, jak nikto, WPscan itp.

Penetration

Identyfikując potencjalne podatności z poprzedniego kroku, trzeba je przetestować. Niektóre podatności to kwestia zmiany jednego parametru przy wysyłaniu zapytania do serwera, niektóre wymagają trochę bardziej skomplikowanych działań. Jest bardzo dużo gotowych exploitów (znane, typowe błędy zabezpieczeń - przyp.red.), które można użyć, ale nie wszystkie są dopasowane do wymogów danego systemu. Niektórzy autorzy takich skryptów specjalnie umieszczają kod, który ma za zadanie zaszkodzić pentesterowi, który je uruchamia bez zrozumienia. Dlatego zazwyczaj z ogólnodostępnych exploitów używamy tylko tych, które są w formie kodu źródłowego i możemy je sobie sami skompilować. Najbardziej skomplikowanym zadaniem w tym kroku, z którym się spotkałem, było napisanie własnego skryptu, który wykorzystywał podatność na blind SQL injection bez znajomości struktury bazy danych.

Jeżeli któraś z odkrytych podatności daje się wykorzystać, mamy tzw. foothold, oparcie dla stóp. Jest to zazwyczaj możliwość uruchomienia własnych plików lub komend w testowanym systemie.

Privilege escalation

Jeżeli uda się wykorzystać podatność i otrzymujemy możliwość wysyłania komend do systemu, mamy zazwyczaj uprawnienia użytkownika lub usługi, która jest skonfigurowana do aplikacji z tą podatnością. Na przykład często strony internetowe są uruchamiane jako użytkownik wwwroot lub IUSR. Jeżeli jest poprawnie skonfigurowane, ten typ użytkownika ma bardzo mało uprawnień, więc nie da się np. otworzyć plików innych niż te zawarte w katalogu ze stroną www itp. Jeżeli uda się naciągnąć jakiegoś użytkownika, żeby kliknął w nasz link w emailu, wtedy możemy otrzymać dostęp do maszyny tego użytkownika z jego uprawnieniami, a to nie jest koniec, trzeba iść głębiej i próbować zdobyć wyższe uprawnienia. Do tego można wykorzystać błędy w konfiguracji, znane podatności w programach i systemie.
Czasami użytkownik z niskimi uprawnieniami, może połączyć się do innego serwera, gdzie ma wyższe uprawnienia i tym sposobem można zajść dalej. Osiągając najwyższe uprawnienia na danym komputerze lub serwerze, jeżeli jest on częścią większej domeny, trzeba iść dalej. Z serwera do serwera itd. Ale żeby dało się iść dalej, dostęp do pierwszego systemu musi być pewny i dobrze by było, żeby w przypadku np. restartu systemu udało się znowu otrzymać dostęp i tym razem bez przechodzenia przez ten sam proces co na początku. To nazywamy stabilizacją dostępu.

Maintaining access

Na różnych systemach istnieją różne techniki, żeby zapewnić sobie stały i stabilny dostęp do systemu. Można np. utworzyć sobie użytkownika, jeżeli jest dostępna usługa RDP albo SSH. Można wygenerować zaufane klucze do SSH. Można utworzyć proste zadanie w harmonogramie zadań (task scheduler lub cron), które próbuje nawiązać połączenie co jakiś czas do naszej maszyny. W razie przerwania połączenia, musimy tylko poczekać kilka sekund lub minut i otrzymujemy połączenie ponownie. Można też zainstalować bardziej zaawansowane bakdoory albo zmodyfikować konfiguracje systemu, żeby system czekał na nasze połączenie.

Cleanup

Po wykonaniu zadania, zrobieniu zrzutów ekranu, trzeba posprzątać. Wszystkie pozostałości jak jakieś skrypty czy exploity mogą stanowić potencjonalne zagrożenie dla klienta, jeżeli jakiś niepoinformowany użytkownik spróbuje je uruchomić lub jeżeli jakiś inny haker trafi w to samo miejsce zanim klient zaktualizuje system. Czasami klient jasno zaznacza w umowie, że nie chce, żeby sprzątać po teście. Informacje, które są zostawione w wielu miejscach mogą pomóc w nauce dla "niebieskich" grup – blue team.

Po teście przychodzi czas na pisanie raportu. Ten składa się zazwyczaj z części dla szefostwa, czyli skrócony opis, bez używania bardzo trudnych zwrotów oraz druga część dla bardziej technicznego personelu z dokładnym opisem krok po kroku i ewentualnymi wskazówkami jak temu zapobiec.

Przy większych projektach klienci zamawiają spotkanie z pentesterem, żeby wspólnie przeanalizować raport i przetłumaczyć na język praktyczny. Bardzo często klient nie ma ludzi w IT na tyle zaznajomionych z tematem, żeby zrozumieć, o co chodzi w raporcie, więc trzeba wszystko wyjaśniać bardzo prostym językiem. Jeżeli to nie pomoże, mamy kolegów w dziale bezpieczeństwa, konsultantów, którzy są specjalistami w poszczególnych rozwiązaniach i w takiej sytuacji oni łatają system bazując na raporcie pentestera.

Dobry raport jest bardzo ważny. Pentester może być bardzo zdolny, ale jeżeli pisze chaotyczny i niezrozumiały raport, nie ma pożytku z jego pracy. Przykład opisu złego raportu można znaleźć tutaj: the worlds worst penetration test report by scumbagpentester

Ktoś pytał, czy hakowania nie da się całkowicie zautomatyzować. Na Infosec w Londynie spotkałem się z kilkoma młodymi firmami proponującymi rozwiązania zautomatyzowanych testów penetracyjnych wykorzystujące bardzo popularne terminy w ostatnim czasie – "machine learning" i sztuczną inteligencję. Jak na razie te systemy są bardzo drogie i nie są tak efektywne jak producenci reklamują. Można to porównać do bardziej rozwiniętego skanu podatności (vulnerability scan) z zaprogramowanymi skryptami do aktywnego testowania. W raportach tych rozwiązań niestety jest bardzo dużo false-positive, czy fałszywych alarmów i zautomatyzowany test zwraca na przykład kilkaset odkrytych podatności. Do rozpoznania, które są faktycznie ważne potrzeba kogoś z doświadczeniem i tak koszty idą w górę. Poza kosztami jest jeszcze jeden aspekt, machine learning czy sztuczna inteligencja, bazując na informacjach z chmury producenta, nie ma informacji o głupocie potencjalnych użytkowników, a ci zdolni są do bardzo niestandardowych rozwiązań. Ale jeżeli ktoś jest zainteresowany moją opinią na ten temat, to mogę powiedzieć, że sztuczna inteligencja i maszynowe uczenie się, są przyszłością w tej dziedzinie, ale do tego jeszcze długa droga.

Najgłupsze błędy i dziury z którymi się spotkałem

Jeden z klientów jako jedyne zabezpieczenie między internetem a wewnętrzną siecią, miał zwykły prosty router bez zapory ogniowej. Ruch był filtrowany kilkoma ACL, wszystkie drukarki i kilka serwerów było dostępne z internetu na większości portów – zapora ogniowa na serwerach była wyłączona.

Inny klient zrobił mały błąd przy konfiguracji swojej zapory ogniowej, miał utworzyć regułę do zezwolenia na nieograniczony ruch z jednego adresu IP w internecie do jednej z wewnętrznych podsieci. Przy wpisywaniu adresu miał podać zakres, czyli od którego adresu do którego. Źle przeczytał i wpisał adres IP i maskę. To był adres IP coś około 61.x.x.x i zamiast jednego adresu otworzył szeroko drzwi dla wszystkich adresów od 61.x.x.x do 255.255.255.255. Zostało to odkryte dopiero po teście, przez kilka miesięcy klient miał dosyć dużo podejrzanego ruchu, którego jakoś nie zauważył.

Kolejny klient miał jeden "bezpieczny" system odpowiedzialnych za obsługę kas sklepowych. Wszystkie transakcje, informacje o produktach itp były zapisywane na centralnym serwerze baz danych i plików. Podczas aktualizacji wersji oprogramowania do kas, technicy mieli jakieś problemy z uprawnieniami do zapisu na serwerze, a że nie było dużo czasu, wybrali proste rozwiązanie, utworzyli nowy share i podzielili cały dysk C na serwerze, nie byłoby to jeszcze najgorsze, ale dali uprawnienia zarówno dzielonego katalogu jak i NTFS na full control grupie "Everyone".

Najczęściej spotykane błędy

Ludzie nie aktualizują systemów. Są znane dziury w systemach, które mają już kilka dobrych lat, a wiele firm nadal ma ważne serwery działające na starych wersja systemu lub pracujące ze starymi aplikacjami. Open-source frameworki, aplikacje sieciowe i pluginy powinny być aktualizowane tak szybko jak to możliwe. Bardzo często spotykamy się z aplikacjami, które klient zamówił, otrzymał i używa. Nikt nie aktualizuje takiej aplikacji ani nie sprawdza, czy czasem jakieś pluginy nie mają dziur. Jeszcze gorzej jak jakaś aplikacja jest napisana tak, że nie można jej prosto zaktualizować. Na przykład główna strona wewnętrzna, używana codziennie przez większość użytkowników w firmie była ustawiona na WordPressie kilka lat temu, nie aktualizowana, bo po co, ona jest dostępna tylko wewnątrz firmy. Jednej małej rzeczy nie zauważono: ta strona korzystała z wielu pluginów, część z nich odwoływała się bezpośrednio do innych serwerów. Jeden z pluginów przestał być rozwijany i został "przejęty" przez kogoś, kto nie miał dobrych zamiarów i tak przez dłuższy czas kopał sobie bitcoiny kosztem firmy. Aktualizowanie jest ważne. Często słyszę opinie ludzi na temat Windowsa 10 i że Microsoft chce zmusić użytkowników do zaprzestania używania Windowsa 7, a Windows 7 jest przecież dużo lepszy niż 10. Dla takich osób polecam przeczytanie dokumentacji Windows internals o różnicy między strukturą i bezpieczeństwem w Windowsie 7 i 10 albo można też posłuchać jednego z wykładów Sami Laiho, gdzie porusza ten temat bardzo dobitnie.

Innym często spotykanym błędem jest brak testowania aplikacji przed wdrożeniem do "produkcji". Rozumiem, że często są dedlajny i trzeba się spieszyć, ale aplikacje nie wystarczy testować na jednej maszynie z jednym użytkownikiem i tylko wpisując informacje, których się spodziewamy przy normalnym użytkowaniu. Dobrze też pousuwać komentarze i niepotrzebne pliki zanim aplikacja będzie publicznie dostępna. Miałem sytuację, gdzie można było znaleźć plik konfiguracyjny z rozszerzeniem .php.old. Normalny plik z rozszerzeniem .php uruchamiany jest po stronie serwera i do przeglądarki zwraca błąd lub pustą stronę, a z dodanym .old otworzył się jako plik tekstowy, zdradzając użytkownika i hasło do bazy danych, wzór do haszowania haseł itp. Jeżeli aplikacja jest przenoszona z testu na produkcję bez robienia zmian, wiadomości o błędach zawierają informacje, których nie powinny być pokazywane użytkownikom, np. błędy zapytań do bazy danych zdradzają jak jest skonstruowane zapytanie, błąd webserwera może zdradzić strukturę plików itp.

Kolejny powszechny błąd lub bardziej problem – informatycy zazwyczaj nie czytają dokumentacji ani informacji o best practice. Bardzo często użytkownicy w domenie AD mają źle skonfigurowane uprawnienia. Użytkownicy używają tych samych kont i maszyn do przeglądania internetu i do wykonywania administracyjnych zadań jako administrator domeny. Group Policy od Microsoftu ma bardzo dużo możliwości, ale skonfigurowanie tego właściwie wymaga czasu i kompetencji. Można spotkać takie konfiguracje, gdzie klient sam sobie założył pętlę na szyję. Na przykład poprzez połączanie polisy w niewłaściwym miejscu, każdy użytkownik stał się automatycznie członkiem grupy "administrators" na maszynach. Nie byłoby w tym bardzo dużego problemu, bo z założenia każdy korzysta z własnej maszyny, ale zapora ogniowa na komputerach była wyłączona również przez group policy i tym sposobem każdy użytkownik miał dostęp do każdego komputera przez sieć.

Jeszcze innym bardzo często spotykanym błędem jest używanie domyślnych haseł i używanie tego samego hasła na różnych urządzeniach/systemach. Serio, nie ustawiajcie tego samego hasła dla administratora czy root na więcej niż jednej maszynie. Używanie słowa "private" jako community do SNMP z uprawnieniami do zmian, też nie należy do polecanych rozwiązań. To samo z kombinacją cisco/cisco/cisco na urządzeniach sieciowych. Niektórzy są przewrażliwieni i ustawiają hasła o długości przynajmniej 30 znaków, losowa kombinacja małych i dużych liter, znaków specjalnych i liczb. Trudne do złamania ale też trudne do zapamiętania, dlatego trzeba to sobie gdzieś zapisać i zabezpieczyć hasłem, ale tym razem łatwiejszym do zapamiętania :) Inni znowu olewają to i używają haseł typu Zima2019, Lato2019, Nazwafirmy123, bo według nich kto by tam chciał ich zhakować, nie mają nic do ukrycia.

Polecam ustawienie uwierzytelniania dwuskładnikowego (two-factor), gdzie to tylko możliwe.


Ostatnim z problemów firm, który chciałbym podkreślić, bo jest często spotykany, a nie jest brany wystarczająco poważnie, to szkolenia dla użytkowników w dziedzinie bezpieczeństwa. Przeciętna znajomość bezpieczeństwa wśród zwyczajnych użytkowników w Norwegii jest bardzo niska, dlatego norweskie firmy są łatwym celem dla phishingu i ataków ransomware. Nie mówię, żeby wysyłać wszystkich użytkowników na zaawansowane technicznie kursy, ale wszyscy użytkownicy powinni wiedzieć jaka jest różnica między zwykłymi stronami, a stronami z szyfrowaną komunikacją, powinni znać podstawowe zasady jak np. nigdy nie podawać swojego hasła w emailu czy przez telefon, nie otwierać wszystkich załączników ani linków z emaili, które przychodzą z dziwnych źródeł, nie logować się do firmowych systemów z nieznanych urządzeń czy z podejrzanych sieci itp. Itd.

Użytkownik jest najsłabszym ogniwem i najłatwiej dostać się do systemu dzięki nieświadomemu użytkownikowi. Bardzo rzadko mamy zlecenia na test penetracyjny, który zawiera również interakcję z użytkownikami, ale zamiast tego klienci mogą zamówić kampanię, gdzie użytkownicy otrzymują dobrze przygotowany email i generowane są statystyki, ilu otworzyło email, ilu otworzyło i uruchomiło załącznik, ilu kliknęło na link i zalogowało się. Średnio ponad połowa użytkowników wypada źle w takim teście.

Tutaj można wypróbować, czy jest się wystarczająco bystrym, żeby rozpoznać próbę phishingu:

https://phishingquiz.withgoogle.com/
https://www.opendns.com/phishing-quiz/

Trochę się rozpisałem, mam nadzieję że dało się coś z tego zrozumieć. Jeżeli ktoś ma jakieś pytanie związane z hakowaniem, z chęcią odpowiem w komentarzach. A za kilka dni spróbuję trochę opisać część Incident Response.