blog

La creación de IOC o Indicadores de Compromiso, es el proceso de documentar las características y artefactos relacionados a un incidente de una manera estructurada. Esto incluye todo desde la perspectiva de un host y la red; cosas más allá de únicamente un malware. Se debe pensar sobre elementos como nombres de directorios de trabajo, nombres de archivos de salida, eventos de login, mecanismos de persistencia, direcciones IP, nombres de dominio, e incluso firmas de protocolos de red sobre malware. La meta de los IOCs es ayudar a describir efectivamente, comunicar, y encontrar artefactos relacionados hacia un incidente. Debido a un IOC es únicamente una definición, no proporciona una mecanismo actual para encontrar coincidencias. Se debe crear o adquirir una tecnología para aprovechar el lenguaje IOC.

Una importante consideración en la selección de como representar IOCs, es la habilidad de utilizar el formato dentro de la organización. Indicadores de compromiso de la red son más comúnmente representados como reglas de la herramienta Snort, además existen productos de nivel comercial como también open source o libres, los cuales son factibles de utilizar. Desde la perspectiva del host, algunos de los formatos IOC disponibles son; STIX y YARA.

STIX (Structured Threat Information Expression) es un lenguaje y formato para serialización, utilizado para intercambiar inteligencia de cyber amenazas (CTI). Mientras YARA es una herramienta cuyo propósito es (pero no se limita) a ayudar a los investigadores de malware a identificar y clasificar fácilmente muestras de malware.

Fuentes:

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti
https://oasis-open.github.io/cti-documentation/stix/intro
https://github.com/mandiant/ioc_writer
http://virustotal.github.io/yara/
http://cyboxproject.github.io/
https://oasis-open.github.io/cti-documentation/

La recopilación de pistas iniciales es un paso fundamental en cualquier investigación. Existe un tema no muy adecuado durante las investigaciones; centrarse únicamente en encontrar malware. Es poco probable la única meta del atacante sea instalar malware. El atacante probablemente tiene otras metas en mente, tal vez robar correos electrónicos o documentos, capturar contraseñas, interrumpir la red, o alterar datos. Una vez el atacante está en la red y tiene credenciales válidas, no necesita utilizar malware para acceder hacia otros sistemas. Enfocarse únicamente en malware probablemente generará la pérdida de hallazgos críticos.

Recordar el enfoque de cualquier investigación debe estar sobre las pistas. Se ha respondido muchas veces a varios incidentes donde otros equipos completaron las investigaciones revelando pocos hallazgos. En muchos casos la falla de las investigaciones previas es debido al hecho de los equipos no se enfocan en desarrollar pistas válidas. En cambio se enfocan en “objetos brillantes” irrelevantes, los cuales no contribuyen para resolver el caso. Existen numerosos incidentes donde se han encontrado hallazgos adicionales, como la perdida sustancial de datos, o acceso hacia sistemas sensibles de cómputo, simplemente siguiendo buenas pistas.

Frecuentemente se pasa por alto el proceso de evaluar nuevas pistas para asegurar sean sensibles. El tiempo extra invertido en evaluar las pistas ayudará la investigación se mantenga enfocada. Por experiencia existen tres características comunes de pistas potenciales:

Relevante: La pista se relaciona con el incidente actual. Esto puede parecer obvio pero frecuentemente es pasado por alto. Una trampa común en la cual caen las organizaciones es categorizar todo lo cual parezca sospechoso como parte del incidente actual. También un incidente hace muchas organizaciones observen el entorno en formas las cuales antes no lo habían hecho, descubriendo muchas “actividades sospechosas“ las cuales en realidad son normales. Esto abruma rápidamente al equipo con trabajo descarrilando la investigación.

Detallado: La pista potencial tiene detalles sobre el curso potencial de la investigación. Por ejemplo un tercero puede proporcionar pistas las cuales indican una computadora en el entorno se comunicó con un sitio web externo hospedando malware. Aunque fue bueno se informe sobre esto esta pista no es muy específica. En este caso se debe necesita una palanca para más detalles. Preguntar sobre la fecha y hora del evento y las direcciones IP; pensar quien, que, donde, cuando, porque, y como. Sin estos detalles se perderá tiempo.

