El pasado 30 de septiembre de 2026, la Universidad de Palermo fue sede de una nueva edición de h4ck3d Persistent, el espacio encuentro coorganizado entre la Facultad de Ingeniería de la UP y Securetia. En esta oportunidad, Javier Vallejos Martínez, cofundador de Securetia, lideró la charla “La Era Mythos, la fábrica de Zero Days”, abordando uno de los fenómenos más disruptivos de la ciberseguridad actual.

¿Qué cambia cuando la Inteligencia Artificial no solo ayuda a escribir código, sino que aprende a buscar, encadenar y explotar fallas desconocidas en segundos?

Del concepto a la realidad: La aceleración de las vulnerabilidades

Durante años, el descubrimiento de una vulnerabilidad Zero-Day (falla de seguridad sin parche disponible) requería semanas o meses de investigación manual por parte de expertos en ingeniería inversa y fuzzing. Era un proceso costoso, de alto esfuerzo humano y reservado para actores altamente capacitados.

Sin embargo, las recientes investigaciones en torno a modelos de vanguardia como Mythos —así como los avances de otros laboratorios de IA— confirmaron una transición inevitable: los modelos de lenguaje y agentes autónomos han aprendido a razonar sobre la seguridad del código.

Esto significa que hoy una IA puede:

1. Analizar repositorios y binarios masivos en cuestión de minutos.

2. Identificar patrones complejos de vulnerabilidad que pasan desapercibidos ante un escáner estático tradicional.

3. Encadenar fallas (exploit chaining): combinar pequeños bugs menores para lograr la ejecución remota de código (RCE).

4. Automatizar la creación del exploit: reduciendo la ventana entre el descubrimiento y la explotación a velocidad de máquina.

El verdadero reto: La asimetría del tiempo defensivo

El verdadero problema para las organizaciones no es solo que existan más vulnerabilidades, sino la destrucción del tiempo de reacción.

Tradicionalmente, los equipos de seguridad contaban con ventanas de días o semanas desde que se publicaba una falla hasta que se observaban intentos masivos de explotación en Internet. En la “Era Mythos”, esa brecha temporal desaparece. Si un atacante utiliza agentes de IA para escanear y encontrar Zero-Days en infraestructuras expuestas, la defensa manual queda completamente desfasada.

¿Cómo nos preparamos para defender la infraestructura?

En la charla de h4ck3d Persistent, remarcamos que la respuesta no puede ser apagar la innovación, sino evolucionar la postura defensiva hacia la continuidad y la automatización inteligente:

• Reducción proactiva de la superficie de ataque: Si un sistema no necesita estar expuesto a Internet, no debe estarlo. El hardening de infraestructura y la segmentación estricta son la primera barrera frente al escaneo automatizado.

• Escaneo y gestión continua de vulnerabilidades (Vulseek): Las auditorías anuales o semestrales son fotos viejas. Necesitamos visibilidad en tiempo real para detectar cambios en la superficie expuesta antes de que sean mapeados por agentes externos.

• Penetration Testing con enfoque ofensivo moderno: Evaluar aplicaciones y sistemas pensando en cómo los atacantes utilizan IA para encadenar fallas, identificando debilidades en la lógica de negocio y configuraciones complejas.

• Cultura de SecDevOps: Integrar la seguridad directamente en el pipeline de desarrollo para que el código nazca auditado antes de llegar a producción.

Pensar como hacker para defender el futuro

Como solemos reflexionar en cada edición de h4ck3d junto a la comunidad académica y profesional, la tecnología avanza para ambos lados de la trinchera. Ante una “fábrica de Zero-Days” impulsada por IA, la resiliencia de las organizaciones dependerá de su capacidad para anticipar escenificar escenarios, ganar visibilidad en tiempo real y reaccionar a velocidad operativa.

👉 ¿Querés evaluar la superficie de exposición de tu empresa y fortalecer tus defensas? Conocé más sobre nuestros servicios de Pentesting, Vulseek y Consultoría en securetia.com.

Descargá la presentación oficial de la charla

Para quienes no pudieron asistir o desean repasar en detalle los análisis, esquemas técnicos y casos expuestos durante el evento, compartimos el material presentado por Javier Vallejos Martínez en la Universidad de Palermo.

Explorá las diapositivas completas para profundizar en el funcionamiento de los nuevos modelos de IA, la aceleración en la creación de exploits y las recomendaciones de arquitectura para proteger tu infraestructura:

Presentación La Era Mythos, La Fábrica De Zero Days

1.51MB ∙ PDF file

Download

Download

Si un atacante accede a una credencial válida de “devops” capturada mediante malware infostealer, y además la consola de automatización o despliegue de pipelines de la empresa está expuesta públicamente sin control de acceso restrictivo ni VPN, el atacante no solo compromete credenciales, sino que adquiere la capacidad de inyectar código malicioso directamente en la cadena de compilación del software transaccional, comprometer repositorios de artefactos o alterar componentes de prevención de fraude.

Este escenario se vuelve aún más peligroso debido a la fuga de topología de red interna (DNS leakage): la configuración inadecuada en DNS públicos que permite resolver subdominios no productivos o de staging a direccionamientos IP privados (como rangos VPC de AWS o CGNAT), revelando pasivamente al atacante los nombres, cantidades y funciones de microservicios internos críticos (tokenización de tarjetas, lavado de activos, contabilidad) sin necesidad de que este acceda a la red.

Metodología y Capacidad de OSINT/CTI Aplicada

El descubrimiento y prevención de estos escenarios de riesgo extremo se realiza mediante técnicas avanzadas de inteligencia técnica:

1. Detección de Fugas de Topología DNS (Capa 1): Enumeración de DNS pasivos analizando la resolución de subdominios de prueba, staging y desarrollo, detectando específicamente aquellos hosts expuestos que devuelven direccionamientos de rangos IP privados internos de nubes públicas o gateways.

2. Auditoría de Consolas de Integración y Despliegue: Fingerprinting pasivo e identificación de plataformas de CI/CD, control de versiones o repositorios de desarrollo accesibles desde el exterior sin necesidad de VPN.

3. Monitoreo de Cuentas de Rol Técnico Crítico (Capa 2): Rastreo en feeds de stealer logs de cuentas administrativas genéricas y técnicas, analizando posibles compromisos por malware y validando de manera controlada el reuso de estas contraseñas corporativas en sistemas de staging propios o en servicios SaaS de terceros utilizados habitualmente por los desarrolladores.

4. Mapeo de Datos Expuestos de Ejecutivos: Identificación de exposición de información personal de identificación (PII) de ejecutivos de nivel C (CTO, CFO) en brechas de terceros que puedan ser utilizadas para campañas de ingeniería social dirigida, pretexting o phishing telefónico dirigido (vishing) para sortear validaciones de seguridad adicionales.

Impacto Operativo y Estratégico

Para un procesador de pagos, la aplicación de este análisis estratégico de inteligencia ayuda a blindar la infraestructura operativa y a mitigar riesgos de cumplimiento regulatorio severos:

• Migración DNS Preventiva: Permite retirar los registros DNS de microservicios internos del ámbito público y migrarlos a zonas de resolución privadas (ej. AWS Route 53 Private Hosted Zones) para anular el reconocimiento pasivo de la red.

• Endurecimiento de Pipelines: Proporciona los argumentos necesarios para restringir de inmediato las consolas de desarrollo/CI/CD detrás de una VPN y auditar las pipelines en busca de modificaciones de código no autorizadas.

• Aislamiento de Malware: Permite identificar y sanear de inmediato los endpoints asociados a las cuentas de DevOps o administración comprometidas por infostealers antes de que las credenciales sean vendidas o explotadas por un actor de amenazas.

¿Qué podemos hacer ante esto?

Para salvaguardar la resiliencia de tu organización, es fundamental conocer con precisión qué información ya se encuentra en manos de posibles atacantes.

• Si deseas evaluar la superficie de exposición actual de tu organización, puedes solicitar un reporte gratuito de credenciales expuestas en internet para tu empresa en https://www.securetia.com/reporte-de-credenciales-filtradas.

• Gran parte de este monitoreo, correlación y detección de inteligencia ya se encuentra automatizado dentro de nuestra plataforma. Si quieres comenzar a utilizarlo y potenciar las capacidades de tu equipo, puedes registrarte en Vulseek a través de https://app.vulseek.io/register.

¡Hola! 👋

Tenemos excelentes noticias. 📣 Durante el transcurso del día de hoy, 21 de septiembre de 2026, van a estar disponibles dos nuevas actualizaciones en Vulseek diseñadas para aumentar la visibilidad de tu infraestructura y darte el control total sobre la gestión de vulnerabilidades.

¡Descubrí los cambios que se van a activar en tu cuenta! 👇

