Security Art Work

Sin duda todos nuestros lectores, sobre todo los que ya tengan una edad, habrán leído el artículo An evening with Berferd, donde Bill Cheswick narra las actividades de un intruso (Berferd) en 1991 y la gestión del incidente realizada desde AT&T, incluyendo una paciente vigilancia de todo lo que hacía Berferd. Obviamente, nosotros somos más de andar por casa y no tenemos la paciencia necesaria para jugar con un atacante durante días o meses, pero también nos pegamos con algún que otro intruso (seguramente no será Berferd, le vamos a llamar Vicente) que por las noches trata de colarse en las máquinas de un cliente al que, por motivos lógicos de confidencialidad, denominaremos ACME :) Ahí va el resumen, con nuestra visión, de la respuesta al incidente… Por supuesto, toda esta historia está basada en hechos ficticios, por lo que cualquier parecido con la realidad es pura coincidencia…

DÍA 1

A las 21:40 se recibe una alerta en nuestro sistema: un amigo, con una dirección IP de un operador al que vamos a llamar OPERATOR genera una alarma crítica en nuestro SOC: un ataque a ACME mediante Acunetix, que se ha bloqueado en el IPS del cliente y teóricamente no ha ido a más, pero que debe considerarse severo. En ese momento se revisa la actividad adicional de esa IP en ACME y el resto de clientes y vemos que ha generado alguna alerta menos crítica (en ACME, parece que este es su único objetivo) y que no requería acción inmediata, pero vamos, que el tío está metiendo caña… se bloquea de inmediato todo el tráfico entrante desde esa dirección y en paralelo comprobamos que la IP es de una línea ADSL, que se geolocaliza en la misma ciudad que ACME, y que detrás de esa IP hay un router Cisco con el telnet abierto (muy curioso, ¿no? ;)

En fin, un ataque que no ha ido a más, bloqueado ya en la infraestructura y que al día siguiente requerirá los formalismos correspondientes (correo a OPERATOR, denuncia de los hechos, etc.). A otra cosa. Pero no; dos minutos después del bloqueo de la IP, aparece un ataque similar: alguien que lanza otra vez Acunetix contra ACME y genera otra alerta crítica… De nuevo iteramos el proceso: bloqueo del tráfico entrante y obtención de información… Ummm, una línea ADSL de OPERATOR con un router Cisco delante, el puerto 23 abierto y (vaya, vaya) geolocalizada donde ACME… ¿Casualidad? Seguro que no: parece que tenemos un amigo interesado en ACME, al que como hemos dicho llamaremos Vicente (Vicentín más tarde, que al final llegamos a coger confianza con él ;)

En fin, nosotros repetimos la respuesta y Vicente el ataque. Esto se pone interesante… Bloqueo de nuevo y otra vez cambio de IP de Vicente: de nuevo un ADSL de OPERATOR geolocalizada en la misma ciudad que ACME, aparentemente con un router Cisco delante y el telnet abierto. Hasta cuatro veces repetimos el proceso y hasta cuatro veces Vicentín hace lo propio: se cambia de IP para seguir “zumbándole” a ACME. Desde luego mañana a denunciar, pero esto no tiene buena pinta… Al final, parece que Vicentín se ha cansado o simplemente que se le han acabado las direcciones dinámicas desde las que atacar… Mañana será otro día para todos, pero esta noche habrá que estar alerta…

DÍA 2

Día tranquilo; Vicentín parece que se ha olvidado de ACME y no da señales de vida… Vemos que no hay nada significativo fuera de las alertas ya identificadas ayer, recopilamos todos los logs, escribimos la denuncia, y a última hora nos vamos a Comisaría a presentarla. Tras un rato de papeleos tenemos ya todo firmado y estamos saliendo… es justo entonces cuando Vicente parece que nos esté viendo: vuelve a la carga contra ACME. Nos llegan las alertas por SMS y viendo sus actividades, confirmamos que sigue el mismo modus operandi que ayer: Acunetix a lo bruto, sin ningún tipo de discreción… Nuestra gente sigue el mismo procedimiento: bloquear cada IP y recopilar evidencias, pero Vicente cambia de direccionamiento como quien cambia de zapatos. Además todas las direcciones son ADSL de OPERATOR geolocalizadas en la misma zona, pero lamentablemente de rangos completamente diferentes, por lo que no lo tenemos tan fácil como bloquear unas clases C para quitarnos a nuestro amigo de encima…

