Encontrar un Keylogger oculto a través de forzar un error de cálculo

2

Debe ser posible detectar el registro de teclas mediante un minucioso control de la sincronización entre la ejecución física de las pulsaciones de tecla y la eventual aparición del personaje en la pantalla.

Un amigo me mostró esto con su cámara. La cámara puede grabar a 16,000 cuadros por segundo. Se grabó a sí mismo escribiendo la letra 'a' en el programa 1, luego, en la reproducción a cámara lenta, la cantidad de tiempo que transcurrió entre la aparición de caracteres en la pantalla difería en el programa 2 o el programa 3, etc.

Esto me hizo pensar. Quizás un keylogger pueda detectarse rápidamente sin tener que lidiar con el diseño malicioso de un keylogger inteligente que puede detectar cuándo se detecta si se analizan este tipo de datos. Si uno conoce las expectativas, y hay una pequeña diferencia de tiempo en este tipo de escala sin que se ejecuten otros procesos, tal vez se pueda deducir algo de dichos datos.

No estoy seguro de si esta pregunta es clara, pero me gustaría saber si hay algún mérito para poder detectar los keyloggers a través del análisis fuera del dispositivo; es decir, como una cámara sofisticada de este calibre utilizada para medir el tiempo de aparición de caracteres.

Tal vez se podría hacer que un dispositivo físico presione las teclas del teclado más rápido de lo que puede realizar una mano humana para generar un error que podría analizarse. Quizás este error pueda ser útil.

Es difícil de calcular lo que te concedo porque probablemente nunca has estado en contacto con una cámara como esta y has visto los resultados como lo he hecho yo. De todos modos, tal vez alguien tenga algo que ofrecer.

    
pregunta Aard-Wolf 15.03.2014 - 08:48
fuente

8 respuestas

7

El gran problema con el que se encontrará si intenta encontrar un keylogger analizando la latencia de la pulsación de tecla es la frecuencia de actualización del monitor: la mayoría de los monitores solo se actualizan 60 veces por segundo. Un buen keylogger solo agregará unos pocos microsegundos de latencia, por lo que incluso antes de tomar en cuenta otras fuentes de ruido (como la aleatoriedad del programador), tiene una desventaja en lo que es esencialmente una relación de señal a ruido de 1: 10000 . Sí, es posible encontrar una señal muy por debajo del piso de ruido (consulte límite de Shannon ), pero no es fácil. / p>     

respondido por el Mark 18.03.2014 - 06:04
fuente
5

En la práctica, esto no funcionará. Hay demasiadas otras cosas sucediendo en una computadora. Cuando presiona una tecla, el SO interpreta la presión de la tecla y luego envía notificaciones a cualquier aplicación que preste atención a la presión de las teclas. El problema es que, en un momento dado, su computadora está realizando numerosas actividades de fondo. No hay una manera particular de juzgar cuánto tiempo debe tardar en registrarse la pulsación de tecla, ya que el SO puede tardar diferentes tiempos en procesar y enviar el evento para la pulsación de tecla porque está trabajando en cosas no relacionadas. / p>

Del mismo modo, la cantidad de esfuerzo que tomará un registrador de claves para recibir notificaciones y registrar el evento es minúscula y se puede ejecutar en un subproceso diferente del sistema operativo. Una táctica más efectiva sería monitorear la cantidad de servicios que están siendo notificados de eventos clave y buscar una discrepancia entre el número esperado y el número que realmente se produce, pero esto no le permitiría simplemente indicar el tiempo. El tiempo va a ser intrínsecamente demasiado variable con muy poco retraso causado por el registrador. Ni siquiera podría usar un programa que simplemente midiera el tiempo de CPU del proceso que le preocupa, ya que el retraso inducido por el registrador de claves estará en el lado del sistema operativo mientras el proceso se encuentre en estado de espera.