🎯 1. Ampliamos la cobertura: ¡Escaneo del 99% de puertos! Llevamos nuestros motores al siguiente nivel. Pasamos de cubrir el 80% de los puertos que se suelen utilizar, ¡a escanear el 99%! 📈 Esto reduce drásticamente los puntos ciegos en tu red y asegura una detección mucho más profunda. ¿Lo mejor? No tenés que hacer nada, esta súper mejora va a empezar a funcionar automáticamente en tus análisis. ✨

⏱️ 2. SLAs 100% configurables para tus hallazgos Sabemos que cada organización es un mundo y tiene sus propios tiempos. Por eso, los usuarios Administradores ahora van a poder personalizar el Acuerdo de Nivel de Servicio (SLA) 🛠️, definiendo la cantidad de días límite que se espera para resolver una vulnerabilidad basándose en su nivel de criticidad. 🚦

👉 ¿Cómo configurarlo? ¡Es muy fácil! 1️⃣ Dirigite al menú principal y abrí el desplegable “Cuenta”. 2️⃣ Ingresá a la nueva pantalla de configuración de SLA. 3️⃣ ¡Establecé los plazos que mejor se adapten a las políticas de tu empresa y listo! ✅

Si tenés alguna consulta sobre estas nuevas funcionalidades o necesitás asistencia para configurarlas, ¡estamos a un mensaje de distancia! 💬 Escribinos a vulseek@securetia.com y con gusto te damos una mano. 🤝

¡Sigamos fortaleciendo tu seguridad! 🔒🌐

El equipo de Vulseek 🦉

Te invitamos a participar de H4ck3d Persistent. La Era Mythos: La fábrica de Zero Days, que estará a cargo de Javier Vallejos Martínez , CEO y Co-Founder de Securetia.

Fecha: miércoles 30 de septiembre de 9:30 a 11:30 hs.

Modalidad: Presencial, Mario Bravo 1050.

La llegada de modelos de razonamiento avanzado y frameworks de Inteligencia Artificial como Claude Mythos ha marcado un punto de inflexión sin retorno en la ciberseguridad: el surgimiento de la explotación de vulnerabilidades verdaderamente autónoma y a escala.

Mientras la industria de la ciberseguridad defensiva continúa operando bajo métricas de remediación que promedian entre 55 y 74 días, la IA generativa y la automatización ofensiva han reducido el tiempo medio entre la divulgación de un hallazgo y su explotación a niveles negativos, permitiendo crear exploits funcionales en cuestión de 10 a 15 minutos. En esta charla abordaremos cómo la IA está reescribiendo la superficie de ataque —desde sistemas corporativos tradicionales hasta infraestructuras críticas y entornos de Tecnología de Operaciones (OT)—, analizando métricas reales del panorama global de amenazas y las estrategias tácticas (Virtual Patching, Hardening y priorización contextual con Vulseek) necesarias para sobrevivir al tsunami de vulnerabilidades de la Era Mythos.

Speaker: Javier Vallejos Martínez, licenciado en Informática por la Universidad de Palermo (UP) y Especialista en Seguridad Informática. Es co-fundador y CEO de Securetia, compañía especializada en ciberseguridad corporativa e industrial. Apasionado del Pentesting y de la Informática Forense, es co-creador de Vulseek y Logseek. Además, se desempeña como docente de posgrado en la Maestría en Seguridad Informática, es orador en conferencias y eventos académicos del sector.

Registrate en https://www.palermo.edu/ingenieria/2026/septiembre/hacked-persistent-la-era-mythos.html

Cuando una organización atraviesa un proceso de fusión, adquisición, transición tecnológica o rebranding, la gestión de la superficie de ataque se vuelve sumamente compleja. Es habitual que convivan infraestructuras modernas que implementan controles de identidad avanzados con activos y dominios históricos que poseen una huella digital extensa y políticas de seguridad laxas. Los actores de amenazas conocen esta asimetría y suelen enfocar sus técnicas de reconocimiento pasivo (MITRE ATT&CK TA0043 - Reconnaissance) en los dominios heredados.

El peligro principal radica en la exposición pública en el DNS de consolas de administración y observabilidad (orquestadores de contenedores, paneles de control web corporativos, wikis internas o paneles de automatización de flota o seguridad física) junto con portales de capacitación interna o plataformas de correo legadas que carecen de MFA. Si se filtra una contraseña a través de una compilación de brechas históricas (como la base COMB) o mediante credenciales capturadas por malware en portales secundarios, los atacantes pueden utilizar la autenticación primaria aceptada de estas plataformas corporativas secundarias para realizar ingeniería social interna, pivotar hacia el Active Directory y propagar un compromiso total, incluyendo ataques de ransomware.

Metodología y Capacidad de OSINT/CTI Aplicada

El análisis sistemático de este vector de amenaza se realiza mediante un proceso analítico continuo sobre los activos digitales de la corporación:

1. Enumeración Consolidada Multidominio (Capa 1): Mapeo de subdominios a lo largo de todos los dominios activos, históricos o marcas asociadas de la corporación, filtrando específicamente aquellos registros DNS públicos que expongan nombres de infraestructura crítica de administración o desarrollo.

2. Evaluación de Credenciales COMB e Identidades Históricas (Capa 2): Análisis de bases de datos masivas para detectar el volumen de cuentas nominales comprometidas en el dominio histórico frente al dominio nuevo, demostrando de forma cuantitativa la asimetría de exposición.

3. Validación Controlada de Identidad y Reuso: Verificación técnica y pasiva de credenciales recuperadas de registros de stealer logs, ejecutando intentos controlados de inicio de sesión de solo lectura para demostrar la vigencia de contraseñas de dominio sobre portales periféricos de la empresa (como plataformas de capacitación o entrenamiento), lo que valida la hipótesis de reutilización de contraseñas de Active Directory.

4. Análisis de Antecedentes y Cadena de Suministro (Capa 3): Investigación histórica en prensa especializada y fuentes de inteligencia para identificar incidentes previos de ransomware o brechas de seguridad sufridas por proveedores de hosting compartido o terceros tecnológicos que afecten o hayan afectado la disponibilidad de los servicios críticos del negocio.

Impacto Operativo y Estratégico

Esta capacidad analítica permite al CISO tomar el control del proceso de consolidación tecnológica de la compañía, logrando:

• Reducción Inmediata de la Superficie: Restringir el acceso público (bloqueando por IP o exigiendo VPN) a todos aquellos subdominios de administración o desarrollo que no requieran visibilidad pública en clearnet.

• Acciones de Identidad Dirigidas: Forzar la rotación preventiva e implementar controles de MFA en todas las cuentas identificadas en la compilación de brechas e infostealers.

• Mitigación de Riesgos de Terceros: Evaluar continuamente la seguridad del ecosistema de hosting y proveedores críticos para evitar incidentes indirectos que afecten la continuidad operativa.

¿Qué podemos hacer ante esto?

Para salvaguardar la resiliencia de tu organización, es fundamental conocer con precisión qué información ya se encuentra en manos de posibles atacantes.

• Si deseas evaluar la superficie de exposición actual de tu organización, puedes solicitar un reporte gratuito de credenciales expuestas en internet para tu empresa en https://www.securetia.com/reporte-de-credenciales-filtradas.

• Gran parte de este monitoreo, correlación y detección de inteligencia ya se encuentra automatizado dentro de nuestra plataforma. Si quieres comenzar a utilizarlo y potenciar las capacidades de tu equipo, puedes registrarte en Vulseek a través de https://app.vulseek.io/register.

El perímetro moderno de una organización de energía o infraestructura suele ser amplio y distribuido, caracterizado por consolas web expuestas y múltiples portales SSL-VPN distribuidos por planta o sucursal. Esta descentralización representa un desafío crítico de seguridad cuando interactúa con el auge del malware de tipo Infostealer (MITRE ATT&CK T1555 - Credentials from Password Stores y T1539 - Steal Web Session Cookie).

A diferencia de las filtraciones históricas de bases de datos de terceros, los stealer logs capturan las credenciales directamente de los navegadores y almacenes locales de dispositivos corporativos o personales comprometidos en el momento exacto en que el usuario se autentica en portales legítimos de la empresa (como portales de identidad o consolas de seguridad de endpoints). Si la organización expone portales VPN u Outlook Web App (OWA) sin un segundo factor de autenticación estricto o resistente a phishing, un atacante en posesión de una credencial exfiltrada recientemente por malware puede realizar un secuestro de cuenta inmediato (Account Takeover - ATO) y utilizarlo como puente directo para el movimiento lateral dentro de la red corporativa.

Metodología y Capacidad de OSINT/CTI Aplicada

La recolección y análisis avanzado de inteligencia sobre este vector de ataque se basa en una metodología analítica de alta fidelidad que procesa metadatos técnicos y telemetría de malware:

1. Mapeo de la Superficie de Acceso Remoto (Capa 1): Se identifican todos los servicios activos expuestos mediante consultas pasivas de DNS e inspección de cabeceras HTTP(S), localizando portales VPN y servidores de correo corporativo que representen el destino final de las credenciales robadas.

2. Análisis de Atribución y Portal de Origen (Capa 2): En lugar de buscar únicamente el dominio de correo, el análisis de inteligencia de amenazas avanzado procesa los registros de stealer logs buscando el campo "origin" que apunta directamente a las URLs de inicio de sesión corporativas legítimas. Esto permite diferenciar un robo de credenciales en un sitio externo (como una red social o portal de capacitación) de un compromiso directo sobre un endpoint con acceso legítimo a las plataformas del negocio.

3. Validación de Vigencia e Higiene de Identidades: Se analiza la persistencia de las credenciales a lo largo del tiempo. Mediante técnicas pasivas de control, se puede evaluar si contraseñas expuestas en brechas muy antiguas siguen activas en sistemas externos de origen (como plataformas de almacenamiento o colaboración), demostrando de forma indirecta la preocupante vigencia de la misma contraseña por parte del usuario durante años o incluso décadas.

Impacto Operativo y Estratégico

Esta inteligencia táctica proporciona un valor directo al CISO y al equipo de SOC, permitiéndoles enfocar los esfuerzos de remediación basados en la severidad real del riesgo:

• Acción Inmediata: Permite identificar endpoints específicos potencialmente infectados con malware activo para proceder con su aislamiento, barrido antimalware profundo y reinstalación de imagen.

• Decisiones de Arquitectura: Justifica la consolidación de accesos remotos y portales VPN distribuidos hacia arquitecturas unificadas de Zero Trust Network Access (ZTNA).

• Políticas de Seguridad: Demuestra la urgencia de aplicar políticas estrictas de caducidad de contraseñas y el despliegue obligatorio de MFA en todos los perímetros expuestos.

¿Qué podemos hacer?

Proteger la infraestructura contra credenciales exfiltradas activamente por malware requiere visibilidad en tiempo real de lo que circula en el mercado clandestino.

• Si deseas evaluar la superficie de exposición actual de tu organización, puedes solicitar un reporte gratuito de credenciales expuestas en internet para tu empresa en https://www.securetia.com/reporte-de-credenciales-filtradas.

• Gran parte de este monitoreo, correlación y detección de inteligencia ya se encuentra automatizado dentro de nuestra plataforma. Si quieres comenzar a utilizarlo y potenciar las capacidades de tu equipo, puedes registrarte en Vulseek a través de https://app.vulseek.io/register.

En el ámbito de la protección de infraestructuras críticas, la seguridad física y los controles perimetrales suelen recibir la mayor parte de la atención. Sin embargo, los actores de amenazas dirigen cada vez más sus esfuerzos hacia la identidad como el vector de acceso inicial más simple y efectivo. La obtención de cuentas válidas (técnica MITRE ATT&CK T1078 - Valid Accounts) a través de filtraciones masivas de terceros (combolists públicas) permite a un atacante evadir por completo los mecanismos tradicionales de detección perimetral.

Este vector de ataque se agrava exponencialmente cuando el personal de alta jerarquía técnica (como gerentes de ingeniería o infraestructura) incurre en la reutilización de contraseñas o en el uso de contraseñas de baja complejidad basadas en diccionarios en sus cuentas personales. Si un atacante logra comprometer una cuenta personal y detecta un patrón de construcción de contraseñas corporativas, puede ejecutar campañas dirigidas de pulverización de credenciales (T1110.003 - Password Spraying), obteniendo acceso a consolas de administración en la nube o portales de correo corporativo, lo que representa el paso previo a un compromiso de sistemas de control industrial o a un ataque de Business Email Compromise (BEC).

Metodología y Capacidad de OSINT/CTI Aplicada

La identificación y mitigación de este riesgo requiere un proceso de reconocimiento pasivo estructurado en tres capas analíticas (superficie técnica externa, exposición de identidades/PII, y presencia en dark web y redes anonimizadas), ejecutado sin realizar explotación ni interacciones activas con los sistemas de la organización:

1. Capa 1: Análisis de la Superficie Técnica y DNS: Se realiza la enumeración pasiva de la infraestructura DNS pública para mapear subdominios activos, analizar registros de seguridad de correo (SPF con mecanismos estrictos, políticas DMARC en modo cuarentena o rechazo) e identificar los gateways dedicados y proveedores SaaS en uso. Este mapeo tecnológico sirve para evaluar la superficie de ingeniería social disponible para un atacante.

2. Capa 2: Análisis de Credenciales e Identidad: A través de la recolección pasiva en bases de datos de brechas y APIs especializadas, se identifican las cuentas corporativas nominales expuestas. La clave metodológica radica en la doble confirmación cruzada: un hallazgo de alta confianza no se basa en un único proveedor de datos, sino en la correlación independiente de múltiples fuentes de inteligencia de credenciales que demuestran la existencia del usuario y la contraseña en texto plano. Asimismo, se analizan las correlaciones de identidad de cuentas personales de roles críticos en la organización para descubrir patrones de debilidad o reutilización de contraseñas de diccionario.

3. Capa 3: Monitoreo en la Dark Web: Se examinan los agregadores de víctimas de ransomware, feeds de extorsión y foros clandestinos (tanto en clearnet como en directorios nativos de la red Tor .onion) para descartar que el dominio u organización ya estén bajo ataque activo o dentro de catálogos de corredores de acceso inicial (IABs).

Impacto Operativo y Estratégico

Para un CISO o un Security Manager, este nivel de inteligencia estratégica es altamente accionable ya que permite actuar de forma preventiva en lugar de reactiva. Identificar una credencial expuesta antes de que sea utilizada por un actor de amenazas reduce drásticamente el Tiempo Medio de Detección (MTTD), permitiendo al equipo de seguridad ejecutar una rotación forzada de contraseñas, auditar los logs de acceso históricos en la consola de identidad (ej. Microsoft Entra ID) y asegurar la implementación obligatoria de autenticación multifactor (MFA) en accesos críticos.

¿Qué podemos hacer ante esto?

Para salvaguardar la resiliencia de tu organización, es fundamental conocer con precisión qué información ya se encuentra en manos de posibles atacantes.

• Si deseas evaluar la superficie de exposición actual de tu organización, puedes solicitar un reporte gratuito de credenciales expuestas en internet para tu empresa en https://www.securetia.com/reporte-de-credenciales-filtradas.

• Gran parte de este monitoreo, correlación y detección de inteligencia ya se encuentra automatizado dentro de nuestra plataforma. Si quieres comenzar a utilizarlo y potenciar las capacidades de tu equipo, puedes registrarte en Vulseek a través de https://app.vulseek.io/register.

Hoy vi un video en YouTube —en general bastante bueno— sobre cómo automatizar tareas usando Claude Code. Hay cada vez más contenido de este estilo, lo cual está bien.

Pero hubo algo que me llamó la atención.

En varios de estos videos se recomienda usar --dangerously-skip-permissions para “ahorrar tiempo”, evitando que la herramienta esté pidiendo confirmaciones constantemente.

Y esto me hizo acordar mucho a algo que ya vimos.

Hace unos años era bastante común ver recomendaciones para deshabilitar el User Account Control (UAC) en Windows. El argumento era el mismo: evitar fricción, ganar velocidad, no perder tiempo haciendo clic en un cartel.

El problema es que ese “ahorro de tiempo” venía con un costo claro: eliminar una capa de seguridad pensada para evitar ejecuciones no deseadas con privilegios elevados.

Hoy estamos repitiendo esa lógica, pero con herramientas de inteligencia artificial.

El problema de fondo

Que más gente esté aprendiendo a usar IA es algo positivo.

El problema es cómo se está aprendiendo.

Se prioriza la productividad inmediata, pero se dejan de lado los fundamentos de seguridad. Entonces terminamos con usuarios automatizando cada vez más cosas, con más permisos, sin entender bien qué puede pasar.

En el caso de --dangerously-skip-permissions, básicamente estás sacando controles. Dependiendo del contexto, eso puede significar:

• Ejecutar comandos sin revisión

• Acceder a archivos sensibles

• Modificar cosas en el entorno sin darte cuenta

• Encadenar acciones que terminan teniendo más impacto del esperado

Y esto se agrava porque no es lo mismo un entorno desktop que la ejecución automatizada de agentes.

No es “no usar IA”, es usarla bien

No se trata de no usar estas herramientas.

La inteligencia artificial es una oportunidad enorme para ser más productivos. Pero eso no puede venir a costa de desactivar controles básicos.

