blog

REMnux es un conjunto de herramientas Linux para realizar ingeniería inversa y analizar software malicioso. REMnux proporciona una colección seleccionada de herramientas gratuitas creadas por la comunidad. Los analistas pueden utilizarlo para investigar malware sin el requerimiento de buscar, instalar, y configurar las herramientas.

El corazón del proyecto es la distribución Linux REMnux basada en Ubuntu, el cual incorpora muchas herramientas utilizadas por los analistas de malware para:

• Examinar las propiedades estáticas de un archivo sospechoso
• Analizar estáticamente código malicioso
• Ingeniería reversa dinámica de código malicioso
• Realizar forense de memoria de un sistema infectado
• Explorar las interacciones de red para realizar análisis de comportamiento
• Investigar las interacciones del malware a nivel del sistema
• Analizar documentos maliciosos
• Recolectar y analizar datos sobre amenazas

La manera más fácil de obtener la distribución REMnux es descargando una máquina virtual en el formato OVA, para luego importarlo en el hipervisor

También se puede instalar la distribución desde cero en un host dedicado, o añadirlo hacia un sistema ejecutando una versión compatible de Ubuntu.

El conjunto de herramientas REMnux también ofrece imágenes Docker de las herramientas populares para análisis de malware, lo cual permite ejecutarlas como contenedores sin el requerimiento de instalar las herramientas directamente en el sistema. Se puede incluso ejecutar la distribución REMnux como un contenedor.

Para detalles más específicos sobre la instalación, utilización, y contribución a REMnux, como también información sobre las herramientas incluidas en el conjunto de herramientas, se sugiere revisar el sitio conteniendo la información oficial de REMnux.

Fuentes:

https://remnux.org/
https://docs.remnux.org

Introducción

El sistema de archivos NTFS es utilizado en todos los sistemas críticos de Microsoft Windows. Es un sistema de archivos avanzado significativamente diferente a los sistemas de archivos UNIX. Este documento ofrece una descripción general rápida de NTFS, además de como fue implemetnado. La más grande diferencia es la utilización de flujos de datos alternativos (ADS), al especificar una estructura de metadatos.

El Sleuth Kit permite investigar una imagen NTFS de la misma manera a cualquier imagen UNIX, incluyendo:

• Creación de una línea de tiempo o cronología ASCII sobre la actividad del archivo
• Análisis de clusters y mapeo entre clusters y entradas MFT
• Análisis MFT y mapeo entre entradas MFT y nombres de archivos
• Análisis a nivel de archivos y directorios, incluyendo archivos borrados

Direcciones de Metadatos

Sleuth Kit permite visualizar todos los aspectos de una estructura NTFS. Se hace utilizando un formato especial para la dirección de metadatos. Con UNIX solo se necesita referencias al número de inodo, pues solo existe una pieza del contenido para el archivo. Con NTFS se puede especificar el número MFT y se utiliza el atributo de datos predeterminado, o se puede especificar el tipo agregándolo hacia el final de la entrada MFT, 36-128 por ejemplo. Si existe más de un atributo del mismo tipo, entonces se puede usar la identificación después del tipo, 36-128-5 por ejemplo.

Todas las herramientas en Sleuth Kit pueden tomar valores MFT en cualquiera de los formatos anteriores, y el resultado de las herramientas también estará en uno de los formatos anteriores. Por ejemplo, la herramienta istat enumerará todos los atributos pertenecientes a un archivo. Para obtener los detalles de la entrada 228 de MFT, utilizar:

$ istat -o 2048 NTFS_Pract_2017.raw 228

Se visualizan cuatro atributos, tres residentes (fíjarase en los tamaños pequeños), y un atributo no residente . Un atributo es $DATA (128-2). El nombre completo de 128-2 es 'firewall.txt'.

El siguiente comando mostraría el atributo de datos predeterminado (128-2):

$ icat -o 2048 NTFS_Pract_2017.raw 228

Lo siguiente es lo mismo:

$ istat -o 2048 NTFS_Pract_2017.raw 228-128-2

Como ejemplo adicional, el formato bruto del atributo $FILE_NAME se puede visualizar utilizando:

$ icat-o 2048 NTFS_Pract_2017.raw 228-128-2

El resultado del comando anterior será una combinación de caracteres UNICODE y otros datos binarios (se sugiere simplemente utilizar el resultado del comando istat para este tipo de datos).

