Casi 20 años del estándar para programas de concientización, NIST Special Publication 800-50

En octubre del año 2003 el National Institute of Standards and Technology (NIST) lanzó la publicación NIST Special Publication 800-50, Building An Information Technology Security Awareness and Training Program. Este documento pretende ser una guía para construir un programa efectivo de concientización y entrenamiento en seguridad informática para agencias federales de Estados Unidos. De todas maneras, también puede ser utilizado por otro tipo de organizaciones, en otros países.

A casi 20 años de su lanzamiento, mucho ha cambiado en el ámbito de las tecnologías y la ciberseguridad, y en nuestras vidas en general. Creemos que es momento de revisar algunos de sus lineamientos a la luz del presente.

Estructura

La guía identifica cuatro pasos críticos en el ciclo de vida de un programa de concientización y entrenamiento:

• Diseño del programa: Se conduce un relevamiento dentro de la organización y, a partir de su resultado, se desarrolla y aprueba la estrategia a seguir durante el programa, alineada a la misión de la organización.
• Desarrollo del material: Se evalúa el alcance del entrenamiento deseado, el contenido necesario para cubrirlo y las posibles fuentes para desarrollarlo.
• Implementación del programa: Se comunica y lanza el programa de concientización y entrenamiento, a través de los medios definidos en la estrategia.
• Post implementación: Se busca mantener una ejecución continua del programa y monitorear su efectividad.

Alcance

Si bien la publicación que estamos analizando suele ser vista como un estándar para el desarrollo de un programa de concientización, en realidad su objetivo es más amplio y considera también:

• Educación puntual de los usuarios técnicos relacionados al área de tecnología
• Entrenamiento especial en seguridad para desarrollar habilidades específicas para distintos roles funcionales dentro de la organización.
• Desarrollo de profesionales especialistas en seguridad informática

Figure 2-1: The IT Security Learning Continuum

Modelos de implementación

La guía discute también tres modelos comunes (para la época) de implementar un programa de concientización y entrenamiento:

• Centralizado: Toda la responsabilidad recae en una autoridad central, por ejemplo el CIO.
• Parcialmente descentralizado: La autoridad central se ocupa de desarrollar una política y una estrategia de implementación. La implementación se distribuye entre distintas áreas funcionales.
• Totalmente descentralizado: La autoridad central únicamente desarrolla una política, pero la estrategia y la implementación recae en distintas áreas funcionales.

Nótese que aquí se menciona al CIO como posible autoridad central de un programa de concientización en ciberseguridad. Por aquel entonces (año 2003), el rol del CISO prácticamente no existía. A la fecha de redacción de este post, ya se habla incluso de un puesto específico encargado del programa de Security Awareness en la organización. Esto da pie a la siguiente sección de este post:

Cambios y continuidades

Al tratarse de una guía redactada en 2003, debemos tomar con cuidado la información que nos brinda.

Concepto de Concientización

Según la guía, la concientización no es más que entregar información a los usuarios. Decirles qué hacer, y qué no. Enfocado 100% a dar cumplimiento a normativas y 0% enfocado en cambiar hábitos y desarrollar una cultura segura.

Sólo se menciona que el usuario conozca manuales, procedimientos, políticas. Pero no se habla de que el usuario comprenda por qué le conviene saber esto, cuáles son sus beneficios en su vida laboral y ni hablar de su vida personal. Tampoco se comenta que la concientización tenga efecto alguno más allá de la organización.

De hecho, no se habla en ningún momento del desarrollo de hábitos seguros para la vida de la persona en el uso de la tecnología. Lo más cercano a esto, y que sin embargo sigue siendo muy lejano, es la mención del entrenamiento como concepto independiente a la concientización orientado a desarrollar habilidades en las personas.

En un contexto actual donde ya se comienza a hablar incluso de Awareness Management Systems, debemos ser muy cuidadosos en seguir estas directivas, que han dejado de ser útiles en el ámbito corporativo cuando el concepto de perímetro de la organización prácticamente desapareció.

