Malwarebytes segnala un «Trojan» in ingresso sul web server: come leggere le detection e capire il rischio reale

La console dell’antivirus segnala un «Trojan» sul web server, con connessione in ingresso sulla porta 80. Il primo istinto è pensare a un server compromesso. Nella maggior parte dei casi non è così: è un bot che bussa alla porta ed è stato fermato. In questo articolo vediamo come leggere le detection di Malwarebytes Endpoint Agent (ThreatDown) direttamente dall’endpoint, come interpretare una detection di tipo Website/Inbound Connection e quali verifiche fare per capire se il rischio è reale.

Il caso

Su un server Windows con IIS che pubblica un sito aziendale, la console ThreatDown Nebula mostra una serie di detection classificate come Trojan, categoria Website, direzione Inbound Connection, processo System, porta locale 80. L’amministratore vuole due cose: vedere l’elenco delle detection da riga di comando sull’endpoint, senza passare dalla console, e capire quanto è grave lo specifico rischio.

Leggere le detection da riga di comando

Il primo strumento che viene in mente è EACmd.exe, l’utility a riga di comando dell’Endpoint Agent. Secondo la documentazione ThreatDown, però, i suoi switch servono per diagnostica, aggiornamenti, identificativi macchina e test di connessione: non esiste un comando documentato per elencare le detection. Conviene comunque controllare cosa espone la propria build, perché l’elenco cambia tra versioni:

cd "C:\Program Files\Malwarebytes Endpoint Agent\UserAgent"
EACmd.exe -?

Due switch sono comunque utili: EACmd.exe -diag genera un pacchetto diagnostico con i log dell’agente e del motore, e EACmd.exe -getmachineids restituisce gli identificativi con cui l’endpoint è registrato nella console.

I risultati di scansione salvati in locale

Sui sistemi Windows il motore di protezione è il servizio MBAMService, che salva i risultati delle scansioni sotto C:\ProgramData\Malwarebytes\MBAMService\ScanResults\. Il primo tentativo di leggerli con ConvertFrom-Json fallisce con un errore del tipo Invalid JSON primitive: il file non è JSON puro, ma inizia con una stringa esadecimale di 64 caratteri, verosimilmente un hash SHA-256 di integrità anteposto al contenuto.

La soluzione è scartare il prefisso e partire dalla prima parentesi graffa. Lo script seguente è compatibile con Windows PowerShell 5.1, quello installato di default sui server: niente operatore ??, che esiste solo in PowerShell 7 e che in 5.1 produce l’errore Unexpected token ‘??’.

# Estrae le detection dai risultati di scansione locali di Malwarebytes (MBAMService)
# Compatibile con Windows PowerShell 5.1
$resultsPath = "C:\ProgramData\Malwarebytes\MBAMService\ScanResults"

# Restituisce il valore della prima proprietà valorizzata tra quelle indicate
function Get-FirstValue {
    param($Object, [string[]]$Names)
    foreach ($n in $Names) {
        if ($Object.PSObject.Properties.Name -contains $n -and $Object.$n) { return $Object.$n }
    }
    return $null
}

Get-ChildItem -Path $resultsPath -File | Sort-Object LastWriteTime -Descending | ForEach-Object {
    $file = $_
    $raw = Get-Content -Path $file.FullName -Raw -Encoding UTF8

    # Il file ha un prefisso hash: si parte dall'inizio del JSON
    $start = $raw.IndexOf('{')
    if ($start -lt 0) { Write-Warning "$($file.Name): nessun JSON in chiaro"; return }

    try { $j = $raw.Substring($start) | ConvertFrom-Json }
    catch { Write-Warning "$($file.Name): parsing fallito"; return }

    # I nomi delle proprietà possono cambiare tra versioni
    $threats = @(Get-FirstValue -Object $j -Names 'threats', 'detections')
    if ($threats.Count -eq 0 -or $null -eq $threats[0]) { return }

    foreach ($t in $threats) {
        [PSCustomObject]@{
            ScanFile   = $file.Name
            ScanDate   = $file.LastWriteTime
            ThreatName = Get-FirstValue -Object $t -Names 'threatName', 'name'
            Path       = Get-FirstValue -Object $t -Names 'fullName', 'path', 'objectPath'
            Action     = Get-FirstValue -Object $t -Names 'action', 'status'
        }
    }
} | Format-Table -AutoSize