(También como se mencionó en otra respuesta, tratar de hacerlo visualmente no funcionará, ya que la actualización del monitor es demasiado lenta).

    
respondido por el AJ Henderson 19.03.2014 - 04:09
fuente
4
  

Quizás esto sea algo un poco más alto de lo que la mayoría de las personas en este sitio pueden responder porque tienen un fondo débil ...

Esto va a ir a lugares ...

  

Debe ser posible detectar el registro de teclas mediante un minucioso control de la sincronización entre la ejecución física de las pulsaciones de tecla y la eventual aparición del personaje en la pantalla.

No, esa aserción no es válida. Los registradores clave no tienen que introducir un retraso, e incluso para los que lo hacen, es probable que el retraso sea tan pequeño que esté bien dentro de los muchos retrasos introducidos en otras partes del sistema, que serán imposibles de aislar. p>

Entonces, no. Este tipo de dispositivo no puede detectar todos los keyloggers (¿alguno?); para el fondo, se pueden hacer keyloggers físicos para leer solo de forma parasitaria las señales que van directamente del teclado a la computadora sin tener que introducir ningún retraso. ¿Qué esperas de tu dispositivo en este escenario?

La demora introducida de un dispositivo en línea en cualquier caso va a ser extremadamente difícil de detectar de todos modos: su cámara de 16k fps no es el problema, y es relativamente redundante dado que un gopro será lo suficientemente rápido como para mantenerse al día. La frecuencia de actualización de las pantallas.

Los keyloggers de software serán igualmente imposibles de intentar y medir, ya que hay muchos procesos iniciados como parte de un sistema operativo moderno que pueden introducir retrasos de tiempo que es imposible aislar y culpar a un presunto keylogger de software: Registradores de teclas y puntos de referencia de rendimiento

    
respondido por el pacifist 19.03.2014 - 03:33
fuente
3

Dependiendo de la tecnología del keylogger, sí, hay una situación particular en la que la información de tiempo podría producir que algo haya cambiado. Un keylogger USB que se implementa como un dispositivo compuesto o hub agregará un retraso cuando se compara con el mismo sistema sin keylogger. Sin embargo, debe medir el tiempo en la computadora host: el tiempo de pulsación de tecla a pantalla es tan poco confiable que no tiene sentido.

Como dijo otra respuesta, no puedes detectar un keylogger parásito usando información de tiempo. Y un keylogger de software estaría mejor expuesto a través de una exploración del sistema y un seguimiento de la pila.

La mejor respuesta es decir "no de forma confiable".

    
respondido por el John Deters 19.03.2014 - 06:24
fuente
2

En teoría, usted tiene razón, puede comparar el tiempo de acierto y el tiempo de aparición y determinar si es legítimo o no.

Sin embargo, en realidad, enfrentará tantas razones para que este tiempo fluctúe y será imposible obtener una proporción de detección decente.

    
respondido por el ack__ 18.03.2014 - 04:03
fuente
1
  

Tal vez se podría hacer que un dispositivo físico presione las teclas del teclado más rápido de lo que puede realizar una mano humana para generar un error que podría analizarse. Quizás este error podría ser útil.

No. De hecho, puede crear dicho dispositivo por aproximadamente $ 2. Simplemente conecte un ATTiny45 y unos pocos pasivos a su puerto USB y podrá descargar el USB a través del bit los pines GPIO. A partir de ahí, la implementación de un teclado HID es bastante trivial. El código existe.

Pero no vas a sacar nada significativo de ello. El error que se produce cuando las pulsaciones de teclado se producen más rápido de lo que la máquina puede procesar (probablemente lo haya visto cuando su computadora estaba demasiado ocupada) es un solo pitido por pulsación de tecla. Ese es el bucle de eventos de Windows que descarta el evento de pulsación de tecla y continúa.

  

Tal vez se pueda detectar un keylogger ... si se conocen las expectativas, y existe una ligera diferencia de tiempo en este tipo de escala sin que se ejecuten otros procesos, tal vez se pueda obtener algo de esos datos.