Ejemplo de un póster de concientización propuesto por la guía. ¿Crees que un usuario actual de tu organización se detendría siquiera a leerlo?

Contenidos de Concientización

La guía propone el desarrollo desde cero del material de concientización: Un trabajo faraónico, tan grande como innecesario.

Si bien se menciona la posibilidad de adquirir o tomar como base contenidos de otras organizaciones proveedoras, no se habla de la opción que hoy en día es la más recomendable: utilizar una plataforma SaaS con contenidos predefinidos (y editables) listos para utilizar, con una política de actualización constante.

Simulaciones

Una nueva alarma para encender si nos basamos en esta guía: el documento no se explaya acerca de las distintas maneras de medir el estado de la capa humana de la organización, siendo el punto de referencia a la hora de comenzar un programa de concientización y demostrar su efectividad.

En la actualidad, guiar un programa de concientización sin apoyarnos en las métricas que arrojan las simulaciones de Phishing y de Ransomware, las cuales reflejan el comportamiento de los usuarios de nuestra organización, es prácticamente como navegar sin siquiera una brújula.

Modelos de implementación

En la guía no existe uno de los modelos de implementación más utilizados hoy, donde el CISO o encargado del plan de concientización se ocupa de la parte estratégica del plan y en general, delega la parte operativa en un partner integrador, quien brinda un servicio de valor agregado.

Conclusiones

Cada día más estamos convencidos acerca de la importancia de la concientización en la seguridad de la información. Es interesante que esta guía sea actualmente un punto de referencia para muchas personas que desarrollan un programa de awareness.

Si bien la información brindada por la guía es muy interesante, necesita por un lado ser actualizada, y por el otro, mantenerse al día con una frecuencia suficiente como para llegar a ser una publicación de referencia a la hora de llevar adelante nuestros planes de concientización.

Por suerte, la actualización ya está cerca, y de seguro será motivo para un nuevo análisis.

Leer Más

Un nuevo informe sobre Moodle, mi experiencia personal, y algunas verdades más

Si eres un CISO o CTO, y estás evaluando incorporar a Moodle en tu organización, o bien ya lo tienes desplegado en tu infraestructura, no puedes dejar de leer el excelente informe de Cristian Borghello y Daniel Maldonado titulado “Moodlelandia: Malas prácticas de Seguridad en las Aulas Virtuales creadas con Moodle”. La verdad es que el artículo no tiene desperdicio, y aquí me propongo complementar lo dicho en ese informe con mi experiencia personal, tratando de arrojar luz sobre el por qué de algunas estadísticas.

Principales hallazgos del informe sobre “Moodlelandia”

Lo primero que noto es que los hallazgos son sorprendentes, por la gravedad de la situación en Latinoamérica y España:

“Luego de analizar casi doce mil sitios, los principales resultados respecto a seguridad de las plataformas Moodle se pueden resumir en los siguientes aspectos:

• Casi la mitad de las instalaciones de Moodle utilizan versiones ya no soportadas por el desarrollador.
• No se encontró ninguna instalación con la última versión y completamente actualizada a la fecha.
• Sólo un tercio de los sitios utilizan comunicaciones cifradas (HTTPS).
• En más de la mitad de los casos, fue posible encontrar archivos de configuración sin protección y no se observó ningún proceso de hardening; sólo un quince por ciento ha decidido proteger de alguna manera la versión de la plataforma de instalación (sistema operativo, servidor web o versión de Moodle).
• Aproximadamente un tercio de los sitios analizados contienen al menos una vulnerabilidad pública, conocida y documentada (con CVE asignado).
• Fue posible identificar más de cincuenta vulnerabilidades distintas en todos los sitios analizados y con un promedio de cinco vulnerabilidades por sitio.”

De estos hallazgos, lo primero que me llevo son las estadísticas actualizadas, ya que he sido CISO en una organización con más de 20 instalaciones de Moodle hace más de 10 años. Lo sorprendente para mí es que, tanto tiempo después, todavía sigan existiendo tantas instalaciones de Moodle en este gravísimo estado de inseguridad.