La situación nos empieza a resultar especialmente incómoda, sobre todo por el sentimiento de indefensión. Tenemos a un tipo intentando colarse en ACME pero lo más que podemos hacer oficialmente es bloquearle la IP. Hablamos con soporte legal para que nos den más alternativas y lo único que nos pueden decir es que acudamos a Juzgado de Guardia para acelerar unas horas los trámites de la denuncia (ojo, una aceleración de “unas horas” para unos trámites que pueden durar semanas). Algunos amigos de FFCCSE de forma extraoficial nos confirman lo que ya sospechábamos: que aparte de denunciar y poner la otra mejilla, no se puede hacer nada, y encima alguien nos comenta, también extraoficialmente, que la gran OPERATOR atiende los requerimientos judiciales cuando ella considera, porque claro, para eso es OPERATOR, más allá del bien y del mal. Nos suena, ¿verdad? En cualquier caso, el segundo día hemos vuelto a cortar a Vicente, o se ha quedado otra vez sin IP disponibles… o simplemente se ha cansado de ACME y ahora está con otro objetivo…

DIA 3

Ampliamos denuncia en Juzgado de Guardia aportando las nuevas evidencias, sobre todo las direcciones IP que recopilamos durante la noche de ayer. Durante el día seguimos dándole vueltas a la situación y a la cara de imbéciles que se nos queda sin poder hacer nada más que filtrar una dirección IP tras otra. ¿Cambiará Vicentín de IP automáticamente? ¿Lo hará para seguir atacando a ACME, o ésta será una de múltiples tareas? ¿Utilizará sistemas intermedios o tira directamente desde la IP de su casa? ¿Por qué siempre a la misma hora? ¿Es cuando llega a casa o cuando se queda solo en la oficina? ¿Nos estará distrayendo con este ataque tonto mientras utiliza otro vector de entrada a ACME? Para descartar esto último y con el modo paranoia ON, se moviliza un equipo auxiliar al GIR que tiene por objeto revisar todos y cada uno de los sistemas de ACME, empezando por los que están en DMZ y siguiendo por los internos. Tras varias horas de trabajo, ni rastro: no hay nada anormal más allá de lo que hemos visto. Vicente sólo dispara a un objetivo, lo hace sin esconderse y aunque le filtremos, él cambia de IP y en segundos o minutos sigue su trabajo…

Por supuesto, a su hora habitual, Vicente vuelve a la carga por tercer día consecutivo. Seguimos metiendo las IP de la línea ADSL en nuestra lista negra y mirando cómo cambia de dirección cada poco tiempo, hasta cuatro o cinco veces. No podemos hacer más, nos dicen. Situación estúpida donde las haya, pero es todo a lo que podemos aspirar, aunque ya empiezan a surgir en el equipo malas ideas (que como somos buena gente, no llegamos a ejecutar -aunque no por falta de ganas-). Y también por tercer día consecutivo, tras varios cambios de direccionamiento, Vicentín se cansa y deja de atacar… Mañana más.

Introducción

Hace tiempo que se han puesto de moda las cámaras de videovigilancia conectadas por IP. Estas cámaras permiten su visualización desde cualquier parte del mundo. Esto se traduce en un problema: El Gran Hermano.

Mucha gente adopta esta medida de vigilancia por su facilidad de instalación y uso. Además de esto, la comodidad de estar fuera de casa y poder controlar todo lo que ocurre en el hogar.

Pero, ¿qué ocurre cuando no sólo lo instala un particular en su casa, sino que también lo hacen las compañías? Por poner varios ejemplos; una tienda, un restaurante ó cafetería, el hall de un hotel…

Como bien expresó Antonio Villalón en su post, nos quejamos del tío Sam, nos sorprendemos cuando salen a la luz ciertas noticias… pero no pensamos en que cuando vamos de compras o a una cafetería estamos siendo controlados en todo momento.

[Read more…]

[Read more…]

Siguiendo con la tecnología punta, que comencé con aquellas placas de la Nixdorf 820/15 en mi artículo anterior, y como parece que resultó interesante, hoy quiero mostrar otro proyecto que pone en evidencia la evolución de la electrónica en un lapso de tiempo no muy largo, pero que ha posibilitado los avances y la miniaturización de los equipos hasta extremos que solo las películas de James Bond podían imaginar.

