ssh-enum

Studio di convalida statistica di CVE-2016-6210

Una ri-indagine riproducibile dell'enumerazione degli username OpenSSH utilizzando l'analisi statistica.

Questo progetto riesamina CVE-2016-6210, un side-channel temporale documentato di OpenSSH, per determinare se rimane osservabile su un moderno server Ubuntu utilizzando la configurazione PAM predefinita.

Invece di assumere che il comportamento pubblicato sia ancora valido, il progetto valuta le misurazioni dei tempi di autenticazione raccolte tramite probing manuale, Hydra e Metasploit utilizzando il test t di Welch e il d di Cohen per distinguere i segnali temporali genuini dal rumore di misurazione.

Lo studio ha riscontrato nessuna differenza temporale statisticamente significativa sulla configurazione predefinita testata, dimostrando il valore della sperimentazione riproducibile e della validazione basata su prove delle affermazioni di sicurezza pubblicate.

⚠️ Avviso legale

Questo progetto è stato condotto interamente all'interno di un ambiente di laboratorio isolato di proprietà. Tutti i risultati si applicano solo alla configurazione testata. Non testare mai sistemi che non possiedi o per i quali non hai esplicita autorizzazione scritta.

🎯 Dichiarazione del problema

Enumerazione degli utenti - la capacità di determinare se un nome utente specifico esiste su un sistema remoto senza credenziali valide. È un primo passo critico nella catena di attacco che porta al compromesso dell'account:``` Reconnaissance → [User Enumeration] → Password Attack → Access ↑ This project investigates here

Se un attaccante può distinguere "questo utente esiste" da "questo utente non esiste" analizzando le risposte del server, può ridurre drasticamente lo spazio delle chiavi per successivi attacchi di forza bruta o credential stuffing.

SSH è un bersaglio frequente perché è quasi universalmente esposto, gestisce l'autenticazione tramite password e le implementazioni più vecchie presentavano differenze di temporizzazione misurabili tra nomi utente validi e non validi (CVE-2016-6210).

**Questa indagine si pone due domande:**

1. OpenSSH moderno su Ubuntu 22.04.5 LTS con configurazione predefinita perde informazioni sull'esistenza degli utenti
   tramite messaggi di risposta, temporizzazione o segnali riportati dagli strumenti?
2. Se un attaccante tenta comunque l'attacco, quali artefatti lascia? e con quanta
   affidabilità possono essere rilevati?

---

## 🖥️ Configurazione del Laboratorio

Tutti i test sono stati eseguiti in una rete virtuale host-only completamente isolata, senza esposizione a internet.

| Macchina | Sistema Operativo          | Ruolo                                   | IP               | Versione SSH    |
|----------|----------------------------|-----------------------------------------|------------------|-----------------|
| Attaccante | Kali Linux 2024.1         | Strumenti offensivi, script di analisi | 192.168.56.5     | —               |
| Target   | Ubuntu Server 22.04.5 LTS | Esecuzione di OpenSSH con configurazione **predefinita** | 192.168.56.10    | OpenSSH 8.9p1   |

**Configurazione SSH di destinazione (`/etc/ssh/sshd_config` predefinita):**```
PasswordAuthentication yes
UsePAM yes                  # Key setting — normalises timing via dummy hash
PermitRootLogin prohibit-password
MaxAuthTries 6
LogLevel INFO

UsePAM yes è l'impostazione critica di hardening. Forza OpenSSH a eseguire un calcolo bcrypt fittizio per utenti inesistenti, eguagliando i tempi di un controllo password reale. Questo è stato introdotto specificamente come contromisura per CVE-2016-6210.

🔬 Metodologia

Ogni metodo di attacco è stato eseguito come prova indipendente con uno stato del log pulito:```bash

Reset log state on target before each trial

sudo truncate -s 0 /var/log/auth.log

After attack: collect evidence

sudo cp /var/log/auth.log ~/evidence/trial-N-auth.log

Evidenze raccolte per ogni prova:
- stdout/stderr dello strumento (salvati fedelmente)
- `/var/log/auth.log` dal target
- Campioni di temporizzazione delle risposte tramite `time.perf_counter()` in `manual_ssh.py`
- Banner SSH acquisito prima di qualsiasi tentativo di autenticazione

### Metodi di Attacco