Entonces me pregunto por qué esto sigue sucediendo y creo que el quid de la cuestión está sobre el final del informe:

“Contrario a lo que se puede pensar, el concepto de LMS gratuito y de distribución libre no es suficiente para que una organización (pública o privada) pueda mantener una plataforma educativa de la complejidad de Moodle. Los métodos de instalación, actualización y configuración pueden ser lo suficientemente dificultosos como para que un administrador no lleve adelante los procesos de hardening y la implementación adecuada de recomendaciones de seguridad.”

Esto me llevó a querer avanzar y complementar la investigación por mi cuenta, averiguando por qué existe este enorme grado de descuido a nivel generalizado sobre las implementaciones de Moodle en lo referido a ciberseguridad. Para eso, lo primero que hice fue llamar a la oficina donde trabajé como CISO hace tantos años y preguntar cómo estaban trabajando.

Mi propio trabajo investigativo

Algo a tener en cuenta es que esa organización cuenta con varios expertos en Moodle, con una experiencia mayor a 15 años, por lo que algo “simple” para ellos puede ser complejo para otra persona que no lleva tanto tiempo trabajando en esa tecnología.

Hablando con los administradores de las más de 20 instancias de Moodle me comentaron que actualizarlo ya no es tan complejo como lo recordaba yo. Ahora es bastante más simple comparativamente, aunque se debe acompañar con algún que otro script cuando hablamos de tantas instancias desplegadas.

Lo segundo que me comentaron fue que, gracias a esa simplificación, están en proceso de migración hacia una versión más reciente usando estos mecanismos modernos para lograr el upgrade. Cuando pregunté de qué versiones estábamos hablando, me detallaron que estaban actualizando de la 3.4.x a la 3.9.x (ver informe)

Suponiendo que se refirieran a la última versión de la rama (3.4.9), entonces podemos ver en el sitio oficial que la “Compostura de problemas para asuntos de seguridad en 3.4.x terminó el 13 de Mayo 2019 (hace 18 meses)”. Eso es siempre y cuando se hayan mantenido actualizados dentro de esa rama. De lo contrario, nos remontaríamos lamentablemente a 2017.

Es decir, que en la propia organización donde yo trabajé, contando con varios expertos en esta tecnología, validan la misma situación que la enumerada por el informe (a excepción de las comunicaciones cifradas HTTPS).

¿Por qué este informe es tan representativo de la realidad?

Como los CISOs (o “ex”, en mi caso) sabemos, la ciberseguridad no es lo que mueve a las organizaciones. Si bien puede haber o no expertos en una tecnología, esto no significa que les preocupe la seguridad. De hecho, la actualización de versiones que me comentaron mis colegas no estaba asociada a una preocupación por tenerlo al día y hardenizado. Incluso, cuando les compartí el informe me respondieron “después lo chequeamos”, hasta con un dejo de desinterés. (Uno se ilusiona y se desilusiona tan rápido…)

Pero por otro lado, Moodle es un sistema enorme que nació en 2003, ampliamente conocido y desplegado por ser uno de los sistemas de software libre más populares. Un sistema casi incuestionable a la hora de implementar capacitación en una organización, mucho más en ámbitos académicos.

Este alto grado de status quo con respecto a EL sistema, y que en muchos casos genera una sensación de “gratuidad” por ser software libre, lleva a pensar además que se tiene que instalar on premise en la organización.

Sin embargo, y lo digo por experiencia propia, es un sistema complejo, no solo desde el punto de vista de la seguridad sino en general, tanto para el docente como para el alumno, pero sobre todo para las personas que quieren implementarlo y mantenerlo. Requiere mucha especialización y tiempo para llegar apenas a adecuarlo a las necesidades de la organización, pero mucho más esfuerzo y pericia para mantenerlo al día.

