Sia la console VBR sia Veeam ONE ci permettono di avere qualche dettaglio su cosa ha fatto scattare gli allarmi di potenziale compromissione nei backup, ovvero segnalare che il salvataggio che abbiamo fatto potrebbe essere già compromesso e, in caso di attacco, fare restore da quel punto potrebbe riportare indietro le cose non abbastanza, ovvero non a prima della infezione.
Insomma ONE non è indispensabile per essere avvisati, però… a mio avviso va messo sempre, a costo di metterlo nella versione free. Vabbè, comunque i messaggi sono analoghi, ma il dettaglio completo si trova solo dentro alcuni file testuali. Per fortuna la loro locazione è rammentata in ogni alert delle GUI.
Come già sanno quelli che hanno la sfortuna di sentirmi spesso, “aborro” l’eccesso di separazione in 1000 funzioni all’interno degli IT aziendali. Qui abbiamo un altro esempio: se chi si occupa dei backup non sa niente di sistemi operativi, di applicazioni “middleware” e dei flussi aziendali, in queste analisi si perderà inutilmente.
In questo mio breve post analizzo un paio di allarmi, uno è facilmente individuabile come falso positivo perché è una VM Kali, che contiene le armi dei cattivi.
Un altro è un po’ più curioso, essendo una applicazione che modifica in modo continuo e “robotico” file e directory, quindi comportandosi in modo sospetto.
https://blog.tinivelli.com/veeam-malware-investigations-examples/
nota birichina: mi sa che andrò sul forum R&D a far presente che i due log file hanno una naming convention diversa per la data, l’uno è aaaa-mm-dd l’altro ha ancora il millenium bug: aa-mm-dd. Sarebbe il caso di uniformarli 😎