Cuatro sniffers de JavaScript que te acechan en las tiendas en línea

Prácticamente cada uno de nosotros utiliza los servicios de tiendas en línea, lo que significa que tarde o temprano corre el riesgo de convertirse en víctima de los sniffer de JavaScript: un código especial que los delincuentes inyectan en el sitio para robar datos de tarjetas de crédito, direcciones, nombres de usuario y contraseñas de los usuarios.

Casi 400,000 usuarios del sitio y la aplicación móvil de la aerolínea British Airways ya han sido víctimas de sniffer, así como los visitantes del sitio británico del gigante deportivo FILA y del distribuidor de entradas estadounidense Ticketmaster. PayPal, Chase Paymenttech, USAePay, Moneris: estos y muchos otros sistemas de pago han sido infectados.

El analista de Threat Intelligence Group-IB, Viktor Okorokov, habla sobre cómo los sniffer se incrustan en el código del sitio y roban información de pago, así como sobre qué CRM atacan.

«Amenaza oculta»

Resulta que durante mucho tiempo, los sniffer de JS permanecieron fuera de la vista de los analistas antivirus, y los bancos y sistemas de pago no los consideraron una amenaza seria. Y totalmente en vano. Los expertos de Group-IB analizaron 2,440 tiendas en línea infectadas, cuyos visitantes - un total de aproximadamente 1.5 millones de personas al día - estaban en riesgo de compromiso. Entre los afectados se encuentran no solo usuarios, sino también tiendas en línea, sistemas de pago y bancos que emitieron tarjetas comprometidas.

Informe Group-IB realizó el primer estudio del mercado oscuro de sniffer, su infraestructura y los métodos de monetización que generan millones de dólares para sus creadores. Identificamos 38 familias de sniffer, de las cuales solo 12 eran conocidas por los investigadores anteriormente.

Detengámonos en detalle en cuatro familias de sniffer estudiadas durante la investigación.

Familia ReactGet

Los sniffers de la familia ReactGet se utilizan para robar datos de tarjetas bancarias en sitios de tiendas en línea. Un sniffer puede trabajar con una gran cantidad de diferentes sistemas de pago utilizados en el sitio: un valor de parámetro corresponde a un sistema de pago, y las versiones específicas detectadas del sniffer pueden usarse para robar credenciales, así como para robar datos de tarjetas bancarias de los formularios de pago de varios sistemas de pago, como un sniffer universal. Se ha establecido que, en algunos casos, los atacantes realizan ataques de phishing a administradores de tiendas en línea con el objetivo de obtener acceso al panel administrativo del sitio.

La campaña que utiliza esta familia de sniffers comenzó en mayo de 2017, apuntando a sitios gestionados por CMS y plataformas como Magento, Bigcommerce, Shopify.

Cómo se introduce ReactGet en el código de la tienda en línea

Además de la 'introducción clásica' del script a través de un enlace, los operadores de los sniffers de la familia ReactGet utilizan una técnica especial: mediante código JavaScript, se verifica si la dirección actual en la que se encuentra el usuario cumple con ciertos criterios. El código malicioso solo se ejecutará si la subcadena aparece en la URL actual checkout o onestepcheckout, onepage/, out/onepag, checkout/one, ckout/one. De esta manera, el código del sniffer se ejecutará en el momento en que el usuario proceda al pago y ingrese la información del pago en el formulario del sitio.

Este sniffer utiliza una técnica no estándar. Los datos de pago y personales de la víctima se recopilan juntos, se codifican utilizando base64, y luego la cadena resultante se utiliza como parámetro para enviar una solicitud al sitio de los atacantes. Con mayor frecuencia, la ruta hacia el gate imita un archivo JavaScript, por ejemplo, resp.js, data.js y así sucesivamente, pero también se utilizan enlaces a archivos de imagen, GIF y JPG. La característica distintiva es que el sniffer crea un objeto de imagen de 1 por 1 píxel y utiliza el enlace obtenido anteriormente como parámetro. src Imágenes. Es decir, para el usuario, tal solicitud en el tráfico se verá como una solicitud de una imagen normal. Se utilizó una técnica similar en los sniffer de la familia ImageID. Además, la técnica que utiliza una imagen de 1 por 1 píxel es aplicada en muchos scripts legítimos de análisis en línea, lo que también puede confundir al usuario.