Así y todo, como parece ser la elección evidente, Moodle se instala y luego, a fuerza de prueba y error, se llega a implementar. Pero las preguntas que deberíamos hacernos como responsables de implantar un sistema LMS (Learning Management System) como este son:

• ¿Es Moodle la solución que necesito?
• ¿Debo agregarlo en mi infraestructura?

Preguntas elementales

La primera pregunta “¿Es Moodle la solución que necesito?” me evoca muchos recuerdos, pero elijo destacar solo dos:

• En primer lugar, cuando estaba trabajando en la organización que les vengo mencionando y decidí lanzarme como emprendedor a crear una plataforma desde cero para cumplir las necesidades que Moodle no satisfacía, el CTO de turno me dijo: “Buena suerte, pero no hay algo más allá de Moodle” (Me sentí Neo de Matrix).
  
  
• En segundo lugar, cuando estuve en la Expo E-learning en Madrid en 2018, allí solo con mi stand en medio de muchos otros rindiendo culto a Moodle, recaí en la cuenta que éramos una de las pocas plataformas en toda la feria que no estaba basada en tal sistema.

Por más popular que sea, no significa que sea lo que se necesite en tu organización. Tal vez cumpla con los requisitos de features, pero… ¿alguna vez has pensado los conocimientos necesarios para su implementación y mantenimiento? ¿O las vulnerabilidades que tiene?

Ante la segunda pregunta “¿Debo agregarlo en mi infraestructura?”, para muchas organizaciones no parece haber otra opción más que “on premise”. En este caso, sepan que Moodle requiere no solo tiempo para su implantación, sino principalmente para su mantenimiento. El hecho de no tener que pagar por la licencia no significa que sea la opción más barata.

Siendo entonces que no se cuestiona si debe ser Moodle u otra solución, y si debe o no estar en la infraestructura propia, esto nos acerca a los resultados del informe y a una situación aún peor: quienes se hayan vuelto especialistas en este sistema, serán sus principales partidarios y no querrán evaluar otra opción mejor.

Respuestas no tan difíciles, pero duras

Mi recomendación siempre es primero evaluar lo que realmente se necesita: un LMS, o un sistema de gestión de formación o concienciación (que no es lo mismo). En estos tiempos ya no estamos en situación de pensar que todo debe ser on premise. Hay muchas opciones más allá de Moodle en formato SaaS, tanto para capacitación como para concientización. Solo es cuestión de pensar en el largo plazo e ir por otra alternativa.

Si la respuesta es que no necesitas Moodle on premise, pero ya tienes Moodle desplegado, en ese caso la salida dependerá de qué tan arraigado esté en tu organización. Si están apenas probando o en etapas iniciales, entonces tienes una chance de demostrar como CISO cuál será el futuro cercano con el informe de Cristian y Daniel, desde el punto de vista de seguridad. Si Moodle está muy arraigado en tu organización, lamento decirte que cambiarlo será una batalla dura, ya que tendrás detractores. Mi recomendación en este caso es ponerlo fuera de la organización, para que no haya una dependencia y arraigo tan grande de gente, y luego el cambio total pueda ser más digerible.

Nuestro rol como CISOs

Moodle no es el demonio. No es ni malo ni bueno. No es el más inseguro ni el más difícil de mantener. Es un sistema más, pero es muy popular y ese es el problema: no se cuestiona.

Pero a los CISOs se les pide evaluar la seguridad y acompañar a la organización a tomar buenas decisiones. Si ponemos a Moodle sobre la mesa, sabremos que tiene vulnerabilidades graves cada año en materia de ciberseguridad, y que es un sistema que no se mantiene actualizado ni hardenizado en la gran mayoría de sus implementaciones, tal como se demuestra en el informe. Si crees ingenuamente que esto no sucederá en tu organización, lamento decirte que las estadísticas y los hechos están en tu contra.

Ahora bien, si tienes Moodle 100% actualizado y hardenizado, en primer lugar te felicito, y en segundo lugar, te invito a ayudar al resto con tips sobre cómo lo lograste sin mayores sobresaltos (nuestro blog está abierto).

