Autor: Israel Nadal

A través de su cuenta de Twitter, publico un hilo donde explicaba de forma sencilla y concreta, su metodología para realizar un Pentesting.


Guía para realizar un Pentesting de Israel Nadal



ESCANEO DE LA RED

nmap -sn 10.11.1.* nmap -sL 10.11.1.* nbtscan -r 10.11.1.0/24 smbtree netdiscover

ESCANEO AL HOST

nmap --top-ports 20 --open -iL iplist.txt nmap -sS -A -sV -O -p- ipaddress nmap -sU ipaddress


ESCANEO DE LOS SERVICIOS

SERVICIOS WEB Nikto dirb dirbuster wpscan otdotpwn view source davtest\cadevar droopscan joomscan LFI\RFI Test S.O. LINUX/WINDOWS snmpwalk -c public -v1 ipaddress 1 smbclient -L //ipaddress showmount -e ipaddress port rpcinfo Enum4Linux

 OTROS nmap scripts (locate *nse* | grep servicename) MSF Aux Modules


POST EXPLOTACIÓN

LINUX linux-local-enum.sh inuxprivchecker.py linux-exploit-suggestor.sh unix-privesc-check.py WINDOWS wpc.exe windows-exploit-suggestor.py windows_privesc_check.py windows-privesc-check2.exe


ESCALADA DE PRIVILEGIOS

Acceso a servicios internos (portfwd) Añadir una cuenta WINDOWS Lista de exploits LINUX Sudo su KernelDB Searchsploit

FINALIZACIÓN

Capturas de pantalla IPConfig\WhoamI Dump hashes Dump SSH Keys Borrado de archivos Documentación final.

 Me he tomado la liberta de "compartir" esta pequeña guian en el Blog para que no caiga en el olvido del timeline de Twitter.

 Gracias Israel por compartir
Cheat Sheet - SNORT

Hace tiempo escribí un articulo sobre la distribución Security Onion, que podéis leer aquí.

El proyecto ha seguido evolucionando, son numerosos los cambios introducidos, para aquellos interesados os dejo el enlace:

- Información: https://securityonion.net

Pero el motivo de escribir esta "mini" entrada, es compartir con todos una hoja resumen de comando sobre SNORT, 

Please, If you want to know how works SNORT go to: https://www.snort.org/, but if you know how it works, then you must want to have the following cheat sheet.

The Snort Cheat Sheet covers:
  • Sniffer mode, Packet logger mode, and NIDS mode operation
  • Snort rules format
  • Logger mode command line options
  • NIDS mode options
  • Alert and rule examples

Thanks to Hannah, who send me a email with Link.




 Con este titulo más parecido a un capitulo de Harry Potter, os presento el Orquestador para Linux Container (LXD). Ver enlace.