Análisis de versiones

El análisis de los dominios activos utilizados por los operadores de los sniffer ReactGet ha permitido descubrir muchas versiones diferentes de esta familia de sniffer. Las versiones difieren en la presencia o ausencia de ofuscación, y además, cada sniffer está diseñado para un sistema de pago específico que procesa pagos con tarjetas bancarias para tiendas en línea. Al variar el parámetro correspondiente al número de versión, los especialistas de Group-IB obtuvieron una lista completa de las variaciones de sniffer disponibles, y a través de los nombres de los campos de formulario que cada sniffer busca en el código de la página, determinaron los sistemas de pago a los que está dirigido el sniffer.

Lista de sniffers y sus sistemas de pago correspondientes

Sniffer de contraseñas

Una de las ventajas de los sniffer de JavaScript que funcionan en el lado del cliente del sitio es su versatilidad: el código malicioso incrustado en el sitio puede robar datos de cualquier tipo, ya sean datos de pago o el inicio de sesión y la contraseña de la cuenta del usuario. Los especialistas de Group-IB descubrieron una muestra de sniffer perteneciente a la familia ReactGet, diseñada para robar direcciones de correo electrónico y contraseñas de los usuarios del sitio.

Intersección con el sniffer ImageID

Durante el análisis de una de las tiendas infectadas, se estableció que su sitio había sido infectado dos veces: además del código malicioso del sniffer de la familia ReactGet, se encontró el código de un sniffer de la familia ImageID. Esta intersección puede ser un indicativo de que los operadores detrás del uso de ambos sniffers emplean técnicas similares para incrustar el código malicioso.

Sniffer universal

Durante el análisis de uno de los nombres de dominio relacionados con la infraestructura de los sniffer ReactGet, se determinó que el mismo usuario había registrado otros tres nombres de dominio. Estos tres dominios imitaban dominios de sitios web reales y se utilizaron anteriormente para alojar sniffer. Al analizar el código de tres sitios web legítimos, se descubrió un sniffer desconocido, y un análisis posterior mostró que era una versión mejorada del sniffer ReactGet. Todas las versiones anteriores de sniffers de esta familia estaban dirigidas a un sistema de pago en particular, es decir, se necesitaba una versión especial del sniffer para cada sistema de pago. Sin embargo, en este caso, se encontró una versión universal del sniffer capaz de robar información de formularios relacionados con 15 diferentes sistemas de pago y módulos de sitios de comercio electrónico para realizar pagos en línea.

Así que, al inicio de su trabajo, el sniffer buscaba los campos básicos de los formularios que contenían información personal de la víctima: nombre completo, dirección física, número de teléfono.

Luego, el sniffer buscaba más de 15 prefijos diferentes, correspondientes a diversos sistemas de pago y módulos para pagos en línea.

Posteriormente, los datos personales de la víctima y la información de pago se reunían y se enviaban a un sitio controlado por el atacante: en este caso concreto, se encontraron dos versiones del sniffer universal ReactGet, ubicadas en dos sitios web hackeados diferentes. Sin embargo, ambas versiones enviaban los datos robados al mismo sitio hackeado. zoobashop.com.

El análisis de los prefijos que utilizó el sniffer para buscar campos que contenían la información de pago de la víctima permitió determinar que esta muestra de sniffer estaba dirigida a los siguientes sistemas de pago:

• Authorize.Net
• Verisign
• First Data
• USAePay
• Stripe
• PayPal
• ANZ eGate
• Braintree
• DataCash (MasterCard)
• Realex Payments
• PsiGate
• Heartland Payment Systems

Qué herramientas se utilizan para robar información de pago

La primera herramienta descubierta durante el análisis de la infraestructura de los atacantes se utiliza para ofuscar scripts maliciosos responsables del robo de tarjetas bancarias. En uno de los host de los atacantes se encontró un script bash que utiliza CLI del proyecto javascript-obfuscator para automatizar la ofuscación del código de los sniffers.