Leer Más

Así de fácil: la implementación de SMARTFENSE

La implementación de una plataforma de Security Awareness se puede percibir a priori como un proceso complejo, lleno de configuraciones y procesos como:

• Configurar una cuenta de correo en un servidor SMTP que brinde la posibilidad de hacer Spoofing y un servidor web para alojar la página de destino de la simulación de Phishing.
• Aplicar las medidas de seguridad pertinentes en ambos servidores para proteger la seguridad de la información.
• Adquirir y configurar dominios para envío de correos de simulación de Phishing y para navegación web del sitio de Phishing simulado, con sus respectivos certificados SSL y registros SPF, DKIM y DMARC.
• Elaborar un plan de contingencia para los dominios de simulación que caigan en listas negras globales y un procedimiento de actualización y hardening de la infraestructura definida.
• Entre otros

Pero claro, estos pasos y muchos otros no son necesarios para implementar una plataforma de concientización en la nube porque ya son provistos a priori. Esto nos permite utilizar nuestro tiempo en lo que realmente importa: brindar una experiencia positiva al usuario final y realizar con éxito las acciones necesarias para lograr un cambio de comportamiento en la organización.

Claro, bien definido y sencillo

El proceso de implementación de la plataforma de concientización SMARTFENSE destaca por ser claro, bien definido y sencillo de llevar adelante.

Al ser realizado con el soporte del partner integrador seleccionado por el cliente, el proceso se realiza de manera ordenada y cuidadosa, acompañado por profesionales certificados.

Los aspectos principales que forman parte del proceso de implementación se relacionan con:

• Seleccionar un método de importación y de autenticación de usuarios.
• Realizar un proceso de Whitelist para garantizar resultados reales en las campañas de Phishing o Ransomware lanzadas.
• Personalizar todo lo que se desee: contenidos, notificaciones, reportes, variables organizacionales, logotipos, etc.
• Lanzar campañas de prueba previas a las campañas reales para comprobar el funcionamiento esperado.

SMARTFENSE provee guías, checklists y gráficos de Gantt para llevar adelante cada paso de manera clara y completa, garantizando así una experiencia agradable al implementador.

Importación y autenticación de usuarios

Desde sencillos archivos en formato CSV hasta integraciones con un alto grado de personalización a través de tecnologías como Microsoft Azure Active Directory o Google Workspace, SMARTFENSE brinda una gran variedad de opciones tanto para importar a los usuarios de la organización dentro de la plataforma como para permitir su autenticación. Las diferentes opciones y su documentación clara y actualizada hacen de este un paso fundamental pero muy sencillo de completar con éxito.

Proceso de Whitelist

Permite asegurarnos que el universo de usuarios que queremos evaluar mediante simulaciones de Phishing y de Ransomware reciba los correos y pueda navegar el sitio web de destino sin inconvenientes técnicos.

Posibilita además que no se generen estadísticas falsas dentro de las campañas lanzadas a causa del análisis de correos electrónicos de parte de las herramientas de seguridad de la organización.

En definitiva, la correcta implementación de Whitelist permite medir el comportamiento de los usuarios de manera objetiva, sin sesgos tecnológicos.

Personalización

En SMARTFENSE es posible personalizar hasta los detalles más pequeños. Ya sean los contenidos que se enviarán a los usuarios (con sus textos e imágenes), las variables organizacionales que definen valores concretos para los contenidos (como nombre de encargados de áreas, números de teléfono, roles), las notificaciones de asignación y recordatorios, los logotipos corporativos para garantizar Marca Blanca, hasta los reportes administrativos y más.

Campañas de prueba

Este tipo de campañas brindan la posibilidad de conocer de primera mano si el proceso de implementación se ha realizado con éxito. Como tales, no afectan las estadísticas globales del programa de concientización.

