{"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 realt\u00e0, lo stesso giorno sono uscite anche nuove versioni di Process Monitor e ProcDump. In questo articolo parler\u00f2 di una novit\u00e0 chiave e ambigua della versione 12 di Sysmon: il tipo di eventi con Event ID 24, in cui viene registrato l'uso degli appunti.<\/p>\n

\"Sysmon
\n
\nLe informazioni di questo tipo di eventi aprono nuove possibilit\u00e0 di controllo sull'attivit\u00e0 sospetta (e nuove vulnerabilit\u00e0). In questo modo, potrai comprendere chi, da dove e cosa stava cercando 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 estratti i dati negli appunti.
\nSessione:<\/b> la sessione in cui \u00e8 avvenuta la registrazione negli appunti. Questo pu\u00f2 essere system(0)
\n durante il funzionamento in modalit\u00e0 interattiva o remota, ecc.
\nClientInfo:<\/b> contiene il nome utente della sessione e, nel caso di una sessione remota, il nome host originale e l'indirizzo IP, se questi dati sono disponibili.
\nHash:<\/b> determina il nome del file in cui \u00e8 stato salvato il testo copiato (analogamente al funzionamento con eventi del tipo FileDelete).
\nArchiviato:<\/b> stato che indica se il testo degli appunti \u00e8 stato salvato nella directory di archivio di Sysmon.<\/p>\n

Gli ultimi due campi suscitano preoccupazioni. Infatti, dalla versione 11 Sysmon pu\u00f2 (con le configurazioni appropriate) salvare diversi dati nella propria directory di archivio. Ad esempio, l'Event ID 23 registra eventi di eliminazione dei file e pu\u00f2 salvarli tutti nella stessa directory di archivio. Ai nomi dei file creati in seguito all'uso degli appunti viene aggiunto il tag CLIP. Questi file contengono dati esatti che sono stati copiati negli appunti.<\/p>\n

Ecco com'\u00e8 un file salvato<\/b>
\n \"Sysmon<\/p>\n

\nIl salvataggio su file \u00e8 abilitato durante l'installazione. \u00c8 possibile impostare whitelist di processi per cui il testo non verr\u00e0 salvato.<\/p>\n

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

\nQui, penso che valga la pena menzionare i gestori di password, che utilizzano anche gli appunti. La presenza di Sysmon nel sistema con un gestore di password ti permetter\u00e0 (o a un attaccante) di catturare queste password. Se ipotizziamo che tu sappia quale processo sta allocando il testo copiato (ed esso non corrisponde sempre al processo del gestore di password, ma pu\u00f2 essere un qualche svchost), questa eccezione pu\u00f2 essere aggiunta alla whitelist e non salvata.<\/p>\n

Potresti non saperlo, ma il testo negli appunti viene catturato da un server remoto quando si passa a esso in modalit\u00e0 sessione RDP. Se hai qualcosa negli appunti e ti sposti tra le sessioni RDP, queste informazioni viaggeranno con te.<\/p>\n

Riassumiamo le capacit\u00e0 di Sysmon nella gestione degli appunti.<\/p>\n

Registrati:<\/p>\n