Respuesta a incidentes de acceso remoto: lista de verificación de la primera hora

Si acaba de enterarse de que una herramienta de soporte puede haber sido el punto de entrada del atacante, la primera hora determina cuánto puede preservar, cuánto alcance puede limitar y si conserva opciones forenses. Este artículo ofrece un playbook operativo y priorizado para esa primera hora: qué hacer, qué recopilar y qué decisiones importan.

Quién necesita esto y qué ofrece este artículo

Está dirigido a IT, SOC y manejadores de incidentes que ya operan herramientas de soporte remoto (TeamViewer, AnyDesk, RDP, Tenvo, etc.). No es un manual forense profundo: es una lista de verificación operativa y breve para ejecutar en la primera hora cuando se sospecha que el canal de soporte fue el punto de entrada. Obtendrá una secuencia de triage priorizada, artefactos concretos para capturar, comprobaciones rápidas de indicadores, acciones de contención que evitan destruir evidencia y una breve lista de comunicación.

Triage inmediato: lista priorizada (primeros 0–60 minutos)

1. No entre en pánico; actúe en orden. La rapidez importa más que la creatividad. Siga los pasos en orden: saltarse la preservación para bloquearlo todo de inmediato dificulta las investigaciones.
2. Identifique las sesiones y usuarios sospechosos. ¿Quién inició la sesión de soporte? ¿Qué cuenta, nombre de usuario o dispositivo del técnico aparece en los logs de soporte? Anote marcas de tiempo (UTC) e IDs de sesión antes de alterar nada.
3. Preserve logs y evidencia primero. Extraiga los logs del servidor de acceso remoto, los logs del relay y cualquier grabación de sesión. Si la herramienta de soporte es gestionada en la nube, exporte los registros desde la consola de administración de inmediato. Si es necesario, haga un snapshot del sistema de soporte (memoria, disco) después de exportar.
4. Aísle, no destruya. Ponga en cuarentena el endpoint comprometido del resto de la red (VLAN, puerto de switch o bloqueos por firewall del host) pero evite apagarlo salvo que sea imprescindible. Desea preservar procesos, memoria y conexiones de red abiertas para el análisis forense.
5. Bloquee el acceso adicional de forma selectiva. Revoque o deshabilite la cuenta de soporte específica o la huella del dispositivo usada en la sesión sospechosa. No revoque todas las cuentas de soporte a ciegas a menos que esté listo para el impacto operativo.
6. Rote credenciales y secretos expuestos a ese dispositivo. Cambie contraseñas, claves API y cuentas de servicio a las que el host o la sesión comprometida tenía acceso —pero documente los cambios con precisión para los investigadores.
7. Notifique a las partes interesadas y habilite un canal de incidente. Informe al responsable de incidentes, legal/cumplimiento y al CISO. Use un canal de incidente preaprobado (chat o ticket) y nombre a un único comandante de incidentes para evitar acciones duplicadas.

Qué recopilar y preservar (lista de evidencia)

Recopilar los artefactos adecuados en la primera hora preserva opciones para determinar la causa raíz y el alcance. Priorice las exportaciones que pueda hacer de forma remota y no destructiva.

• Logs del software de acceso remoto: marcas de tiempo de inicio/fin de sesión, IDs de sesión, IPs de pares conectados, IDs de usuario/dispositivo, indicador de uso de relay y cualquier grabación de sesión.
• Logs de autenticación: logs de IdP, logs de push/ticket de MFA y cualquier registro de SSO que muestre la actividad de la cuenta de soporte con marcas de tiempo coincidentes con los eventos de sesión.
• Logs y memoria del endpoint: Windows Event Log (Security y System), Linux /var/log/auth.log y syslog, listas de procesos y volcado de memoria si es posible.
• Capturas de red: PCAPs desde el puerto de switch del endpoint, el firewall aguas arriba o un TAP. Capture al menos 60–120 segundos alrededor de las horas de sesión conocidas si la captura continua no está disponible.
• Logs de auditoría del relay/proveedor: si la sesión pasó por un relay gestionado, exporte los logs de conexión del proveedor del relay y las regiones/POPs utilizados.
• Instantáneas de configuración y políticas: configuración actual de la herramienta de soporte, listas de control de acceso, membresías de grupos, cuentas de administrador local y cambios de política recientes.

Win: wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text > log_4624.txt
Linux: sudo journalctl --since '2026-10-13 09:00:00' --until '2026-10-13 10:00:00' > auth-window.log
Network: sudo tcpdump -i any -s 0 -w suspect.pcap host 198.51.100.23