Accionable: La pista contiene información factible de ser utilizada y la organización posee los medios necesarios para seguir la pista. Considerar una pista la cual indique una gran cantidad de datos transferidos hacia un sitio web externo asociado con una botnet. Se tiene la fecha y hora exacta, y la dirección IP de destino. Sin embargo la organización no tiene registros de datos sobre el flujo de red o firewall, disponible para identificar el recurso interno el cual fue la fuente de datos. En este caso esta pista no es muy accionable, porque no hay una manera de trazar la actividad hacia una computadora específica de la red.

Fuentes:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2…

Wfuzz ha sido creado para facilitar la tarea en las evaluaciones contra aplicaciones web, y está basado en un concepto simple; reemplaza cualquier referencia a la palabra clave FUZZ, por el valor del payload (carga útil) definido.

Un payload en Wfuzz es una fuente de datos.

Este concepto simple permite cualquier entrada sea inyectada en cualquier campo de una petición HTTP, permitiendo realizar ataques complejos de seguridad web en diferentes componentes de la aplicación web, como parámetros, formularios, directorios/archivos, cabeceras, etc.

Wfuzz es más a únicamente un escáner de contenido web:

• Wfuzz podría ayudar a asegurar las aplicaciones web, encontrando y explotando vulnerabilidades en la aplicación web. El escáner de vulnerabilidades de aplicación web de Wfuzz es soportado por plugins.
• Wfuzz es un framework completamente modular, lo cual facilita para incluso los novatos en desarrollo con Python contribuir. Construir plugins es simple, y toma poco más de algunos minutos.
• Wfuzz expone una interfaz simple de lenguaje hacia peticiones y respuestas HTTP previas, realizadas utilizando Wfuzz u otras herramientas como Burp. Esto permite realizar pruebas manuales o semiautomáticas con el contexto completo, y entendiendo las acciones, sin depender del escáner de aplicación web subyacente a la implementación.

Wfuzz fue creado para facilitar la tarea en las evaluaciones de aplicaciones web. Es una herramienta de profesionales en pruebas de penetración, para profesionales en pruebas de penetración.

La opción “-h” presenta la ayuda de la herramienta Wfuzz.

# wfuzz -h

Wfuzz puede ser utilizado para buscar contenido oculto, como archivos y directorios dentro de un servidor web, permitiendo encontrar vectores de ataque. El éxito o no de esta tarea depende altamente de los diccionarios utilizados.

La siguiente demostración se realiza utilizando la aplicación web de nombre “XVWA”. Se ejecuta Wfuzz para encontrar directorios dentro de la aplicación web “XVWA”.

La opción “-w” define el archivo conteniendo la lista de palabras. (es una alias para -z file,wordlist). La opción “--hc”, oculta las respuestas con un código 404. Es decir “Archivo no encontrado”.

# wfuzz -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt –hc 404 http:// 192.168. 0.66 /xvwa/FUZZ

Los resultados muestran 17 payloads encontrados. Mostrándose respuestas diferentes al código 404, como 200, 301 y 302. Todos estos resultados deben ser verificados manualmente, y así evitar los falsos positivos.

Adicionalmente se muestra el número de peticiones realizadas, el tiempo total de procesamiento, el número de peticiones procesadas, el número de peticiones filtradas, y el número de peticiones por segundo.

Fuentes:

https://github.com/xmendez/wfuzz
https://wfuzz.readthedocs.io/en/latest/
https://github.com/s4n7h0/xvwa

Droopescan es un escáner basado en plugins, el cual ayuda a los investigadores de seguridad en la identificación de problemas con algunos CMS.

El uso de droopescan para atacar sistemas sin un consentimiento mutuo y previo es ilegal. Es la responsabilidad del usuario final obedecer todas las leyes locales, estatales o federales. Los desarrolladores no asumen responsabilidad por algún uso inadecuado o daño causado por este programa. Por favor anotar aunque los resultados de droopescan para la mayoría de CMSs, es probable incluyan la versión instalada en el host remoto, cualquier correlación entre los números de versión y vulnerabilidades deben ser hechos manualmente por el usuario.

