Hackers crearon cuenta fraudulenta en el portal de solicitudes policiales de Google, confirma la empresa

Resumen del incidente

Google ha confirmado que atacantes crearon una cuenta fraudulenta en su plataforma Law Enforcement Request System (LERS), el sistema que utiliza la policía y otras autoridades para enviar solicitudes oficiales de datos a la compañía. La confirmación, divulgada por Google y recogida por medios especializados, sitúa el incidente como una intrusión dirigida al punto de contacto formal entre las fuerzas del orden y la empresa tecnológica.

Google ha confirmado que hackers crearon una cuenta fraudulenta en su Law Enforcement Request System (LERS), plataforma que usa la policía para presentar solicitudes oficiales.

Contexto y por qué importa

Las plataformas como LERS actúan como canal formalizado para que autoridades pidan información a proveedores de servicios en internet. A través de ellas se tramitan órdenes judiciales, solicitudes de conservación de datos y otras peticiones que pueden incluir metadatos de cuentas, registros de acceso y, en algunos casos, contenido bajo órdenes legales válidas.

Un acceso no autorizado a ese tipo de plataforma plantea riesgos singulares: además del posible acceso a información sensible, existe la capacidad de interferir en procesos legales, suplantar peticiones legítimas o manipular trazas que sustentan investigaciones. Por ello, la integridad, disponibilidad y autenticidad de los mecanismos de envío y recepción de solicitudes legales son críticos tanto para la seguridad pública como para la protección de derechos civiles.

Análisis para profesionales: vectores, controles y preguntas clave

La confirmación de una cuenta fraudulenta obliga a plantear hipótesis técnico-procedimentales sobre cómo se produjo la intrusión y qué controles deben reforzarse. Aunque Google no ha publicado públicamente todos los detalles del incidente, hay una serie de consideraciones y controles que los equipos de seguridad y legal deben evaluar.

• Posibles vectores de creación de cuentas fraudulenta: verificación insuficiente del registro, abuso de procesos automatizados de inscripción, suplantación de identidad (fraudulent credentialing), o explotación de flujos administrativos internos.
• Mecanismos de detección y mitigación: sistemas de registro y aprobación manual en cuentas sensibles, validación adicional fuera de banda (out-of-band) para nuevas cuentas con privilegios, verificación por múltiples factores del origen institucional de las solicitudes.
• Registro y auditoría: registros de auditoría inmutables y vigilancia continuada de acciones realizadas desde cuentas con acceso a peticiones legales, incluyendo alertas por patrones anómalos (p. ej., múltiples descargas, gestión de solicitudes fuera del horario habitual o desde ubicaciones inusuales).
• Gestión de la cadena de custodia: cómo se documentan y preservan las solicitudes y las respuestas para que, en caso de abuso, sea posible reconstruir la cadena de decisiones y operaciones.
• Preguntas que los equipos deben plantearse: ¿Se limitaron las acciones de la cuenta fraudulenta a la creación o hubo consultas/descargas? ¿Qué verificación exigía Google para crear un perfil LERS? ¿Se notificó a los organismos titulares de las supuestas solicitudes?

Casos comparables y marco general

Los incidentes que afectan a sistemas de gestión de peticiones judiciales o a portales de comunicación entre autoridades y proveedores no son inéditos. A modo de contexto general y sin equiparar directamente técnicas o alcance, existen ejemplos ampliamente documentados que ilustran las consecuencias de accesos no autorizados a canales de control o administración:

• Filtraciones y abusos de cuentas privilegiadas en grandes plataformas que permitieron cambios de control o exfiltración de datos.
• Brechas en proveedores de identidad o servicios de terceros que habilitaron el movimiento lateral hacia sistemas sensibles en organizaciones afectadas.
• Incidentes que pusieron de manifiesto la necesidad de procesos más rigurosos para la creación y verificación de cuentas con privilegios administrativos.

Estos ejemplos subrayan una lección repetida en seguridad: los canales administrativos y de gobernanza (incluidos los que gestionan solicitudes legales) requieren controles y monitoreo tan estrictos como las interfaces de consumo de datos.

Riesgos, implicaciones y recomendaciones accionables

El acceso fraudulento a una plataforma como LERS tiene múltiples capas de riesgo —operacionales, legales y reputacionales— tanto para los proveedores de servicios como para las propias fuerzas del orden. A continuación se detallan implicaciones y medidas prácticas que deberían considerar proveedores, equipos de respuesta y autoridades.

• Riesgos inmediatos: solicitudes forjadas que pueden llevar a la entrega de datos incorrectos o no autorizados; interferencia en investigaciones; pérdida de confianza institucional en el mecanismo de envío de solicitudes.
• Riesgos a medio y largo plazo: debilitamiento de la colaboración entre empresas y autoridades; impacto en la protección de datos personales y en garantías procesales si no se conoce el alcance del abuso.
• Recomendaciones técnicas (para proveedores y administradores de portales):
  • Implementar verificación estricta de identidad para la creación de cuentas con privilegios (procesos manuales complementarios, comprobación de credenciales oficiales y dominios verificados).
  • Exigir autenticación multifactor obligatoria y preferir factores hardware o basados en certificados para cuentas administrativas.
  • Registrar operaciones sensibles en logs inmutables y aplicar retención prolongada para auditoría forense.
  • Activar alertas por comportamiento anómalo y limitar acciones críticas por defecto (principio de mínimo privilegio y aprobación por múltiples actores).
• Recomendaciones procesales (para fuerzas del orden y units legales):
  • Validar solicitudes de forma recíproca cuando se ocultan o modifican metadatos sensibles; establecer canales de verificación fuera de la plataforma en casos de discrepancia.
  • Documentar y preservar la correspondencia y la evidencia asociada a cada solicitud para mantener cadena de custodia y transparencia.
  • Exigir a proveedores reportes de incidentes claros y notificaciones ágiles cuando una cuenta vinculada a solicitudes oficiales resulte comprometida o fraudulenta.
• Recomendaciones para equipos de respuesta a incidentes:
  • Activar investigaciones forenses que incluyan revisión de logs, análisis de actividad de la cuenta fraudulenta y verificación del posible acceso a datos solicitados.
  • Coordinar con unidades legales y organismos afectados para determinar obligaciones de notificación y preservación de evidencia.
  • Revisar y ajustar políticas de creación de cuentas y roles en la plataforma tras cerrar el incidente.

Conclusión

La confirmación por parte de Google de la creación de una cuenta fraudulenta en LERS pone el foco en un riesgo específico: la posible manipulación de los canales formales entre autoridades y proveedores tecnológicos. Aunque los detalles operativos del incidente no han sido difundidos en su totalidad, el suceso refuerza la necesidad de controles robustos en procesos de alta sensibilidad, auditoría continua y mecanismos de verificación fuera de banda. Para organizaciones y administradores de plataformas, las medidas prácticas incluyen reforzar la verificación de identidad, exigir MFA fuerte, auditar actividades con retención segura de logs y coordinar procedimientos claros de respuesta con las partes afectadas.

Source: www.bleepingcomputer.com