{"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\/es\/blog\/administrirovanie\/sysmon-teper-mozhet-zapisyvat-soderzhimoe-bufera-obmena","title":{"rendered":"Sysmon ahora puede registrar el contenido del portapapeles","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El lanzamiento de la versi\u00f3n 12 de Sysmon se anunci\u00f3 el 17 de septiembre en la p\u00e1gina de Sysinternals<\/a><\/noindex>. De hecho, ese d\u00eda tambi\u00e9n se lanzaron nuevas versiones de Process Monitor y ProcDump. En este art\u00edculo voy a hablar sobre la nueva y controvertida funci\u00f3n clave de la versi\u00f3n 12 de Sysmon: el tipo de eventos con Event ID 24, que registra operaciones con el portapapeles.<\/p>\n

\"Sysmon
\n
\nLa informaci\u00f3n de este tipo de eventos abre nuevas oportunidades para el control de actividades sospechosas (adem\u00e1s de nuevas vulnerabilidades). De este modo, podr\u00e1s entender qui\u00e9n, de d\u00f3nde y qu\u00e9 exactamente intentaron copiar. A continuaci\u00f3n se describe algunos campos del nuevo evento y un par de casos de uso.
\n<\/a><\/noindex>
\nEl nuevo evento contiene los siguientes campos:<\/p>\n

Imagen:<\/b> el proceso cuyos datos fueron escritos en el portapapeles.
\nSesi\u00f3n:<\/b> la sesi\u00f3n en la que se realiz\u00f3 la escritura en el portapapeles. Esto puede ser system(0)
\n al trabajar en modo interactivo o remoto, etc.
\nClientInfo:<\/b> contiene el nombre del usuario de la sesi\u00f3n, y en el caso de una sesi\u00f3n remota, el nombre de host de origen y la direcci\u00f3n IP, si esos datos est\u00e1n disponibles.
\nHashes:<\/b> determina el nombre del archivo donde se guard\u00f3 el texto copiado (de manera similar a los eventos del tipo FileDelete).
\nArchivado:<\/b> el estado, si el texto del portapapeles fue guardado en el directorio de archivos de Sysmon.<\/p>\n

Los dos \u00faltimos campos generan preocupaci\u00f3n. La cuesti\u00f3n es que a partir de la versi\u00f3n 11, Sysmon puede (con la configuraci\u00f3n adecuada) guardar diferentes datos en su directorio de archivos. Por ejemplo, el Event ID 23 registra eventos relacionados con la eliminaci\u00f3n de archivos y puede guardarlos en el mismo directorio de archivos. A los nombres de los archivos creados como resultado de operaciones con el portapapeles se les a\u00f1ade la etiqueta CLIP. Los archivos en s\u00ed contienen los datos exactos que fueron copiados en el portapapeles.<\/p>\n

As\u00ed se ve el archivo guardado<\/b>
\n \"Sysmon<\/p>\n

\nEl guardado en archivo se activa durante la instalaci\u00f3n. Se pueden configurar listas blancas de procesos que no guardar\u00e1n texto.<\/p>\n

As\u00ed se ve la instalaci\u00f3n de Sysmon con la configuraci\u00f3n adecuada del directorio de archivos:<\/b>
\n \"Sysmon<\/p>\n

\nAqu\u00ed, creo que vale la pena recordar a los administradores de contrase\u00f1as que tambi\u00e9n utilizan el portapapeles. Tener Sysmon en el sistema con un administrador de contrase\u00f1as te permitir\u00e1 (o a un atacante) capturar estas contrase\u00f1as. Si asumes que sabes qu\u00e9 proceso est\u00e1 asignando el texto copiado (y no siempre es el proceso del administrador de contrase\u00f1as, podr\u00eda ser algo como svchost), se puede a\u00f1adir esta excepci\u00f3n a la lista blanca y no guardar.<\/p>\n

Puede que no lo supieras, pero el texto del portapapeles es capturado por el servidor remoto al cambiar a \u00e9l en modo de sesi\u00f3n RDP. Si tienes algo en el portapapeles y cambias entre sesiones RDP, esta informaci\u00f3n viajar\u00e1 contigo.<\/p>\n

Resumamos las capacidades de Sysmon en relaci\u00f3n con el portapapeles.<\/p>\n

Se registra:<\/p>\n