Si algo ya aprendimos (y el caso de UAC es un buen ejemplo), es que cuando la seguridad molesta, alguien la termina desactivando. Y cuando eso pasa en muchos lados al mismo tiempo, empiezan los problemas.

Qué falta

Más allá de evitar este tipo de flags, hay algo más importante: definir cómo usar estas herramientas de forma segura en entornos reales.

No alcanza con decir “no uses esto”. Hay que entender:

• Qué permisos dar y cuáles no

• Cómo limitar lo que puede hacer la herramienta

• Cómo auditar lo que ejecuta

• Cómo integrarla sin romper lo que ya tenés armado

Sobre eso vamos a ir profundizando en próximos artículos.

La idea no es frenar el uso de IA, sino usarla mejor: ser más productivos sin poner en riesgo nuestra información, la de la empresa y la de los clientes.

En una empresa de ciberseguridad, elegir una tecnología no es solo una decisión técnica: es una decisión que impacta en el desarrollo, el mantenimiento y la operación durante años.

En nuestro caso, tratamos de mantener un enfoque muy pragmático. No buscamos usar lo último ni lo más “interesante”, sino lo que realmente resuelve un problema sin agregar complejidad innecesaria.

1. Partimos siempre de una necesidad real

Antes de evaluar cualquier tecnología, lo primero que definimos es si existe una necesidad concreta.

No trabajamos sobre hipótesis del tipo:

“esto nos podría servir en el futuro”

Si no hay una necesidad real hoy, no se incorpora nada.

Esto nos permite evitar una de las principales fuentes de complejidad en los sistemas: agregar herramientas “por las dudas”.

2. Evitar nuevas tecnologías siempre que sea posible

Una vez identificada la necesidad, el siguiente paso no es buscar una herramienta nueva.

Es preguntarnos:

• ¿Podemos resolver esto con lo que ya tenemos?

• ¿Podemos extender alguna tecnología existente?

Un ejemplo muy común es el uso de bases de datos no relacionales.

Ante la necesidad de manejar datos sin estructura fija, muchas veces la reacción inmediata es incorporar herramientas como MongoDB o Elasticsearch.

Sin embargo, en muchos casos esa necesidad se puede cubrir usando PostgreSQL con tipos de datos como JSON o JSONB.

Esto nos permite:

• evitar sumar una nueva tecnología

• reducir costos de mantenimiento

• mantener el stack más simple

La lógica es bastante simple:

Si podemos evitar incorporar una tecnología nueva, mejor.

3. El costo oculto de cada tecnología

Cada tecnología que se incorpora no es solo una herramienta más.

Implica:

• instalación

• mantenimiento

• monitoreo

• capacitación del equipo

• posibles dependencias adicionales

Y muchas veces, una tecnología nueva no viene sola.

Puede arrastrar otras decisiones que terminan modificando el stack completo.

Por eso priorizamos mantenernos lo más cerca posible de lo que ya usamos.

4. Qué tecnologías descartamos rápidamente

Hay algunos patrones claros que nos llevan a descartar tecnologías:

❌ Tecnologías que no encajan con el stack

Si una herramienta nos obliga a cambiar demasiado nuestro entorno (por ejemplo, sistema operativo o ecosistema), la descartamos salvo que sea estrictamente necesario.

❌ Tecnologías demasiado nuevas o no probadas

En sistemas críticos, evitamos herramientas que:

• no tengan suficiente adopción

• no estén bien documentadas

• no tengan comunidad o soporte

Esto no significa no innovar, sino ser estratégicos según el contexto.

❌ Tecnologías en declive

También evitamos herramientas que claramente están quedando en desuso.

Adoptar una tecnología que el mercado está abandonando es comprar un problema a futuro.

5. El error más común: seguir modas

El error más frecuente que vemos en equipos es dejarse llevar por tendencias.

Adoptar tecnologías porque:

• “están de moda”

• “todos las usan”

• “parecen interesantes”

sin validar si realmente resuelven una necesidad.

Otro problema asociado es no dimensionar el impacto de estas decisiones.

Elegir una tecnología no es algo reversible en el corto plazo.

Son decisiones con las que una empresa puede convivir durante años.

6. La regla más importante

Si tuviéramos que resumir todo en una idea:

Elegir una tecnología es asumir un compromiso a largo plazo.

Por eso:

• analizamos antes de implementar

• priorizamos simplicidad

• evitamos sumar complejidad innecesaria

Porque en la práctica, muchas veces:

menos tecnología = mejores sistemas

La suplantación de identidad por correo electrónico (email spoofing) sigue siendo una de las técnicas más utilizadas en fraudes, phishing e ingeniería social.
En muchos casos, no requiere comprometer servidores ni credenciales, sino simplemente aprovechar una mala configuración de SPF y DMARC.

En esta guía técnica repasamos:

• Cómo funcionan SPF y DMARC a nivel práctico

• Qué errores de configuración son más comunes

• Ejemplos reales de registros DNS

• Buenas prácticas para reducir el riesgo de suplantación

Modelo de ataque típico

Desde el punto de vista del atacante, el escenario es simple:

1. Identifica un dominio sin SPF o con SPF laxo

2. Envía correos usando cualquier servidor SMTP

3. El correo aparenta venir de usuario@empresa.com

4. El receptor confía en el remitente

5. Se ejecuta el fraude o phishing

Sin SPF y DMARC bien configurados, el dominio no tiene forma de “defender su identidad”.

SPF en detalle

¿Qué hace SPF exactamente?

SPF permite declarar, mediante DNS, qué servidores están autorizados a enviar correos para un dominio.

Cuando un servidor recibe un correo:

1. Extrae el dominio del MAIL FROM

2. Consulta el registro SPF del dominio

3. Evalúa si la IP emisora está autorizada

4. Decide si el correo pasa o falla SPF

Ejemplo básico de SPF

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Este registro indica:

• v=spf1: versión

• ip4:203.0.113.10: servidor propio autorizado

• include:_spf.google.com: autoriza Google Workspace

• -all: rechaza todo lo demás

👉 Este -all es clave: sin él, el SPF no protege realmente el dominio.

Errores comunes en SPF

1. SPF demasiado permisivo

v=spf1 +all

Esto equivale a:

“Cualquiera puede enviar correos por este dominio”

Desde el punto de vista de seguridad, es lo mismo que no tener SPF.

2. SPF incompleto

v=spf1 include:_spf.google.com ~all

• ~all (softfail) no bloquea

• Muchos proveedores siguen aceptando estos correos

Sirve como etapa de prueba, pero no como configuración final.

3. Demasiados include

SPF tiene un límite de 10 consultas DNS.
Excederlo provoca fallos SPF incluso si los servidores son legítimos.

Este problema es muy común cuando:

• Se agregan herramientas de marketing

• Se usan múltiples proveedores externos

• Nadie revisa el SPF históricamente

DMARC en detalle

¿Qué agrega DMARC?

DMARC actúa como una capa de control y política sobre SPF (y DKIM).

Permite:

• Definir qué hacer si SPF falla

• Recibir reportes de abuso del dominio

• Reducir drásticamente el spoofing

Ejemplo básico de DMARC

v=DMARC1; p=none; rua=mailto:dmarc@empresa.com; ruf=mailto:dmarc@empresa.com; fo=1

Este registro:

• Activa DMARC

• No bloquea correos (p=none)

• Habilita reportes agregados (rua)

• Habilita reportes forenses (ruf)

Es ideal como primer paso.

Políticas DMARC

Modo monitoreo

p=none

• No bloquea correos

• Permite ver quién está enviando emails

• Recomendado como etapa inicial

Cuarentena

p=quarantine

• Correos sospechosos pueden ir a spam

• Reduce ataques sin ser demasiado agresivo

Rechazo

p=reject

• Correos no alineados son rechazados

• Máxima protección contra suplantación

• Requiere que SPF esté bien configurado

Error común: DMARC “activo” pero inefectivo

Muchos dominios tienen DMARC así:

v=DMARC1; p=none

Esto no protege, solo observa.
Si nunca se avanza de p=none, el dominio sigue siendo suplantable.

Alineación SPF + DMARC

DMARC no solo verifica SPF, sino que exige alineación:

• El dominio del MAIL FROM

• Debe coincidir (o alinearse) con el dominio visible

Errores de alineación:

• Subdominios mal definidos

• Proveedores externos mal configurados

• Reenvíos de correo

Este es uno de los puntos donde más errores se cometen.

Riesgos reales de una mala configuración

En escenarios reales hemos visto:

• Facturas falsas enviadas desde dominios legítimos

• Correos de “cambio de CBU” a proveedores

• Phishing interno a empleados

• Caída de reputación del dominio (emails legítimos a spam)

Todo esto sin comprometer infraestructura interna.

¿Por qué no basta con “seguir un tutorial”?

Aunque SPF y DMARC parecen simples:

• Cada entorno es distinto

• Cada proveedor agrega complejidad

• Un error puede bloquear correos críticos

Los problemas más comunes aparecen cuando:

• Se endurece DMARC sin analizar reportes

• Se olvida autorizar un proveedor externo

• Se rompe la alineación SPF

• Se superan límites de DNS

¿Cómo puede ayudar Securetia?

En Securetia ayudamos a:

• Analizar SPF y DMARC existentes

• Detectar riesgos reales de suplantación

• Corregir configuraciones sin impacto operativo

• Definir políticas progresivas y seguras

• Dejar todo documentado y mantenible

Si querés revisar el estado de tu dominio o necesitás ayuda para corregirlo correctamente, podés contactarnos y lo vemos en conjunto.

Conclusión

SPF y DMARC son controles simples en concepto, pero críticos en impacto.
Una mala configuración deja el dominio expuesto a suplantación, fraude y pérdida de confianza.

Detectar el problema es fácil.
Corregirlo bien es lo que realmente protege.

Estamos muy contentos de anunciar que Vulseek ya está oficialmente disponible en AWS Marketplace. Este paso representa un gran hito para nosotros y reafirma tanto la madurez de nuestro producto como nuestro compromiso de seguir trabajando junto al ecosistema de AWS.

El proceso para llegar hasta aquí fue exigente y enriquecedor. Pasamos por varias instancias de revisión y val

idación, incluyendo la presentación de nuestro diagrama de arquitectura para garantizar que cumplimos con los estándares de seguridad, escalabilidad y confiabilidad que AWS exige. Cada una de estas etapas fue una oportunidad para reforzar y perfeccionar nuestro producto.

¿Por qué es importante para nuestros clientes?

Estar en AWS Marketplace trae beneficios directos:

• Facturación integrada: ahora nuestros clientes pueden realizar la facturación directamente a través de AWS, simplificando procesos administrativos y optimizando la gestión financiera.

• Confianza y validación: el hecho de haber superado el riguroso proceso de aprobación de AWS es una garantía adicional de calidad y seguridad.

• Acceso simplificado: adquirir y comenzar a usar Vulseek es tan fácil como hacerlo desde cualquier otro servicio del ecosistema AWS, sin configuraciones complejas.

Una experiencia que nos impulsa

Más allá de la parte técnica y los requisitos formales, esta experiencia reafirma que estamos en el camino correcto: construir soluciones sólidas, confiables y enfocadas en aportar valor real a nuestros clientes. Publicar en AWS Marketplace no es solo un logro comercial, sino también un testimonio de nuestra capacidad para cumplir con los más altos estándares del mercado.

Ahora que Vulseek está disponible en AWS Marketplace, el siguiente paso es simple: comenzar a usarlo y aprovechar al máximo sus capacidades para la gestión y detección de vulnerabilidades.

https://aws.amazon.com/marketplace/pp/prodview-oxi3fp4s6p4s6

El pasado 2 de julio vivimos una jornada intensa, cargada de contenido técnico, demos en vivo e ideas que desafiaron la manera tradicional de pensar la ciberseguridad. H4CK3D 2025, el evento que organizamos junto a la Universidad de Palermo, fue un espacio único donde profesionales, entusiastas y especialistas compartieron conocimiento, herramientas y experiencias reales.

Sabemos que muchos querían volver a repasar algunas de las charlas, o quizás no pudieron asistir al evento. Por eso, ya están disponibles para descargar en formato PDF las presentaciones utilizadas por los speakers durante la jornada.

¿Qué vas a encontrar?

• Investigaciones originales y casos reales de vulnerabilidades

• Herramientas open source explicadas desde adentro

• Técnicas de Red Team y defensas modernas

• Automatización y uso de inteligencia artificial aplicada a seguridad ofensiva

• Y mucho más...

🎥 Próximamente vamos a estar publicando los videos completos de las charlas en nuestros canales oficiales. Si todavía no te suscribiste a nuestro canal de YouTube, este es un buen momento para hacerlo.

🙏 Queremos agradecer especialmente a la Universidad de Palermo por abrirnos las puertas y acompañarnos en esta iniciativa. Sin su apoyo, este evento no hubiera sido posible.

Gracias a todos los que participaron en esta edición de H4CK3D. Si te quedaste con ganas de más, seguinos en nuestras redes para enterarte de lo que se viene 👀

📥 Accedé a las presentaciones desde este enlace:

https://drive.google.com/drive/folders/188q4Jt770wZVD7P1TquzV-NhN8XYjvV0?usp=sharing

Te vamos a mostrar cómo ocurren estos ataques, qué impacto real pueden tener en tus sistemas y, lo más importante, cómo prevenirlos desde el código. Todo explicado con ejemplos prácticos y recomendaciones concretas para aplicar en tus desarrollos.

🔒 El desarrollo seguro no es opcional: es una responsabilidad. Sumate a esta charla pensada especialmente para quienes quieren escribir código más robusto, confiable y seguro.

🧠 ¿Qué vas a aprender?

• Qué es una SQL Injection y cómo se explota

• Qué tipos de XSS existen y cómo afectan a los usuarios

• Casos reales de vulnerabilidades mal gestionadas

• Buenas prácticas y herramientas para prevenir ataques

• Cómo integrar la seguridad en tu proceso de desarrollo

🎯 Público objetivo

Este webinar está pensado para:

• Desarrolladores/as de software (back y front)

• Líderes técnicos

• Equipos de QA y testing

• Arquitectos/as de software

• Personas interesadas en seguridad informática

• Estudiantes avanzados de programación o sistemas

📝 Inscripción

La participación es gratuita pero los cupos son limitados.

¡Reservá tu lugar hoy!

https://www.eventbrite.com.ar/e/securetia-webinar-desarrollo-seguro-tickets-1452796536549?aff=oddtdtcreator

Fue una jornada intensa, con charlas técnicas, desafíos en vivo, comunidad y mucho entusiasmo. Si estuviste ahí, probablemente te cruces con alguna cara conocida. Y si no pudiste venir, esta es una buena forma de asomarte a lo que fue el evento.

Próximamente también vamos a estar subiendo los videos completos de las charlas a nuestro canal de YouTube, así que si no querés perdértelo, te recomendamos suscribirte.

Gracias a todos los que participaron y ayudaron a que H4CK3D sea lo que fue.
¡Nos vemos en la próxima!

—
El equipo de Securetia

La presentación —que podés descargar al final de este artículo— se enfocó en los desafíos reales que enfrentamos durante el desarrollo del producto, así como en las decisiones que tomamos para que Vulseek sea una solución rápida, útil y fácil de mantener.

🚧 Desafíos técnicos reales, decisiones concretas

Uno de los temas centrales de la charla fue el tiempo hasta obtener resultados útiles. Quienes trabajamos en seguridad sabemos que los escaneos de vulnerabilidades pueden ser lentos, variables o incluso inestables. Por eso, desde el inicio nos propusimos que Vulseek pudiera ofrecer resultados en menos de 5 minutos, incluso en escenarios complejos.

Para lograrlo, implementamos una arquitectura basada en colas priorizadas, escaneos paralelizados y entrega progresiva de resultados. Usamos AWS para resolver la parte de mensajería y autoscaling, pero siempre priorizamos que la solución fuera sencilla de mantener: somos un equipo chico y eso nos obliga a optimizar todo lo que hacemos.

El segundo gran desafío que abordamos fue el de entregar resultados consistentes. Incluso usando herramientas conocidas como Nmap, los resultados pueden variar enormemente según la latencia, los filtros de red o incluso la versión del sistema operativo del escáner. Analizamos ejemplos reales durante la charla (que también están en la presentación), mostrando cómo distintas configuraciones pueden generar diferencias que no son triviales de interpretar.

💡 Principios de diseño: SYLPA

Una de las ideas que más resonó durante la charla fue la noción de "SYLPA": que las cosas Sirvan Y Las Podamos Administrar.
Este principio lo aplicamos tanto a nivel técnico como organizacional. No basta con que algo funcione: tiene que poder mantenerse en el tiempo, escalar si hace falta, y no convertirse en un caos si una persona del equipo se va o cambia de rol.

Desde el diseño del stack (Python, PostgreSQL, contenedores, etc), hasta el uso de IA para priorización de vulnerabilidades (con integración de modelos como los de Anthropic), todo está pensado para que la solución funcione hoy y siga siendo viable en el futuro.

📄 Descargá la presentación

Podés ver todos estos temas en detalle descargando la presentación que usamos en el evento. Está en español y pensada tanto para perfiles técnicos como para quienes estén explorando cómo construir su propio SaaS en el mundo de la ciberseguridad:

🔍 ¿Querés probar Vulseek?