Due accorgimenti: in PowerShell l’accesso alle proprietà non distingue tra maiuscole e minuscole, quindi non serve provare threatName e ThreatName separatamente; e i nomi dei campi vanno verificati aprendo un file reale, perché possono variare tra versioni del motore. Per salvare l’elenco basta sostituire Format-Table con Export-Csv.

Se i file risultano cifrati, o se serve un elenco completo e affidabile, la fonte autorevole resta la console. Le stesse detection si possono leggere da script tramite la Nebula API con credenziali client OAuth, filtrando per il machine_id dell’endpoint: è la strada più pulita per integrarle in uno strumento di monitoraggio.

Cosa significa davvero «Trojan – Inbound Connection»

Qui sta il punto più importante. Una detection Website/Inbound Connection con processo System sulla porta 80 non indica un trojan presente sul server. Significa che un indirizzo IP esterno, classificato come malevolo da Malwarebytes, ha aperto una connessione verso la porta HTTP, cioè verso HTTP.sys e IIS, e il modulo Web Protection l’ha bloccata.

L’etichetta «Trojan» descrive la reputazione dell’IP sorgente, non un file trovato sul disco. Nel caso analizzato, l’indirizzo segnalato risultava presente nella blacklist Spamhaus XBL/CBL, che raccoglie IP di macchine compromesse, era segnalato su AbuseIPDB e rilevato da honeypot per attività di crawling HTTP. Anche altri IP della stessa subnet avevano precedenti di scansione. Il profilo è quello di uno scanner automatico che cerca vulnerabilità sui server web esposti: rumore di fondo di Internet, non un attacco mirato.

Le verifiche da fare

Che la connessione sia stata bloccata non basta a chiudere il caso. Queste sono le verifiche che permettono di capire se c’è qualcosa di più.

1. Cosa ha chiesto l’IP: i log di IIS

È il dato più utile. Gli URL richiesti rivelano cosa cercava lo scanner: /.env, /wp-login.php, percorsi legati a vecchie CVE.

# Cerca nei log IIS le richieste provenienti dall'IP segnalato
$ip = "203.0.113.45"
Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC*\*.log" |
  Select-String -Pattern $ip -SimpleMatch |
  Select-Object -ExpandProperty Line

Le righe con status 200 sono quelle da approfondire. Se il blocco è avvenuto prima che la richiesta arrivasse a IIS è possibile non trovare nulla: in quel caso vanno controllati anche i log di HTTP.sys in C:\Windows\System32\LogFiles\HTTPERR\.

2. Nessun traffico in uscita

Il vero segnale di compromissione sarebbe una connessione dal server verso quell’IP o la sua subnet:

Get-NetTCPConnection | Where-Object RemoteAddress -like "203.0.113.*"

Nella console conviene filtrare le detection dello stesso endpoint e verificare che non ci siano eventi di tipo Outbound o File/Malware.

3. Reputazione e orari

Per approfondire la reputazione dell’IP sono utili AbuseIPDB, VirusTotal, Shodan e soprattutto GreyNoise, che distingue tra scanner di massa e attività mirate. Attenzione agli orari: prima di confrontare l’ora mostrata dalla console con i log di IIS, che di default sono in UTC, verificate in quale fuso è espressa.

Le azioni consigliate

Bloccare a monte. Meglio fermare la subnet sul firewall perimetrale che lasciare il traffico arrivare all’endpoint. Su un router MikroTik, ad esempio, basta un’address list con una regola di drop sulla chain forward:
```
/ip firewall address-list add list=blacklist address=203.0.113.0/24 comment="detection inbound"
```
Ridurre la superficie esposta. Se il sito deve rispondere solo in HTTPS, la porta 80 può essere chiusa o limitata al redirect.
Mettere un filtro davanti. Se le detection inbound si ripetono da molti IP diversi, gestirle una per una non scala: un WAF o un reverse proxy davanti al server filtra lo scanning prima che raggiunga l’applicazione.

In sintesi

Una detection «Trojan» in ingresso su un web server è quasi sempre un tentativo bloccato, non un’infezione. Ma va letta, non ignorata: i log di IIS dicono cosa cercava l’attaccante, l’assenza di traffico in uscita conferma che il server è pulito, e il blocco perimetrale riduce il rumore. Avere uno script che estrae le detection direttamente dall’endpoint rende questo controllo una routine di pochi minuti.

Gestite server esposti su Internet e volete un supporto per monitoraggio, hardening o risposta agli incidenti? Contattateci: il nostro team può aiutarvi a impostare controlli e procedure su misura.