La situación era la siguiente: 1984, en una compañía que fabrica ropa, principalmente la ropa tejana, con un mercado muy competitivo en el que aparecen nuevas marcas continuamente y en el que los costes de producción deben limitarse al máximo para sobrevivir en el mercado, nos encontramos con que los muestrarios de prendas para la temporada del año siguiente se han de fabricar con 12 meses de antelación. Ello supone comprar o fabricar el tejido necesario que, muchas veces viene de sitios como la India, Paquistán, etc (años 80 ojo) y ello conlleva adquirir compromisos de consumo y fabricación de dichos tejidos, que al final han de gustar o no gustar a los clientes de las tiendas de moda que van a marcar lo que “se lleva” en la temporada.

Pues bueno, en esta situación, el fabricante prepara el muestrario de prendas, lo distribuye a sus vendedores que viajan a lo largo del país y van recogiendo pedidos sobre blocs de papel diseñados para ello. En el fin de semana, los vendedores -o estudiantes contratados por ellos- , codifican los pedidos con las series, modelos, tejido, color y conjunto de tallas que el cliente ha pedido. El objetivo es tenerlo listo para enviarlo por correo (no hay mensajeros) a la oficina más cercana (la de Valencia en este caso) y allí se introducirán en el sistema (IBM/38) de la época y una vez depurados los errores de codificación y de catálogo (no todas las combinaciones de serie-modelo-tejido-color y talla eran aceptables), se obtiene la información necesaria para ver qué es lo que “se lleva” o “no se lleva” en la temporada siguiente, o sea, que tejido y en qué cantidades habrá que pedir para atender los pedidos. Este proceso tomaba entre dos y tres semanas y era crítico para la buena planificación de recepción de materias primas, planes de fabricación, gestión de almacenes y distribución del producto a los clientes antes de comenzar la temporada dichosa.

En esta situación, el equipo de Informática de la empresa, se puso a indagar en la tecnología disponible para acortar en lo posible la gestión de esos pedidos que marcaban la temporada y el coste de la misma. En estos años, trabajábamos con los “nuevos” PCs de IBM, con pantalla verde, dos unidades de diskette de 5-1/4 pulgadas y los más afortunados tenían un disco duro de 16 o 32 MB, menos fiable que una cafetera, pero que daba su servicio con la primera hoja de cálculo “Lotus 123” y algún “Writer” como editor de texto.

Buscando en el mercado, el director del departamento encontró el EPSON PX-8, un ordenador “portátil” de la época en el que había una pantalla líquida con 8 líneas de 80 caracteres y una unidad de micro-casete que podía almacenar datos. El problema era como meter y mantener el catálogo de productos dentro de este equipo con apenas 128K de memoria y sin disco duro y como gestionar pedidos de productos con hasta 17 tallas posibles en cada línea. Aún así, el director de la compañía, con gran visión de negocio, dio el visto bueno para el proyecto y los técnicos nos atrevimos con él, teniendo yo la satisfacción personal de ser el responsable del proyecto desde el lado móvil, y compartiendo con el equipo de programación de sistemas el desarrollo de los procesos.

Los programas iban en una EP-ROM de 32 K y el catálogo se actualizaba en la transmisión de cada noche, sobre memoria. Los pedidos se recogían en el casete. La idea era dotar al EPSON PX-8 de un catálogo que el programa gestionase mostrando las combinaciones de serie-modelo, etc. válidas y depurando así el pedido en el momento de su captura. El vendedor debía usar el PX-8 en lugar del block de papel. Esto fue duro, muy duro, y el soporte recayó en mi persona, con lo que el manual de usuario (en papel claro está), las sesiones de entrenamiento, la puesta a punto del software, etc. fueron un proyecto muy interesante y una gran experiencia para mí.

Los pedidos se recogían en el PX-8, se imprimían en una impresora EPSON de papel térmico y se le entregaba una copia al cliente, que recibiría el pedido en el formato “oficial” después por correo, tal como lo generaba el sistema central.

Durante la noche, los pedidos recogidos en la jornada de trabajo, eran transmitidos por teléfono analógico, conectando un acoplador acústico al teléfono del hotel (lo llamábamos “zapatófono” y si miráis las fotos veréis porqué), en el que se encontrase el vendedor ese día y donde muchas veces, la centralita del mismo introducía ruidos y provocaba errores en la transmisión, por lo que les tuvimos que dotar de un amplificador de sonido que sustituía al micrófono del teléfono, abriéndolo y cambiando su micro por el nuestro. El problema vino cuando muchas veces, después de un largo día de trabajo, el vendedor olvidaba recuperar el amplificador y se llevaba en su lugar el micro del teléfono del hotel. El nuevo inquilino de la habitación notaría una buena mejora en la comunicación, pero el vendedor se había quedado sin su ayuda.