Cómo determinar si la herramienta de soporte fue el punto de entrada

No toda sesión de soporte sospechosa equivale a una compromisión. Estas comprobaciones ayudan a determinar si la sesión fue una herramienta post‑compromiso, el vector inicial o una omisión benigno.

• Sincronía de la sesión vs tiempo de detección. Si la sesión se inició antes de la primera detección (alerta de AV, creación de cuenta nueva o proceso sospechoso), es más probable que fuera el vector.
• Anomalías de credenciales. Busque nuevas huellas de dispositivo, nuevas claves API o una cuenta de soporte recién creada. Verifique si la sesión usó SSO o usuario/contraseña directa y si MFA fue omitido o no usado.
• Relay vs conexión directa peer-to-peer. Determine si el cliente se conectó directamente peer-to-peer (NAT hole-punch) o a través de un relay. En la mayoría de herramientas, la caída a relay implica que el punto de terminación del relay tiene visibilidad del tráfico de la sesión — capture esos logs del relay y los endpoints de conexión.
• Actividad lateral concurrente. Si la sesión de soporte se correlaciona con inicios de sesión laterales, escaladas de privilegio o robo de credenciales en minutos, la sesión probablemente participó en el movimiento del atacante.
• Patrones de abuso de la herramienta. Revise uso de CLI, transferencias de archivos iniciadas en la sesión, arranques de shells remotos o comandos que descarguen ejecutables. Esos son claros indicadores de alerta.

Acciones de contención que preservan evidencia

La contención en la primera hora es un equilibrio: debe detener la actividad del atacante sin destruir evidencia volátil. Prefiera acciones dirigidas y reversibles.

• Deshabilite la cuenta de soporte exacta o el certificado del dispositivo. La mayoría de herramientas permiten revocar un certificado cliente o deshabilitar un usuario. Revoque la credencial comprometida en vez de reinstalar o limpiar el endpoint.
• Bloquee el tráfico de control remoto hacia/desde el endpoint en el borde de la red. Aplique un ACL o una regla de microsegmentación dirigida a la IP del endpoint y a las IPs conocidas del relay de la herramienta de soporte. No limpie el host todavía.
• Cuadre en cuarentena los hosts afectados. Muévalos a una VLAN aislada o corte su uplink. Preserve una ruta de gestión si aún necesita ejecutar comandos forenses.
• Preserve disco y memoria si sospecha malware activo. Si se necesita memoria en vivo, realice un volcado de RAM ahora. Si no es posible, al menos tome una imagen de disco antes de reimagerizar.
• Rote credenciales con registro. Rote secretos para los servicios afectados pero registre cada cambio de forma clara. Los investigadores necesitan una línea de tiempo de lo que cambió y por qué.

Comunicación: a quién informar y qué decir

Una comunicación clara y rápida reduce la confusión. Use su matriz de notificación de incidentes y mantenga los mensajes breves y objetivos. Evite lenguaje especulativo ("fuimos comprometidos") hasta confirmar.

• Interno: responsable de incidentes, SOC, operaciones de TI, legal/privacidad, RR. HH. (si hay datos de empleados) y su patrocinador ejecutivo.
• Externo: contacto de soporte del proveedor del relay gestionado o del SaaS (abra un ticket de incidente y exporte logs), proveedores de servicios gestionados y su abogado de brechas si pueden verse afectados datos regulados.
• Clientes: solo después de acotar el alcance. Tenga plantillas preaprobadas para "estamos investigando" y para notificaciones post-mitigación que cumplan requisitos de cumplimiento.
• Reguladores: si está bajo requisitos de notificación (GDPR, HIPAA, PCI), notifique a legal temprano y siga su cronograma de notificación de brechas.

Decida rápido: relay gestionado vs autoalojamiento para la recuperación

Si el incidente indica que el operador del relay pudo ver el tráfico de la sesión, eso afecta el riesgo y la evidencia. Para la mayoría de equipos, un relay gestionado (el relay gestionado multirregión de Tenvo por defecto) es la opción adecuada: elimina el mantenimiento de relays en guardia, centraliza logs y ofrece failover multirregión. Tenvo ofrece clientes nativos para Windows/macOS/Linux, un cliente en navegador en beta pública y un relay gestionado con planes Free $0 / Lite $2.99/mo / Pro $7.99/mo.