La segunda herramienta detectada está destinada a generar el código responsable de cargar el sniffer principal. Esta herramienta genera código JavaScript que verifica si el usuario se encuentra en la página de pagos, buscando en la dirección del usuario las cadenas checkout, carrito y así sucesivamente, y si el resultado es positivo, entonces el código carga el sniffer principal desde el servidor del atacante. Para ocultar la actividad maliciosa, todas las cadenas, incluidas las cadenas de prueba para determinar la página de pago, así como el enlace al sniffer, están codificadas utilizando base64.

Ataques de phishing

Durante el análisis de la infraestructura de red de los atacantes, se estableció que a menudo utilizan phishing para obtener acceso al panel administrativo de la tienda en línea objetivo. Los atacantes registran un dominio que se asemeja visualmente al dominio de la tienda y luego despliegan un formulario falso de inicio de sesión del panel administrativo de Magento. Si tienen éxito, los atacantes obtendrán acceso al panel administrativo del CMS Magento, lo que les permite editar componentes del sitio e implementar un sniffer para robar datos de tarjetas de crédito.

Infraestructura

Familia G-Analytics

Esta familia de sniffers se utiliza para robar las tarjetas de los clientes de las tiendas en línea. El primer nombre de dominio utilizado por el grupo fue registrado en abril de 2016, lo que puede indicar el inicio de la actividad del grupo a mediados de 2016.

En la campaña actual, el grupo utiliza nombres de dominio que imitan servicios reales, como Google Analytics y jQuery, enmascarando la actividad de los sniffers con scripts legítimos y nombres de dominio similares a los legítimos. Los sitios bajo CMS Magento han sido atacados.

Cómo G-Analytics se integra en el código de una tienda en línea

La característica distintiva de esta familia es el uso de diversas técnicas para robar la información de pago del usuario. Además de la clásica inyección de código JavaScript en la parte del cliente del sitio, el grupo delictivo también aplicó la técnica de inyección de código en la parte del servidor del sitio, específicamente en los scripts PHP que procesan los datos ingresados por el usuario. Esta técnica es peligrosa ya que dificulta la detección del código malicioso por investigadores externos. Los especialistas de Group-IB descubrieron una versión del sniffer inyectada en el código PHP del sitio, que utiliza como puerta el dominio dittm.org.

También se descubrió una versión temprana del sniffer que utiliza el mismo dominio para recolectar datos robados dittm.org, pero esta versión está destinada ya a instalarse en el lado del cliente de la tienda en línea.

Posteriormente, el grupo cambió su táctica y comenzó a enfocarse más en ocultar la actividad maliciosa y disfrazarla.

A principios de 2017, el grupo comenzó a utilizar el dominio jquery-js.com, que se disfraza como un CDN para jQuery: al visitar el sitio de los delincuentes, el usuario es redirigido a un sitio legítimo jquery.com.

Y a mediados de 2018, el grupo adoptó el nombre de dominio g-analytics.com y comenzó a disfrazar la actividad del sniffer como un servicio legítimo de Google Analytics.

Análisis de versiones

Durante el análisis de los dominios utilizados para almacenar el código de los sniffers, se descubrió que el sitio contiene numerosas versiones, que difieren en la presencia de ofuscación, así como en la inclusión o exclusión de código inalcanzable, agregado al archivo para distraer y ocultar el código malicioso.

En total, en el sitio jquery-js.com se identificaron seis versiones de sniffers. Los datos robados son enviados a una dirección que se encuentra en el mismo sitio que el sniffer: hxxps://jquery-js[.]com/latest/jquery.min.js:

• hxxps://jquery-js[.]com/jquery.min.js
• hxxps://jquery-js[.]com/jquery.2.2.4.min.js
• hxxps://jquery-js[.]com/jquery.1.8.3.min.js
• hxxps://jquery-js[.]com/jquery.1.6.4.min.js
• hxxps://jquery-js[.]com/jquery.1.4.4.min.js
• hxxps://jquery-js[.]com/jquery.1.12.4.min.js