| Metodo                   | Strumento                            | Wordlist                | Scopo                                           |
|--------------------------|--------------------------------------|-------------------------|-------------------------------------------------|
| SSH manuale              | `ssh` CLI + Paramiko                 | 50 nomi utente comuni   | Baseline; ispezionare risposte grezze           |
| Forza bruta con Hydra    | `hydra`                              | stessi 50               | Automatico; sfrutta la modalità enum integrata  |
| Modulo Metasploit        | `auxiliary/scanner/ssh/ssh_enumuser` | stessi 50               | Modulo di enumerazione dedicato del framework   |
| Impronta digitale banner | `BannerFingerprinter` personalizzato | N/A                     | Perdita di versione senza autenticazione, CVE   |
| Analisi temporale        | `ResponseAnalyzer` personalizzato    | subset valido vs invalido | Controllo statistico del canale laterale       |

---

## Cosa è Stato Realizzato

Questo progetto va oltre la semplice esecuzione di strumenti — incapsula ogni attacco e tutta la logica di rilevamento in un codebase Python strutturato e fornisce un orchestratore che esegue l'intera pipeline dall'inizio alla fine.

### Strumenti di Attacco (`src/attack_tools/`)

**`ManualSSHEnumerator`** — Testa ogni nome utente N volte con `paramiko`, registrando
temporizzazione precisa, tipo di risultato e banner SSH. Calcola media/deviazione standard per nome utente. Criticamente,
**non** riutilizza le connessioni tra tentativi, assicurando che ogni campione catturi il
tempo completo di elaborazione lato server.

**`BannerFingerprinter`** — Acquisisce il banner SSH su un socket TCP grezzo (nessuna credenziale
necessaria). Analizza il nome dell'implementazione, la stringa di versione e un suggerimento sul SO. Incrocia i riferimenti
con un registro CVE locale. Una versione come `OpenSSH_8.9p1 Ubuntu-3ubuntu0.6` rivela
l'esatto software server — potenzialmente sufficiente per identificare vulnerabilità note prima
che venga tentata qualsiasi autenticazione.

**`HydraAutomation`** — Wrapper per sottoprocesso attorno a Hydra. Analizza stdout per estrarre
login riusciti, messaggi di errore e il verdetto di enumerazione di Hydra stesso
(`does not support user enumeration`).

**`MetasploitScanner`** — Scrive uno script di risorse temporaneo e guida `msfconsole`
tramite sottoprocesso. Analizza l'output per il rilevamento di hardening e eventuali nomi utente trovati.

### Strumenti di Rilevamento (`src/detection_tools/`)

**`LogParser`** — Analizzatore di auth.log basato su espressioni regolari che supporta cinque tipi di eventi SSH:
`failed_invalid_user`, `failed_valid_user`, `pre_auth_reject`, `accepted`,
`disconnected`. Restituisce dizionari di eventi strutturati con timestamp, tipo di evento, nome utente,
IP sorgente e porta.

**`ResponseAnalyzer`** — Esegue il test t di Welch sulle distribuzioni di temporizzazione da nomi utente validi vs
non validi. Calcola delta di temporizzazione (ms), p-value, dimensione dell'effetto d di Cohen, e
una conclusione in linguaggio semplice. Soglia: delta ≥ 5ms AND p < 0.05 attiva un avviso
di canale laterale.

**`EnumerationDetector`** — Quattro pattern di rilevamento:
- **Sonde rapide di utenti**: finestra scorrevole - stesso IP, ≥10 nomi utente distinti entro 60s
- **Correlazione con wordlist**: tasso di corrispondenza tra nomi utente tentati e liste di attacco note
- **Temporizzazione sequenziale**: coefficiente di variazione sugli intervalli tra tentativi (basso CoV → strumento)
- **Sondaggio distribuito**: stesso nome utente da più IP (ricognizione per credential stuffing)

**`AlertingSystem`** — Emettitore di avvisi leggero. Genera avvisi JSON con timestamp su
stdout. Estendibile con integrazioni email/SIEM/webhook secondo necessità.

### Orchestratore

**`run_investigation.py`** — Driver CLI che esegue tutte e quattro le fasi in sequenza e scrive
i risultati in `data/results/`. Eseguire con `--help` per l'uso completo.```bash
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth.log \
    -known-valid root ubuntu \
    -samples 10

Osservazioni & Risultati