Otro problema tedioso que se repetía cada día, sobre todo en determinados vendedores, era el saber enchufar los dispositivos entre sí, no doblando las patillas de los micro-conectores al equivocar la entrada elegida o la posición correcta para conectar, y presionar la clavija intentando que entrase. El intercambio de cables con clavijas “espatarradas” era continuo. En vista de ello, se me ocurrió una solución, busqué un maletín grande y ligero en el que diseñé una espuma interior con los conductos requeridos para mantener los cables y dispositivos conectados. El alimentador del EPSON, la impresora y el cable de comunicación con el zapatófono, quedaban fijos dentro de la maleta y así se solucionó, solo que, las protestas de los vendedores por llevar la maleta con ellos y custodiarla, arreciaron, pero al final, el éxito del proceso calmó los ánimos.

Para la transmisión, se conectaba el PX-8, vía acoplador acústico y se enviaban los pedidos al sistema central de la red Mark III de General Electric, donde se recogían y a primera hora del día siguiente (7 de la mañana) se transmitían al sistema 38 de nuestro centro. Allí se hacía el proceso estadístico y se presentaba a la dirección los resultados de la campaña de ventas, decidiendo entonces que productos iban a venderse y que otros debían desecharse del catálogo. Pasamos de tres semanas de latencia de los pedidos, a tres días, eso sí con un gran esfuerzo y un “Smart Computer” de los años 80. El impacto en los vendedores de la competencia (se conocían todos y se encontraban en los mismos hoteles) fue genial, mostrando su asombro por la osadía de nuestros vendedores haciendo trabajar aquella cosa de EPSON. Tengamos en cuenta que la informática casera de la época era el Sinclair ZX y algún Amstrad asequible, los Pcs de IBM y los Apple eran carísimos.

Os adjunto unas fotos del sistema, el zapatófono y el “Smart Maletín”. Ah por cierto, luego se instaló en las oficinas de Francia, Inglaterra y Alemania, todo un éxito para la época.

Recientemente revisando los resultados de salida que Nessus sacaba tras una auditoría de vulnerabilidades a un servidor FTP nos dimos cuenta de lo siguiente:

En principio nada destacable, ninguna vulnerabilidad relevante, pero como siempre, procedemos a una revisión manual de los resultados.

El caso es que si examinamos el banner de salida de este servidor nos muestra lo siguiente:

[Read more…]

Como muchos ya sabéis se ha publicado la nueva versión de la ISO/IEC 27001:2005 bajo el nombre ISO/IEC 27001:2013.

En esta revisión la norma ha sufrido grandes cambios destacando por ejemplo la flexibilidad a la hora de elegir metodologías de análisis de riesgos o mejora continua, la estructura de documentación, nuevos controles, nuevos conceptos, etc. pero sobre todo en su estructura pasando a utilizar el modelo del “anexo SL” del que ya habló nuestro compañero Alberto Olmos en estas entradas: Sistemas de Gestión Integrados: anexo SL (I), Sistemas de Gestión Integrados: anexo SL (II).

Una vez publicada la nueva norma, se ha abierto un periodo (presumiblemente de dos años) durante el cual las organizaciones que deseen seguir certificadas deberán adecuar sus SGSI a la nueva versión. Esta “actualización” podrá consolidarse durante una auditoría de seguimiento, de recertificación, o incluso mediante una auditoría extraordinaria si se considera oportuno.

Muchos se preguntan qué va a suponer este proceso de actualización y si van a tener que rehacer todo el sistema de gestión. La respuesta no es sencilla: depende (si no esté post no sería tan largo). Si bien a nivel técnico no parece que la actualización vaya a suponer ningún trauma, en lo que respecta a la organización del SGSI sí que existen muchas consideraciones a tener en cuenta por lo que analicémoslo por partes.

[Read more…]

¿Qué es YARA?

Cuando se habla de detección de malware existen principalmente tres maneras de determinar si un fichero es dañino o no: firmas, heurística y string signatures.

