Terminación de un proceso antivirus protegido

Question

Estoy usando el antivirus ESet, y recientemente su GUI front-end egui.exe colgó y estaba tomando 50% de CPU (es decir, 100% de un núcleo). Sorprendentemente, descubrí que no puedo matarlo, incluso con privilegios de depuración habilitados.

Ahora tengo curiosidad: ¿cómo implementan tal defensa, y hay una manera de matarlo sin escribir un controlador de kernel?

El proceso egui.exe se ejecuta bajo un usuario normal (no administrador), e intento eliminarlo de varias maneras con una cuenta administrativa. Esto es lo que intenté.

• no se puede matar desde el administrador de tareas
• no se puede acabar con él utilizando pskill
• no se puede acabar con él utilizando el explorador de procesos, ni se puede adjuntar un depurador a ella

Entonces empecé alguna programación y encontró que:

• en usuario no privilegiado puede abrirlo con PROSESS_TERMINA Acceso TE, pero la llamada real a TerminateProcess() falla con el error 5.

• en cuenta de administrador puede abrirlo con los derechos de acceso que desee (después de habilitar el privilegio de depuración, por supuesto), pero luego llama a TerminateProcess(), GetKernelObjectSecurity(), SetKernelObjectSecurity() todo con el error 5.

Esto definitivamente apunta a algún tipo de tocar el violín más allá de establecer el proceso DACL, ya que si no fuera Terminar en la DACL, no sería capaz de abra el proceso con PROCESS_TERMINATE en primer lugar. ¿Están realmente interceptando las llamadas API de Win32? ¿Si es así, entonces cómo? Ha pasado un tiempo desde que hice la programación de bajo nivel del sistema, perdón por mi ignorancia.

Answer 1

Si puede obtener el "Verificador de virginidad del sistema" de Joanna Rutkowska, esto debería darle una muy buena idea donde implementan sus ganchos. Se pueden usar herramientas similares (incluyendo GMER) para investigar qué está sucediendo en las entrañas del sistema. Puede sonar extraño, pero a veces los AV utilizan técnicas que también se encuentran comúnmente en software malicioso, es decir, técnicas de rootkit, en un intento de proteger su software de ser engañado.

Parece que SSDT-Hooking y técnicas similares se han utilizado para "proteger" el proceso. Mi primer intento sería suspender todos los hilos del proceso. La mayoría de estos mecanismos de protección (de malware y antimalware por igual) se activan solo en intentos de finalización. Pero una vez que suspende todos los subprocesos (Process Explorer puede hacer eso) el planificador ya no programará ninguno de ellos (lo que no ocasionará el uso de la CPU).

SSDT (a veces SDT) significa System Service Descriptor Table. Es la tabla con las direcciones de función de los servicios del sistema (el número del servicio del sistema es el índice). Cuando llamas a algo como CreateFile desde tu aplicación Win32, terminará en NTDLL llamando al NtCreateFile (== ZwCreateFile en UM). A partir de ahí, el mecanismo (que ha cambiado desde Windows 2000/XP) diferirá en la forma en que pasa al modo núcleo (KM), también conocido como "anillo 0". De todos modos, la implementación de NtCreateFile en NTDLL hace más o menos lo siguiente: mueve el índice del servicio del sistema a un registro y luego invoca el método que se usa para hacer la transición a KM (sysenter opcode en implementaciones más nuevas). Al llegar a KM, el controlador verificará el índice, calculará la dirección de la función desde el SSDT y luego llamará a esa función. Hay algo más de comprobación de la pila de mensajería unificada aquí (cuando vienes de la mensajería unificada), pero este es el proceso en términos simples. Por lo tanto, cuando conecta la funcionalidad a este nivel, puede evitar que cualquier subsistema, incluido el subsistema Win32, haga cosas. Sin embargo, esto tiene varios problemas asociados (el tuyo es el menor de ellos). La mayoría de los implementadores hacen un mal trabajo, que a menudo se ve en malware, como el rootkit que Sony eligió para colocar algunos CDs de audio en 2005. Así que desconectarlo es virtualmente imposible sin arriesgar una comprobación de errores y varias partes de código independientes conectadas El índice SSDT también suele generar problemas debido a la imprudencia de parte de los implementadores.

Así que suspender los hilos parece una posibilidad, aunque esta pregunta por supuesto es algo indefinida (sin conocer los detalles de los controladores de ESET). Sin embargo, si también lo previenen, deberían considerar cambiar los productos. Apuesto a que las desventajas de la estabilidad del sistema de dichos productos superan a la "protección" adicional, aunque (ESET) te dirá lo contrario.

Otro método posible podría ser inyectar código (por ejemplo, a través de una DLL) y hacer que el proceso llame al ExitProcess. Esto también depende de si sus ganchos permiten o no esta laguna.

Answer 2

Puede haber casos diferentes, dicen:

1. Si un hilo hijo del proceso que está intentando matar está esperando en algún objeto de núcleo, no va a ser terminado hasta que la espera ha terminado. Esto puede hacer que la aplicación deje de responder. Cualquier subproceso en el proceso está marcado para la finalización; es uno de los pasos de terminación del proceso;
2. Software tan inteligente como cortafuegos, AV y otras cosas relacionadas con la seguridad siempre instala ganchos kernel (también conocido como enganche, interceptando llamadas API, mensajes o eventos pasados ​​entre objetos kernel o componentes de software). Siempre tienen un escudo para proteger a las fuerzas externas.

Usted está recibiendo ERROR_ACCESS_DENIED. No sé qué pasos siguió, pero le sugiero que lo haga:

1. Abra el Administrador de tareas y vaya a la pestaña Procesos;
2. Haga clic derecho en egui.exe y haga clic en Propiedades;
3. Haga clic en la pestaña Seguridad y luego en Editar.
4. En la ventana Permisos, verifique sus credenciales;
5. Agregue un usuario y/o configure los permisos completos.

Puedes jugar con eso, porque incluso cuando inicies tu aplicación (eso es lo que intentaste hacer, supongo) usará las credenciales de tu cuenta.