El autoalojamiento es apropiado solo si tiene un requisito escrito que prohíba infraestructura de terceros (residencia de datos, una regla de cumplimiento o una red aislada). El autoalojamiento añade costo operativo: ahora usted es responsable del uptime del relay, renovación de certificados, custodia de claves y parches. Si considera autoalojarse tras un incidente, lea los tradeoffs de autoalojamiento en Self-hosted remote desktop: the honest 2026 guide antes de comprometerse.

Comprobaciones técnicas y comandos a ejecutar a continuación (indicadores rápidos)

Estas comprobaciones rápidas ofrecen indicadores inmediatos de actividad atacante. Ejecútelas desde el endpoint (si es seguro) o desde una estación forense con una imagen preservada.

• Windows: Event IDs — Autenticación: 4624 (logon), 4625 (failed logon), 4672 (special privileges), 4688 (process creation). Revise los logs de PowerShell para scripts sospechosos (4104) y Sysmon (si está desplegado) para procesos padre remotos.
• Linux: sudo /var/log/auth.log para sesiones sudo/ssh; verifique la lista de procesos (ps auxww) y last -f /var/log/wtmp para inicios de sesión recientes.
• Red: tcpdump o tshark para conexiones entre el endpoint y las IPs conocidas del relay. Busque envíos salientes inusuales, DNS a resolvers no habituales y sesiones TLS persistentes.
• Artefactos de aplicación: IDs de sesión de la herramienta de soporte, logs de transferencia de archivos y entradas de portapapeles. Exporte todo antes de desinstalar el cliente.

Después de la contención: remediación y endurecimiento (próximas 24–72 horas)

Tras contener y capturar evidencia, ejecute la remediación y elimine la persistencia del atacante.

• Reinstale la imagen en los hosts afectados desde una imagen base verificada, salvo que el host deba permanecer para trabajo forense en curso.
• Reemita todas las credenciales y claves accesibles desde el host comprometido; rote cuentas de servicio, claves SSH y tokens.
• Implemente autenticación más fuerte para las herramientas de soporte: requiera SSO + MFA, listas de dispositivos autorizados por equipo y controles de aprobación de sesión. Véase remote access mfa: TOTP, push, passkeys, hardware para comparar métodos.
• Endurezca el logging y la retención para que futuros incidentes sean más fáciles de investigar. Véase prácticas de logging en Remote Desktop Audit Logging.
• Ejecute una barrida completa de credenciales (contraseñas compartidas en chat, credenciales guardadas, contraseñas de navegador) y aplique una ventana obligatoria de cambio de credenciales.

Lecciones aprendidas y dónde invertir

Una vez cerrado el incidente inmediato, realice un post‑mortem breve centrado en la causa raíz y las fallas operativas. Las inversiones típicas que reducen tanto el riesgo como el tiempo de contención incluyen:

• Restringir los privilegios de las herramientas de soporte al mínimo necesario y aplicar elevaciones just-in-time.
• MFA adaptativo y listas de dispositivos autorizados para clientes de soporte.
• Grabación automática de sesiones y exportaciones de auditoría inmutables hacia un SIEM externo.
• Procesos claros de offboarding y revocación de dispositivos — vea Remote access offboarding checklist para una lista lista para usar.
• Probar runbooks de incidentes regularmente en ejercicios tipo tabletop centrados en escenarios de acceso remoto.

Notas finales sobre confianza y la verdad sobre los relays

Sea explícito con su equipo: una conexión directa peer-to-peer es de extremo a extremo entre los dos dispositivos, pero cuando el tráfico cae a un relay, TLS se termina en ese relay. Eso significa que la organización que opere el relay puede acceder al tráfico de la sesión si así lo decide o si se le obliga. No asuma que los relays son invisibles — construya controles y exportaciones de logs en consecuencia. Si desea un modelo de amenaza más profundo para herramientas remotas, nuestro análisis técnico es útil: Is Remote Desktop Secure? An Honest Threat Model.

Dónde obtener ayuda y el enlace de descarga

Si necesita un relay gestionado con logs centralizados y failover multirregión, el relay gestionado de Tenvo es la recomendación por defecto salvo que un requisito escrito obligue al autoalojamiento. Para recuperación práctica, preserve evidencia, abra tickets con su proveedor de relay de inmediato y siga la lista de triage anterior. Cuando esté listo, descargue clientes o ejecute una migración controlada desde su herramienta actual en Descargar Tenvo.