Los CMS soportados son SilverStripe y Wordpress. Tiene funcionalidad parcial para Joomla (Únicamente enumeración de la versión y URLs interesantes). Moodle (Muy limitada verificación de plugins y temas). Y Drupal (Descubrimiento parcial de plugins sobre nuevas instalaciones de Drupal).

Droopescan no está instalado por defecto en Kali Linux. Su procedimiento de instalación implica ejecutar los siguientes comandos:

# git clone https://github.com/ droope/droopescan.git
# cd droopescan
# pip install -r requirements.txt

La opción “help” permite visualizar la ayuda de Droopescan.

# ./droopescan --help

Para obtener un lista completa y detallada de opcionesde Droopescan ejecutar:

# ./droopescan scan --help

El primer escaneo implica realizar un escaneo contra una instalación de WordPress.

# ./droopescan scan wordpress -u http://192.168 .0.66 /wordpress/

Los resultados obtenidos incluyen los temas encontrados, posibles URLs interesantes, y posibles versiones, además de los plugins encontrados. Mencionar aquí la versión de Wordpress no es la misma, pero se aproxima bastante.

El segundo escaneo implica realizar un escaneo contra una instalación de Drupal.

# ./droopescan scan drupal -u http://192.168 .0.66 /drupal/

Los resultados obtenidos incluyen los temas encontrados, posibles URLs interesantes, y posibles versiones, además de los plugins encontrados. Mencionar aquí la versión de Drupal si es la correcta.

El tercer y último escaneo implica realizar un escaneo contra una instalación de Joomla.

# ./droopescan scan joomla -u http://192.168 .0.66 /joomla/

Los resultados obtenidos incluyen los temas encontrados, posibles URLs interesantes, y posibles versiones. Mencionar aquí la versión de Joomla correcta se incluye en el listado. Lo cual puede ser útil como referencia de otras evaluaciones.

Fuentes:

https://github.com/droope/droopescan

Gobuster es una herramienta utilizada para realizar fuerza bruta a: URIs (directorios y archivos) en sitios web, subdominios DNS (con soporte de comodines), y nombres de hosts virtuales en los servidores web.

Gobuster tiene tres modos disponibles. “dir”, el modo clásico de fuerza bruta contra directorios, “dns”, el modo de fuerza bruta contra subdominios DNS, y “vhost”, el modo de fuerza bruta contra hosts virtuales (no es lo mismo a “DNS”).

La opción “help” muestra la ayuda de nivel superior de Gobuster

# gobuster help

La opción “help dir” muestra la ayuda específica del modo “dir”. Pudiendo ser utilizada también para obtener la ayuda de los otros modos, como “dns” y “vhost”

# gobuster help dir

Para la siguiente demostración se utiliza Gobuster contra la aplicación web de nombre XVWA.

La opción “-u” define la URL en evaluación. La opción -t define el numero de hilos concurrentes (en este caso 20). La opción “-w” define el archivo conteniendo una lista de palabras. (En este caso se utiliza una de las listas de una herramienta de nombre dirbuster). Y la opción “-x” define las extensiones de los archivos a buscar (en este escenario son archivos .php y .html)

# gobuster dir -u http:// 192.168. 0.66/xvwa/ -t 20 -w /usr/ share/wordlists/dirbuster/directory-list-1.0.txt -x .php .html

Para los resultados obtenidos, se sugiere tener especial atención en los códigos de estado devueltos por las peticiones realizadas. En esta demostración se han obtenido los códigos de estado 200, 301, 302. Adicionalmente se deben revisar los resultados manualmente utilizado un navegador web.

Fuentes:

https://github.com/OJ/gobuster
https://github.com/s4n7h0/xvwa

HTTP ofrece un número de métodos los cuales pueden ser utilizados para realizar acciones sobre el servidor web (el estándar HTTP 1.1 se refiere a estos como métodos, pero también son comúnmente descritos como verbos). Aunque GET y POST son los métodos más utilizado para acceder a información proporcionada por un servidor web, HTTP permite algunos otros métodos (siendo algunos métodos poco conocidos). Estos pueden ser utilizados para propósitos nefastos si el servidor web está mal configurado.

A continuación se exponen tres técnicas para evaluar los métodos HTTP.