Esto le permite identificar fácilmente todos los flujos de datos.

Tenga en cuenta que Autopsy puede automatizar este proceso permite ver todos los atributos.

Fuentes:

http://wiki.sleuthkit.org/index.php?title=NTFS_Implementation_Notes
http://www.sleuthkit.org/autopsy

Este documento es una evaluación sobre los fundamentos científicos actuales del forense digital. Se examinan las descripciones de técnicas para investigación digital desde fuentes revisadas por pares, materiales académicos y de aula, directrices técnicas desde organizaciones profesionales, y fuentes publicadas independientemente. Las técnicas de investigación digital están basadas en métodos de ciencias de las computación, y cuando son utilizadas apropiadamente son consideradas fiables. El proceso de evaluar, por ejemplo, el contenido del disco duro de una computadora, no crea información la cual no estaba allí antes de comenzara la investigación. Sin embargo, debido al campo está cambiando rápidamente, existen limitaciones los cuales profesionales y las partes interesadas deben tener en consideración: (1) como con cualquier escena del crimen, no toda la evidencia puede ser descubierta; (2) cuando se recuperen archivos borrados, los resultados pueden incluir material extraño; (3) los examinadores necesitan entender el software (sistemas operativos y aplicaciones), es revisado por significado e importancia de los artefactos digitales creados por diferentes versiones del software, los cuales pueden ser diferentes.

Además, debido a frecuentemente existen múltiples maneras de buscar por información, dos examinadores pueden encontrar diferentes subconjuntos de toda la información potencialmente relevante. Los métodos utilizados en las investigaciones digitales frecuentemente no son revisados por pares en un proceso formal, pero la confiabilidad la establecen los miembros de la comunidad forense digital, quienes prueban los métodos propuestos, realizan pruebas, y hacen circular actualizaciones dentro de la comunidad. Este proceso fortalece la conciencia del examinador sobre las capacidades y limitaciones de sus técnicas.

Fuentes:

https://www.nist.gov/publications/digital-investigation-techniques-nist…
https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8354.pdf

La creación de una línea de tiempo sobre la actividad del sistema, proporciona a un profesional forense evidencia sobre donde investigar más a fondo. Las líneas de tiempo en The Sleuth Kit permiten obtener rápidamente una visión a alto nivel sobre la actividad del sistema, como cuando se compilaron los archivos y cuando fueron abiertos. The Sleutk Kit le permite generar lineas de tiempo sobre la actividad a partir de una variedad de fuentes. Autopsy también permite crear líneas de tiempo utilizando las herramientas TSK.

Introducción

Muchos archivos y directorios tienen tiempos con estos. La cantidad y descripción de los cuales dependen del tipo de sistema de archivos. Por ejemplo los sistemas de archivos FFS y Ext2/3/4, tienen una hora de modificación, acceso y cambio. Ext2/3 también tiene una hora de eliminación. FAT almacena la hora de escritura, acceso y creación, aunque por especificación las horas de creación y acceso son opcionales, además la hora de acceso solo es exacta al día. NTFS tiene tiempos de creación, modificación, cambio, y acceso.

Otros registros de eventos y fuentes de datos también pueden tener datos temporales. Por ejemplo, registros de eventos, registros del sistema, registro de Windows, y metadatos de documentos. Tenerlos en una sola línea de tiempo, junto con los datos del sistema de archivos, puede ayudar a reconstruir los eventos. Se puede crear o buscar herramientas para guardar datos temporales en el formato de archivo “body”.

Creación de línea de tiempo

En un alto nivel, la generación es un proceso de dos pasos. En el primer paso, los datos temporales se recopilan desde varias fuentes de datos (como sistemas de archivos, registros, registros de eventos, etc.), además se guardan en el formato de archivo “body”. Este paso se realiza utilizando la herramienta 'fls' en TSK u otras herramientas. El segundo paso es ordenar y fusionar todos los datos temporales en una única línea de tiempo. Este paso se realiza utilizando el script 'mactime' en The Sleuth Kit.

Recopilación de datos

El principal método para recopilar datos temporales desde sistemas de archivos es ejecutar “fls” con la opción '-m'.

El comando 'fls' requiere el argumento '-m' con también la opción '-r', para recopilar todos los archivos. Este paso recorre la jerarquía de directorios y genera una línea para cada archivo en el sistema de archivos. Este comando debe ejecutarse para cada partición de una imagen de disco.