Si todavía no conocés Vulseek, podés registrarte y empezar a probarlo gratis. No pedimos tarjeta de crédito y la interfaz está completamente en español.

🔗 https://www.securetia.com/vulseek

Estamos constantemente mejorando el producto y cualquier feedback que puedas darnos es más que bienvenido.
Gracias por acompañarnos en este camino!

Vulseek Internals H4ck3d 2025

1.19MB ∙ PDF file

Download

Download

📬 Notificaciones por correo: configuralas como quieras

Ahora podés elegir cómo y cuándo recibir notificaciones de Vulseek directamente en tu correo electrónico.

🔧 Configurá esta opción desde tu perfil, dentro del apartado "Datos".

Además, si tu usuario tiene rol de Administrador, vas a poder gestionar las notificaciones de otros miembros de tu equipo desde la pantalla de Usuarios. Seleccioná el usuario que quieras modificar, hacé clic en "Editar" 📝 (esquina superior derecha del listado) y ajustá su configuración.

🖥️ Identificación de Sistemas Operativos con un solo vistazo

¿Querés saber qué sistema operativo corre en cada uno de tus activos?
Ahora en las pantallas de Direcciones IP públicas y Direcciones IP privadas, vas a ver una nueva columna con el logo del sistema operativo que Vulseek detectó automáticamente.

🔍 Pasá el cursor sobre el ícono para ver más detalles.
🖱️ Hacé clic para acceder al listado completo de activos que usan ese sistema operativo dentro de tu cuenta.

Seguimos trabajando para brindarte mayor capacidad de prevención, detección y respuesta contra ciberamenazas.

Introducción

El post se centrará principalmente en cómo recolectar los datos del disco rígido sin la alteración de los mismos utilizando una herramienta OpenSource y gratuita.

En nuestro caso de estudio trabajaremos con la distribución de DEFT Zero, la cual dispone de todas las herramientas necesarias para realizar la toma de evidencia. Para la misma utilizaremos una herramienta muy sencilla y util a la vez: dd.

Sin embargo, daremos un paseo por un listado de buenas prácticas que son recomendables realizar previo a la recolección de la evidencia.

Buenas Prácticas antes de comenzar la recolección

Según las Buenas Prácticas del Servicio Secreto de Estados Unidos, estos son algunos puntos importantes a tener en cuenta al momento de comenzar con la recolección de la evidencia dentro del ámbito de la Informática Forense:

• No utilizar la computadora ni intentar buscar evidencia.

• Fotografiar el equipo del frente y de atrás tal como se encuentra, con los cables y dispositivos conectados.

• Si la computadora se encuentra apagada, no encenderla.

• Si la computadora se encuentra encendida y en la pantalla se muestre algo, sacar una fotografía a la misma. En el caso de que la pantalla esté apagada, encenderla; y en el caso de que no se muestre la imagen en la misma mover el mouse para que se muestre en pantalla alguna imagen y luego fotografiar la misma.

• Desconectar el cable de tensión por detrás del equipo.

• En el caso de tratarse de una Notebook y que la misma no se apague al desconectar el cable, extraer la batería de la misma para que el equipo se apague.

• Etiquetar los cables para luego identificar los dispositivos conectados.

• Desconectar todos los cables y dispositivos.

• Documentar todo el procedimiento realizado.

• Mantener todos los medios, incluyendo el gabinete, lejos de imanes, radiotransmisores y otros elementos potencialmente dañinos.

• Entre otras acciones.

Identificando unidades

Tal como indicamos al comienzo e iremos recordando durante todo el post, lo más importante es que, al momento de la recolección, la evidencia no sea alterada. Por tal motivo, es indispensable que el sistema con el que trabajemos no monte las unidades conectadas de manera automática, ya que si el mismo es montado la evidencia se altera. La versión de DEFT Zero que utilizaremos no monta las unidades automáticamente.

En nuestro caso, sabemos que contamos con 2 unidades de disco. Ambos de tecnología SATA, por lo tanto, el sistema los reconocerá como sd. El que contiene la evidencia a recolectar tiene un tamaño de 100MB y el otro de 1GB. Para ver cómo los reconoce el sistema es necesario ver los logs.

En donde identificamos ambos discos. En el caso de la evidencia el sistema lo detectó como sda y el otro como sdb. Por lo tanto, para guardar la evidencia necesitaremos montar nuestro disco, en particular la unidad lógica del mismo (sdb1).

Recolectando la evidencia

La recolección de evidencia se puede hacer por partición o por disco. Es recomendable trabajar con el disco completo, ya que si eligiésemos trabajar con particiones y fuese necesario buscar información borrada en el disco no estaremos analizando las partes que no se encuentren particionadas. Durante todo el post se realizarán copias de disco completo, o como se lo conoce: Adquisición Física.

dd

Es un comando de la familia de los Sistemas Operativos Unix/Linux que permite copiar a bajo nivel (bit a bit o bloque a bloque) cualquier archivo dentro del sistema. Es importante recordar que para este tipo de Sistemas Operativos todo es un archivo. Uno de los puntos fuertes de dd es que copia los datos en crudo (raw data) y otro punto muy importante es que viene por defecto con todas las distribuciones de Unix/Linux.

Un ejemplo de cómo utilizar el comando puede ser el siguiente:

En este caso le estamos especificando que el archivo de entrada es /dev/sda, el archivo de salida es /mnt/root/forensic/artefacto01.dd y que el tamaño en que leerá los bloques será de 64 bytes.

Uno de los puntos a tener en cuenta es el tamaño del bloque, ya que cuanto más chico sea más tardará en realizar la copia. Por ejemplo, utilizando un bloque de 4096 bytes el tiempo será mucho menor.

Para determinar este tipo de tamaño es importante saber si la unidad se encuentra dañada o no, ya que de estarlo es preferible utilizar bloques más pequeños de manera de reducir la cantidad de datos corruptos. En el caso de encontrar errores en la unidad también es recomendable utilizar las opciones conv=noerror,sync. La opción noerror permite continuar después de encontrar errores y la opción sync permite rellenar los errores encontrados con 0’s.

Si bien con ambos archivos se crean en momentos diferente y se utiliza el parámetro bs distinto, se puede ver que los HASH’s tanto del dispositivo y de las evidencias tomadas son iguales.

Una buena metodología para corroborar la integridad de la evidencia es tomando los HASHs de los mismos. En este post se utilizaremos SHA256, esto es debido a que MD5 y SHA1 son algoritmos que se encuentran rotos.

Problemas de espacio

Debido a que en la actualidad los discos rígidos son muy grandes y en el hipotético caso de que necesitemos partir el archivo, podemos utilizar el comando split (también incorporado en todos los sistemas Linux)

    split -d -b 50m artefacto01.dd artefacto-partido

Cuando necesitemos volver a ensamblarlo podemos utilizar el comando cat de la siguiente manera:

cat artefacto-partido* >> artefacto-reensamblado.dd

Siempre tenemos que tener presente comprobar que el HASH sea el mismo que el original, hay que recordar que estamos manejando evidencia y que la misma tiene que ser integra y consistente.

Otra manera de reducir el tamaño de la evidencia es comprimir el archivo al momento de generarlo utilizando el comando gzip

Claramente el tamaño del archivo comprimido es muy inferior, pero no debemos olvidar de corroborar su integridad comparando los HASH’s.

Adquisición Indirecta

En el caso que estemos imposibilitados de realizar la copia en el mismo equipo (Adquisición directa), podemos enviar la evidencia por la red a algún equipo donde podamos almacenar el archivo. Para este proceso podemos utilizar el comando nc.

Nuevamente corroboramos que tanto el origen como el destino tienen el mismo contenido.

Una de las contras de dd es que no muestra progreso y que todas las comprobaciones deben realizarse de forma manual, aunque podemos utilizar las siguientes alternativas:

Utilizando el comando kill, el cual viene con todas las distribuciones Linux podremos ver el estado de nuestra copia bit a bit.

Ojo que si lo utilizamos mal podríamos matar el proceso de copia y no queremos volver a empezar.

Para que nos diga el estado de dd le pasaremos el parámetro -USR1, también es necesario pasarle el PID. Nos quedará algo por el estilo algo por el estilo:

    kill -USR1 $(ps -ef | fgrep .dd | grep -v grep | awk '{print $2}')

El comando

    ps -ef | fgrep .dd | grep -v grep | awk '{print $2}'

nos permite extraer el PID, siempre y cuando hayamos utilizado la extensión .dd.

La ejecución del kill nos dará la siguiente pantalla:

También podríamos utilizar otra herramienta que nos mantenga al tanto de lo que hace dd, como por ejemplo pv.

pv no viene por defecto con esta distro, con lo cual hay que instalarla desde el repo

    apt-get update
    apt-get install pv

Como no podía ser de otra manera, tenemos que corroborar el HASH de nuestra copia.