El dominio más reciente g-analytics.com, utilizado por el grupo en ataques desde mediados de 2018, sirve como un almacén para un mayor número de sniffers. En total se descubrieron 16 versiones diferentes del sniffer. En este caso, la puerta para enviar los datos robados estaba disfrazada como un enlace a una imagen en formato GIF: hxxp://g-analytics[.]com/__utm.gif?v=1&_v=j68&a=98811130&t=pageview&_s=1&sd=24-bit&sr=2560×1440&vp=2145×371&je=0&_u=AACAAEAB~&jid=1841704724&gjid=877686936&cid
=1283183910.1527732071:

• hxxps://g-analytics[.]com/libs/1.0.1/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.10/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.11/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.12/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.13/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.14/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.15/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.16/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.3/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.4/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.5/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.6/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.7/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.8/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.9/analytics.js
• hxxps://g-analytics[.]com/libs/analytics.js

La monetización de los datos robados

El grupo delictivo monetiza los datos robados, vendiendo tarjetas a través de una tienda clandestina especialmente creada, que ofrece servicios a los carders. El análisis de los dominios utilizados por los atacantes permitió determinar que google-analytics.cm fue registrado por el mismo usuario que el dominio cardz.vc. Dominio cardz.vc se refiere a una tienda de venta de tarjetas bancarias robadas llamada Cardsurfs (Flysurfs), que ganó popularidad en la época de la activa plataforma de comercio clandestino AlphaBay como un mercado para la venta de tarjetas bancarias robadas a través de sniffer.

Analizando el dominio analytic.is, ubicado en el mismo servidor que los dominios utilizados por sniffers para recopilar datos robados, los especialistas de Group-IB encontraron un archivo que contenía registros de un Cookie-stiller, que aparentemente fue abandonado posteriormente por el desarrollador. Uno de los registros en el log contenía el dominio iozoz.com, que anteriormente fue utilizado en uno de los sniffers activos en 2016. Se presume que este dominio fue usado anteriormente por un atacante para recopilar tarjetas robadas con ayuda de un sniffer. Este dominio fue registrado con la dirección de correo electrónico kts241@gmail.com, que también fue utilizado para registrar los dominios cardz.su y cardz.vc, relacionados con la tienda de carding Cardsurfs.

A partir de los datos obtenidos, se puede suponer que la familia de sniffers G-Analytics y la tienda clandestina de venta de tarjetas bancarias Cardsurfs son gestionadas por las mismas personas, y que la tienda se utiliza para la venta de tarjetas bancarias robadas a través de un sniffer.

Infraestructura

Familia Illum

Illum es una familia de sniffers utilizada para ataques a tiendas en línea que operan con CMS Magento. Además de la inserción de código malicioso, los operadores de este sniffer también utilizan la inserción de formularios de pago falsos que envían datos a puertas de enlace controladas por los atacantes.

Al analizar la infraestructura de red utilizada por los operadores de este sniffer, se observó una gran cantidad de scripts maliciosos, exploits, formularios de pago falsos, así como un compendio de ejemplos de sniffers maliciosos competidores. A partir de la información sobre las fechas de aparición de los nombres de dominio utilizados por el grupo, se puede suponer que el inicio de la campaña se sitúa a finales de 2016.

Cómo Illum se inserta en el código de la tienda en línea

Las primeras versiones del sniffer detectadas se insertaban directamente en el código del sitio web comprometido. Los datos robados se enviaban a la dirección cdn.illum[.]pw/records.php, la puerta de enlace estaba codificada usando base64.

Más tarde se descubrió una versión empaquetada del sniffer que utiliza otra puerta de enlace — records.nstatistics[.]com/records.php.

Según informe Willem de Groot, el mismo host utilizado en el sniffer que fue inyectado en el sitio de la tienda, perteneciente al partido político alemán CSU.

Análisis del sitio de los delincuentes

Especialistas de Group-IB descubrieron y analizaron un sitio utilizado por este grupo criminal para almacenar herramientas y recopilar información robada.

Entre las herramientas descubiertas en el servidor de los delincuentes se encontraron scripts y exploits para elevar privilegios en el sistema operativo Linux: por ejemplo, Linux Privilege Escalation Check Script, desarrollado por Mike Czumak, así como un exploit para CVE-2009-1185.