OpenStack / LXD + JujuCharms (https://jujucharms.com/)

Como si por arte de "Magia" se tratase, "conjure-up" es la forma más rápida (dependerá de tus recursos principalmente el disco duro SSD) de crear un cluster Kubernetes perfectamente configurado y listo para trabajar.

 Limitaciones

 Si deseas trabajar "localmente" en un Host, se presentan ciertas limitaciones técnicas a la hora de utilizar conjure-up, o incluso "juju".
  1. La instalación local solamente contempla trabajar con un "equipo físico (hardware)", aunque la herramienta juju permite trabajar con múltiples proveedores de Cloud (Azure, Google Cloud , AWS) será utilizando LXD localmente cuando más partido se le puede sacar a estar herramienta.
  2. Networking, se debe diseñar muy bien inicialmente todo lo necesario para la comunicación entre los contenedores, así como la publicación de los recursos. Si trabajas con un cluster Kubernetes ya tendrás cierta experiencia en ello. No obstante, hay que realizar un buen planteamiento de networking antes de comenzar. Sobre todo con el objetivo de la publicación de los recursos.
Esas son las principales "limitaciones", puesto que si deseamos disponer de múltiples Host (bare metal / hardware) la opción de utilizar conjure-up "localmente" no contempla de momento la capacidad de "clustering" que trae LXD 3.0. Por lo que el diseño de networkin inicial será fundamental para ser capaz de comunicar varios Host (Hardware / VM) entre si, y las APP contenidas en LXD. Un ejemplo claro, es desplegar todo un cluster Kubernetes en un Host (localhost) y luego querer ampliar la capacidad del cluster añadiendo "Worker / Nodos al cluster" en otros Host para alta disponibilidad y recursos. Esto requiere de un diseño de la red (previo al despliegue) y "tunning" a nivel de networking para lograrlo. Puesto que la herramienta de momento (como he comentado anteriormente) no contempla la capacidad de utilizar la funcionalidad nativa de clustering.

 Cómo parece lógico, la opción de utilizar LXD, es evitar utilizar HyperV/VMWare en tus servidores locales, creando tu propia Cloud con los recursos hardware directamente con LXD, que por otro lado, mejoran los resultados al trabajar con lo que denominan pure-container hypervisor [info].

 Por tanto, si quieres trabajar en producción con LXD + juju como orquestador, te recomiendo:
  • Una Host con al menos 128GB RAM, 4 CPUS, disco duro SSD local + cabina (storage) con direct attach de tipo SSD, 
  • Un según Host de igual capacidad conectado a la cabina storage (direct Attach)


 Con esto montar dos "cluster locales kuebernetes" y utilizar la capacidad de federación entre cluster de kubernetes, que permitirá repartir y balancear los recursos entre los cluster federados. [info]

 Ventajas

 No todo iban a ser limitaciones, para el área DevOps y el ciclo de CI/CD Integración continua) todo son ventajas:
  1. Montar un cluster Kubernetes rápidamente totalmente operativo.
  2. Desplegar Jenkins (integración continua) y Sonar (Auditoria de Código)
  3. Y Probar las aplicaciones en un entorno igual al de producción en los principales Proveedores de Cloud.
Happy Hacking !!! DevOps ! :)




Cuando eres un Tier1/L2 SOC Security Analyst disponer de la mejor herramienta para la toma de decisiones es fundamental con objeto de "responde" ante una Amenaza de la mejor forma y lo más rápido posible.

En mi paso como "Manager" del antiguo equipo del Centro de Inteligencia y Operaciones de Seguridad, denominado SSIC por la siglas (SVT Security Intelligence & Operations Center), se indicaba que la prioridad era conseguir herramientas que permitan a nuestros analistas L1 / L2 disponer de la mejor información en el menor tiempo posible, permitiendo decisiones / acciones inmediatas.

Es un placer compartir con la comunidad el desarrollo de un módulo para análisis de direcciones IP "sospechosas", os presento, cymon-analyzer, es un plugins (analizador) desarrollado para el motor Cortex del proyecto [TheHive-Project]

Descripción

 cymon-analyzer permite analizar información sobre la reputación IP en un "Incidente / Alerta" de seguridad en el servicio cymon.io (Open Threat Intelligence) de forma automática, para ello se utiliza la API que nos proporciona este servicio.

He desarrollado un modulo para Cortex, que permite analizar rápidamente y comprobar si la IP detectada como "potencialmente peligrosa" (observable / evidencia) esta listada en "lista negras" por mala reputación [Malware, Spam, Phishing, blacklist, Actividad Maliciosa, etc].

cymon-analyzer | Working in TheHive Platform | Captura pantalla del analyzer en funcionamiento.
De forma automática, un analista puede comprobar y obtener información desde múltiples IP / Observables con un solo click. Se puede ejecutar el Analyzer, y el motor [Cortex] a través del Analizador se encarga de consultar "IP por IP" al servicio cymon.io devolviendo la información en forma de etiqueta e Informe.

Full Report | Informe resultante cymon-analyzers

TheHive-Project es una plataforma de gestión de Incidentes de Seguridad (relativamente nueva) consolidada, que proporciona la herramienta que un SOC/CERT necesita.

Es una herramienta desarrollada por expertos en Seguridad para equipos de Seguridad. Sus capacidades de integración son espectaculares, no solo gracias a la comunidad que cada día desarrolla más "Analyzer" incrementando el valor de la herramienta y sus capacidades, sino también debido a la capacidad de integración que proporciona la API de la plataforma.

Si estáis interesados, podéis conseguir el analyzer en mi cuenta  personal de GitHUB | ST2Labs

Repositorio: cymon-analyzer

Enlaces de Interés



ST2Labs

Designed with by Way2themes | Distributed by Blogspot Themes