Fundament: jakie kryteria decydują o „dobrym” języku dla Red Team
Różnica między narzędziami Red Team a typowym developmentem
Tworzenie narzędzi Red Team i automatyzacji ataków ma inny zestaw priorytetów niż klasyczna aplikacja webowa czy system biznesowy. Zamiast stabilności na lata i eleganckiej architektury, liczą się:
stealth – jak trudno wykryć narzędzie (AV, EDR, SOC),
szybkość developmentu – jak szybko da się przygotować proof-of-concept czy narzędzie pod konkretny engagement,
dostęp do systemu – API systemowe, pamięć, procesy, sieć, AD, Office,
łatwość modyfikacji – ciągłe zmiany, obejścia reguł, customizacja pod klienta,
łatwość dystrybucji – jak prosto przenieść narzędzie na host ofiary (jeden plik? brak instalacji?),
sygnaturowość – jak bardzo narzędzie przypomina znane malware lub popularne frameworki.
Typowy developer buduje produkt, który ma przetrwać lata. Red teamer buduje środek bojowy, który być może przeżyje jedno ćwiczenie, a potem trafi do archiwum lub zostanie przerobiony. Z tego powodu wybór języka programowania dla Red Team często faworyzuje:
języki z szybkim cyklem pisanie–testowanie,
języki dające dostęp do niskopoziomowych funkcji systemu,
języki, które dają binarkę lub skrypt łatwy do „zasiania” w obcej infrastrukturze.
Kluczowe kryteria wyboru języka dla narzędzi ofensywnych
Przy wyborze języka do narzędzi Red Team warto przejść po kilku konkretnych kryteriach. Dobrze działa prosta checklista:
Ekosystem security – czy istnieją gotowe biblioteki, frameworki i przykłady? Python ma Impacket, pwntools, Scapy; C# ma ogrom narzędzi do AD; C/C++ – biblioteki do WinAPI i exploitów.
Wydajność i kontrola – czy potrzebny jest pełny dostęp do pamięci, syscalle, manipulacja procesami? Tu królują C, C++ i częściowo Rust.
Wykrywalność – czy język/środowisko jest mocno monitorowane przez EDR? Popularne framweworki .NET i typowe techniki PowerShell są intensywnie profilowane.
Łatwość dystrybucji – Go zapewnia statyczne binarki, C/C++ dają małe exe/dll, Python wymaga runtime lub dołączenia interpretera/pyinstaller.
Krzywa nauki – jak szybko da się osiągnąć poziom „produktywny”? Python i C# wygrywają na starcie, C/C++ i Rust wymagają dużo więcej czasu.
Platforma docelowa – czy cel to głównie Windows domenowy, czy serwery Linux i kontenery?
Dobry język dla Red Team to nie ten „najbardziej modny”, ale taki, który pozwala w danym kontekście najszybciej i najciszej osiągnąć cel ataku. Czasem będzie to prosty skrypt w Pythonie, czasem misternie przygotowany loader w C, a czasem agent C2 napisany w Go.
Kategorie zadań Red Team a wymagania techniczne
Zadania Red Team można w uproszczeniu podzielić na kilka kategorii, które wymuszają inne wymagania techniczne wobec języka programowania:
Rekonesans i skanowanie – dużo I/O, sieć, integracje z API. Liczy się szybkość pisania, obsługa HTTP/HTTPS, DNS, SMB, LDAP, dobre biblioteki sieciowe. Zwykle Python lub Go.
Eksploatacja – generowanie payloadów, ROP, shellcode, exploitowanie błędów pamięci. Potrzebny dostęp do niskiego poziomu: C, C++, czasem Rust i Assembler.
Post-eksploatacja – narzędzia do enumeracji, persistence, lateral movement, C2. Tu dominują C#, C/C++, Go, a do automatyzacji – Python i PowerShell.
Command & Control (C2) – serwery i agenty, komunikacja sieciowa, protokoły, szyfrowanie, wieloplatformowość. W praktyce firmy często wybierają Go lub C# (po stronie agenta Windows).
Automatyzacja i orkiestracja – klejenie narzędzi, pipeline’y, integracja z CI/CD, zarządzanie zadaniami. Tutaj świetnie sprawdza się Python.
Każda z tych kategorii ma inny „profil” wymagań. Dlatego w profesjonalnych zespołach Red Team nie ma jednego „głównego” języka. Zawsze jest stack – kombinacja 2–4 języków, które się uzupełniają.
System operacyjny a wybór języka
Środowisko docelowe mocno filtruje realne możliwości. To, co jest naturalne na Linuxie, może być sztuczne lub podejrzane na Windowsie domenowym:
Windows – królują C#, C/C++, PowerShell. Świetny dostęp do WinAPI, .NET, WMI, Active Directory, Office VBA. Środowisko mocno monitorowane przez EDR.
Linux – Python, C, Go. Dużo narzędzi CLI, łatwe pisanie wrapperów, skryptów automatyzujących ruchy lateralne między serwerami.
macOS – mniej typowy target, ale podobny zestaw: Python, Go, C/C++, Swift/Objective‑C przy głębszej integracji.
Przy planowaniu własnej ścieżki rozwoju najrozsądniej jest zaczynać od platformy, na której najczęściej pracują klienci. Jeśli to środowiska domenowe, priorytet dostają C#/.NET, PowerShell, C/C++. Jeśli głównie serwery Linux – Python, Go, C.
Kiedy „język do wszystkiego”, a kiedy niszowa specjalizacja
W bezpieczeństwie ofensywnym pojawia się naturalna pokusa: „nauczę się jednego języka i zrobię w nim wszystko”. W praktyce wygląda to tak:
Język do wszystkiego – w roli takiego „centrum” często występuje Python. Nadaje się do automatyzacji, szybkich PoC, tworzenia narzędzi pomocniczych, API, integracji. Świetny jako pierwszy język.
Języki specjalistyczne – do ścisłego Red Teamingu wchodzi C/C++ (loader’y, shellcode), C# (AD, .NET), Go (C2, skanery sieciowe), Rust (bezpieczniejsze narzędzia niskopoziomowe).
Rozsądne podejście: jeden język „bazowy” + jeden język niskopoziomowy + jeden język „platformowy”. Przykładowo:
Python (bazowy) + C (niski poziom) + C# (.NET/Windows),
Python (bazowy) + C (niski poziom) + Go (C2 i sieć).
Python – szwajcarski scyzoryk do automatyzacji i prototypowania
Dlaczego Python dominuje w świecie security
Python jest najczęstszym pierwszym wyborem, gdy wchodzi się w automatyzację ataków pentest i narzędzia ofensywne security. Składają się na to trzy cechy:
niski próg wejścia – czytelna składnia, mało „ceremonii”, dużo tutoriali,
ogrom bibliotek – praktycznie każde popularne zadanie bezpieczeństwa ma już gotową implementację lub przykład,
gotowe frameworki – narzędzia napisane w Pythonie można łatwo modyfikować, dopisywać moduły, automatyzować.
W praktyce w wielu zespołach Python staje się „klejem” łączącym różne narzędzia i systemy. Tam, gdzie trzeba coś:
pobrać z sieci,
przetworzyć/parsować,
porównać, zmerge’ować,
zapisać w CSV/JSON/DB,
– najczęściej pojawia się mały skrypt w Pythonie zamiast budowania pełnej aplikacji.
Typowe zastosowania Pythona w Red Team
Najbardziej praktyczne zastosowania Pythona w Red Team kręcą się wokół automatyzacji i szybkich prototypów:
Automatyzacja powtarzalnych zadań – obróbka wyników z Nmap, Nessus, Burp Suite, generowanie raportów, ustawianie scenariuszy testowych.
Szybkie PoC exploitów – gdy wychodzi nowy exploit, często pierwsze publikowane PoC są w Pythonie. Łatwo je dostosować pod własnego klienta czy infrastrukturę.
Integracja narzędzi – skrypty spinające Cobalt Strike, system ticketów, Slack/Teams, wewnętrzne API firmy, logowanie wyników testów.
Python rzadziej służy do końcowego payloadu na host ofiary (choć bywa), a częściej do zaplecza operacyjnego: przygotowanie, orkiestracja, wsparcie, analiza danych.
Kluczowe biblioteki i frameworki przydatne dla Red Team
Zamiast uczyć się Pythona abstrakcyjnie, lepiej od razu zacząć od bibliotek typowych dla ofensywnego bezpieczeństwa.
Scapy – manipulacja pakietami sieciowymi
Scapy pozwala:
tworzyć i wysyłać pakiety sieciowe (TCP, UDP, ICMP, DNS i wiele innych),
analizować przechwycone pakiety,
budować własne testery protokołów czy skanery.
Przykładowy scenariusz: szybkie przygotowanie niestandardowego pakietu DNS lub SMB, aby przetestować dziwne zachowanie aplikacji, bez konieczności kompilowania binarek w C.
Impacket – praca z protokołami Microsoft (SMB, Kerberos, AD)
Impacket to złoty standard dla operacji związanych z infrastrukturą Microsoftu. Pozwala m.in. na:
implementację ataków na Kerberos (np. Kerberoasting),
pracę z SMB (smbclient, wyciąganie plików, enumeracja udziałów),
operacje na kontach domenowych, sesjach, politykach.
Dla red teamera działającego w środowisku domenowym, umiejętność czytania i modyfikowania skryptów Impacketu to bardzo szybki sposób na custom narzędzia, zamiast pisania wszystkiego od zera w C#.
pwntools – framework do exploitów i CTF
pwntools jest używany głównie w CTF i przy nauce exploitacji binarnej, ale przenosi się też do realnych zadań Red Team. Ułatwia:
tworzenie i wysyłanie payloadów,
automatyzację interakcji z procesami (lokalnie i przez sieć),
budowanie ROP chainów, obsługę format string, overflow, itp.
Dobrze sprawdza się jako szybkie środowisko do prostych exploitów, które później mogą zostać przepisane do C/C++ jako docelowe, bardziej stealth’owe narzędzia.
Paramiko, Requests, inne fundamenty
Kilka bibliotek, które w ofensywnym security przydają się niemal codziennie:
paramiko – praca z SSH (tunelowanie, automatyczne logowanie, wykonywanie komend, zbieranie wyników),
requests – HTTP(S) na sterydach, obsługa proxy, headerów, cookies, tokenów,
pypsrp / winrm – zdalne wykonywanie komend na Windows z poziomu Python,
pycryptodome – prymitywy kryptograficzne, własne protokoły komunikacji C2.
Mocne strony Pythona w ofensywnym bezpieczeństwie
Największy atut Pythona: przyśpiesza iterację. Zamiast spędzać tygodnie na dopieszczaniu C++, red teamer może:
napisać PoC exploita w kilka godzin,
sprawdzić realne możliwości w labie lub u klienta,
na tej podstawie podjąć decyzję, czy opłaca się inwestować w produkcyjną wersję w innym języku.
Do tego dochodzi:
ogromna społeczność,
gotowe snippet’y pod konkretne CVE,
łatwa integracja z narzędziami zewnętrznymi (API CI/CD, Jira, Slack, SIEM, bazy danych).
Python świetnie sprawdza się też jako język orkiestracji dla złożonych kampanii Red Team – skrypty, które:
startują i zatrzymują infrastrukturę (VM, kontenery, serwery C2),
zbierają logi z agentów,
sprawdzają, czy konkretne zadania zostały wykonane.
wykrywalność – duże binarki po pyinstallerze, charakterystyczne artefakty w pamięci,
dystrybucja – zależności, moduły, brak Pythona na hostach produkcyjnych.
Wtedy lepiej:
wykorzystać Pythona do prototypu,
zweryfikować technikę w labie,
docelową wersję napisać w C/C++, C# lub Go – w zależności od systemu i potrzeb.
Dobry wzorzec pracy: PoC w Pythonie + moduł niskopoziomowy w C. Krytyczną część (np. szyfrowanie, operacje na pamięci) przenosisz do C jako bibliotekę, a Python tylko steruje logiką.
Źródło: Pexels | Autor: Al Nahian
C i C++ – baza pod exploity, payloady i code injection
Dlaczego bez C/C++ trudno o poważny Red Teaming
C i C++ dają coś, czego nie daje żaden wysoki język: pełną kontrolę nad pamięcią i procesem. Bez tego trudno pisać:
loader’y shellcode’u,
moduły do code injection,
custom implanty i agenty C2,
narzędzia obchodzące EDR/AV na poziomie API i syscalli.
To z tych języków korzysta większość zaawansowanych narzędzi ofensywnych – zarówno open source, jak i komercyjnych. W praktyce C/C++ to:
język do “ostrej roboty” na hoście ofiary,
warstwa, którą naprawdę analizują analitycy malware i EDR.
Typowe zastosowania C/C++ w narzędziach Red Team
Najczęściej C/C++ pojawia się przy operacjach zbliżonych do malware lub defensywy na niskim poziomie:
implanty / agenty C2 – małe, statycznie linkowane binarki, które łączą się do serwera C2, wykonują komendy, zbierają dane,
loader’y i stager’y – binarki, które pobierają, deszyfrują i wstrzykują shellcode do pamięci innych procesów,
injection i migracja procesu – CreateRemoteProcess, WriteProcessMemory, QueueUserAPC, NtCreateThreadEx i inne techniki znane z Windows API,
hookowanie i unhookowanie – modyfikacja IAT, EAT, inline hooks, praca z bibliotekami ntdll.dll, kernel32.dll,
manipulacja PE/ELF – packery, obfuscatory, konstrukcja custom binarek i loaderów.
Dodatkowo C/C++ przydaje się do pisania:
modułów kernelowych (sterowniki, LKM),
narzędzi do analizy pamięci (dumpowanie procesów, parsowanie struktur jądra),
custom rozszerzeń do istniejących narzędzi (np. pluginy do Burp, routerów, IDS/IPS).
Praktyczne fundamenty C/C++ pod bezpieczeństwo ofensywne
Zamiast rzucać się na pisanie exploitów ROP po tygodniu nauki, lepiej zbudować kilka podstawowych klocków:
proste programy konsolowe: input/output, praca z plikami,
obsługa sieci (sockets) – klient/serwer, proste protokoły,
korzystanie z bibliotek dynamicznych (DLL/so),
kompilacja z różnymi flagami optymalizacji i debugowania.
Potem warto wejść w elementy krytyczne dla Red Team:
struktura plików PE/ELF,
wywołania systemowe i WinAPI/POSIX,
alokacja pamięci, wskaźniki, wskaźniki do funkcji.
Na tym poziomie można już pisać:
minimalne implanty komunikujące się po HTTP(S)/DNS,
proste in‑memory loader’y,
narzędzia do enumeracji hosta, które nie zostawiają zbyt wielu śladów na dysku.
WinAPI i specyfika Windows w C/C++
Jeśli celem są sieci domenowe, C/C++ na Windows to mieszanka dwóch tematów:
Active Directory i sieć – LDAP, SMB, RPC, WMI, COM.
Najbardziej praktyczny zestaw ćwiczeń:
napisanie prostego reverse shell w C,
implementacja „notatnika zdalnego” – proces, który łączy się do serwera i wykonuje otrzymane komendy,
program enumerujący procesy, moduły i otwarte uchwyty (similar to tasklist/handle),
prosty injector – otwarcie obcego procesu, wstrzyknięcie bufora, uruchomienie wątku.
Na tym fundamencie można już dopinać techniki unikania EDR: unhooking ntdll, syscalle bezpośrednie, klasyczne API stomping czy powłoki reflective DLL.
Zastosowania C/C++ poza Windows
Na Linuxie i macOS C/C++ przydaje się głównie przy:
modułach kernela (LKM, sterowniki),
hookowaniu funkcji libc (LD_PRELOAD),
narzędziach do analizy i modyfikacji ruchu (np. raw sockets, eBPF),
sprzężeniu z komponentami sieciowymi (routery, IoT, firmware).
W praktyce tam, gdzie trzeba wejść poniżej poziomu typowego user‑space, wybór i tak pada na C. Dlatego znajomość tego języka otwiera drogę do projektów, które w Pythonie czy C# są po prostu nierealne.
Kompromisy: bezpieczeństwo, złożoność, czas
C/C++ daje ogromne możliwości, ale płaci się za nie:
czasem developmentu – więcej kodu, więcej bugów, dłuższe debugowanie,
podatnościami – overflow, UAF, race condition; trzeba stale pilnować pamięci,
kosztem utrzymania – rozbudowane projekty C++ potrafią boleśnie rosnąć w złożoność.
Dlatego rozsądny workflow to:
PoC i orkiestracja w Pythonie,
core ofensywny (loader, implant, krytyczne moduły) w C/C++,
niewielka, dokładnie testowana baza kodu C – zamiast „wszystko w C++”.
C# i .NET – król Windowsa w środowisku domenowym
Dlaczego C# stał się standardem w atakach na AD
W środowiskach domenowych C# i .NET są naturalnym wyborem. System i aplikacje biznesowe już ich używają, więc kod C#:
wygląda „normalnie” dla systemu i wielu SOC,
ma natywny dostęp do .NET, WMI, LDAP, COM, WinAPI,
łatwo integruje się z istniejącą infrastrukturą (Exchange, SharePoint, Office, serwisy webowe).
Do tego dochodzą gotowe projekty typu Sharp* (SharpHound, SharpDump, SharpKatz itd.), które można kompilować, modyfikować, łączyć w własne toolkity.
Typowe scenariusze użycia C# w Red Team
Przy operacjach na Active Directory C# jest narzędziem numer jeden w kilku obszarach:
enumeracja AD – użytkownicy, grupy, GPO, delegacje, ACL, SPN – to, co robi BloodHound i pochodne,
atakowanie Kerberosa – Kerberoasting, AS‑REP Roasting, S4U; łatwy dostęp do bibliotek kryptograficznych,
LSASS / credential access – zrzuty pamięci, integracja z API podobnymi do Mimikatz,
C# ma coś, czego brakuje wielu innym językom w tym kontekście: refleksję i dynamiczne ładowanie assembly. Z punktu widzenia Red Team oznacza to możliwość:
ładowania modułów bez zapisu na dysk (in‑memory),
odpalenia innego narzędzia .NET „z RAM‑u” – jako assembly osadzone w kodzie,
obsługi wielu funkcji ofensywnych w jednym pliku wykonywalnym.
Przykład z praktyki: jedno narzędzie .NET, które:
enumeruje AD,
przeprowadza Kerberoasting,
zrzuca LSASS,
przesyła wyniki na serwer C2.
Każda z tych funkcji może być osobnym assembly, ładowanym tylko na chwilę, wykonywanym i wyrzucanym z pamięci. Dla EDR utrudnia to analizę – szczególnie przy dobrej obfuskacji.
PowerShell vs C# – kiedy który wybrać
PowerShell długo był podstawowym narzędziem ofensywnym na Windows. Dziś jest jednym z najbardziej monitorowanych elementów systemu. C# często przejmuje jego rolę:
PowerShell – szybkie komendy, skrypty jednorazowe, praca interaktywna; idealny w fazie rekonesansu i manualnych testów,
C# – stabilne narzędzia, które mają żyć dłużej, działać w tle, przechodzić przez EDR, być częścią większego toolkitu.
Sensowny workflow:
test techniki w PowerShell (komendy, moduły),
gdy działa – przeniesienie logiki do C#/.NET,
dopracowanie obfuskacji, logiki ładowania, konfiguracji,
integracja z C2 lub innymi narzędziami kampanii.
Narzędzia i biblioteki C# przydatne w ofensywie
Ekosystem .NET ma kilka elementów, które mocno ułatwiają życie:
System.DirectoryServices / DirectoryServices.Protocols – praca z AD/LDAP bez dodatkowych zależności,
System.Management – WMI, informacje o systemie, zdalne wykonywanie,
System.Security.Cryptography – kryptografia pod Kerberos, DPAPI, custom protokoły,
Sharp* – cała rodzina gotowych narzędzi, których kod można czytać i modyfikować pod własne potrzeby.
Dobrym ćwiczeniem jest wybranie jednego projektu z rodziny Sharp i:
zrozumienie, jak enumeruje AD lub jak zrzuca LSASS,
wycięcie zbędnych funkcji,
dopisanie własnego prostego modułu – np. exfil danych do swojego serwera.
Ograniczenia i ryzyka C#/.NET
C# bywa łatwiejszy do analizy niż C. Kod IL można dekompilować narzędziami typu dnSpy, ILSpy, co oznacza:
większą czytelność dla blue teamu,
konieczność obfuskacji (ConfuserEx, własne techniki),
ryzyko szybkiego „rozbrojenia” narzędzia bez dobrych zabezpieczeń.
Do tego dochodzi:
monitoring .NET w EDR,
analityka oparta na assembly i metodach,
środowiska z ograniczonym dostępem do CLR (AppLocker, WDAC).
Dlatego wiele zespołów łączy C# z innymi komponentami: krytyczna logika i injection w C, a warstwa „użytkowa” w .NET.
Źródło: Pexels | Autor: Muhammed Ensar
Go (Golang) – sieć, C2 i przenośne binarki
Co daje Go w kontekście Red Team
Go ma kilka cech, które idealnie wpasowują się w narzędzia ofensywne:
statyczne binarki – jeden plik, bez zależności, łatwy do dystrybucji na hosty,
dobra obsługa sieci i współbieżności – goroutines, kanały, standardowa biblioteka net/http,
wieloplatformowość – łatwe cross‑compile na Windows, Linux, macOS, a także ARM,
relatywnie prosta składnia – szybsza nauka niż C++ czy Rust.
Typowe zastosowania Go w narzędziach ofensywnych
Go sprawdza się głównie tam, gdzie liczy się sieć, stabilność i szybkie wdrażanie na wiele platform. W praktyce najczęściej ląduje w roli:
serwerów C2 – HTTP(S), WebSocket, gRPC, custom protokoły na TCP/UDP,
klientów/implantów – lekki agent z podstawowym zestawem funkcji,
proxies i tuneli – reverse proxy, pivoting między sieciami, SOCKS,
scannerów i enumeratorów – szybki skan sieci, serwisów, domen,
narzędzi do exfiltracji – przesyłanie dużych zestawów danych,
„kleju” między usługami – mikroserwisy wspierające kampanię ofensywną.
Prosty przykład z praktyki: mały binarny proxy w Go, dropowany na host w DMZ, który:
nasłuchuje na TCP/443,
tuneluje ruch do wewnętrznej sieci,
zarządza połączeniami goroutines, utrzymując setki sesji bez zadyszki.
Goroutines i kanały w służbie C2
Model współbieżności Go zwalnia z zabawy w manualne wątki. Dla C2 to ogromny plus:
każda sesja implanta może być osobną goroutine,
kanały pozwalają łatwo rozdzielać zadania i wyniki między modułami,
serwer C2 skalujący się do setek implantów nie wymaga skomplikowanej architektury.
Praktyczny schemat:
goroutine przyjmująca nowe połączenia od agentów,
kanał z zadaniami do wykonania (job queue),
goroutines‑workers, które obsługują komendy, logowanie i zapis wyników.
Taki wzorzec da się zaadaptować zarówno do klasycznego C2, jak i do narzędzi pomocniczych – np. serwera do zbierania beaconów z wielu kampanii naraz.
Cross‑compile Go na różne systemy
Jedna z większych przewag Go to łatwe budowanie binarek na różne platformy. Typowy workflow:
kod źródłowy w Go utrzymywany na Linuxie,
kompilacja na Windows:
GOOS=windows GOARCH=amd64 go build -o agent.exe
kompilacja na Linux:
GOOS=linux GOARCH=amd64 go build -o agent
Bez zewnętrznych cross‑kompilatorów, bez kombinowania z toolchainami. Przy kampaniach obejmujących wiele OS skraca to przygotowanie paczek do minimum.
Ukrywanie i minimalizowanie śladu binarek Go
Domyślne binarki Go bywają „grube” i łatwe do wykrycia po charakterystycznych sygnaturach. Da się to ograniczyć:
linkowanie z flagami:
go build -ldflags="-s -w" -o agent
zmniejsza rozmiar, usuwa symbole i debug info,
użycie narzędzi typu upx do packowania (z ostrożnością, bo to sygnał dla AV),
unikanie niepotrzebnych dużych bibliotek (np. ciężkich frameworków webowych).
Dodatkowo:
sensowne jest pisanie własnych, prostych implementacji protokołów zamiast gotowych frameworków,
konstrukcje kodu Go są coraz częściej profilowane przez EDR, więc unikanie sztampowych implant‑template’ów ma znaczenie.
Integracja Go z innymi językami
Go rzadko występuje w izolacji. Częsty wzorzec to:
implant lub proxy w Go (stabilność, sieć, cross‑platform),
„ostre” moduły w C/C++ (injection, exploit, bypass EDR),
warstwa orkiestracji w Pythonie (kontrola, raportowanie, automatyzacja).
Dwa praktyczne kierunki integracji:
CGO – wywoływanie bibliotek C z Go (np. custom loader w C, wywoływany z Go),
protokół sieciowy – Go jako serwer C2, a inne komponenty komunikują się po HTTP/gRPC.
Ograniczenia i wady Go w ofensywie
Go nie jest bez wad. Najważniejsze przeszkody:
rozmiar binarek – nawet „goły” program bywa kilkumegabajtowy,
łatwa identyfikacja – specyficzne stringi i struktury w pliku,
brak pełnej kontroli nad niskim poziomem – injection czy finezyjne techniki unikania EDR nadal wygodniej robić w C.
Sensowne jest ograniczanie Go do tego, w czym jest mocny – logika, sieć, równoległość – a nie na siłę używanie go do wszystkiego.
Rust – bezpieczne system‑level, gdy liczy się kontrola i jakość
Gdzie Rust ma przewagę nad C/C++
Rust łączy niski poziom z kontrolą nad pamięcią bez klasycznych bugów typu overflow czy use‑after‑free (przy przestrzeganiu reguł borrow checker’a). W kontekście Red Team przydaje się w:
implantach i loaderach, gdzie ważna jest stabilność i odporność na crashe,
modułach do analizy binarek i protokołów,
narzędziach do pracy z kernel‑level (zależnie od systemu i dostępnych bindings),
komponentach wymagających wysokiej wydajności i bezpieczeństwa pamięci.
W odróżnieniu od klasycznego C:
większość klas błędów pamięciowych jest wycinana przez kompilator,
łatwiej utrzymać większy kod, jeśli zespół trzyma się jednego stylu i zasad.
Rust a wykrywalność i analiza
Binarki Rust są mniej „oczywiste” do ręcznej analizy niż C#/.NET, ale też potrafią być masywne. Dla Red Team liczy się kilka kwestii:
brak IL/bytecode do łatwej dekompilacji jak w .NET – utrudnia szybkie reverse,
nietypowe nazwy funkcji i modułów (mangling), które można potem porządkować w build pipeline,
rosnąca liczba sygnatur AV na popularne projekty ofensywne w Ruście – gotowe frameworki zostawiają ślad.
Przy własnych projektach:
dobrze jest minimalizować zależności z crates.io,
unikać kopiowania kodu „1:1” z popularnych repo ofensywnych,
budować własne, lekkie biblioteki do kluczowych zadań (np. komunikacja z C2).
Przykładowe use‑case’y Rust w narzędziach Red Team
Kilka projektów, które realnie da się utrzymać w Ruście:
implant komunikujący się po HTTP/2 lub QUIC – Rust radzi sobie dobrze z nowoczesnymi protokołami,
moduł do parsowania i modyfikacji binarek (PE/ELF/Mach‑O),
analizator logów i telemetry, agregujący duże ilości danych w infrastrukturze Red Team,
narzędzia do fuzzingu protokołów i serwisów wewnętrznych klienta.
Częsty model: część odpowiedzialna za precyzyjne parsowanie i manipulację strukturami binarnymi w Ruście, a orkiestracja całości w Pythonie lub Go.
Wyzwania przy adopcji Rust
Rust nie jest „plug and play”. Typowe problemy:
krzywa nauki – borrow checker wymusza inne myślenie o pamięci i własności,
dłuższy czas developmentu przy pierwszych projektach,
mniej przykładów ofensywnych niż w C/C++/C#, więc więcej własnego R&D.
Sprawdza się podejście:
pierwsze PoC w C lub Pythonie,
rysowanie interfejsu modułu (API) w Rust,
przeniesienie najwrażliwszych fragmentów (np. parserów, krypty) do Rust,
stopniowe rozszerzanie, gdy zespół nabiera doświadczenia.
Łączenie języków w jednym ekosystemie Red Team
Warstwy narzędzi: od PoC do produkcyjnego toolkitu
W praktyce jeden język nigdy nie ogarnia całej operacji ofensywnej. Sensowny podział na warstwy:
PoC i prototypy – Python, PowerShell, czasem Bash na Linuxie,
moduły niskopoziomowe – C/C++/Rust,
narzędzia domenowe Windows – C#, czasem PowerShell (silnie ograniczony),
Kluczowe jest zachowanie spójnych interfejsów między tymi warstwami: JSON, prosty REST, gRPC lub proste kolejki zadań (np. Redis, pliki, SQS – w zależności od środowiska).
Projektowanie API między komponentami
Im prostszy protokół komunikacji, tym mniej problemów przy rozwoju. Sprawdzone podejście:
komunikacja C2 ↔ implant po HTTP(S) z JSON (lub binarny protobuf, jeśli zależy na rozmiarze),
komunikacja moduł ↔ orchestrator przez CLI:
moduł przyjmuje parametry w linii komend,
wynik wypisuje w JSON na stdout,
orchestrator parsuje wynik i podejmuje kolejne akcje.
Takie „narzędzia jako filtery” pozwalają łatwo łączyć C, Go, Pythona i C# bez skomplikowanych integracji.
Strategia rozwoju umiejętności językowych pod Red Team
Rozrzucanie się na wszystkie języki naraz kończy się często brakiem głębi. Rozsądna kolejność nauki:
C – pamięć, procesy, WinAPI/Linux API, podstawy exploitu,
C# – AD, .NET, narzędzia domenowe Windows,
Go – C2, sieć, cross‑platformowe binarki,
Rust (opcjonalnie) – bezpieczeństwo i stabilność krytycznych komponentów.
Na każdym etapie sens mają małe, konkretne projekty:
w Pythonie – klient REST do C2, który odpala lokalne moduły,
w C – injector DLL i prosty loader shellcode,
w C# – narzędzie do enumeracji AD z wybranym scenariuszem (np. delegacje),
w Go – serwer C2 do reverse shelli,
w Ruście – parser PE ze zrozumieniem sekcji i importów.
Automatyzacja operacji Red Team z użyciem wielu języków
Przy większych kampaniach bez automatyzacji szybko powstaje chaos. Sprawdzony wzorzec to:
„control plane” w Pythonie – skrypty i frameworki zarządzające:
deployem implantów,
zbieraniem wyników z C2,
generowaniem raportów cząstkowych.
komponenty wykonawcze:
C# – AD, Kerberos, WMI,
C/C++ – low‑level na hostach,
Go – serwisy sieciowe, pivoting, tunelowanie.
Całość można spiąć prostym systemem zadań:
zadanie opisane w JSON (cel, technika, parametry),
odpowiedni moduł językowy wykonuje operację,
wynik wraca w standardowym formacie i jest archiwizowany.
Najczęściej zadawane pytania (FAQ)
Jaki język programowania najlepiej wybrać na start do Red Team i automatyzacji ataków?
Najrozsądniejszy start to Python. Ma niski próg wejścia, ogrom gotowych bibliotek security (Impacket, pwntools, Scapy) i świetnie nadaje się do automatyzacji, rekonesansu, pisania PoC i klejenia różnych narzędzi w jedną całość.
Drugim krokiem zwykle jest język „platformowy”, zależny od środowiska klientów: C# i PowerShell przy środowiskach domenowych Windows, albo Go przy nacisku na serwery Linux i narzędzia sieciowe. Dopiero później dochodzi język niskopoziomowy (C/C++ lub Rust) do loaderów i exploitów.
Czy da się robić cały Red Team tylko w jednym języku, np. w Pythonie?
Da się sporo, ale nie wszystko. Python świetnie ogarnia rekonesans, automatyzację, integracje z API, szybkie exploity i narzędzia pomocnicze. Słabiej wypada tam, gdzie potrzebna jest mała, trudniej wykrywalna binarka albo głęboki dostęp do systemu (WinAPI, syscalle, manipulacja pamięcią).
W praktyce większość zespołów kończy z małym stosem technologii: np. Python jako „klej”, C/C++ do shellcode i loaderów oraz C# lub Go do agentów C2 i post‑eksploatacji. Jednojęzykowe podejście szybko zaczyna ograniczać możliwości techniczne i stealth.
Jaki język jest najlepszy do tworzenia agentów C2 i narzędzi post-eksploatacyjnych?
Przy agentach C2 i narzędziach post‑eksploatacyjnych dominują C#, C/C++ i Go. C# ma świetny dostęp do .NET, Active Directory, WMI i ekosystemu Windows, ale jest mocno obserwowany przez EDR. C/C++ daje najmniejszy narzut, pełną kontrolę nad pamięcią i możliwość pisania bardzo „cichych” loaderów.
Go jest częstym wyborem do agentów C2 ze względu na łatwe tworzenie statycznych, wieloplatformowych binarek i bogate biblioteki sieciowe. Jeśli celem są głównie środowiska domenowe, wiele zespołów łączy C# (logika, AD) z C/C++ (injectory, loader). Przy mieszanych środowiskach Windows/Linux wygodny jest Go jako wspólny mianownik.
Jak system operacyjny ofiary wpływa na wybór języka do narzędzi Red Team?
Na Windows preferowane są C#, C/C++ i PowerShell. Pozwalają korzystać z WinAPI, .NET, WMI, Office VBA i integracji z Active Directory. Jednocześnie są intensywnie monitorowane przez EDR, więc pojawia się potrzeba kombinowania z formą payloadów (DLL, reflective loading, in-memory).
Na Linuxie wygodnie pracuje się z Pythonem, C i Go – wiele operacji da się załatwić przez CLI, skrypty i lekkie binarki. macOS to zwykle podobny zestaw (Python, Go, C/C++), a przy głębszej integracji dochodzą Swift/Objective‑C. W skrócie: zaczynasz od systemu, na którym żyją Twoi klienci, a dopiero potem dobierasz język.
Jakie kryteria brać pod uwagę, wybierając język do konkretnego narzędzia ofensywnego?
Praktyczna mini-checklista wygląda tak:
Ekosystem security – są gotowe biblioteki, frameworki, przykłady?
Wydajność i kontrola – potrzebujesz bezpośredniego dostępu do pamięci, syscalli, procesów?
Wykrywalność – środowisko (np. .NET, PowerShell) jest silnie monitorowane przez EDR/SOC?
Dystrybucja – czy łatwo przeniesiesz narzędzie na host ofiary (jeden plik, brak instalatora)?
Krzywa nauki – ile czasu zajmie dojście do poziomu „produktywny”?
Platforma docelowa – Windows domenowy, serwery Linux, kontenery, macOS?
W efekcie to nie „moda” na język decyduje, tylko kontekst zadania. Prosty rekonesans HTTP zrobisz szybciej w Pythonie, a niewielki loader in‑memory dla Windows raczej w C niż w wysokopoziomowym frameworku.
Czy warto uczyć się C lub C++ do Red Team, skoro jest Python i C#?
Tak, choć nie jako pierwszy krok. C/C++ przydają się tam, gdzie inne języki zaczynają być zbyt „ciężkie” lub zbyt łatwo wykrywalne: loader’y, shellcode, exploitacja błędów pamięci, niestandardowe injektory. Dają pełną kontrolę nad pamięcią, strukturami PE/ELF i integracją z systemem na bardzo niskim poziomie.
Praktyczny schemat nauki to: najpierw język bazowy (Python), potem platformowy (.NET/C# lub Go), a na końcu C jako narzędzie do zadań „specjalnych”. Nawet podstawowa znajomość C mocno ułatwia rozumienie exploitów, shellcode i technik unikania detekcji.
Jak sensownie zbudować stos języków dla kariery w Red Teamingu?
Sprawdza się prosty wzorzec: jeden język bazowy + jeden niskopoziomowy + jeden platformowy. Typowe zestawy to:
Python (bazowy) + C (niski poziom) + C# (.NET/Windows domenowy),
Python (bazowy) + C (niski poziom) + Go (C2, narzędzia sieciowe, Linux).
Python ogarnia automatyzację, skrypty pomocnicze i szybkie prototypy. C służy do loaderów i bardziej „surowych” części implantów. C# lub Go pokrywają C2, post‑eksploatację i integrację z konkretnymi środowiskami produkcyjnymi.
Co warto zapamiętać
Dobry język dla Red Team to taki, który pozwala najszybciej i najciszej osiągnąć cel ataku, a nie ten „najmodniejszy” – liczy się stealth, łatwość modyfikacji, dystrybucji i dostęp do systemu.
Red Team nie buduje wieloletnich produktów, tylko „środki bojowe” na konkretne ćwiczenia, więc priorytetem jest szybki cykl pisanie–testowanie i możliwość szybkiego obchodzenia reguł bezpieczeństwa.
Nie istnieje jeden idealny język na wszystko – profesjonalne zespoły używają stacku 2–4 języków dopasowanych do zadań: rekonesans, eksploatacja, post-eksploatacja, C2 oraz automatyzacja.
Platforma docelowa filtruje wybór: na Windows dominują C#, C/C++ i PowerShell, na Linuxie – Python, C, Go, a na macOS podobny zestaw z dodatkiem Swift/Objective‑C przy głębszej integracji.
Praktyczny model rozwoju to kombinacja: jeden język bazowy (najczęściej Python), jeden niskopoziomowy (C/C++) oraz jeden „platformowy” (np. C# dla Windows lub Go dla C2 i narzędzi sieciowych).
Przy wyborze języka trzeba przejść konkretną checklistę: ekosystem security, wydajność i kontrola nad systemem, wykrywalność w EDR, łatwość dystrybucji, krzywa nauki oraz docelowy system operacyjny.
Python pełni zwykle rolę „szwajcarskiego scyzoryka” – nadaje się do szybkiego prototypowania, automatyzacji, klejenia narzędzi i PoC, podczas gdy C/C++, C#, Go czy Rust obsługują bardziej specjalistyczne i niskopoziomowe zadania.