Como ejemplo, considerar un sistema Windows.

$ fls -m "C:/" -o 2048 -r Craig\ Tucker\ Desktop.E01 > body.txt

El desfase temporal del sistema puede también ser tomado en consideración durante este paso. Utilizando el argumento '-s' para “fls”, el archivo “body” puede tener tiempos ajustados para el sistema sea consistente con otros servidores.

NOTA: La herramienta mac-robber también se puede utilizar para recopilar datos desde archivos asignados en un sistema de archivos montado. “mac-robber” es útil para sistemas de archivos donde no existen herramientas (como AIX jfs).

Cualquier dato con horas se puede convertir al formato que necesita mactime. Creé scripts para convertir archivos de registro al formato anterior para que todos los datos estuvieran en una sola línea de tiempo.

Creación de línea de tiempo

Cuando todos los datos temporales se han fusionado en un solo archivo “body”, los datos pueden ser ordenados basados en tiempos. El programa “mactime” realiza esto.

Fuentes:

http://wiki.sleuthkit.org/index.php?title=Timelines
http://wiki.sleuthkit.org/index.php?title=Body_file
http://www.sleuthkit.org/mac-robber/
http://wiki.sleuthkit.org/index.php?title=Mactime

Lo cual ellos son

Los archivos huérfanos son archivos eliminados los cuales todavía tienen metadatos de archivos en el sistema de archivos, pero a los cuales no se puede acceder desde el directorio raíz. En la mayoría de los sistemas de archivos, los metadatos del archivo (como horas y bloques asignados hacia un archivo) se almacenan en una localización diferente comparada al nombre del archivo. El nombre apunta hacia la ubicación de los metadatos.

Es posible borrar o reutilizar el nombre de un archivo eliminado, pero los metadatos del archivo aún existen. A estos archivos se les denomina o llama huérfanos, pues no tienen padre (o al menos el directorio raíz no es su último padre).

A partir de The Sleuth Kit versión 3, los archivos huérfanos se enumeran en el directorio $OrphanFiles en el directorio raíz. Tener en consideración este directorio en realidad no existe en la imagen del disco, es solo una forma virtual para The Sleuth Kit brinde acceso hacia los metadatos existentes.

Como son Determinados

The Sleuth Kit determina los archivos huérfanos recorriendo primero el árbol de directorios, y enumerando todas las direcciones de metadatos hacia las cuales apuntan los nombres de los archivos. Luego,revisa todas las estructuras de metadatos e identifica cuales de las estructuras no asignadas no tienen un nombre señalándolas. Estos son los archivos huérfanos.

Fuentes:

http://wiki.sleuthkit.org/index.php?title=Orphan_Files
https://wiki.sleuthkit.org/index.php?title=Metadata_addresses

Unidad de datos es el término genérico utilizado en The Sleuth Kit para referirse hacia una agrupación de sectores consecutivos. Los sectores suelen tener 512 bytes y los sistemas de archivos los agrupan para formar unidades de almacenamiento más grandes. Por ejemplo pueden agrupar 8 sectores consecutivos de 512 bytes, para formar unidades de 4096 bytes cada uno. El sistema de archivos asigna una dirección hacia cada una de estas unidades de datos. Típicamente los sistema de archivos no proporcionan una dirección para cada sector. Sólo asigna y referencia a las unidades de datos.

Los siguientes son los términos utilizados por cada uno de los sistemas de archivos para referirse hacia una unidad de datos.

ExtX: fragmento

Fragmento es el término utilizado en los sistemas de archivos ExtX y UFS, para referirse hacia una agrupación de sectores consecutivos. Los sectores son típicamente de 512 bytes cada uno, y es más eficiente para un sistema de archivos asignar y utilizar múltiples sectores a la vez. Cada sistema de archivos utiliza un término diferente para el grupo resultante. The Sleuth Kit utiliza el término unidad de datos para referirse a la agrupación.

Estos sistemas de archivos también agruparán fragmentos consecutivos en bloques, pero las direcciones de los bloques son iguales a las direcciones de los fragmentos.

Tener en consideración, aunque los sistemas de archivos ExtX admiten fragmentos y bloques, típicamente tienen tamaños iguales (lo cual significa un bloque es igual a un fragmento).