Se ejecuta la herramienta de nombre “curl”. La opción “-i”, incluye las cabeceras de respuesta HTTP en la salida. Las cabeceras de respuesta puede incluir, el nombre del servidor, cookies, fecha del documento, versión HTTP y más. La opción “-X” específica un método personalizado de petición, el cual es utilizado cuando se realiza la comunicación con el servido HTTP.

# curl -i -X OPTIONS http://192. 168.0. 66

Se ejecuta la herramienta de nombre “nmap”. El script de nombre NSE “http-methods”, encuentra las opciones soportadas por el servidor HTTP, enviando una petición OPTIONS. Listando potencialmente los métodos riesgosos. El argumento del script “http-methods.url” define la ruta para realizar la petición.

# nmap -p80 –script http-methods –script-args http-methods.url=’/xvwa’ 192. 168.0. 66

Es factible también hacer las peticiones manualmente, para evaluar los diferentes métodos tales como GET, POST, PUT, DELETE, CONNECT, OPTIONS y TRACE. Siendo factible también utilizar la herramienta “curl”. A continuación un ejemplo con el método “POST”.

Se ejecuta la herramienta de nombre “curl”. Aparte de las opciones definidas y explicadas en el primer ejemplo, la opción “-d” envía los datos especificados en la petición POST hacia el servidor HTTP, de la misma manera hecha por el navegador cuando un usuario completa un formulario HTTP, y luego presiona un botón enviar.

# curl -i -X POST http://192. 168.0. 66/dvwa/index.php -d “username=user&password=user”

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
https://tools.ietf.org/html/rfc7231
https://curl.haxx.se/
https://nmap.org/nsedoc/scripts/http-methods.html

La complejidad intrínseca de la infraestructura de red interconectada y heterogénea, lo cual incluye cientos de aplicaciones web, genera la administración y revisión de la configuración sea un paso fundamental en cada prueba y despliegue de las aplicaciones. Puede ser una vulnerabilidad la cul mine la seguridad completa de la infraestructura, e incluso pequeños problemas y aparentemente sin importancia, pueden evolucionar en severos riesgos para otra aplicación en el mismo servidor. Para abordar estos problemas, es de suma importancia realizar una revisión profunda de la configuración y problemas conocidos de seguridad, después de haber mapeado toda la arquitectura.

La gestión adecuada de la configuración de la infraestructura del servidor web es muy importante para preservar la seguridad de la aplicación. Si elementos tales como el software del servidor web, los servidores de datos backend, o los servidores de autenticación no son adecuadamente revisados y asegurados, podría introducir riesgos indeseables o introducir nuevas vulnerabilidades los cuales podrían comprometer la aplicación.

Por ejemplo una vulnerabilidad del servidor web podría permitir a un atacante remoto exponer el código fuente de la aplicación por si misma (una vulnerabilidad la cual ha surgido varias veces en los servidores web o servidores de aplicaciones), lo cual podría comprometer la aplicación, como usuarios anónimos podrían utilizar la información expuesta en el código fuente para aprovechar los ataques contra la aplicación o usuarios.

Se deben seguir los siguientes pasos para probar la configuración de la gestión de infraestructura.

• Los diferentes elementos constituyendo la infraestructura necesitan ser determinados para entender como interactúan con una aplicación web, y como afectan su seguridad.
• Todos los elementos de la infraestructura necesitan ser revisados para asegurarse no contienen vulnerabilidades conocidas.
• Una revisión necesita ser hecha de las herramientas administrativas utilizadas para mantener todos los diferentes elementos.
• Los sistemas de autenticación necesitan ser revisados para asegurar sirven a las necesidades de la aplicación, y no pueden ser manipulados por los usuarios externos para aprovechar el acceso.
• Una lista de puertos definidos requeridos por la aplicación deben ser mantenidos bajo control de cambios.

Después de haber mapeado los diferentes elementos componiendo la infraestructura, es posible revisar la configuración de cada elemento encontrado, para luego evaluarlo por vulnerabilidades conocidas.

Objetivos de la Prueba

Mapear la infraestructura soportando la aplicación y comprender como afecta la seguridad de la aplicación