El lanzamiento de las campañas de prueba permite diagnosticar cualquier paso extra que sea necesario realizar antes de ejecutar las primeras campañas reales, además de evaluar el correcto funcionamiento de los procesos de Whitelist para las campañas de simulación de Phishing o de Ransomware.

Tiempo de implementación

El tiempo de implementación de SMARTFENSE depende en realidad de los tiempos internos de cada organización.

Para organizaciones ágiles con experiencia previa en procesos similares, una única semana puede ser suficiente para comenzar a ejecutar el plan de concientización, enviando campañas reales y evaluando sus resultados.

El caso más común es que las organizaciones dediquen de 2 a 4 semanas para completar el proceso, debido principalmente a temas administrativos internos.

Soporte del partner integrador

No se trata únicamente de guías y procedimientos. Una buena experiencia en la implementación de una plataforma sólo es posible a través de un contacto estrecho con expertos. SMARTFENSE valora y recomienda la labor de las personas que forman parte de los equipos de nuestros partners certificados, que apoyarán siempre al cliente en cada paso, brindando las herramientas y recomendaciones necesarias para una implementación rápida y eficaz.

Leer Más

Ataques BEC y EAC: ¿Cuáles son las diferencias y cómo protegernos?

Diferentes, pero no tanto

Para empezar, debemos aclarar que los ataques BEC (Business Email Compromise, por sus siglas en inglés) y los ataques EAC (Email Account Compromise) tienen igual objetivo: Ganar dinero o robar información confidencial.

Tanto uno como otro se basan en ingeniería social, aprovechando que es mucho más sencillo engañar a una persona desinformada que saltar las barreras tecnológicas de seguridad de una organización. A ello se suma la realidad de muchas compañías que aún no asumen las crecientes amenazas y por lo tanto, no fortalecen la capa humana, la barrera más importante de defensa.

De los ataques BEC y EAC se derivó por ejemplo, el famoso Fraude del CEO: un ataque de ingeniería social, donde los ciberdelincuentes suplantan la identidad de un alto ejecutivo mediante correo electrónico. El fin más común es lograr que la víctima del engaño envíe dinero a una cuenta fraudulenta.

Entonces, si el objetivo es el mismo, ¿qué diferencia a estos dos ataques? El proceso de suplantación de identidad.

Ataques BEC (Business Email Compromise)

Los ciberdelincuentes utilizan diversas técnicas para hacerse pasar por otra persona, por ejemplo:

• Domain Spoofing
• Display-name Spoofing
• Lookalike Domains

Es importante destacar que los ciberdelincuentes no obtienen acceso a la cuenta de email que desean suplantar sino que, a través de estas técnicas, envían correos en su nombre.

Ataques EAC (Email Account Compromise)

Los ciberdelincuentes comprometen la cuenta de correo de su víctima utilizando diversas técnicas:

• Robo de credenciales a través de Phishing
• Consulta de credenciales filtradas
• Técnicas de fuerza bruta
• Malware

Este tipo de ataque es más sofisticado. La ventaja para el ciberdelincuente es el acceso a toda la información que su víctima posee en su correo electrónico:

• Historial de correos y destinatarios comunes
• Archivos adjuntos enviados y recibidos
• Firma
• Configuraciones

El sólo hecho de comprometer la cuenta de su víctima, como puede verse, es para los atacantes una mina de oro.

Pero muchos no se conforman con esto, sino que además se aseguran de mantener el acceso a la cuenta en el tiempo, creando reglas de reenvío de correos o cambiando los permisos. Así, monitorean de manera cercana a su víctima y pueden realizar una inteligencia certera de la organización.

Con este conocimiento y capacidad de acceso, pueden intervenir en cualquier conversación y enviar correos realmente convincentes en nombre de la víctima en el momento más adecuado, y lograr así sus objetivos.

Cómo protegernos

Como siempre proclamamos, la mejor manera de enfrentar un riesgo es mediante una estrategia de seguridad en capas.