Específicamente para ataques contra tiendas en línea, los delincuentes utilizaron dos exploits: el primero capaz de inyectar código malicioso en core_config_data a través de la explotación de CVE-2016-4010, el segundo exploita una vulnerabilidad de tipo RCE en los plugins para CMS Magento, permitiendo la ejecución de código arbitrario en el servidor web vulnerable.

Además, durante el análisis del servidor se encontraron diversas muestras de sniffers y formularios de pago falsos utilizados por los delincuentes para recopilar información de pago de sitios hackeados. Como se puede notar en la lista a continuación, algunos scripts fueron creados individualmente para cada sitio hackeado, mientras que para ciertos CMS y pasarelas de pago se usaron soluciones universales. Por ejemplo, los scripts segapay_standart.js y segapay_onpage.js están diseñados para ser inyectados en sitios que utilizan la pasarela de pago Sage Pay.

Lista de scripts para diversas pasarelas de pago

Host paymentnow[.]tk, utilizado como puerta de enlace en el script payment_forminsite.js, fue descubierto como subjectAltName en varios certificados relacionados con el servicio CloudFlare. Además, en el host se encontró un script evil.js. Judging por el nombre del script, podría haber sido utilizado en la explotación de CVE-2016-4010, que permite inyectar código malicioso en el footer de un sitio administrado por CMS Magento. Como puerta de enlace, este script utilizó el host request.requestnet[.]tk, que utiliza el mismo certificado que el host paymentnow[.]tk.

Formularios de pago falsos

A continuación, se muestra un ejemplo del formulario para ingresar los datos de la tarjeta. Este formulario fue utilizado para inyectarse en el sitio de la tienda en línea y robar los datos de las tarjetas.

En la siguiente imagen se muestra un ejemplo de un formulario de pago falso de PayPal, utilizado por delincuentes para infiltrar sitios web que utilizan este método de pago.

Infraestructura

Familia CoffeMokko

La familia de sniffer CoffeMokko, diseñada para robar tarjetas bancarias de usuarios de tiendas en línea, ha estado en uso desde al menos mayo de 2017. Se cree que los operadores de esta familia de sniffer son un grupo criminal conocido como Group 1, descrito por los especialistas de RiskIQ en 2016. Los ataques han afectado a sitios administrados por sistemas de gestión de contenido como Magento, OpenCart, WordPress, osCommerce, Shopify.

Cómo se infiltra CoffeMokko en el código de las tiendas en línea

Los operadores de esta familia crean sniffers únicos para cada infección: el archivo sniffer se ubica en el directorio src o js en el servidor de los delincuentes. La inserción en el código del sitio se realiza a través de un enlace directo al sniffer.

El código del sniffer tiene codificados de manera fija los nombres de los campos del formulario de los cuales se deben robar datos. Además, el sniffer verifica si el usuario está en la página de pago, comparando una lista de palabras clave con la dirección actual del usuario.

Algunas versiones del sniffer que se detectaron estaban ofuscadas y contenían una cadena cifrada que almacenaba el arreglo principal de recursos: en este se encontraban los nombres de los campos de formularios para distintos sistemas de pago, así como la dirección del gateway a la que se debían enviar los datos robados.

La información de pago robada se enviaba a un script en el servidor de los delincuentes a través de la ruta /savePayment/index.php или /tr/index.php. Se cree que este script sirve para enviar los datos desde el gateway al servidor principal, que consolida los datos de todos los sniffers. Para ocultar la información transmitida, toda la información de pago de la víctima se codifica utilizando base64, y luego se realizan varios reemplazos de caracteres:

• el carácter «e» se reemplaza por «:»
• el carácter «w» se reemplaza por «+»
• el carácter «o» se reemplaza por «%»
• el carácter «d» se reemplaza por «#»
• el carácter «a» se reemplaza por «-»
• el carácter «7» se reemplaza por «^»
• el carácter «h» se reemplaza por «_»
• el carácter «T» se reemplaza por «@»
• el carácter «0» se reemplaza por «/»
• el carácter «Y» se reemplaza por «*»

Como resultado de los reemplazos de caracteres, los datos codificados con base64 son imposibles de decodificar sin realizar la transformación inversa.

Así es como se ve un fragmento de código de un sniffer que no ha sido ofuscado:

Análisis de infraestructura

En campañas anteriores, los atacantes registraron nombres de dominio similares a los de sitios legítimos de comercio electrónico. Su dominio podría diferir del legítimo por un solo carácter o por otro TLD. Los dominios registrados se utilizaron para hospedar el código del sniffer, cuyo enlace se inyectaba en el código de la tienda.

También, este grupo utilizó nombres de dominio que recordaban a los nombres de populares plugins de jQuery (slickjs[.]org para sitios que utilizaban el plugin slick.js), gateways de pago (sagecdn[.]org para sitios que utilizaban el sistema de pago Sage Pay).

Más tarde, el grupo comenzó a crear dominios cuyos nombres no tenían ninguna relación ni con el dominio de la tienda ni con la temática de la tienda.

Cada dominio correspondía a un sitio en el que se creaba un directorio /js o /src. En este directorio se almacenaban los scripts de los sniffers: uno por cada nueva infección. El sniffer se inyectaba en el código del sitio a través de un enlace directo, aunque en raras ocasiones los atacantes modificaban uno de los archivos del sitio y añadían código malicioso a él.

Análisis del código

El primer algoritmo de ofuscación

En algunas muestras detectadas de este tipo de sniffers, el código fue ofuscado y contenía datos cifrados necesarios para el funcionamiento del sniffer: en particular, la dirección del gateway del sniffer, la lista de campos del formulario de pago, y en algunos casos, el código de un formulario de pago falso. En el código, dentro de la función, los recursos estaban cifrados mediante XOR con una clave que se pasaba como argumento a la misma función.

Al descifrar la cadena con la clave correspondiente, única para cada muestra, se puede obtener una cadena que contiene todas las cadenas del código del sniffer separadas por un símbolo delimitador.

El segundo algoritmo de ofuscación

En muestras más recientes de este tipo de sniffers, se utilizó otro mecanismo de ofuscación: en este caso, los datos fueron cifrados mediante un algoritmo casero. La cadena que contenía los datos cifrados necesarios para el funcionamiento del sniffer era pasada como argumento a la función de descifrado.

Con la consola del navegador se puede descifrar los datos cifrados y obtener un array que contiene los recursos del sniffer.

Vínculo con ataques tempranos de MageCart

Durante el análisis de uno de los dominios utilizados por el grupo como puerta de entrada para recopilar datos robados, se estableció que en este dominio se había desplegado una infraestructura para robar tarjetas de crédito, idéntica a la empleada por el Grupo 1, uno de los primeros grupos, descubiertos por los especialistas de RiskIQ.

En el host de la familia de snifers CoffeMokko se encontraron dos archivos:

• mage.js — un archivo que contiene el código del snifer del Grupo 1 con la dirección de la puerta de enlace js-cdn.link
• mag.php — un script PHP que se encarga de recopilar los datos robados por el snifer

Содержимое файла mage.js
También se estableció que los primeros dominios utilizados por el grupo detrás de la familia de snifers CoffeMokko fueron registrados el 17 de mayo de 2017:

• link-js[.]link
• info-js[.]link
• track-js[.]link
• map-js[.]link
• smart-js[.]link

El formato de estos nombres de dominio coincide con los nombres de dominio del Grupo 1 que fueron utilizados en los ataques de 2016.

Sobre la base de los hechos descubiertos, se puede suponer que existe una conexión entre los operadores de los snifers CoffeMokko y el grupo criminal Grupo 1. Presumiblemente, los operadores de CoffeMokko podrían haber tomado prestadas de sus predecesores herramientas y software para el robo de tarjetas. Sin embargo, es más probable que el grupo criminal detrás del uso de los snifers de la familia CoffeMokko sea el mismo que realizó ataques en el marco de las actividades del Grupo 1. Después de la publicación del primer informe sobre las actividades del grupo criminal, todos sus nombres de dominio fueron bloqueados y sus herramientas estudiadas y descritas en detalle. El grupo se vio obligado a tomarse un descanso, mejorar sus herramientas internas y reescribir el código de los snifers para continuar sus ataques y permanecer desapercibidos.

Infraestructura

Fuente: habr.com