Bueno, hemos hecho un largo recorrido con el copiado bit a bit de la mano de dd, les dejo para que prueben Uds. otros comandos que suelen utilizarse para realizar adquisiciones bit a bit: dc3dd, dd_rescue, ewfadquire y para los que les gusta el entorno gráfico Guymager.

Una vez que hayan probado los mismos podrán decidir Uds. mismos qué herramienta por software utilizarán para realizar Adquisiciones Forenses.

Espero que les haya resultado interesante el artículo.

Nos vemos en el próximo post.

En este caso voy a hacer una breve revisión sobre algunas de las distribuciones que tenemos disponibles para llevar adelante con nuestra labor.

El fin del mismo no es recomendarles una de ellas sino presentarles algunas de las herramientas gratuitas para llevar a cabo algunas de las tareas pertenecientes a las acciones de identificación, preservación y análisis vistas en el post anterior. Y no presentaré todas las existentes, ya que, son muchas las que hoy tenemos en la actualidad, sino que nos basaremos en cuatro que son de uso gratuito, aquellas que no podemos dejar de conocer. Muchas de ellas surgen de alguna distribución de Linux. En particular, vamos a estar hablando sobre 4 de ellas, le dedicaremos este post a DEFT, Huemul, SIFT y Santoku.

No todas estas distros las utilizaremos bajo las mismas circunstancia, a medida que hablemos de cada una de ellas veremos bajo qué condición nos convendrá una u otra.

Antes de comenzar con la presentación de cada una, lo que debemos que tener presente, para considerar que una distribución es forense, es que la herramienta que utilicemos *no debe alterar bajo ningún concepto el objeto a peritar*.

DEFT

Arranquemos por DEFT, DEFT es el acrónimo de Digital Evidence & Forensic Toolkit tenemos dos sabores para esta distribución, una de ellas es DEFT 8.2 y la otra DEFT Zero rc1.

DEFT 8.2

La primera de ellas es la versión 8.2, la misma se encuentra basada en Lubuntu 12.10, tiene un tamaño de 3.1 GB y dispone de una gran variedad de herramientas para realizar nuestras labores forenses, tanto para la adquisición como para el análisis del mismo. Como vemos en la siguiente imagen, en DEFT tenemos distribuídas las aplicaciones en los siguientes grupos: Analysis, Antimalware, Data Recovery, Hashing, Imaging, Mobile Forensics, Network Forensics, OSINT, Password recovery y Reporting tools.

DEFT 8.2 también viene con DART, acrónimo de Digital Advanced Response Toolkit, el cual es un conjunto de herramientas que trabaja bajo entornos Microsoft. Posee tools de Adquisición entre las que cabe destacar la aplicación FTK Imager, herramienta gratuita perteneciebte a una empresa lider en el ámbito forense. Data Recovery, Forensics, Incident Response, Networking, Password, Visualize y Utility son otros de los tópicos dentro de DART.

Descarga DEFT 8.2

DEFT Zero

La segunda es DEFT Zero rc1, la cual es una distro reducida que tiene un tamaño de únicamente 403 MB. Esto es debido a que el fin de la misma es para que realicemos únicamente la adquisición forense para después utilizar un nuestro laboratorio las herramientas que consideremos necesarias.

Descarga DEFT Zero

Huemul

Toca el momento de hablar de Huemul, esta es una distro argentina la cual se encuentra en su versión 1.0. La misma se encuetra basada en Debian.

Una característica de esta distribución es que está separado su menú en Etapas, en donde aparecen la Etapa de Adquisición, Clonación y Análisis. También en el menú nos encontramos con Borrado seguro, Celulares y Cifrado. Otra característica de esta distro es que en el menú, tal como puede apreciarse en la siguiente imagen, no aparece solo el nombre de la aplicación sino una breve descripción de la misma.

Descarga Huemul

Santoku

Por último, tenemos a Santoku 0.5, una distribución basada en Ubuntu 14.04.1 LTS con sponsor de VIA Forensic. Una particularidad que tiene esta distro es que tiene varias herramientas para trabajar con telefonía mobile, tanto para la adquisición como así también para el análisis. Posee tools para realizar reversing de aplicaciones desarrolladas para Android y algunas otras para hacking.

En su menú tiene los siguientes grupos de aplicaciónes: Development Tools, Device Forensics, Penetration Testing, Reverse Engineering y Wireless Analyzers. Esta puede ser una buena opción en el caso de tener que trabajar con dispositivos con Android como Sistema Operativo.

Descarga Santoku

Como hemos visto en muchas de estas distribuciones, entre las herramientas forenses nos encontrado con varias tools de hacking. Por qué? se preguntaran, la realidad es que en muchos casos es necesario romper algunas barreras para llegar a realizar la labor propuesta. Pero ojo, siempre debemos disponer de la autorización del dueño del activo y/o del Juez interviniente en la causa.

Obviamente nosotros podemos armar nuestra propia distribucuón Linux con las herramientas que más nos guste pero para un caso legal, cuanto más conocida sea la distribución que utilicemos menos tendremos que defenderla, ya que, será el mismo mercado quien avale nuestra herramienta forense.

En los próximos posts empezaremos a incursionar dentro de las acciones a realizar dentro de un proceso forense utilizando herramientas provistas por alguna de las distribuciones aquí mencionadas.

Como indica el título, comenzaré por una introducción a la Informática Forense para enmarcar los próximos artículos que hablarán sobre la temática, los cuales tendrán mayor profundidad técnica.

En esta Ciencia es muy importante tener una metodología, ya que, debería poder reproducirse las acciones tomadas llegando al mismo resultado con posterioridad. No debemos olvidarnos de llevar una bitácora de las acciones realizadas.

En algunos casos nos encontraremos con los artefactos presentados como prueba digital los cuales posteriormente podrían convertirse en evidencia de la cual se nutra el Juez para dictar sentencia.

En el camino podremos encontrarnos con artefactos con barreras criptográficas que pueden dar bastante dolor de cabeza al momento de tener que aplicar forense sobre los mismos.

Definiciones

Arranquemos por algunas definiciones que nos servirán para introducirnos en este asombroso mundo de la Informática Forense.

Seguramente muchos de los lectores saben la definición pero cuando les pregunto a mis alumnos que definan Qué es la Informática? muchos se quedan pensando sin poder definirla correctamente. Para esto, citaré a la definición contenida en la RAE que indica que la Informática es un “Conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la información por medio de computadoras”.

Teniendo nuestra primer definición en el bosillo, pasamos a la segunda que tiene que ver con el concepto de Ciencias Forenses, en donde la explicación más acertada es decir que “Es la aplicación de prácticas científicas dentro del proceso legal”.

No podemos dejar de nombrar a Edmon Locard quien fuera un criminalista francés, considerado uno de los principales pioneros de esta ciencia. Es famoso por enunciar el conocido “Principio de intercambio de Locard” en donde enuncia que “Siempre que dos objetos entran en contacto transfieren parte del material que incorporan al otro objeto”. Una lectura recomendable es el “Manual de Técnica Policíaca” de Locard.

Ahora necesitamos hacer un mix de las definiciones antes descriptas, la cual nos dará como resultado que la “Informática Forense es la aplicación de técnicas científicas y analíticas especializadas a infraestructura tecnológica que permiten identificar, preservar, analizar y presentar datos que sean válidos dentro de un proceso legal”.

Forense sobre Informática Forense

Dimos la definición que nos interesa, Informática Forense, es el momento de desensamblarla para comprender cada una de sus acciones.

Cuando hablamos de identificar es introducirnos en el momento, el entorno, la causa y el activo informático al cual hay que realizarle forense. Tendremos distintas metodologías para las distintas situaciones que nos surjan.

En la preservación de los artefactos que vayamos adquiriendo durante el proceso es esencial mantener la integridad de los mismos. De otro modo se estaría contaminando la evidencia y la misma no tendría valor alguno.

El analisis será nuestro próximo paso dentro de nuestro proceso forense, en donde a partir de lo adquirido llegaremos a conclusiones que harán a la causa.

Por último, se encuentra la acción de presentar, el armado del Informe Pericial o simplemente un Informe. Este siempre tiene que tener el vocabulario necesario para su comprensión por las personas que vayan a hacer lectura del mismo. En un Informe que hará vista un Gerente de Sistemas, Tecnología o Seguridad Informática de la entidad que nos solicitó el trabajo tendrá un vocabulario técnico-gerencial. Sin embargo, cuando se trata de un Informe Pericial y nuestro lector es un Juez hay que tener presente que su expertise se encuentra en el campo de las Leyes y no en el de la Informática, con lo cual debe ser claro el mensaje ya que será leído por una persona que no tiene sufuciente conocimiento sobre nuestra disciplina. Ojo, esto no quiere decir que no utilicemos ninguna palabra técnica, sino que al momento de utilizarlas se debe dar una breve descripción para darle al Juez el conocimiento necesario para la comprensión de nuestro Informe Pericial.

