Tras ver el hackeo en el caso de Ebay, se preguntaba en el artículo si habíamos probado la resistencia de nuestra empresa contra ataques de phishing que buscaran robar las credenciales de los usuarios internos. Este es un caso de ataque típico desde hace muchos años que se puede usar en ejemplos de robo de fotos de famosas o que lo pueden usara los Syrian Electronic Army para hackear a la RSA Conference.
Así que, aceptando el reto propuesto, y con el objetivo de medir y analizar el grado de conocimiento y conciencia sobre la seguridad de la información en la empresa, se realizó una simulación de ataque de phishing a los trabajadores de la empresa. Estos son los resultados obtenidos, que nos han hecho preocuparnos.
El escenario de auditoría
El ataque que se planteo fue muy sencillo, y consistió en hacer llegar a los usuarios un correo que llegaba supuestamente desde el banco que utiliza la empresa para pagar los sueldos, ofreciendo una promoción atractiva e indicando que era necesario suscribirse siguiendo un hipervínculo.
Para hacerlo más creíble, se registró un nombre de dominio relacionado con el nombre del banco, pero que evidentemente no era el del banco. Se gestionó para que todo fuera mucho más aparente, además, un certificado SSL Clase 1 firmado por una autoridad certificante confiable por cualquier navegador, por lo que se eligió StartCom.
Cuando el usuario seguía el enlace, era dirigido a un sitio idéntico al de la Banca Personal del banco que fue copiado con httrack, pero que esta vez estaba controlado por el área de Seguridad de la Información de la empresa. Cada enlace enviado contenía un código único que hacía posible trazar la actividad individual de cada usuario dentro del sitio, para facilitar el análisis posterior y para que fuera más efectivo el APT y no fuera detectado por ningún bot o afectara a otros usuarios, el firewall del servidor solo aceptaba peticiones desde la dirección IP pública de la empresa.
Por supuesto, el sitio de phishing solicita las credenciales, las almacena localmente y redirige a una página de error del sitio real del banco. Por tratarse de información sensible, sólo se almacenó una fracción de las credenciales, con el objetivo de poder verificar si se trata de credenciales que posiblemente eran reales o si eran valores aleatorios.
El análisis de los resultados
Para que sea fácil entender lo que sucedió, clasificamos los usuarios en tres tipos. Los que calificaríamos como alertados y precavidos que no hicieron nada, los curiosos que siguieron el hiper-enlace asumiendo riesgos pero sin introducir las credenciales y las víctimas, que ingresaron los datos. La siguiente tabla detalla el comportamiento de los usuarios luego de recibir el correo:
Además, cabe destacar la velocidad y efectividad del ataque, ya que una gran parte de los intentos de autenticación, el 72% de ellos, sucedieron dentro de las primeras 4 primeras horas de vida del ataque desde que fueron enviados los correos, lo que hace dudar mucho de la efectividad de los servicios de bloqueos de hoy en día.
En nuestro caso, hay que felicitar al administrador de red de la empresa que recibió el correo y al verificar que se trataba de un sitio sospechoso, bloqueó el acceso al sitio para toda la empresa a los 86 minutos de ser enviados los correos. Luego, a pedido del Área de Seguridad, lo volvió a habilitar. En el caso de haber sido una situación real, el bloqueo hubiera evitado el 63% de los intentos de autenticación por una buena acción del servicio de seguridad de red.
Algunos empleados, más alertados de este tipo de ataques, tomó una actitud activa demostrando que estaban concienciados con la seguridad y el área de Recursos Humanos envió una consulta a la sucursal local del banco, bajo la sospecha de que se trataba de un caso de phishing. Luego de recibir la confirmación por parte del banco, dio aviso al Área de Sistemas para que tomara acción al respecto.
Por último y para dar por cerrado el experimento, desde Sistemas se envió una circular, indicando que se trataba de un correo de phishing y que era conveniente no seguir los enlaces ni enviar las credenciales y luego, se eliminó del servidor toda la información relacionada con el proyecto y se redirigió el dominio a otro servidor.
Conclusiones
Después de esta prueba, me cruce con uno de los usuarios en el cajero automático (ATM) de la empresa, hablando por el teléfono móvil. Estaba furioso porque no podia cambiar su clave de banca personal. Creo que ese usuario aprendió que no debe ingresar credenciales en sitios raros. Este usuario era uno de los que había ingresado 9 veces sus credenciales en el sitio de phishing
El proyecto no sólo sirvió para medir y analizar el estado de seguridad de los usuarios, sino también para concientizarlos de cómo se hacen estos ataques y los riesgos que hay, además de detectar actitudes que ayudan a reducir el riesgo, como la acción activa de verificación por parte del area de RRHH y el Área de Seguridad de Red. Tal vez, un proceso interno más ágil en el que los usuarios puedan pedir a seguridad de red que verifique si un correo es phishing hubiera podido reducir los tiempos.
Los usuarios que ingresaron sus credenciales y luego recibieron información de que se trataba de phishing, posiblemente hayan tomado conciencia sobre el riesgo de seguir enlaces de correos no esperados o ingresar credenciales en sitios no verificados correctamente. Los usuarios que no ingresaron sus credenciales, posiblemente hayan reforzado el estado de conciencia que demostraron al no hacerlo en primera instancia.
Por supuesto, internamente se planifica a futuro, realizar un proyecto similar, con el fin de realizar un análisis comparativo y tomar algunas conclusiones. En un caso de un APT, el atacante solo necesitaría una credencial, y viendo el número de ellas y la velocidad que con que se consiguen, hace pensar que la protección de todas las identidades que se usan en una empresa por solo usuarios y contraseñas no es nunca una buena idea, y que implantar el uso de segundos factores de autenticación es cada vez más necesario.
Autor: V.L.
PD:Nosotros ya lo hemos probado, ahora te toca probarlo en tu empresa.
 |