Finding 1: Consistenza delle Risposte — La Difesa Principale

Ipotesi testata: OpenSSH restituisce un messaggio di errore diverso per un utente inesistente rispetto a un utente esistente con password errata?```bash

Non-existent user

$ ssh [email protected] Permission denied (publickey,password).

Existing user, wrong password

$ ssh [email protected] Permission denied (publickey,password).

**Risultato:** Le risposte sono identiche byte per byte. Il protocollo non perde nulla.

**Perché:** Dalla versione 7.3 di OpenSSH, `UsePAM yes` forza il server a eseguire un'operazione fittizia `crypt()` per utenti inesistenti, eguagliando sia il tempo che il percorso di errore di un'autenticazione fallita reale. La correzione è stata una risposta diretta a CVE-2016-6210.

---

### Risultato 2: Nessun Canale Laterale Temporale Rilevato

**Ipotesi testata:** Anche se i messaggi di errore corrispondono, esiste una differenza temporale misurabile tra nomi utente validi e non validi che potrebbe essere sfruttata statisticamente?

Sono stati raccolti dieci campioni temporali per ciascuno dei 50 nomi utente. Gli utenti noti validi (confermati dal sistema) sono stati confrontati con il pool di utenti non validi.

| Metrica                      | Valore                               |
|------------------------------|--------------------------------------|
| Tempo medio — utenti non validi | ~312 ms                               |
| Tempo medio — utenti validi   | ~311 ms                               |
| Delta                        | **~1 ms**                            |
| Valore p del test t di Welch | > 0.40                               |
| Conclusione                  | **Nessun canale laterale distinguibile** |

Il delta di circa 1 ms è ben al di sotto della soglia di rumore di 5 ms e non è statisticamente significativo (p >> 0.05). Il calcolo hash fittizio di OpenSSH è efficace.

---

### Risultato 3: Hydra Segnala Nessun Supporto per l'Enumerazione

La modalità di enumerazione SSH di Hydra si basa su uno di tre segnali: messaggi di errore differenti, diverso timing o diverso comportamento di connessione. Con tutti e tre normalizzati, Hydra segnala esplicitamente:```
[ERROR] target ssh://192.168.56.10:22/ does not support user enumeration
[STATUS] 50/50 tries completed, 0 valid logins found

Effetto collaterale osservato: Nonostante il fallimento dell'enumerazione, tutti i 50 tentativi vengono registrati in /var/log/auth.log con IP sorgente, timestamp e nome utente tentato. La presenza dell'attaccante è completamente visibile.

Risultato 4: Metasploit rileva l'hardening prima di completare la scansione

Il modulo auxiliary/scanner/ssh/ssh_enumuser controlla la versione di OpenSSH dal banner prima di tentare l'enumerazione. Le versioni ≥ 7.3 con UsePAM yes vengono contrassegnate come hardened e il modulo termina anticipatamente:``` [] 192.168.xx.xxxx:22 - SSH - Checking for vulnerability [] 192.168.xx.xxxx:22 - SSH - Target is not vulnerable: OpenSSH 8.9p1 (hardened)

Questo è un risultato utile: il banner da solo comunica la postura difensiva del server a un attaccante prima che venga fatto qualsiasi tentativo di enumerazione.

---

### Risultato 5: Il rilevamento è affidabile anche quando l'enumerazione fallisce

Il punto chiave dal punto di vista del difensore: **l'attacco genera rumore anche quando non ha successo**. Tutti e quattro i pattern di rilevamento hanno funzionato correttamente contro il auth.log raccolto:

| Rilevamento            | Trigger                                       | Severità |
|------------------------|-----------------------------------------------|----------|
| Sondaggio rapido utenti | IP Kali ha sondato 50 nomi utente in <60s    | ALTA     |
| Correlazione wordlist  | 48/50 nomi tentati corrispondevano alla wordlist | ALTA     |
| Timing sequenziale     | CoV inter-tentativo = 0.04 (firma dello strumento) | MEDIA    |
| Sondaggio solo banner  | Disconnessioni pre-autenticazione prima dell'invio di qualsiasi nome utente | BASSA    |

---

## Processo di pensiero

### Perché prima l'enumerazione SSH manuale?

