{"id":94862,"date":"2020-09-22T19:42:18","date_gmt":"2020-09-22T17:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sysmon-teper-mozhet-zapisyvat-soderzhimoe-bufera-obmena"},"modified":"2020-09-22T19:42:18","modified_gmt":"2020-09-22T17:42:18","slug":"sysmon-teper-mozhet-zapisyvat-soderzhimoe-bufera-obmena","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sysmon-teper-mozhet-zapisyvat-soderzhimoe-bufera-obmena","title":{"rendered":"Sysmon ora pu\u00f2 registrare il contenuto degli appunti","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il rilascio della versione 12 di Sysmon \u00e8 stato annunciato il 17 settembre su pagina Sysinternals<\/a><\/noindex>. In effetti, in questo giorno sono state rilasciate anche nuove versioni di Process Monitor e ProcDump. In questo articolo parler\u00f2 della chiara e controversa novit\u00e0 della versione 12 di Sysmon: il tipo di eventi con l'ID Event 24, che registra le operazioni con il clipboard.<\/p>\n

\"Sysmon
\n
\nLe informazioni di questo tipo di eventi aprono nuove opportunit\u00e0 per il monitoraggio di attivit\u00e0 sospette (e vulnerabilit\u00e0). Cos\u00ec, potrete capire chi, da dove e cosa esattamente hanno tentato di copiare. Di seguito, una descrizione di alcuni campi del nuovo evento e un paio di casi d'uso.
\n<\/a><\/noindex>
\nIl nuovo evento contiene i seguenti campi:<\/p>\n

Immagine:<\/b> il processo da cui sono stati registrati i dati nel clipboard.
\nSessione:<\/b> la sessione in cui \u00e8 avvenuta la scrittura nel clipboard. Pu\u00f2 essere system(0) in modalit\u00e0 interattiva o remota, ecc.
\n ClientInfo:
\ncontiene il nome utente della sessione e, nel caso di una sessione remota, il nome host e l'indirizzo IP di origine, se disponibili.<\/b> Hash:
\nidentifica il nome del file in cui \u00e8 stato salvato il testo copiato (analogamente al funzionamento degli eventi di tipo FileDelete).<\/b> Archiviato:
\nArchived:<\/b> stato, se il testo \u00e8 stato salvato negli appunti nella directory di archivio di Sysmon.<\/p>\n

Gli ultimi due campi sollevano preoccupazioni. Infatti, dalla versione 11 Sysmon pu\u00f2 (con le impostazioni appropriate) salvare diversi dati nella sua directory di archivio. Ad esempio, l'Evento ID 23 registra gli eventi di eliminazione dei file e pu\u00f2 salvarli nella stessa directory di archivio. Ai nomi dei file creati a seguito delle operazioni con gli appunti viene aggiunto il tag CLIP. I file stessi contengono i dati esatti copiati negli appunti.<\/p>\n

Ecco come appare il file salvato<\/b>
\n \"Sysmon<\/p>\n

\nIl salvataggio in file viene attivato durante l'installazione. \u00c8 possibile impostare elenchi bianchi di processi per i quali il testo non verr\u00e0 salvato.<\/p>\n

Ecco come appare l'installazione di Sysmon con la configurazione appropriata della directory di archivio:<\/b>
\n \"Sysmon<\/p>\n

\nQui, credo, dovremmo menzionare i gestori di password, che utilizzano anche il clipboard. Avere Sysmon in un sistema con un gestore di password consentir\u00e0 di catturare queste password sia da parte vostra che da un potenziale attaccante. Supponendo che sappiate qual \u00e8 il processo che alloca il testo copiato (e questo non \u00e8 sempre il processo del gestore di password, ma potrebbe essere un svchost), questa eccezione pu\u00f2 essere aggiunta alla whitelist e non salvata.<\/p>\n

Forse non lo sapevate, ma il testo negli appunti viene catturato da un server remoto quando si passa a esso in modalit\u00e0 RDP. Se avete qualcosa negli appunti e passate tra le sessioni RDP, queste informazioni viaggeranno con voi.<\/p>\n

Riepiloghiamo le capacit\u00e0 di Sysmon nella gestione del clipboard.<\/p>\n

Si registrano:<\/p>\n