/*codigo slider*\

viernes, 13 de febrero de 2015

What is the Deep Web? A first trip into the abyss

What is the Deep Web? A first trip into the abyss



The Deep Web (or Invisible web) is the set of information resources on the World Wide Web not reported by normal search engines.



According several researches the principal search engines index only a small portion of the overall web content, the remaining part is unknown to the majority of web users.

What do you think if you were told that under our feet, there is a world larger than ours and much more crowded? We will literally be shocked, and this is the reaction of those individual who can understand the existence of theDeep Web, a network of interconnected systems, are not indexed, having a size hundreds of times higher than the current web, around 500 times.

Very exhaustive is the definition provided by the founder of BrightPlanet, Mike Bergman, that compared searching on the Internet today to dragging a net across the surface of the ocean: a great deal may be caught in the net, but there is a wealth of information that is deep and therefore missed.

Ordinary search engines to find content on the web using software called "crawlers". This Deep Web technique is ineffective for finding the hidden resources of the Web that could be classified into the following categories:
  • Dynamic content: dynamic pages which are returned in response to a submitted query or accessed only through a form, especially if open-domain input elements (such as text fields) are used; such fields are hard to navigate without domain knowledge.
  • Unlinked content: pages which are not linked to by other pages, which may prevent Web crawling programs from accessing the content. This content is referred to as pages without backlinks (or inlinks).
  • Private Web: sites that require registration and login (password-protected resources).
  • Contextual Web: pages with content varying for different access contexts (e.g., ranges of client IP addresses or previous navigation sequence).
  • Limited access content: sites that limit access to their pages in a technical way (e.g., using the Robots Exclusion Standard, CAPTCHAs, or no-cache Pragma HTTP headers which prohibit search engines from browsing them and creating cached copies).
  • Scripted content: pages that are only accessible through links produced by JavaScript as well as content dynamically downloaded from Web servers via Flash or Ajax solutions.
  • Non-HTML/text content: textual content encoded in multimedia (image or video) files or specific file formats not handled by search engines.
  • Text content using the Gopher protocol and files hosted on FTP that are not indexed by most search engines. Engines such as Google do not index pages outside of HTTP or HTTPS.

martes, 3 de febrero de 2015

Cómo evitar el cibercrimen

viernes, 12 de diciembre de 2014

Segu-Info: Publicada Guía del Desarrollador OWASP v4




Para los que trabajamos asegurando aplicaciones web, sin dudas esta es una excelente noticia que traerá beneficios a todos los sitios web: Mateo Mucci, uno de los líderes del proyecto ha anunciado la nuevaOWASP Developer Guide 2014.

Esta una obra reescrita en su totalidad a partir de uno de los primeros proyectos de OWASP y también uno de los más descargados. El enfoque se movió desde las contramedidas y debilidades hacia la ingeniería de software seguro. La primera guía del desarrollador de OWASP fue publicada en 2002, cuando todavía se usaba Internet Explorer y, desde entonces la web ha recorrido un largo camino. Por desgracia, la guía del desarrollador nunca realmente despegó en su público objetivo: los desarrolladores. La guía original trataba de cómo realizar pruebas de penetración de aplicaciones web, material que ahora está mejor cubierto en la Guía de Pruebas de OWASP.

La nueva guía del desarrollador 2014 es un libro sobre los "primeros principios" y no está específicamente orientado a un lenguaje de programación aunque sí hay temas muy específicos sobre diferentes lenguajes, tales como opciones de configuración o sobre cómo aplicar los principios básicos de seguridad sobre sistemas y aplicaciones.

Como principales novedades, además de la reorganización de categorías y subcategorías de algunas pruebas, se ha puesto especial hincapié en los siguientes puntos:


Además, se ha modificado y mejorado el contenido de los puntos de control habituales, haciendo un total de 87 puntos de control (frente a los 64 de la versión anterior). Se ha incluido información con referencias a otros proyectos importantes de OWASP, como son las guías de programación segura y para desarrolladores. Para esta versión 4 de la guía, encontraremos las siguientes categorías (en inglés): 

  1. Information Gathering (OTG-INFO)
  2. Configuration and Deployment Management Testing (OTG-CONFIG)
  3. Identity Management Testing (OTG-IDENT)
  4. Authentication Testing (OTG-AUTHN)
  5. Authorization Testing (OTG-AUTHZ)
  6. Session Management Testing (OTG-SESS)
  7. Input Validation Testing (OTG-INPVAL)
  8. Testing for Error Handling (OTG-ERR)
  9. Testing for weak Cryptography (OTG-CRYPST)
  10. Business Logic Testing (OTG-BUSLOGIC)
  11. Client Side Testing (OTG-CLIENT)
Cabe destacar la gran revisión que se la ha dado a la categoría "Business Logic" (Lógica de negocio), que ha pasado de tener una única subcategoría general en la versión 3 a 9 subcategorías en la versión 4. La re-factorición del material original de la Developer Guide v2.0, lanzado en julio de 2005, permite enfocarse en las aplicaciones del mundo y de las aplicaciones web modernas que utilizan AJAX, API RESTful y conectividad móvil. Todo el material (sobrante) sobre la realización de pruebas se moverá a la OWASP Testing Guide y todo material de revisión de código a la OWASP Code Review Guide.

Cristian de la Redacción de Segu-Info

martes, 9 de septiembre de 2014

Un informático en el lado del mal: Robar fotos de Apple iCloud de un usuario de iPhon...

Robar fotos de Apple iCloud de un usuario de iPhone

Ayer estuve en el programa de televisión "El Hormiguero" explicando cómo se pueden robar las fotos de un usuario de Apple iCloud que tenga un iPhone para  que la gente pueda entender entender de qué forma se ha podido realizar algún robo de fotos del Celebgate, para robar las fotos desnudas de las famosas. Al final, tal y como yo suponía, no ha sido un bug único sino un trabajo de mucha gente durante mucho tiempo que se ha dedicado a coleccionar este tipo de fotografías, haciendo para ello ataques dirigidos a las cuentas de las famosas.
Figura 1: Vídeo de la demo en el programa de El Hormiguero

Entre los trucos para robar las contraseñas se ha podido encontrar el ataque por fuerza bruta a Find My iPhone, el  robo mediante ataques man in the middle, elshoulder surfing o cualquier otro medio de ataque, pero seguro que muchos han optado por el ataque mucho más sencillo de Phishing dirigido. Esto en iOS, como se  cuenta en el libro de Hacking iPhone, es muy sencillo debido a las WebViews y la política de Apple contra el spoofing de correo electrónico y su aplicación. Vamos a ver la demo paso por paso para que se entienda mejor.

Fase 1: Spoofing, SPF y la  política de Gmail

Para hacer este ataque dirigido, el esquema que se va a utilizar es de lo más sencillo del mundo. Vamos a enviar un correo electrónico a la víctima haciéndola creer que viene de apple@apple.com. Para hacer esto nos vamos a aprovechar de que el filtro anti-spoofing de correo electrónico del dominio apple.com definido en el registro SPF (Sender Policy Framework) está configurado como un SoftFail (~s) y no como unHardFail (-s).

Figura 2: Configuración de registro SPF de apple.com

Esto quiere decir que el servidor de correo que recibe un correo del dominioapple.com que no venga de una dirección IP 17.0.0.X debería subir el scoring de posible spam, pero no darlo por malo. En el caso de que hubiera un HardFail (-s) se supone que apple.com le estaría diciendo al servidor de correo electrónico que recibe este correo que lo tire, que es falso.

Nuestra víctima de ejemplo tiene un correo electrónico creado para la ocasión deGmail, y Google no es especialmente amigo de tirar los correos electrónicos que el registro SPF marque como SoftFail, así que, como veremos, el correo entrará en el buzón de entrada de la víctima.

Fase 2: Spam y Phishing para robar la contraseña

Para hacer el ataque, en Eleven Paths creamos un pequeño panel de control que envía el "spam" - aunque sólo sea un correo a un destinatario - con un mensaje desde el equipo de Gmail o Apple que urge a las víctimas a ir a un servidor web a revisar su configuración.

Figura 3: Panel de control web para enviar spam de phishing y capturar las claves

Por supuesto, en ese servidor web lo que hay son dos páginas de Phishing que roban el usuario y la contraseña de las víctimas y re-dirigen después a las páginas originales. Un viejo truco del mundo del fraude online. No nos hemos complicado mucho y hemos copiado el formato de los mensajes usados en campañas de verdad.

Fase 2: Alerta inútil en Gmail para iOS & Address Bar Spoofing

Cuando el mensaje de correo electrónico llega, hemos utilizado como lector Gmail para iOS. Esto es así por varios motivos. El primero de ellos es porque es el cliente oficial de Gmail para los terminales iPhone, y muchos usuarios lo utilizan y el segundo porque tiene dos debilidades dignas de resaltar.

Figura 4: En Gmail entra el  e-mail de apple.com com SPF SoftFail
La primera debilidad es que tiene una alerta de navegación externa bastante inútil que informa de que se va a proceder a una navegación externa, pero la URLque el usuario ve es la de un servidor de Gmail y no la del  servidor web dePhishing, con lo que ayuda a tranquilizar a la víctima y que haga clic en el enlace.

Figura 5: Alerta de external page que no informa bien y Address Bar Spoofing en la WebView
La segunda de ellas es  que cuando se abre, lo hace una WebView que oculta la barra de direcciones y solo muestra el campo título de la página web, lo que ayuda a que se produzca un bug de Address Bar Spoofing de libro.

Figura 6: La contraseña se recoge en el panel del servidor de phishing
Por supuesto, en cuanto el usuario introduce su usuario y su contraseña en la web dePhishing, nosotros la enviamos a nuestro panel y después re-dirigimos la navegación del WebView a la web original de Apple y/o Gmail.

Fase 3: Acceso a Apple iCloud sin alerta ni 2FA

Con la contraseña de la víctima, el siguiente paso es bastante trivial. Basta con conectarse a Apple iCloud y descargarse el backup. Existen librerías en Python para hacer esto, pero para transmitir a la gente que esto a día de hoy no es "rocket science" hemos usado una herramienta muy conocida que se llama ElcomSoft Phone Password Breaker, que ya tiene herramientas para monitorizar backups en Apple iCloud.

Figura 7: ElcomSoft Phone Password Breaker permite descargar de iCloud
Para ello se necesita introducir el usuario y la contraseña o un token de autenticación de la cuenta y listo. No hace falta robar un segundo factor de autenticación, pues aunque el usuario tenga Verificación en Dos Pasos configurada en su cuenta de Apple ID y/o Apple iCloud, el servidor de Apple iCloud lo ignora.

Figura 8: Las credenciales para descargar el backup de Apple iCloud. Elcomsoft dice que ahora puede descargar el backup sin credenciales.
Una vez conectados a su cuenta, se pueden ver todos los dispositivos que hay, el número de serie, el UDID para preparar un troyano dirigido y el número de backupsque hay disponibles de ese dispositivo.
Figura 9: Se puede personalizar lo que se desea descargar del backup
Para no descargar todo puedes personalizar la descarga del backup, y bajarte lo que te interese. En este caso las fotografías de la víctima, pero podríamos descargar la base de datos de WhatsApp -  es conocido como un método para espiar WhatsApp -, la información de FacebookGmail, etcétera.
Figura 10: Se descarga lo seleccionado con hacer clic en Download
Una vez que se han descargado, ya lo único que hay que hacer es abrir la ubicación de descarga y tendremos acceso a las fotografías de la víctima, en este caso las de la falsa cuenta de Pablo que creamos para la ocasión.

Conclusiones

En este caso la password se roba con trucos muy conocidos y funcionales en el mundo del e-crime que todavía, a día de hoy, siguen funcionado. Tal vez porque los usuarios tienen que introducir demasiadas passwords en su vida y ya no se fijan dónde y cuándo lo hacen. Hay que intentar que cada vez que se inicia una sesión en un sitio se conozca, y por eso nosotros apostamos por algo como Latch.

Figura 11: El rollo de fotos descargado del backup de Apple iCloud
Respecto a Apple, a mí me encantaría que mejorasen la configuración del filtro SPF, que no hubiera posibilidad de hacer Brute Forcing en ningún sitio de la web - que ya está hecho según parece - que pudiera poner una clave extra de cifrado del backup - al igual que se hace en Apple iTunes -, que el segundo factor de autenticación funcionase en Apple iCloud y a ser posible que las contraseñas caducasen y se avise mejor de todos los inicios de sesión de cuentas (ahora se puede configurar una alerta  por e-mail).

Saludos Malignos!

lunes, 7 de julio de 2014

ElevenPaths Blog: Cómo y cuándo se ataca a Microsoft: análisis de vu...

Cómo y cuándo se ataca a Microsoft: análisis de vulnerabilidades

Microsoft ha publicado un par de artículos muy interesantes en su blog de seguridad, donde se desgrana quétipo de fallos de seguridad son los más atacados y cuándo se ha descubierto un exploit para ellos. Pretenden dejar claro que han mejorado (y es cierto), pero veamos algunos detalles que no mencionan y reflexiones derivadas de la evolución mostrada en los últimos años.

Lo primero, ha sido estudiar las causas de las vulnerabilidades más graves (las de ejecución de código) en su software desde 2006 a 2013. Según la raíz del problema, la vulnerabilidad será más o menos difícil de explotar por un atacante, aunque todas concluyan con la posibilidad de controlar del sistema. Es un estudio interesante porque:

  • Se centra en vulnerabilidades graves y explotables. Nada de números camuflados entre las "no explotables" o la gravedad.
  • No se compara más que con sus propios productos.
  • Las vulnerabilidades estudiadas no se encuentran contaminadas por el comportamiento del usuario. En este caso no importa qué haga ni qué ejecute (tan solo un poco qué visite, quizás, pero no parece relevante).

El estudio se resume en esta gráfica.

Causa de las vulnerabilidades de ejecución de código en Microsoft desde 2006

Lo primero que se observa es un descenso pronunciado de los desbordamientos de pila clásicos. Estas son las más sencillas de explotar... y detectar por el equipo de programación. Es cierto, Microsoft ha librado una lucha contra este tipo de fallo y al pensar en la seguridad desde el diseño, ha prohibido el uso de técnicas de programación que puedan derivar en este método y de librerías de C que se sabían inseguras. Incluso incorporan un "banned.h" para que el compilador avise directamente. Parece que da resultado...

Pero nada desaparece sin que lo sustituya otra técnica, puesto que los niveles de explotación se mantienen.Use-after-free es un fallo más complejo de detectar programando, y por eso Microsoft no puede detenerlo tan fácilmente. Si los atacantes no encuentran desbordamientos de pila, acuden a este fallo de manejo de objetos que puede derivar en ejecución de código. Además, da la "casualidad" de que este tipo de vulnerabilidades se encuentra más en los programas "cliente" y en concreto en el navegador, el tótem preferido por los exploiters: ejecución de código en IE implica tener el control del cliente con solo visitar una web.

Los exploits que evitaban la carga de DLL desde otras rutas fue una moda desde que se detectó el método, pero era fácil de corregir y dos años después ya casi no se encuentran programas que lo hagan mal (al principio la lista fue interminable, tanto de Microsoft como de otros). El desbordamiento de heap, más difícil de detectar en tiempo de programación (y de explotar), se mantiene invariable en estos años.

¿Han descendido las vulnerabilidades?

Una de los métodos que tiene Microsoft para luchar contra las vulnerabilidades de ejecución de código son DEP y ASLR, introducidos en Vista en 2006. Son las armas implementadas de forma predeterminada para amedrentar a los exploiters. Pero no tanto. La aparición de ROP, las fugas de direcciones de memoria, o el uso de librerías que no son compatibles con ASLR ha permitido a los atacantes seguir sacando provecho de estas vulnerabilidades. Pero aunque el el statu quo se ha mantenido, "huyendo" a otros tipos de vulnerabilidad o con la aparición de métodos nuevos... parece que según Microsoft, el número de vulnerabilidades de ejecución de código explotadas ha descendido un 70% en los últimos tres años en el software de la compañía. Este gráfico así lo muestra:

¿Cuándo se ha detectado un exploit para una vulnerabilidad de ejecución de código en Microsoft?
Esta imagen explica que, de las 20 vulnerabilidades que fueron explotadas en 2013 en sus productos, 13 se descubrieron siendo explotadas en forma de 0-day. 6 vulnerabilidades se descubrieron siendo explotadas durante los 30 días siguientes al anuncio del fallo, y solo una más tarde. Y, aunque en Microsoft destaquen sus bondades y la interpretación de estadísticas y barras se preste a todo tipo de argucias argumentales, este gráfico es muy curioso por varias razones. Algunas que consideramos relevantes.

¿Qué se deduce del gráfico?

  • En los titulares, Microsoft habla de la caída de vulnerabilidades desde 2010, pero no de la subida desorbitada hasta ese año, ni sus razones. ¿Por qué esa explosión de un año a otro? En 2010, con Windows 7 y IE8 ya en el mercado, el número de vulnerabilidades se dispara... fue un año convulso en Microsoft, y también para los atacantes. La creación de exploits les costó más esfuerzo (muchos más se crearon dentro de los 30 días posteriores al anuncio de la vulnerabilidad). Quizás sea porque estaban naciendo las nuevas técnicas para eludir DEP y ASLR, ya implantados con Windows 7, que se introducía en el mercado en ese momento y al que necesitaban llegar los atacantes. O también cabe otra teoría. ¿Puede ser que muchas de esas vulnerabilidades fueran encontradas por la propia Microsoft y luego los exploiters crearan el ataque? Esto en realidad sería positivo, una especie de "cura" interna por parte de la compañía para eliminar puntos débiles.
  • Si se habla desde 2006 es porque fue cuando se introdujo Vista, el primer sistema operativo con medidas de seguridad reales de serie... Si miramos de nuevo el gráfico, vemos que el número de vulnerabilidades de ejecución de código para las que se ha encontrado exploit, no ha variado sustancialmente desde 2006. Quizás, tras la desaparición de XP y la introducción de mejoras sustanciales de seguridad en el sistema, se podría esperar una caída más pronunciada en los exploits contra Microsoft... pero no parece que sea el caso. Como decíamos, el statu quo se mantiene. Las defensas mejoran pero los ataques son más sofisticados.
  • Echamos de menos especificar a qué software se refieren exactamente en las gráficas. Pero aunque no lo mencionen, sí es cierto que el número de vulnerabilidades de ejecución remota de código explotadas en programas servidor de Microsoft (Exchange, MSSQL, IIS, etc) es casi anecdótico desde hace años.
  • El número de vulnerabilidades descubiertas en forma de 0-day (siendo explotadas) no ha descendido en absoluto desde 2006. Son las más peligrosas y las que más daño causan a los usuarios.
  • En 2013, los exploits posteriores a los 30 días ya no tienen apenas presencia. No sirven a los atacantes. Y aquí quizás entra en juego el parcheo rápido y automático de Windows, que tanto bien ha proporcionado a los usuarios.
  • Se nota un descenso pronunciado a partir de 2012 del número de vulnerabilidades. ¿Microsoft ha mejorado o es que ya no suponían mucho interés para los atacantes? Un poco de todo. Recordemos que a partir de 2012 ocurrió algo muy interesante en el mundo de la seguridad: Java y sus fallos. Un auténtico caos que, hasta 2013, lo dominó todo (Oracle fue objeto de mofa durante dos años). Lo más sencillo para los atacantes era crear exploits triviales para Java y conseguir resultados óptimos. Solo hace falta ver el gráfico más abajo para comprender qué ocurrió en 2013. Entonces, desde el punto de vista de los atacantes ¿para qué analizar tanto el software de Microsoft (que además se hace más complicado cada vez) si se dispone de Java para mantener los niveles de infección y poder explotar? Ya sabemos que la correlación no implica causalidad, pero puede ser una teoría interesante. Habría que ver qué ocurre durante este año y el próximo para confirmar.

Fuente: Kaspersky

Pero en resumen, no se puede decir que Microsoft no haya mejorado. Es un hecho que explotar IE es ahora mucho más "caro" para un atacante, entre otras razones. Un detalle que mencionan, casi de pasada, es queaunque el número de 0-day en 2006 es parecido a los de 2013, no son de la misma "naturaleza": una buena parte se han encontrado atacando a objetivos muy específicos, es decir, hablamos de ciber-guerra. A medida que un 0-day tiene más valor, los atacantes no lo "malgastan" en el usuario medio... lo aprovechan para usos más "lucrativos" y potentes.

Sergio de los Santos
ssantos@11paths.com

miércoles, 25 de junio de 2014

Un informático en el lado del mal: Todas las herramientas de Black USA 2014 Arsenal

Todas las herramientas de Black USA 2014 Arsenal

Esta semana se ha publicado la lista de herramientas que van a componer el Arsenal de Black Hat USA 2014, y este año parece que han batido records en cuanto a número de ellas propuestas, ya que el número que hay es ingente. Entre ellas hay herramientas de compañeros y amigos como ProxyMe de nuestro compañero Manu "The Sur"WhatsApp Privacy Guard de Jaime Sánchez y Pablo San Emeterio para ayudar evitar los ataques de quienes quieren espiar WhatsApp o Voyeur de Juan Garrido "Silverhack" para auditar un Active Directory usando PowerShell y sin necesidad de cuentas administrativas.

Figura 1: Herramientas en Black Hat USA 2014 Arsenal

La lista es larga, y cuenta con herramientas de gran calado y utilidades pequeñitas pero que pueden resultar más que prácticas para muchos entornos. Aún no están disponibles en la web de Black USA 2014 Arsenal, pero la mayoría de ellas se pueden encontrar en sus repositorios de desarrollo. Este es un resumen que he hecho por si te puede ayudar a localizarlas mejor.

- ANDROID DEVICE TESTING FRAMEWORK: Framework y APIs para auditar Android
- AUTOMATED MEMORY ANALYSIS: Plugins para Cuckoo Sandbox
BEEF (Browser Explotation Framework): JavaScript Botnets Control Panel
- BREWSKI (BURP RHINO WEB SCANNER): Plugin para Burp scriptable
- C-SCAD: Herramienta de explotación de un cliente SCADA
CHIPSECAuditoría de plataforma (Secure Boot, BadBios, etc..)
CLASSIFY6: Command Line Tool que clasifica una dirección IPv6
CYNOMIX: Proyecto de clasificación de malware en familias
- DAMM: Análisis diferencial de malware en memoria
DEPENDENCY-CHECK: Analiza dependencias entre apps y librerías
DRADIS: Plataforma para consolidación de datos en auditorías
- FILIBUSTER: Analiza puertos filtrados en firewalls
FLOWINSPECTAnálisis e inspección de tráfico de  red con reglas
- FSEXPLOITME: ActiveX vulnerable para enseñar Browser Explotation
HEYBE: Herramienta de pentesting para redes empresariales
- ICE-HOLE: Framework para auditar tests de phishing en auditoría
IDB: Herramienta automatizada para auditar apps en iOS
- IMAS: iOS Mobile Application Security Libraries
IMPACKET: Clases en Python para herramientas de hacking de red
- ISPY: Herramientas de auditoría de Apps para iOS
JTAGULATOR: Herramienta de auditoría de chips en hardware
MALTRIEVERecuperar malware desde la fuente en que se sirve
- MELKOR: Herramienta de Fuzzing para formato de fichero ELF
MODSECURITY: Popular WAF OpenSource. Lo usamos en FOCA.
- MORNING CATCH: Virtual Machine para enseñar ataques client-side
MOZDEF THE MOZILLA DEFENSE PLATFORMPlataforma SIEM de Mozilla
- NFCULT: Auditar y explotar NFC ultralight en Android
- OOPS, RFIDID IT AGAIN: Pentesting de RFID
OWASP PCI TOOLKIT: Herramientas OWASP para aplicar PCI
OWASP ZED ATTACK PROXY (ZAP): Popular Proxy para pentesting
POWERSPLOITMetasploit-like escrito en PowerShell
PRAEDA: Explota impresoras multi-función y saca credenciales
- PROXYME: Proxy HTTP-s con plugins scriptables para auditoría web
- REGEORG: Creación de túneles vía HTTPs a puertos de red
- RICKROLLING YOUR NEIGHBORS WITH GOOGLE CHROMECAST: hacking Chromecast
- SECURESCAN SAAS FREE SCANNER: Vulnerability Management Cloud-Service
SERPICO: Crear informes con datos de herramientas de auditoría
- SHINOBOT SUITE: R.A.T. Simulator para auditar sistemas
SIMPLERISK: Herramienta de gestión de riesgo para empresas
- SMARTPHONE PEN-TEST FRAMEWORK: Hacking de usuarios con smartphone
SNOOPYSonda para recolectar información de dispositivos con cercanía
SPOTLIGHT INSPECTORAnálisis forense de BBDD Spotlight de OSX
- TAINTLESS: Detección y explotación de SQL Injection
THREADFIX: Gestión de vulnerabilidades y parches
VEIL-FRAMEWORK: Herramienta para pentesting en equipos
- VIPER: Herramienta de gestión de scrips para reversing
VIPROY: Herramienta para hacking de VoiP
VOLATILITY FRAMEWORK 2.4: Nueva versión de memory forensics
- VOYEUR: Auditoría de Active Directory hecha en PowerShell
W3AF: Web Security Scanner
WATOBO: Herramientas para auditoría web
WHATSAPP PRIVACY GUARD: Cifrado de WhatsApp
- ZIG TOOLS: Librerías Python para desarrollo con Freakduino
- ZITMO NOM: Para auditar el despliegue de ZitMo vía SMS
Como veis, la lista de herramientas es grande, así que he intentado resumir en una sola línea información básica para que decidas si quieres conocer mejor esas herramientas o no, además de dejaros enlaces a algunos de sus repositorios y/o documentación disponible. Si quieres saber más de cada una de ellas, visita la web del Arsenal o busca la herramienta en su repositorio si está disponible y ponte a probarla.

La verdad es personalmente me encanta ver la cantidad de gente que hay haciendo investigación en seguridad y que hace que cada día avance más el conocimiento. Con grandes herramientas, pequeñas soluciones o simplemente documentando y creando recursos para enseñar o agitar la mente de todos con nuevas ideas.

Saludos Malignos!

Related Posts Plugin for WordPress, Blogger...