L'istinto di iniziare con test manuali era metodologicamente valido: prima di fidarsi dell'output dello strumento, è necessario capire cosa dice effettivamente il protocollo grezzo. Eseguire `ssh ghost@target` e osservare il messaggio di errore esatto ti dice se c'è *qualcosa* da enumerare prima di investire tempo nell'automazione.

La prima osservazione, che `Permission denied (publickey,password)` appare identico indipendentemente dal fatto che l'utente esista, è stata il risultato centrale. Tutto ciò che è seguito è stata la validazione di quel risultato.

### Assunzioni fatte (e riesaminate)

L'assunzione iniziale era che Hydra e Metasploit sarebbero stati *più* capaci dei test manuali, quindi se il manuale falliva, gli strumenti potevano ancora avere successo. Questo si è rivelato sbagliato nella direzione prevista ma corretto nel *perché*: gli strumenti non aggiungono capacità qui perché il protocollo stesso non perde il segnale. Gli strumenti sono solo automazione dello stesso protocollo.

Una seconda assunzione degna di esame: il primo tentativo manuale era notevolmente più lento dei successivi, e il tentativo con password corretta era veloce. Questo è stato inizialmente interpretato come un potenziale segnale di timing. Riflettendo, il rallentamento era dovuto al sovraccarico di stabilimento della connessione TCP in uno stato di rete fresco (risoluzione ARP, configurazione connessione), non al tempo di elaborazione lato server. Controllare questo — misurando da `time.perf_counter()` *dopo* l'handshake TCP, o scartando il primo campione — sarebbe stato più rigoroso. L'implementazione di `ManualSSHEnumerator` affronta questo raccogliendo 10 campioni per nome utente e riportando media/deviazione standard, che diluisce il rumore del primo campione.

### Cosa è cambiato durante il progetto

L'ambito originale era ristretto: eseguire tre strumenti, documentare se funzionano. Il progetto si è evoluto in due direzioni:

**Verso l'interno (analisi più approfondita):** Quando i risultati iniziali erano negativi, la domanda naturale è diventata *perché* — il che ha portato a leggere i changelog di OpenSSH, CVE-2016-6210 e l'implementazione di `UsePAM`. Comprendere il meccanismo è più prezioso che registrare solo il risultato.

**Verso l'esterno (pivot di rilevamento):** Un risultato negativo di attacco è comunque un punto dati difensivo utile. Il pivot verso "anche se l'enumerazione è fallita, cosa ha visto il server?" ha portato ai componenti di analisi dei log e ingegneria del rilevamento, che hanno trasformato un esercizio unidimensionale di esecuzione di strumenti in un'indagine a due facce.

### Cosa sarebbe stato fatto diversamente

Le misurazioni di timing sono state effettuate su una rete virtuale host-only, che introduce meno jitter di una rete reale ma significa anche che i risultati sono ottimistici. In un ambiente reale con latenza TCP, jitter e ritrasmissioni, il rumore di fondo sarebbe più alto e l'analisi di timing richiederebbe più campioni per nome utente. Una metodologia più robusta testerebbe su un collegamento WAN simulato (usando `tc netem` per introdurre latenza e jitter controllati) per vedere come le conclusioni reggono in condizioni realistiche.

---

## Rischi di sicurezza

Anche se l'enumerazione non ha avuto successo in questo laboratorio, la superficie di attacco e i rischi associati sono:

**Se l'enumerazione *fosse* possibile (ad esempio, OpenSSH più vecchio, `UsePAM no`, stack PAM personalizzato):**
- Gli attaccanti potrebbero restringere una campagna di forza bruta ai soli nomi utente confermati validi, riducendo il rischio di rilevamento e aumentando drasticamente l'efficienza.
- Combinato con lo spraying di password (una password comune per tutti i nomi utente validi), questo bypassa i lockout per utente di `MaxAuthTries`.