Como Evaluar

Vulnerabilidades Conocidas del Servidor

Las vulnerabilidades encontradas en las diferentes áreas de la arquitectura de la aplicación, ya sea en el servidor web o en la base de datos backend, pueden severamente comprometer la aplicación. Por ejemplo considerar una vulnerabilidad la cual permite a un usuario remoto no autenticado subir archivos hacia el servidor o incluso reemplazar archivos. Esta vulnerabilidad podría comprometer la aplicación, pues un usuario maliciosos puede ser capaz de reemplazar la aplicación o introducir código el cual afectaría a los servidores backend, pues el código de aplicación se ejecutaría como cualquier otra aplicación.

Revisar las vulnerabilidades del servidor web puede ser difícil de hacer si la prueba necesita ser hecha a través de una prueba de penetración ciega. En estos casos las vulnerabilidades necesitan ser probadas desde un sitio remoto, típicamente utilizando una herramienta automática. Sin embargo, probar por vulnerabilidades puede tener resultados impredecibles en el servidor web, y probar por otras (como aquellas directamente involucradas en ataques de negación de servicio), podrían no ser posibles, debido al tiempo de inactividad involucrados si la prueba no es exitosa.

Algunas herramientas automáticas marcarán vulnerabilidades basadas en la versión obtenida del servidor web. Esto conduce a falsos positivos o falsos negativos. De otro lado si el proveedor del software no actualiza la versión del servidor cuando se arreglan las vulnerabilidades, la herramienta de escaneo marcará las vulnerabilidades no existentes. Un caso muy común es algunos proveedores de sistemas operativos respaldan parches de vulnerabilidades de seguridad al software proporcionado con el sistema operativo, pero no realizan una carga completo a la versión más reciente del software. Esto ocurre en muchas distribuciones GNU/Linux como Debian, Red Hat o SuSE. En muchos casos, los escaneadores de vulnerabilidades de una arquitectura de una aplicación, solo encontrarán vulnerabilidades asociadas con los elementos “expuestos” de la arquitectura (como el servidor web), y usualmente serán incapaces de encontrar vulnerabilidades asociadas con elementos los cuales no están expuestas directamente, como con backends de autenticación, el backend de base de datos, o proxys reversos utilizados.

Finalmente no todos los proveedores de software exponen las vulnerabilidades de una manera pública, y por lo tanto estas debilidades no se registran dentro de las bases de datos públicas de vulnerabilidades. Esta información es únicamente divulgada hacia los clientes o publicadas a través de arreglos, los cuales no tienen anuncios acompañándolos. Esto reduce la utilidad de las herramientas para el escaneo de vulnerabilidades. Típicamente la cobertura de vulnerabilidades de estas herramientas sería muy buena en productos comunes (como un servidor web Apache, Microsoft IIS, o Lotus Domino de IBM), pero será escaso para productos menos conocidos.

Esto es porque revisar las vulnerabilidades es mejor hecho cuando al profesional se le proporciona información interna del software utilizado, incluyendo versiones y publicaciones utilizados, además de los parches aplicados en el software. Con esta información, el profesional puede obtener información del proveedor, para luego analizar cuales vulnerabilidades podrían estar presenten en la arquitectura, y como estas pueden afectar la aplicación. Cuando es posible estas vulnerabilidades pueden ser evaluadas para determinar sus efectos reales, y para detectar si podrían existir algunos elementos externos (como sistemas para la detección o prevención de intrusiones), los cuales podrían reducir o negar la posibilidad de una explotación exitosa. Los profesionales podrían incluso determinar, a través de una revisión de configuración, la vulnerabilidad no está presente, pues afecta un componente de software no siendo utilizado.