Es una idea interesante, y puede funcionar en un entorno de laboratorio cuidadosamente controlado, tal vez en una configuración única. Pero es fundamentalmente un problema de señal a ruido. Hay un lote que sucede entre una pulsación de tecla y cuando se muestra un carácter, y la velocidad de Ese proceso depende de todo tipo de factores. No va a ser consistente entre máquinas o incluso en una sola máquina de minuto a minuto.

Detectar un retraso causado por un keylogger podría ser posible si puedes mantener el resto de la constante de retraso, pero en una computadora del mundo real, no puedes. E incluso si pudiera, un keylogger podría modificarse de forma trivial para simplemente poner en cola los eventos de pulsación de teclas en un búfer y procesarlos en lotes, eliminando efectivamente el retraso por pulsación de tecla. El que escribí hace 15 años hizo precisamente eso.

    
respondido por el tylerl 21.03.2014 - 02:47
fuente
1

Otra respuesta para agregar al coro de "No funcionará:"

Es posible crear un keylogger que se ejecute como el usuario del sistema que simplemente actúa como un demonio separado: un programa separado que escucha todas las pulsaciones de teclas. Ya que el sistema operativo es aparentemente el primer actor en "escuchar" una pulsación de una tecla y reenvía esa señal a cualquier programa de escucha, cualquier keylogger que no se coloque a sí mismo en medio el sistema operativo y el proceso evitará perfectamente éxitos de rendimiento.

ACTUALIZADO

Comencé a buscar una forma de persistir el malware en una GPU ... y luego se me ocurrió la idea "¿Qué tal si instalamos un keylogger en el espacio de memoria de la GPU >" Las GPU utilizan controladores de hardware, por lo que se ejecutan en el espacio del kernel ... por lo tanto elevados. ¡Suena como una buena herramienta de rootkit!

Y luego vine este documento . Maldita sea. ¡Alguien lo pensó hace un año!

Aquí es cómo funciona el programa: el proceso escanea la memoria para ubicar el código del controlador del teclado USB, luego pasa esa dirección al malware invocado en la GPU y luego usa el Acceso directo a la memoria (DMA) para simplemente inspeccionar la memoria donde el controlador del teclado almacena su búfer para las pulsaciones de teclas ... Odio decirte esto, pero debido a los subprocesos múltiples, nunca puedes estar seguro de que un proceso del kernel no pueda ver esos búferes de memoria donde vienen las pulsaciones en, y omite por completo la API estándar del sistema operativo que observa las pulsaciones de tecla ... este ataque se elimina de forma efectiva de cualquier tipo de detección de tiempo. También argumenta directamente por qué es una mala idea que nuestra informática esté limitada a una máquina de dos estados, pero esa es una queja diferente para otro día ...

    
respondido por el avgvstvs 19.03.2014 - 12:05
fuente
0

El análisis de los retrasos en las pulsaciones de teclas no es la forma correcta de identificar un keylogger.

Utilice el Explorador de procesos y revise los procesos existentes.

enlace

seleccionar columnas - línea de tiempo del proceso

identifique qué proceso está comenzando con la computadora que puede ser roja. A menudo se destacarán en varios colores el proceso de sospecha.

También puedes consultar el total de virus.

seleccione columnas - ubicación de inicio automático - si esto no es normal, entonces esto también puede dar una idea.

puede utilizar este tipo de análisis de malware para buscar este proceso de keylogger de colorete que se ejecuta en segundo plano y, más aún, probablemente enganchado en Svchost.

Si esto está más allá de su nivel de habilidad, puede ejecutar bytes de malware y otros escáneres similares para ayudar a identificar este tipo de software que se instaló y que ha bloqueado su PC.

    
respondido por el Jon_Little-Sec Engineer 20.03.2014 - 18:15
fuente

Lea otras preguntas en las etiquetas