Por un lado, necesitamos de las medidas técnicas necesarias para proteger los dominios de nuestra organización de ser suplantados, realizar hardening de nuestros servidores de correo y disponer de herramientas tecnológicas que nos ayuden a detectar las distintas técnicas de intrusión de los ciberdelincuentes.

Por otro lado, debemos desarrollar un plan de concientización de los usuarios, generando compromiso e involucramiento en la seguridad de la información mediante contenidos significativos para su vida personal y profesional.

Al tener sus cimientos en la Ingeniería Social, un gran porcentaje de los ataques BEC o EAC eluden con éxito a las herramientas tecnológicas de seguridad, o directamente ocurren fuera del dominio de éstas, a través de correo personal, aplicaciones de mensajería o llamados telefónicos.

Un usuario concientizado respecto a este tipo de ataques, estará atento y podrá detectarlos, reportarlos y prevenir convertirse en víctima de los ciberdelincuentes. Las personas se convierten en el arma más importante contra la ingeniería social.

Al incluir al usuario final en la estrategia de seguridad, estaremos realizando además una inversión transversal que actúa sobre todos los niveles de nuestras organizaciones y sus beneficios pueden medirse de manera objetiva y sin esfuerzo, mediante las herramientas apropiadas.

Reflexiones finales

Existen muchos reportes donde se pueden apreciar las grandes pérdidas financieras producto del BEC y EAC. Además, en la última década, todos los informes de ciberseguridad señalan al Phishing como la principal puerta de entrada de los ciberdelincuentes a nuestras organizaciones.

Si no eres del grupo de personas que confía en alcanzar la seguridad al 100% mediante soluciones tecnológicas, ¿crees que tus usuarios ya están preparados para evitar un compromiso de sus cuentas? ¿Consideras que podrían reconocer un ataque de este estilo?

Leer Más

Cómo alojar un Phishing en los servidores de Google

Esta no es una primicia. No es la primera vez que los servicios de Google se utilizan para enviar trampas de Phishing de gran calidad a los usuarios de nuestra organización.

En este artículo analizaremos un nuevo ejemplo, donde Google facilita al ciberdelincuente los pasos técnicos más engorrosos del Phishing, dejando el engaño servido en bandeja de plata (o en un dominio con reputación intachable).

Paso a paso para hostear la trampa de Phishing

1. Elaborar y subir el código HTML

El primer paso que debe seguir el ciberdelincuente es generar el código HTML que desea alojar en Google Docs. Luego, debe subirlo como un archivo con extensión .html a su cuenta de Google Drive.

2. Publicar el sitio en Google Docs

Una vez cargado el archivo .html, debe hacer clic con el botón derecho sobre su ícono y abrirlo con Google Docs:

En Google Docs, debe seleccionar la opción Archivo > Publicar en la web:

Finalmente, tiene que seleccionar la opción Embed y Publicar:

3. Salir de pesca

Google ha realizado todo el trabajo duro. El ciberdelincuente ya tiene su sitio de Phishing hosteado en un dominio de gran reputación como el de Google Docs:

Sólo resta compartir la URL generada por Google a la víctima, y listo. ¡A pescar!

Implicancias

Un ciberdelincuente que siga estos pasos tiene el poder de clonar con facilidad la imagen de cualquier organización mediante contenido web de alta calidad.

A su vez, puede alojar este contenido de manera gratuita en los servidores de Google, en el dominio de docs.google.com, el cual goza de gran reputación y rara vez estará incluido en una lista negra. Bueno, es prácticamente imposible que lo esté.

Lo anterior significa también que las herramientas tecnológicas antiphishing no detectarán un enlace generado con este procedimiento como malicioso, y llegará sin problemas hasta la bandeja de entrada del usuario final.

Esto demuestra, una vez más, que los ataques evolucionan, los ciberdelincuentes son muy creativos, y en el 2021, ya no podemos depender únicamente de herramientas tecnológicas para combatir la ingeniería social. Por eso insistimos en la necesidad de invertir en el hardening de usuarios.

Leer Más