La más extendida en los sistemas de detección antivirus es la detección en base a firmas, es decir, en base al resultado de calcular el HASH de un fichero, pasarlo por una base de datos de firmas y comprobar si este fichero ha sido detectado anteriormente como malware. Este tipo de firma es inútil para la detección de malware no conocido y para evadirlo basta con recompilar el código en un sistema diferente o cambiarle un solo bit.

Para tratar de parar estos métodos de evasión se utiliza el método heurístico. Este método se basa en el comportamiento del ejecutable y, de acuerdo a las acciones que realiza dentro del sistema, se decide si el fichero es malicioso o no. El principal problema de este método es que puede generar una gran cantidad de falsos positivos ya que muchos programas realizan acciones lícitas que pueden hacer saltar las alertas.

Por último, queda el método que atañe a este artículo, string signatures. Este método se basa en otro tipo de firmas diferente al comentado anteriormente. En lugar de usar firmas tipo HASH, utiliza cadenas de texto o binarias que identifican inequívocamente a un malware. De esta forma aunque se modifique el fichero, si este sigue conteniendo esas cadenas que conforman una firma, los analistas seguirán siendo capaces de detectar y clasificar ese malware.

[Read more…]

Como ya indicaba en el anterior artículo de este ciclo, quiero recordar que estoy escribiéndolos basándome en mi propia (y dilatada) experiencia y reflejan tan solo ideas generales y prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado.

Así pues, continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez consideramos que la toma de requerimientos ha sido hecha y documentada adecuadamente y el cliente ha dado su visto bueno, comenzaremos con el diseño del sistema de tratamiento de la información. En esta etapa debemos asegurarnos de plasmar en el diseño todos aquellos requerimientos que hayamos sido capaces de conocer, aun cuando se dé el caso frecuente de que no va a ser posible implementar todas las funciones posibles ya que el cliente ha limitado el ámbito de actuación, solicitado un sistema más sencillo y de bajo coste y en este caso hay que recortar el desarrollo hasta donde sensatamente se pueda y limitarlo a la visión del cliente.

Es aquí donde la habilidad del responsable del proyecto debe mostrarse, definiendo las funciones esenciales, las que son convenientes —pero no son esenciales— y otras funciones posibles y deseables que, en una primera versión del sistema, tal vez no podrán implementarse, pero que muy posiblemente serán objeto de posteriores peticiones del cliente para ampliar la funcionalidad del sistema y si hemos sido capaces de prevenir estas circunstancias, será más sencillo satisfacerlas. De este modo, y tal como ya dije en mi artículo anterior, el clásico “esto no me lo habías contado y no está previsto”, quedará sustituido en la mayoría de las veces por “es posible integrar lo que me pides” y la inversión para implementar estas nuevas funcionalidades será menor y más rentable para el proveedor que lo tenía previsto que para aquel que necesita replantearse el diseño del sistema. Para ello, conviene dotar al diseño inicial de ciertos elementos de ajuste y flexibilización en la forma de procesar la información, que más adelante nos van a permitir implementar funciones y controles adicionales sin gran esfuerzo, rentabilizando así la inversión inicial.

¿Cómo se puede llegar a esto? Adquiriendo conocimientos extra durante el diálogo con el cliente, intuyendo lo que no ha dicho y previniendo que suceda. Por ejemplo, identificando los elementos clave que pueden definir el modo de procesar la información y añadiéndolos al sistema como entidades gestionables individualmente. Cuando el interlocutor te dice, tenemos clientes y proveedores —por ejemplo— pero no ha definido clases dentro de ambos, debemos averiguar si hay clientes que requieren procesos específicos o funciones dedicadas a su situación o necesidad y en tal caso prevenir ya que van a haber categorías de clientes y seguramente también de proveedores, así como que clientes o proveedores tendrán ramificaciones en el interior de los procesos. Si nos dice que compran o prestan tal o cual servicio, averiguar cuantas particularidades corresponden a cada uno y cómo se aplican a los clientes y proveedores (tal vez se está haciendo manualmente y bajo la “cultura” de algún empleado experto) y así sucesivamente. Probablemente de pronto el sistema tenga definido un fichero de tipos de cliente, otro de tipos de proveedor, otro de tipos de servicio (distribución), otro de condiciones de facturación, etc., de tal modo que si surgen nuevas combinaciones no hay que tocar programas, solo combinar nuevas entradas en los ficheros. Será importante también establecer relaciones válidas entre los diferentes conceptos, que al final definan las transacciones posibles que el sistema va a ejecutar, de manera que sólo sea posible procesar aquellas combinaciones previamente definidas en tablas de control.