También es importante considerar, los proveedores algunas veces arreglan silenciosamente las vulnerabilidades, y hacen los arreglos disponibles con nuevas publicaciones del software. Diferentes proveedores podrían tener diferentes ciclos de publicación, lo cual determina el soporte brindado para publicaciones anteriores. Un profesional con información detallada sobre versiones de software utilizado por la arquitectura, puede analizar el riesgo asociado por el uso de publicaciones anteriores de software, lo cual podría no ser soportado a corto plazo, o ya no ser soportado. Esto es crítico pues si una vulnerabilidad aparece en una versión antigua de software ya no soportada, el personal de los sistemas podría no ser directamente consciente de esto. Ningún parche podría incluso estar disponible para esto, y los anuncios podrían no listar las versiones vulnerables, pues ya no son soportadas. Incluso en un evento en el cual se sea consciente de la vulnerabilidad está presente y el sistema es vulnerable, se necesita hacer un actualización completa hacia la nueva publicación del software, lo cual podría introducir tiempo de inactividad significativo, o podría forzar la aplicación se vuelva a activar debido a incompatibilidades con la más reciente versión del software.

Herramientas Administrativas

Cualquier infraestructura de servidor web requiere la existencia de herramientas administrativas para mantener y actualizar la información utilizada por la aplicación. Esta información incluye contenido estático (páginas web, archivos gráficos), código fuente de la aplicación, bases de datos para autenticación del usuarios, etc. Las herramientas administrativas podrían diferir dependiendo del sitio, la tecnología, o software utilizado. Por ejemplo algunos servidores web podrían ser gestionados utilizando interfaces administrativas los cuales en son si mismos los servidores web (como el servidor web iPlanet), o se podría administrar mediante la configuración de archivos en texto plano (en el caso de Apache), o utilizar herramientas gráficas del sistema operativo (cuando se usa el servidor Microsoft IIS o ASP.Net).

En muchos casos la configuración del servidor web podrían ser manejada utilizando diferentes herramientas para el mantenimiento de archivos utilizados por el servidor web, los cuales son gestionados a través de FTP, WebDAV, sistemas de archivos en red (NS, CIFS), u otros mecanismos. Obviamente el sistema operativo de los elementos constituyendo la arquitectura de la aplicación también se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener interfaces administrativas incorporadas en estas, las cuales son utilizadas para gestionar los datos de la aplicación (usuarios, contenidos, etc.).

Después de haber mapeado las interfaces administrativas utilizadas para gestionar las diferentes partes de la arquitectura, es importante revisarlas, pues si un atacante gana acceso hacia cualquiera de estas, pueden comprometer o dañar la arquitectura de la aplicación. Para hacer esto es importante:

• Determinar loa mecanismos controlando el acceso hacia estas interfaces y sus susceptibilidades asociadas. Esta información puede estar en línea.
• Cambiar el nombre de usuario y contraseña por defecto.

Algunas compañías seleccionan no gestionar todos los aspectos de sus aplicaciones de servidor web, pero hacen a otras partes gestionen el contenido entregado por la aplicación web. Esta compañía externa podría ya sea proporcionar únicamente partes del contenido (noticias o promociones), o podría gestionar completamente el servidor web (incluyendo contenido y código). Es común encontrar interfaces administrativas disponibles desde Internet en estas situaciones, pues utilizar Internet es barato en lugar de proporcionar una línea dedicada la cual conectará la compañía externa hacia la infraestructura de la aplicación, a través de una interfaz de gestión. En esta situación es muy importante evaluar si las interfaces administrativas pueden ser vulnerables a ataques.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appl…
https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appl…

Las evaluaciones de Equipo Rojo ofrecen ventajas sobre los otros métodos y tecnologías para mejorar la postura de seguridad de una organización. Los Equipos Rojos son la herramienta más precisa para la implementación en seguridad de la información. Esto no implica decir es lo mejor o lo mejor en cualquier situación, es simplemente más preciso. Un Equipo rojo puede identificar las capacidades y deficiencias de los diferentes activos de una organización, lo cual proporcionar una evaluación única sobre la preparación de una organización, para resistir los esfuerzos de un atacante malicioso.

Es importante entender la evaluación es tan buena como los profesionales en Hacking Ético quienes lo realizan, y quienes evalúan están limitados con el alcance y las reglas del contrato a los cuales se sujetan. Todo lo cual se considera adecuado para la situación, el Equipo Rojo proporciona una gran eficiencia en costos para le mejora en la postura de seguridad, cuando se compara con abarcar las preocupaciones en seguridad después de haber sido aprovechadas por un atacante malicioso.