FAT: sector (anotar FAT agrupa los sectores en clústeres, pero no todos los sectores son asignados hacia un clúster y, por lo tanto, las direcciones de los clústeres no cubren todo el sistema de archivos. The Sleuth Kit utiliza direcciones de sectores con FAT, así todas las partes del sistema de archivos pueden ser referenciadas.

Un sector es la más pequeña la unidad direccionable sobre un disco duro u otro medio de almacenamiento no volátil. Sobre un disco duro típico, un sector tiene un tamaño de 512 bytes. Los CD-ROM utilizan sectores de 4096 bytes, existiendo discos duros más nuevos saliendo con sectores de 4096 bytes.

A cada sector se le asigna una dirección iniciando en 0. Esto se denomina dirección LBA. Existen otros esquemas para direccionamiento utilizando geometría de la unidad, pero rara vez se utilizan.

Para eficiencia los sistemas de archivos suelen agrupar sectores consecutivos en unidades de datos (los nombres comunes incluyen clúster o bloque). Las unidades de datos también reciben direcciones.

FFS: fragmento (anotar FFS también agrupa múltiples fragmentos en bloques, pero cada fragmento tiene una dirección)

Fragmento es el término utilizado en los sistemas de archivos ExtX y UFS, para referirse hacia una agrupación de sectores consecutivos. Los sectores son típicamente de 512 bytes cada uno, y es más eficiente para un sistema de archivos asignar y utilizar múltiples sectores a la vez. Cada sistema de archivos utiliza un término diferente para el grupo resultante. The Sleuth Kit utiliza el término unidad de datos para referirse a la agrupación.

Estos sistemas de archivos también agruparán fragmentos consecutivos en bloques, pero las direcciones de los bloques son iguales a las direcciones de los fragmentos.

Tener en consideración, aunque los sistemas de archivos ExtX admiten fragmentos y bloques, típicamente tienen tamaños iguales (lo cual significa un bloque es igual a un fragmento).

HFS: bloque

El término bloque se utiliza en un par de contextos diferentes con The Sleuth Kit.

Unidad de datos

Bloque es el término utilizado en los sistemas de archivos HFS para referirse hacia una agrupación de sectores consecutivos. Los sectores suelen tener 512 bytes cada uno, y es más eficiente para un sistema de archivos asignar y utilizar varios sectores al mismo tiempo. Cada sistema de archivos utiliza un término diferente para el grupo resultante. The Sleuth Kit utiliza el término unidad de datos para referirse a la agrupación.

Bloque es también utilizado en los sistemas de archivos ExtX y UFS para referirse a una agrupación de fragmentos. Estos sistemas de archivos agrupan sectores en fragmentos y fragmentos en bloques. Sin embargo los bloques no reciben direcciones únicas. Su dirección es la dirección del primer fragmento del bloque.

Herramientas para línea de comando en la capa de unidad de datos

Las herramientas en línea de comando de The Sleuth Kit están organizadas en capas. Las herramientas para la capa de unidades de datos comienzan con 'blk', la cual es la abreviatura de bloque. Se sugiere consultar la descripción general de la herramienta The Sleutk Kit para obtener más detalles sobre las capas de herramientas.

NTFS: clúster

Clúster es el término utilizado en los sistemas de archivos FAT y NTFS para referirse a una agrupación de sectores consecutivos. Los sectores son típicamente de 512 bytes cada uno, y es más eficiente para un sistema de archivos asignar y utilizar varios sectores al mismo tiempo. Cada sistema de archivos utiliza un término diferente para el grupo resultante. The Sleutk Kit utiliza el término unidad de datos para referirse a la agrupación.

Se sugiere consulte las notas de implementación para FAT, y obtener una descripción de la razón por la cual The Sleutk Kit utiliza direcciones de sector y no de clúster cuando trabaja con sistemas de archivos FAT.

YAFFS2: trozo (anotar YAFFS2 agrupa múltiples trozos en bloques, pero cada fragmento tiene una dirección)

Un trozo es la unidad de datos utilizada por YAFFS2. Consta de página y zona de repuesto. Típicamente se han visto tamaños de página de 2048 bytes, y un tamaño libre de 64 bytes.

Fuentes:

http://wiki.sleuthkit.org/index.php?title=Data_units
http://wiki.sleuthkit.org/index.php?title=Fragment
http://wiki.sleuthkit.org/index.php?title=Sector
http://wiki.sleuthkit.org/index.php?title=Block
http://wiki.sleuthkit.org/index.php?title=Cluster
http://wiki.sleuthkit.org/index.php?title=Chunk

Introducción

Dirección de Metadatos es un término utilizado en The Sleuth Kit, como término genérico para las direcciones correspondientes a las estructuras de datos específicas para un sistema de archivos, el cual almacenan metadatos de archivos. Cada sistema de archivos tiene un nombre diferente para las estructuras donde se almacenan los metadatos, incluyendo:

• FAT/exFAT: Entrada de directorio
• NTFS: Entrada MFT
• UFS: Inodo
• ExtX: Inodo
• HFS: Registro de Catálogo
• YAFFS2: Fragmento de Encabezado

La dirección de metadatos se puede utilizar en The Sleuth Kit para especificar los archivos a analizar.

Formato

En general a cada estructura de metadatos se le asigna una única dirección numérica. Algunos sistemas de archivos, como FAT, no asignan una dirección a las estructuras, pero The Sleuth Kit las crea.

Algunos sistemas de archivos, como NTFS y HFS, permiten un archivo tenga múltiples nociones de contenido. Los archivos NTFS puede tener múltiples atributos $Data, siendo cada uno básicamente un archivo independiente. Para permitir el usuario acceda hacia cada atributo, se utilizan direcciones de metadatos especiales. Estas direcciones toman la forma de ADDR-TYPE o ADDR-TYPE-ID. ADDR es la dirección de metadatos, TYPE es el tipo de atributo, e ID es la identificación del atributo.

El número de TYPE especifica el tipo de datos almacenados en el atributo (como el contenido del archivo, el contenido del directorio, o los metadatos del archivo). Estos números son específicos del sistema de archivos. El número de identificación permite diferenciar entre diferentes instancias del mismo tipo de atributo. Cada atributo de un archivo tendrá un valor ID único. Tener en consideración algunos archivos NTFS tendrán atributos abarcando varias entradas MFT. En este caso, NTFS no garantiza cada ID de atributo será único, pues NTFS solo garantiza un ID será único para una única entrada MFT. Sin embargo, The Sleuth Kit anula estos valores ID y asigna otros nuevos para cada atributo sea único.

Como ejemplo, aquí está el resultado del comando fls en una imagen NTFS:

$ fls -o 2048 NTFS_Pract_2017.raw 222-144-2

En la imagen existen tres archivos (con direcciones 225, 223 y 224). El valor de tipo 128 en un sistema de archivos NTFS corresponde al atributo $Data.

En general, si requiere The Sleuth Kit elija el atributo de datos predeterminado (o si el sistema de archivos no admite la noción de atributos), se debe proporcionar a TSK solo la dirección de metadatos. Si requiere especificar un atributo y se conoce solo existe uno de ellos, utilizar ADDR-TYPE. Si existen varios atributos del mismo tipo, especificar también el ID. Normalmente la salida del comando istat muestra cuales atributos están definidos para un archivo.

$ istat -o 2048 NTFS_Pract_2017.raw 222-144-2

Fuentes:

http://wiki.sleuthkit.org/index.php?title=Metadata_Address
http://wiki.sleuthkit.org/index.php?title=FAT_Implementation_Notes
http://wiki.sleuthkit.org/index.php?title=NTFS_Implementation_Notes

Kali Linux “Vivo” (Live) proporciona un “modo forense”, una característica introducida primero en BackTrack Linux. La opción "Inicio vivo en modo forense" ha probado ser muy popular por varias razones:

• Kali Linux está disponible de manera amplia y fácil; muchos potenciales usuarios ya tienen una ISO de Kali o unidades USB de iniciables.
• Cuando surge una necesidad forense, Kali Linux “Vivo” permite sea rápido y fácil poder trabajar con Kali Linux.
• Kali Linux viene previamente cargado con el software forense de fuente abierta más popular, un conjunto de herramientas útil cuando se necesita realizar un trabajo forense.

Cuando se inicia en el modo de inicio forense, existen algunos cambios muy importantes en el funcionamiento regular del sistema:

1. Primero, el disco duro interno nunca es tocado. Si existe una partición de intercambio (swap), no se utilizará, y no se montará automáticamente ningún disco interno. Esto se verificó tomando primero un sistema estándar y eliminando el disco duro. Se generó un hash desde la unidad utilizando un paquete forense comercial. Luego se volvió a conectar el disco hacia la computadora para iniciar Kali Linux “Vivo” en modo forense. Después de utilizar Kali por un período de tiempo, se apagó el sistema, se retiró el disco duro, y se generó nuevamente un hash. Estos hashes coincidieron, lo cual indica en ningún momento se cambió sobre el disco.

2. El otro igualmente importante es, se desactiva el montaje automático de medios extraíbles. Las memorias USB, CD, y similares no se montarán automáticamente cuando se inserten. La idea detrás de esto es simple: en modo forense, no debería pasarse nada hacia ningún medio sin la acción directa del usuario. Todo lo cual sea realizado como usuario depende como es consecuente, del usuario.

Si planea utilizar Kali para cualquier tipo de análisis forense del mundo real, se recomienda no confiar simplemente en lo antes descrito. Todas las herramientas forenses siempre deben validarse para saber como se comportarán en cualquier circunstancia en las cuales vayan a utilizarse. Finalmente, mientras Kali continúa enfocándose en proporcionar la mejor colección de herramientas para pruebas de penetración de fuente abierta disponibles, siempre es posible se haya pasado por alto alguna herramienta forense de fuente abierta importante. El proyecto siempre buscando herramientas de fuente abierta de alta calidad, la cuales puedan ser agregadas a Kali para mejorarlo aún más.

Fuentes:

https://www.kali.org/docs/general-use/kali-linux-forensics-mode/
https://www.kali.org/get-kali/#kali-live

Las fallas relacionadas a fuga de información, proporcionan datos adicionales para la etapa de reconocimiento, las cuales son muy útiles durante un proyecto de hacking ético y pruebas de penetración.

Típicamente estás fallos no conducen directamente a la explotación. Pero la información obtenida durante esta etapa es utilizada como una entrada para etapas posteriores, como por ejemplo inyección SQL, adivinar contraseñas, y otros escenarios más.

Anotación importante

Los siguientes ejemplos se obtuvieron utilizando el motor de búsqueda Google. Yo NO realicé escaneos, ni otro tipo de interacción manual adicional. Únicamente ingrese a los enlaces mostrados, producto de buscar en Google.

Para el primer ejemplo, el mensaje de error es mostrado de manera estructurada, incluyendo rutas y nombres de archivos, como también nombres de columnas.

En el segundo escenario, el mensaje de error incluye el tipo de servidor de base de datos (Maria DB), además del nombre de una columna (idPlaza)

En el tercer ejemplo. El extenso mensaje revela el tipo de servidor (MariaDB), además de la consulta SQL, entre nombres de columnas, tablas y nombres de bases de datos.

Para el cuarto escenario, el mensaje de error expone también información del servidor (MariaDB), además parte de la consulta y nombres de tabla.

Para todos los ejemplos mencionados, se conoce se está interactuando con una base de datos backend MariaDB, y los errores cometidos por los diseñadores y programadores.

Fuente:

https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Expos…
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

SecLists es el compañero del profesional en pruebas de penetración y hacking ético. Es una colección de múltiples tipos de listas utilizadas durante las evaluaciones en ciberseguridad, recopiladas en un solo lugar. Los tipos de listas incluyen nombres de usuario, contraseñas, URLs, patrones de datos confidenciales, cargas útiles (Payloads) para fuzzing, shells vía web y mucho más. Su propósito es permitir un profesional coloque este repositorio dentro de una nueva caja para pruebas, para tener acceso hacia todo tipo de listas factibles de ser necesitadas.

SecLists está estructurado en nueve directorios; Descubrimiento (Discovery), Fuzzing, Indicadores de Compromiso (IOC), Misceláneo (Miscellaneous), Contraseñas (Passwords), Coincidencia de Patrones (Pattern-Matching), Cargas Útiles (Payloads), Nombres de Usuario (Usernames), y Shells Web (Web-Shells).

$ ls -l /usr/share/seclists/

Es factible también utilizar el comando tree para visualizar la estructura de directorios de manera recursiva.

$ tree -d /usr/share/seclists

Al momento de realizar la presente publicación está constituido de 109 directorios.

Siempre se sugiere revisar el contenido de los archivos antes de utilizarlas para realizar las evaluaciones.

$ column /usr/share/seclists/Passwords/500-worst-passwords.txt

Fuentes:

https://github.com/danielmiessler/SecLists
https://www.kali.org/tools/seclists/