**Rischi che si applicano anche con la resistenza all'enumerazione:**
- Il banner SSH perde la versione esatta di OpenSSH e il sistema operativo. Un attaccante che vede `OpenSSH_8.9p1` può immediatamente verificare se CVE-2024-6387 (regreSSHion) è applicabile, prima di inviare un singolo pacchetto di autenticazione.
- Tutti i tentativi di enumerazione vengono registrati con IP di origine. Se il monitoraggio dei log è assente, un attacco lento (un tentativo all'ora) potrebbe sondare migliaia di nomi utente senza attivare avvisi basati sulla frequenza.
- `PasswordAuthentication yes` mantiene aperta la superficie di attacco basata su password anche se l'enumerazione non è fattibile. Gli attacchi di credenziali post-OSINT (utilizzo di elenchi di password violate contro nomi utente derivati da OSINT) non richiedono affatto l'enumerazione lato server.

---

## Strategie di mitigazione

| Minaccia                    | Mitigazione                                                       | Modifica di configurazione richiesta                    |
|-----------------------------|-------------------------------------------------------------------|---------------------------------------------------------|
| Canale laterale di timing   | Assicurarsi `UsePAM yes` (predefinito su Ubuntu)                  | Nessuna — già predefinito                               |
| Divulgazione versione del banner | `VersionAddendum none` e `DebianBanner no` in `sshd_config`    | Sì                                                      |
| Attacchi basati su password | `PasswordAuthentication no` — autenticazione solo con chiave       | Sì                                                      |
| Forza bruta dopo OSINT      | `fail2ban` con jail `sshd`                                        | Installare + configurare                                |
| Enumerazione lenta          | Invio log a SIEM; avviso su >N nomi utente distinti/IP/ora       | SIEM richiesto                                          |
| Login come root             | `PermitRootLogin no`                                              | Sì (il predefinito è `prohibit-password`)               |
| Disconnessioni pre-autenticazione | `MaxStartups 10:30:60` per limitare il rate delle connessioni non autenticate | Sì                                                      |

**Aggiunte minime raccomandate a `sshd_config` per un deployment rafforzato:**```
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
MaxStartups 10:30:60
VersionAddendum none
LogLevel VERBOSE

Miglioramenti Futuri

Il progetto attuale testa un protocollo in una configurazione. Estensioni naturali:

Enumera altri servizi sullo stesso host. SMTP (VRFY/EXPN), LDAP (query sugli attributi), moduli di login HTTP e SNMP sono tutti vettori comuni di leak di username sulla stessa macchina che è protetta su SSH. Uno studio comparativo tra i servizi produrrebbe un quadro di rischio più completo.

Testa configurazioni SSH non predefinite. UsePAM no, moduli PAM personalizzati, backend di autenticazione Kerberos e versioni più vecchie di OpenSSH (distribuite in sistemi embedded, apparati di rete) possono ancora presentare fughe temporali. Testare la stessa pipeline contro una configurazione deliberatamente vulnerabile dimostrerebbe il contrasto.

Rilevamento in tempo reale con inotify. L'attuale rilevamento viene eseguito a posteriori su un file di log copiato. Una versione di livello produttivo userebbe inotify (o tail -f + un thread parser) per rilevare e avvisare in tempo quasi reale, entro secondi dall'inizio di un tentativo di enumerazione.

Rilevamento a livello di rete. Auth.log è un artefatto basato sull'host. Completalo con il rilevamento a livello di pacchetto: connessioni TCP di breve durata alla porta 22 che si chiudono prima di completare l'handshake di autenticazione sono una firma di fingerprinting solo banner. Questo potrebbe essere implementato come regola Zeek o Suricata.

Notebook Jupyter per report statistici. I dati temporali raccolti sono adatti alla visualizzazione - box plot delle distribuzioni temporali per utente, grafici a dispersione della frequenza dei tentativi nel tempo, mappe di calore degli IP sorgente. I notebook renderebbero l'analisi riproducibile e condivisibile.

Struttura del Progetto```

ssh-enumeration-analysis/ │ ├── README.md ├── run_investigation.py ← Full pipeline orchestrator (start here) ├── requirements.txt │ ├── src/ │ ├── attack_tools/ │ │ ├── init.py │ │ ├── manual_ssh.py ← Paramiko-based timing probe │ │ ├── banner_fingerprinter.py ← No-auth banner grab + CVE lookup │ │ ├── hydra_automation.py ← Hydra subprocess wrapper │ │ └── metasploit_scanner.py ← MSF console automation │ │ │ └── detection_tools/ │ ├── init.py │ ├── log_parser.py ← auth.log regex parser │ ├── response_analyzer.py ← Welch t-test + Cohen's d │ ├── pattern_detector.py ← 4 detection patterns │ └── alerting_system.py ← JSON alert emitter │ ├── data/ │ ├── sample-logs/ │ │ ├── auth-baseline.log ← Normal SSH activity (no attacks) │ │ ├── auth-hydra-run.log ← Captured during Hydra trial │ │ └── auth-msf-run.log ← Captured during Metasploit trial │ │ │ ├── wordlists/ │ │ ├── common-usernames-50.txt │ │ └── common-usernames-100.txt │ │ │ └── results/ ← Auto-generated (gitignored) │ ├── investigation-summary.json │ ├── manual-enumeration-results.json │ ├── timing-analysis.json │ └── detection-report.json │ ├── tests/ │ ├── test_enumeration.py │ ├── test_detection.py │ └── test_log_parser.py │ ├── case-study/ │ └── User_Enumeration_attempt_using_manual_SSH.docx │ └── screenshots/ ├── manual-ssh-same-response.png ├── hydra-no-enumeration-support.png ├── metasploit-hardened-detected.png ├── auth-log-hydra-evidence.png └── detection-alerts-output.png

## ⚡ Avvio rapido```bash
# 1. Clone and install dependencies
git clone https://github.com/Alisha-chaudhary/ssh-enum
cd ssh-enum
pip install -r requirements.txt

# 2. Run just the banner fingerprint (no credentials needed)
python -c "
from src.attack_tools.banner_fingerprinter import BannerFingerprinter
r = BannerFingerprinter().grab('192.168.xx.xxxx')
print(r.raw_banner, r.cves)
"

# 3. Run the full investigation pipeline
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth-hydra-run.log \
    -known-valid root ubuntu \
    -samples 10

# 4. Analyse a log file only (no live target needed)
python -c "
from src.detection_tools.pattern_detector import EnumerationDetector
d = EnumerationDetector('data/sample-logs/auth-hydra-run.log')
import json; print(json.dumps(d.run_all(), indent=2))
"

Requisiti:``` paramiko>=3.3.1 scipy>=1.11.0 Hydra and Metasploit must be installed separately (pre-installed on Kali Linux).

---

## 📚 Riferimenti

| Risorsa                                                                              | Rilevanza                                       |
|--------------------------------------------------------------------------------------|-------------------------------------------------|
| [CVE-2016-6210](https://nvd.nist.gov/vuln/detail/CVE-2016-6210)                      | Il canale laterale temporale testato da questo progetto |
| [CVE-2024-6387 (regreSSHion)](https://nvd.nist.gov/vuln/detail/CVE-2024-6387)        | RCE non autenticata in OpenSSH ≤ 9.7            |
| [Manuale sshd_config di OpenSSH](https://man.openbsd.org/sshd_config)                | `UsePAM`, `MaxAuthTries`, `VersionAddendum`     |
| [OWASP — Enumerazione utenti](https://owasp.org/www-community/attacks/User_Enumeration) | Modelli generali di attacco di enumerazione     |
| [RFC 4252 — Protocollo di autenticazione SSH](https://tools.ietf.org/html/rfc4252)    | Specifica del protocollo; definisce il comportamento dei messaggi di errore |
| [Documentazione di fail2ban](https://www.fail2ban.org/wiki/index.php/Main_Page)      | Limitazione della frequenza e blocco IP         |

---

## 🎓 Competenze dimostrate

| Dominio                | Evidenza                                                                                                |
|------------------------|---------------------------------------------------------------------------------------------------------|
| Interni del protocollo SSH | Comprensione della normalizzazione temporale di `UsePAM`, fix per CVE-2016-6210, esposizione delle informazioni del banner |
| Sicurezza offensiva    | Uso pratico di Hydra, Metasploit e probing personalizzato con Paramiko in una metodologia strutturata   |
| Analisi statistica     | Test t di Welch, d di Cohen, coefficiente di variazione applicati ai dati temporali                     |
| Ingegneria del rilevamento | Rilevamento IOC basato su log attraverso quattro tipi di pattern; output di avviso strutturato          |
| Ingegneria Python      | Dataclasses, type hints, automazione subprocess, parsing regex, librerie statistiche                    |
| Ricerca sulla sicurezza | Ipotesi → esperimento controllato → raccolta di evidenze → risultati documentati → conclusioni attuabili |

---

**Stato:** Completato | **Testato su:** Ubuntu Server 22.04 LTS + OpenSSH 8.9p1 | Kali Linux 2024.1

ssh-enum

Più Popolari

Informazioni