El Equipo Rojo es considerado una herramienta precisa, porque es muy quirúrgica en su aplicación, además de ser extremadamente peligrosa en manos no entrenadas o no éticas. Realizado por un equipo competente, es la única herramienta para compromiso proactivo disponible. Donde muchas tecnologías en seguridad son construidas alrededor del concepto de reaccionar, el Equipo Rojo permite a una organización buscar problemas de seguridad y mitigarlos antes de se inicien los intentos de compromiso, no después.

Se puede argumentar, las actividades como los escaneos de vulnerabilidades y buena gestión de parches son también proactivos. Es importante anotar, aunque no se basa en una reacción hacia un evento de seguridad dentro de una organización, ambas son reacciones hacia eventos de seguridad, en otros lugares donde proporcionan detalles para las nuevas vulnerabilidades por los cuales se escanean o arreglan. Algunos consideran a la caza de amenazas como otra herramienta proactiva por naturaleza, la cual tiene como propósito identificar indicadores de compromiso de actores ya dentro de la organización, lo cuales pueden ser o no agresores conocidos. A diferencia del Equipo Rojo, la caza de amenazas es una actividad posterior al compromiso.

Fuentes:

https://en.wikipedia.org/wiki/Red_team
https://en.wikipedia.org/wiki/Cyber_threat_hunting

Botones y Atajos

El botón ubicado en la esquina superior izquierda del Cliente Maltego, es llamado el botón de Aplicación (algunas veces también llamado el icono Globo), su propósito es abrir el Menú de Aplicación.

Los botones hacia la derecha del botón de Aplicación son botones atajo de aplicación. Los botones Deshacer, y Rehacer incluyen menús desplegables, haciendo clic se mostrará un lista de acciones gráficas factibles de ser deshechas y nuevamente hechas, dependiendo de la selección.

Al superponerse sobre una acción podría también seleccionar todas las acciones antes de esta.

El botón de Inicio de Máquina también incluye un menú desplegable, el cual muestra una lista de todas las Máquinas disponibles en el Cliente Maltego cuando se hace clic.

Hacer clic en una de las Máquinas desde la lista, abrirá una ventana de diálogo donde los objetivos de la Máquina pueden ser ingresados, a continuación de lo cual la Máquina será ejecutada.

La flecha hacia abajo debajo del botón de Nuevo gráfico es utilizado para minimizar la cinta principal.

Cuando se minimiza, el hacer clic en cada una de las pestañas en la cinta, se abrirá temporalmente la cinta hasta se haga clic fuera de esta. Esto permite liberar espacio real en pantalla cuando se trata con grandes gráficos.

Al hacer clic en la flecha hacia la derecha se maximizará nuevamente la cinta, para siempre sea mostrada.

Desplegable

El botón de Aplicación de Maltego proporciona acceso hacia las siguientes funcionalidades estándar:

• Nuevo Gráfico
• Abrir Gráfico
• Guardar
• Guardar Todo
• Guardar Como

Maltego puede Abrir y Guardar gráficos con extensión mtgl.

Abrir el Menú de Aplicación proporciona las siguientes opciones:

En el lado derecho del Menú de Aplicación desplegable, los gráficos recientemente abiertos con Maltego serán listados. Estos gráficos pueden ser rápidamente abiertos haciendo clic en estos.

Importar

Bajo la sección Importar del Menú de Aplicación, se listan varias opciones de importación, los cuales permiten importar datos en Maltego.

Exportar

Bajo la sección Exportar del Menú de Aplicación, se listan varias opciones de exportación sacar datos desde el Cliente Maltego.

Imprimir

El menú del botón Aplicación también proporciona la opción de Imprimir o Previsualizar el Gráfico Actual.

Hacer clic en “Imprimir una Previsualización del Gráfico Actual” abrirá una ventana de previsualización de impresión, el cual proporciona diversas opciones.

Maltego puede enviar el gráfico actual (en cualquier vista o disposición) hacia la impresora. Se puede imprimir una única página o varias páginas. Con múltiples páginas se necesita especificar cuantas filas y cuantas columnas de páginas serán impresas.

Herramientas

Casa

Hacer clic en el botón “Casa” abrirá la Página de Inicio de Maltego, y el Concentrador de Transformadas en una nueva pestaña.