Por citar un ejemplo de lo que propongo, un cliente del sistema de salud no puede recibir un medicamento registrado si no es una farmacia. Por tanto un hospital ha de comprar estos medicamentos a través de su farmacia o de una farmacia externa, pero nosotros no podemos servir ni facturar estos medicamentos a un cliente que no es una farmacia. Las entradas de nuestras tablas reflejarán las relaciones válidas entre tipos de clientes (hospital, clínica, farmacia, etc.) y tipos de productos (producto hospitalario, medicamento no registrado, medicamento registrado, etc.) y de este modo el sistema dará un aviso e impedirá —si se desea— que se asigne inventario de un producto a un pedido de un cliente que legalmente no puede comprar ese producto, evitando errores en la transacción final, y lo que es más importante, riesgos legales. Crear un programa que sirva y facture cualquier producto a cualquier cliente es fácil, pero no hablamos de eso, sino de control, seguridad y valor añadido.

Del mismo modo, podremos actuar en la definición de funciones, habrá que esforzarse en que unas no dependan de otras y las puedan condicionar, sino que las condiciones estén gestionadas a través de elementos externos, de nuevo, en una tabla o veinte tablas de la base de parámetros de ajuste del sistema.

El análisis de los procesos reflejará con claridad las funciones a ejecutar y sus relaciones con las entradas de las tablas o ficheros citados, para que los técnicos puedan aplicar estos criterios y crear programas que gestionen transacciones basadas en los parámetros incluidos en las tablas de control citadas y también en los registros de datos, ya que en este último caso, por ejemplo, habrán sido añadidos al crear un cliente, definiendo su clase y validándola en la tabla de clases de clientes, el tipo de servicio que requiere, sus particularidades para facturarle, etc., tal como haya sido predefinido anteriormente por el usuario experto o el administrador del sistema.

Tal vez parezca que todo esto es obvio, pero pueden creerme si les digo que el mundo está lleno de sistemas y procesos que no entienden nada de esto y que requieren intervención —a veces intencionada— de soporte cada vez que algo nuevo afecta al proceso de la información, por no hablar aquí de las condiciones de explotación del sistema (ya lo hice en otro artículo “La Explotación de Sistemas Informáticos”). Definir nuevas transacciones de negocio debe convertirse en un problema de administración y ajuste del sistema, en lugar de una revisión y reprogramación del mismo. Como ya he indicado, habrá un usuario, o varios, expertos en la administración del sistema y en la definición y ajuste de los parámetros que componen las transacciones que ejecuta, y aunque esta tarea puede ser subcontratada externamente como parte de un servicio, es muy conveniente que quede dentro de la empresa usuaria.

Tal vez el cliente pueda sorprenderse de que se requiere hacer una definición inicial de todos los parámetros y se pierda en el concepto, pero verá sus resultados con cierta rapidez, en cuanto pueda definir sus propias funciones dentro de lo previsto y cambiar el modo en que se procesa la información en ciertas circunstancias (un cliente que inicia una nueva actividad o negocio, por ejemplo).

Continuamos con el resumen de la 3ª edición de Navaja Negra, al que asistimos José Vila (@jovimon) y un servidor los pasados días 3-5 de octubre.

En este segundo día, la primera charla fue a cargo de Marc Rivero (@Seifreed), en la que habló sobre la evolución del fraude en Internet. En ella, Marc comenzó haciendo un breve resumen sobre las amenazas más sonadas: phishing, troyanos, el virus de la Policía… así como de los kits disponibles en el mercado negro para facilitar la creación de los mismos.

Respecto a este tipo de amenazas, Marc también hizo hincapié acerca de las herramientas disponibles en ambos bandos ya sea para verificar que el malware es indetectable o bien para poder neutralizarlo. También se habló sobre las técnicas Man-in-the-Browser, en las que el atacante actúa de árbitro entre el cliente y el servidor, obteniendo en este caso las credenciales de acceso a la cuenta corriente de la víctima, para luego realizar pequeñas transferencias que puedan pasar desapercibidas.

Otros temas que se trataron en la charla fueron los de los muleros y el uso de servidores a prueba de balas, o servidores comprometidos, para alojar el malware y dificultar la identificación de los responsables.

[Read more…]