| Figura 1: El viejo y el mar. Viejas técnicas de pesca, mismos resultados. |
Así que, aceptando el reto propuesto, y con el objetivo de medir y analizar el grado de conocimiento y conciencia sobre la seguridad de la información en la empresa, se realizó una simulación de ataque de phishing a los trabajadores de la empresa. Estos son los resultados obtenidos, que nos han hecho preocuparnos.
El escenario de auditoría
El ataque que se planteo fue muy sencillo, y consistió en hacer llegar a los usuarios un correo que llegaba supuestamente desde el banco que utiliza la empresa para pagar los sueldos, ofreciendo una promoción atractiva e indicando que era necesario suscribirse siguiendo un hipervínculo.
Para hacerlo más creíble, se registró un nombre de dominio relacionado con el nombre del banco, pero que evidentemente no era el del banco. Se gestionó para que todo fuera mucho más aparente, además, un certificado SSL Clase 1 firmado por una autoridad certificante confiable por cualquier navegador, por lo que se eligió StartCom.
Cuando el usuario seguía el enlace, era dirigido a un sitio idéntico al de la Banca Personal del banco que fue copiado con httrack, pero que esta vez estaba controlado por el área de Seguridad de la Información de la empresa. Cada enlace enviado contenía un código único que hacía posible trazar la actividad individual de cada usuario dentro del sitio, para facilitar el análisis posterior y para que fuera más efectivo el APT y no fuera detectado por ningún bot o afectara a otros usuarios, el firewall del servidor solo aceptaba peticiones desde la dirección IP pública de la empresa.
Por supuesto, el sitio de phishing solicita las credenciales, las almacena localmente y redirige a una página de error del sitio real del banco. Por tratarse de información sensible, sólo se almacenó una fracción de las credenciales, con el objetivo de poder verificar si se trata de credenciales que posiblemente eran reales o si eran valores aleatorios.
El análisis de los resultados
Para que sea fácil entender lo que sucedió, clasificamos los usuarios en tres tipos. Los que calificaríamos como alertados y precavidos que no hicieron nada, los curiosos que siguieron el hiper-enlace asumiendo riesgos pero sin introducir las credenciales y las víctimas, que ingresaron los datos. La siguiente tabla detalla el comportamiento de los usuarios luego de recibir el correo:
- Sin Acción: El usuario no siguió el link enviado en el correo.Sorprendentemente, en algunos casos los usuarios visitaron el sitio y/o ingresaron sus credenciales más de una vez. Sólo se consideraron las visitas únicas en cada caso.
- Visita: El usuario siguió el link, pero no ingresó sus credenciales.
- Autenticación: El usuario siguió el link e ingresó sus credenciales.
 |