Algunas definiciones más

Durante lo descripto ut supra (ut supra? Si, son palabras que suelen encontrarse en causas judiciales ya que a los letrados les gusta utilizar expresiones del latín. En este caso, “ut supra” significa literalmente “como arriba” y se emplea en ciertos documentos para referirse a una fecha, cláusula o frase escrita más arriba y evitar su repetición) nos encontramos con palabras que necesitaremos tener presente:

Artefactos

Objetos obtenidos sobre el proceso de adquisición forense.

Prueba digital

Parte de la Documental presentada en una Causa Judicial, la cual deberá ser constatada por un Perito Informático.

Evidencia digital

Se habla de evidencia cuando una prueba ha sido constatada por el experto, en donde se tiene una certeza clara y manifiesta de la que no se puede dudar.

Criptografía

Se describirá brevemente este concepto, ya que, requeriríamos de una serie de artículos sobre esta temática, lo cual no descarto pero esa, esa es otra historia.

Podríamos definir como criptografía al arte y técnica de escribir con procedimientos y claves secretas o no tan secretas, de tal forma que lo escrito solamente sea inteligible para quien sepa y posea de la/s clave/s necesaria/s para descifrarlo.

Existe la Criptografía Simétrica y la Asimétrica. Ejemplos de la primera podrían ser los algoritmos 3DES y AES, los cuales utilizan la misma clave tanto para cifrar como para descifrar. Por el lado de los algoritmos criptográficos Asimétricos se encuentran RSA y DSA, en este caso se utiliza una clave para cifrar y otra para descifrar.

HASH

Es un algorítmo critográfico bastante particular, debido a que, el mismo no tiene una función de retorno, esto quiere decir que de un objeto (por ejemplo un archivo) aplicandole un algoritmo de hash obtendríamos el hash de dicho objeto pero desde este resultado será imposible obtener el objeto original.

Este algoritmo va a tener un gran valor en cuestiones forenses, ya que, con el mismo podremos asegurar la integridad de los artefactos desde el momento de la adquisición hasta el momento de la entrega del Informe Pericial.

Cadena de Custodia

La Cadena de Custodia es otro concepto muy importante dentro de la Informática Forense. Es la manera en que se asegura la NO alteración de los artefactos recolectados desde su adquisición hasta la presentación de la evidencia.

En este primer artículo aprendimos algunos conceptos claves dentro del apasionante mundo de la Informática Forense, en los siguientes artículos hablaremos sobre Mejores Prácticas en esta disciplina, forensia sobre Android, entre muchos más dentro de la temática.

También en Video!

El contenido de este artículo también se encuentra publicado en formato de video, está disponible en el siguiente link:

KRACK - Ataque de Reinstalación de Clave

Fue a mediados de Octubre que se dió a conocer el Ataque de Reinstalación de Clave o mejor conocido como KRACK (Key Reinstallation Attacks).

En este caso, la víctima es WPA2. WPA2 es un sistema que se utiliza para proteger redes inalámbricas y es el mecanismo de seguridad más utilizado en la actualidad, ya que, es, o mejor dicho, era un mecanismo seguro. Digo era porque con la llegada de KRACK ha puesto en jaque la seguridad de WPA2.

Según la investigación de Mathy Vanhoef y Frank Piessens el problema radica en el 4-way handshake con la cual se genera la clave de sesión. Ellos demostraron que el 4-way handshake permite un ataque de reinstalación de clave. En su paper indican que con WPA2 utilizando AES-CCMP un adversario pouede reproducir y descifrar paquetes, esto permite que se realice la técnica hijack TCP stream y se inyecte datos maliciosos dentro de ellos. Para el caso de WPA-TKIP el impacto es catastrófico, debido a que, los paquetes pueden ser reproducidos, descifrados y falsificados.

Para esta vulnerabilidad se encuentran múltiples CVEs asociados, entre ellos: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088

La prevención es mediante la actualización, tanto en clientes como en Access Point. Tanto Microsoft, la comunidad Linux, Intel, F5, TP-Link y muchas otras han sacado el la corrección para que KRACK no los afecte.

ROCA - Return of Coppersmith’s Attack

ROCA es la segunda vulnerabilidad sobre criptografía que hablaremos durante este post. En este caso, investigadores de la Universidad Masaryk (República Checa) descubrieron el problema en la generación de claves RSA utilizadas por una biblioteca de software adoptada en tarjetas inteligentes criptográficas, tokens de seguridad y otros chips de hardware seguros fabricados por Infineon Technologies AG permite un ataque de factorización práctico, en el que el atacante calcula la parte privada a partir de una clave públida RSA.

El ataque es factible para claves de longitud comúnmente utilizadas, incluyendo 1024 y 2048 bits, y afecta a los chips fabricados a partir de 2012.

La vulnerabilidad se caracteriza por la estructura de los primos generados que utiliza RSA, lo que hace prácticamente posible la factorización de longitudes de clave comúnmente utilizadas que incluyen 1024 y 2048 bits. Solo se necesita el conocimiento de una clave pública y no se requiere acceso físico al dispositivo vulnerable. La vulnerabilidad NO depende de un generador de números aleatorios débil o defectuoso: TODAS las claves RSA generadas por un chip vulnerable se ven afectadas. El ataque fue prácticamente verificado por varias claves RSA de 1024 bits seleccionadas al azar y por varias claves seleccionadas de 2048 bits.

En pruebas de laboratorio se obtuvo que el precio en el caso más desfavorable de la factorización en una instancia de cálculo en Amazon AWS es $ 76 para la clave de 1024 bits y aproximadamente $ 40,000 para la clave de 2048 bits.

En la primera semana del mes de febrero la vulnerabilidad fue revelada a Infineon Technologies AG, siguiendo el principio de divulgación responsable, se acordó un período de 8 meses antes de una divulgación pública. Los principales proveedores, incluidos Microsoft, Google, HP, Lenovo y Fujitsu, ya publicaron las actualizaciones de software y las directrices para una mitigación.

Pasados los 8 meses acordados, se ha hecho pública la vulnerabilidad y ha sido Octubre el mes de su publicación.

DUHK - Don’t Use Hard-coded Keys

DUHK (No usar claves codificadas) es una vulnerabilidad que afecta a los dispositivos que usan ANSI X9.31 generador de números aleatorios (RNG) junto con una clave de inicialización codificada. ANSI X9.31 RNG es un algoritmo que hasta hace poco se usaba comúnmente para generar claves criptográficas que aseguran las conexiones VPN y las sesiones de navegación web, evitando que terceros lean las comunicaciones interceptadas.

DUHK permite a los atacantes recuperar claves secretas de cifrado de implementaciones vulnerables y descifrar y leer comunicaciones que pasan por conexiones VPN o sesiones web cifradas. Los datos cifrados podrían incluir datos comerciales confidenciales, credenciales de inicio de sesión, datos de tarjetas de crédito y otro contenido confidencial. Las implementaciones afectadas fueron históricamente compatibles con FIPS, las Normas federales de procesamiento de información.

¿Quién es vulnerable?

El tráfico de cualquier VPN que utilice FortiOS 4.3.0 a FortiOS 4.3.18 puede ser descifrado por un adversario que escuche de forma pasiva en la red y que pueda observar el tráfico de enlace cifrado. Otros ataques de recuperación de claves en diferentes protocolos también pueden ser posibles.

También se han encontrado otras once implementaciones históricamente certificadas por FIPS que documentan claves de semilla X9.31 RNG codificadas en sus productos. La lista completa, descubierta hasta el momento, se encuentra en el paper de referencia.

Los usuarios de los productos afectados deberían aplicar las últimas actualizaciones de software.

Un dispositivo es vulnerable a DUHK si:

Utiliza el generador de números aleatorios X9.31

y

La clave de semilla utilizada por el generador está codificada en la implementación

y

La salida del generador de números aleatorios se usa directamente para generar claves criptográficas

y

Al menos algunos de los números aleatorios antes o después de los utilizados para hacer las claves se transmiten sin cifrar. Este es típicamente el caso para SSL / TLS e IPsec.

Conclusión

Octubre sin duda a dado que hablar en el ambiente criptográfic. Si bien no afecta directamente a algún algoritmo sino que afecta a implementaciones que utilizan algoritmos criptográfico, no deja de ser un golpe duro para dicha disciplina.

La recomendación, parece obvia y hasta suele aburrir repetirla, es tener un Patch Management adecuado dentro de nuestras infraestructuras para evitar que problemas conocidos afecten la Seguridad de nuestro negocio.

Referencias

KRACK ROCA DUHK