¿Alguien está al tanto de un procedimiento de Windows 7 en el que el atacante puede acceder al equipo host de forma remota a través de RDP en el puerto 3389, e implementar el exploit utilman y / o stickykey?
afaik the exploit exploit fue un ataque local. No sabía que pudiera implementarse de forma remota.
-
Hechos:
-
La máquina host es un servidor, siempre encendido, ejecutando 7 ultimate
-
La máquina host tenía una contraseña numérica de más de 9 dígitos que no estaba entre las 1000 peores contraseñas, pero estaba en la lista de los 10000 principales.
-
El equipo host tenía el puerto 3389 abierto y RDC estaba habilitado.
-
El primer intento de RDC ocurrió la noche anterior, y el equipo host estuvo en la pantalla de bloqueo toda la noche.
-
Se notó el ataque cuando el usuario comenzó a trabajar y notó que el servidor estaba en la pantalla de bloqueo. El usuario inmediatamente intentó desbloquear la computadora a través de utilman > osk.exe y tuvo éxito. Segundos después, la máquina host se colocó en la pantalla de inicio de sesión. El usuario intentó desbloquear a través de utilman, pero esta vez apareció un mensaje que decía "Ingrese la contraseña para el archivo cifrado: C: \ Windows \ wpmsvc.exe" El usuario pudo iniciar sesión después de conectar un teclado físico e inmediatamente deshabilitó el adaptador de red.
Se crearon varios archivos en el momento del incidente, así como una nueva cuenta de administrador.
Los archivos que se crearon son los siguientes:
Despuésderevisarlosregistrosdeeventos,seconfirmóquelanuevacuentadeusuariosecreóenestemomento,noantes,apesardelintentodeconexiónquetuvolugarlanocheanterior.(Otrochicosediocuentadeestocuandosalíadelanocheanterior,peroconfirmóestoperonosabíaqueestoeraanormaly,porlotanto,noloinformó.Sinembargo,elchicodeAMsabíaqueestamáquinasiempredeberíaestarconectadaydesbloqueada)
AlrevisarelarchivoRDPWrap.ini,seconfirmóqueelatacanteintentabapermitirmúltiplesconexionessimultáneasalescritorioremoto.Presumiblementeparapoderconectarsesinbloquearlapantalla.
SupuseporprimeravezquesetratabadeunataqueogusanoautomatizadoquebuscaenInternetpuertosRDPabiertos.Asumíestoporqueparecequeelataquerequeríaqueelusuarioloiniciarahaciendoclicenelbotónutilman(lamarcadetiempoenlacreacióndelanuevacuentadeusuarioeralahoradelincidente).Solohabíaunacuentaenlamáquinahostantesdelincidenteysolodosdespués(elAdministradorestabadeshabilitado),porloqueasumíqueelatacantenopodíaaccederalacuentaprincipal(sipudieraserinnecesario,¿verdad?)
Despuésdeverlosregistros,sinembargo,notéunIDdeeventode25"Servicios de escritorio remoto: la reconexión de la sesión se realizó correctamente:" con una IP rusa, así como una dos horas antes.
Y bajo los servicios de terminal, los registros del administrador de conexión remoto veo cientos de usuarios aleatorios bajo el ID de evento 1149 "Servicios de escritorio remoto: autenticación de usuario exitosa:" todos de IP europeos y nombres que indican que son de negocios y cómputos de puntos de venta negocios al azar, que abarcan los días anteriores.
Comprendo cómo se hizo esto en su mayor parte, con la excepción de que fue posible cambiar a utilman con otro archivo de forma remota a través de RDC (sin un inicio de sesión activo) para iniciar el truco.
Y si pudieran iniciar sesión con la cuenta principal y única de usuario (¿por qué otra cosa iría a la pantalla de bloqueo a menos que haya un inicio de sesión exitoso?), entonces ¿por qué tenían que hacer el exploit de utilman para crear otra cuenta? ¿No podrían simplemente crearlo de la manera normal?
¿Alguna idea?
por cierto, solo pude encontrar una referencia a este método, específicamente las páginas 20-26 de esta guía en pdf en chino que no puedo leer completamente.