| Figura 2: Números de cada tipo de acción |
Además, cabe destacar la velocidad y efectividad del ataque, ya que una gran parte de los intentos de autenticación, el 72% de ellos, sucedieron dentro de las primeras 4 primeras horas de vida del ataque desde que fueron enviados los correos, lo que hace dudar mucho de la efectividad de los servicios de bloqueos de hoy en día.
 |
| Figura 3: Un 20 % de los usuarios tuvieron comportamiento inseguro |
En nuestro caso, hay que felicitar al administrador de red de la empresa que recibió el correo y al verificar que se trataba de un sitio sospechoso, bloqueó el acceso al sitio para toda la empresa a los 86 minutos de ser enviados los correos. Luego, a pedido del Área de Seguridad, lo volvió a habilitar. En el caso de haber sido una situación real, el bloqueo hubiera evitado el 63% de los intentos de autenticación por una buena acción del servicio de seguridad de red.
Algunos empleados, más alertados de este tipo de ataques, tomó una actitud activa demostrando que estaban concienciados con la seguridad y el área de Recursos Humanos envió una consulta a la sucursal local del banco, bajo la sospecha de que se trataba de un caso de phishing. Luego de recibir la confirmación por parte del banco, dio aviso al Área de Sistemas para que tomara acción al respecto.
Por último y para dar por cerrado el experimento, desde Sistemas se envió una circular, indicando que se trataba de un correo de phishing y que era conveniente no seguir los enlaces ni enviar las credenciales y luego, se eliminó del servidor toda la información relacionada con el proyecto y se redirigió el dominio a otro servidor.
Conclusiones
Después de esta prueba, me cruce con uno de los usuarios en el cajero automático (ATM) de la empresa, hablando por el teléfono móvil. Estaba furioso porque no podia cambiar su clave de banca personal. Creo que ese usuario aprendió que no debe ingresar credenciales en sitios raros. Este usuario era uno de los que había ingresado 9 veces sus credenciales en el sitio de phishing
El proyecto no sólo sirvió para medir y analizar el estado de seguridad de los usuarios, sino también para concientizarlos de cómo se hacen estos ataques y los riesgos que hay, además de detectar actitudes que ayudan a reducir el riesgo, como la acción activa de verificación por parte del area de RRHH y el Área de Seguridad de Red. Tal vez, un proceso interno más ágil en el que los usuarios puedan pedir a seguridad de red que verifique si un correo es phishing hubiera podido reducir los tiempos.
Los usuarios que ingresaron sus credenciales y luego recibieron información de que se trataba de phishing, posiblemente hayan tomado conciencia sobre el riesgo de seguir enlaces de correos no esperados o ingresar credenciales en sitios no verificados correctamente. Los usuarios que no ingresaron sus credenciales, posiblemente hayan reforzado el estado de conciencia que demostraron al no hacerlo en primera instancia.
Por supuesto, internamente se planifica a futuro, realizar un proyecto similar, con el fin de realizar un análisis comparativo y tomar algunas conclusiones. En un caso de un APT, el atacante solo necesitaría una credencial, y viendo el número de ellas y la velocidad que con que se consiguen, hace pensar que la protección de todas las identidades que se usan en una empresa por solo usuarios y contraseñas no es nunca una buena idea, y que implantar el uso de segundos factores de autenticación es cada vez más necesario.
Autor: V.L.
PD:Nosotros ya lo hemos probado, ahora te toca probarlo en tu empresa.
De acuerdo Lactch funciona y proporciona una capa adicional de seguridad y tal, pero esto empieza a parecer un"Teletienda".
ResponderEliminarCreo que precisamente en este artículo no se habla de Latch en ningún momento. Al final es un blog relativo a la seguridad informática, que siempre estará relacionada con Latch.
ResponderEliminar- José Luis
Las propuestas son interesantes y a tomar en serio ;)
ResponderEliminar