Metadato del Gráfico

El botón de Metadatos del Gráfico abrirá una nueva ventana conteniendo los metadatos del gráfico. El campo Autor para el gráfico actual puede ser editado en esta ventana.

Las métricas sobre el número de Entidades y Enlaces para cualquier gráfico siempre se encuentran en la esquina inferior derecha del gráfico.

El primer número es el número de Entidades en el gráfico, incluyendo todas las Entidades encontradas en la colección de nodos. El segundo número es el número de nodos en el gráfico, esto contabiliza una colección (con múltiples Entidades) como un simple nodo. El tercer número es el número de enlaces en el gráfico, y el último número son bordes donde las conexiones entre colecciones de nodos se contabilizan como un borde.

Abrir un Gráfico de Ejemplo

Hacer clic en Abrir un Gráfico de Ejemplo abrirá un gráfico de mediano tamaño. Este gráfico de ejemplo es útil cuando se necesita rápidamente un gráfico para propósitos demostrativos.

Encontrar en Archivos

Encontrar en Archivos permite buscar a través de múltiples gráficas de Maltego a la vez, las cuales están almacenadas en la máquina cliente.

Activación Fuera de Linea

Esto tiene relación con la Activación Inicial de Maltego sin conexión a Internet.

Verificar por Actualizaciones

Hacer clic en Verificar por Actualizaciones abrirá un ventana donde se puede visualizar si están disponibles nuevas actualizaciones, para ser descargadas e instaladas.

Reseteo de Fábrica

El Reseteo de Fabrica reseteara el Cliente Maltego hacia un estado fresco de instalación. Esto significa todas las configuraciones personalizadas de Maltego se perderán. Al hacer clic en el botón de reseteo de Fábrica se abrirá un ventana de diálogo para continuar con este proceso.

Abrir Carpeta de Logs

La Carpeta de Logs ayuda al equipo de soporte para la resolución de problemas experimentados al utilizar Maltego.

Más Sobre Maltego

Las secciones Más sobre Maltego del Menú de Aplicación proporciona los siguientes enlaces:

• Leer la Guía de Usuario: Esto abrirá la documentación oficial de Maltego en el navegador por defecto.
• Obtener Soporte Técnico: Esto abrirá un formulario web de contacto, donde cualquier pregunta técnica puede ser enviada directamente al equipo de soporte técnico.
• Registrar una Falla: Esto abrirá un formulario web de contacto, donde cualquier falla en Maltego puede ser reportada al equipo de desarrollo.
• Leer el Blog de Maltego: Este enlace abrirá el blog oficial de Maltego, donde se publican nuevas funcionalidades publicadas para Maltego
• Sobre Maltego: Hacer clic en esta última opción de la sección, Sobre Maltego, abrirá una página la cual proporciona información sobre la instalación del Cliente Maltego actual, y la configuración del sistema.

Fuentes:

https://www.maltego.com/
http://www.reydes.com/d/?q=Glosario_de_Terminos_de_Maltego
http://www.reydes.com/d/?q=Pagina_Principal_de_Maltego

Cuando se inicia el Cliente de Escritorio Maltego por primera vez se presentará una Página Principal.

La Página Principal incluye la Página de Inicio ubicado en el lado izquierdo, y el Concentrador de Transformadas ubicado en el lado derecho.

Página de Inicio

La Página de Inicio incluye enlaces hacia todas las cuentas en medios sociales de Maltego, además de notificaciones importantes. Generalmente Maltego utiliza Twitter para publicar notificaciones sobre las nuevas características y YouTube para publicar video tutoriales. Cualquier notificación crítica será publicado directamente en esta página.

Cualquier entrenamiento público también será anunciado en la página de inicio.

Concentrador de Transformadas

En el lado derecho de la página principal se encuentra en Concentrador de Transformadas

El Concentrador de transformadas permite instalar Transformadas proporcionadas por proveedores terceros de Transformadas, como también Transformadas adicionales proporcionados por Paterva. Cada uno de los paquetes de Transformadas en el concentrador de Transformadas son referidos como elementos del Concentrador de Transformadas.

Fuentes:

https://www.maltego.com/