DEV Community: David Moya

Practical Malware Analysis: Still the #1 Book in 2026?

David Moya — Tue, 22 Sep 2026 14:00:00 +0000

Every malware analysis reading list starts with the same book: Practical Malware Analysis by Michael Sikorski and Andrew Honig. It was published in 2012. Fourteen years later, it is still the most recommended first book in the field.

That raises a fair question: is a 2012 book still relevant when malware has evolved so much?

What the Book Covers

The book follows a structured progression from basic to advanced:

Part 1: Static Analysis (Chapters 1-4)
Extract information from binaries without executing them. Strings, imports, PE sections, packer identification. Tools: PEiD, Dependency Walker, CFF Explorer.

Part 2: Dynamic Analysis (Chapters 5-7)
Run malware in a controlled environment and observe behavior. Process creation, file modifications, network connections, registry changes. Tools: Process Monitor, Wireshark, FakeNet.

Part 3: IDA Pro Deep Dive (Chapters 8-14)
Navigate disassembly, read control flow graphs, recognize API call patterns, and identify data structures. This is the largest section and where most of the learning happens.

Part 4: Anti-Analysis (Chapters 15-18)
Debugger detection, VM evasion, packers, and obfuscation. How malware fights back against your analysis.

The 60+ Labs Are the Real Value

Each chapter includes lab exercises with purpose-built malware samples. These are not CTF challenges. They are designed to teach specific techniques:

Lab 1-1: Basic static analysis of a DLL and EXE pair
Lab 9-1: OllyDbg debugging with anti-debug bypass
Lab 13-1: Data encoding with XOR and Base64
Lab 18-1: Packed malware requiring manual unpacking

The samples ship with the book and solutions are available online. The structured progression from "run strings" to "manually unpack and decrypt C2 config" is what makes this book work as a learning path.

What's Timeless

The methodology. The book teaches you to think in a specific sequence:

1. Triage     → file, strings, imports (30 seconds)
2. Static     → PE structure, sections, entropy (5 minutes)
3. Dynamic    → Sandbox execution, behavioral indicators (15 minutes)
4. Deep dive  → Disassembly, debugging, decryption (hours)

This workflow applies to any malware, regardless of when it was written. The tools change, the thinking does not.

Other timeless elements:

PE format analysis (still the dominant executable format on Windows)
x86 assembly patterns (function prologues, API calling conventions)
C2 communication patterns (DNS, HTTP callbacks, custom protocols)
Anti-analysis concepts (the cat-and-mouse game is the same, just more sophisticated)

What's Outdated

Be honest about the gaps:

Missing topic	Why it matters in 2026
Fileless malware	PowerShell, .NET in-memory execution dominate modern attacks
Go/Rust malware	Statically linked, stripped binaries need different tooling
Linux/macOS	Cloud and container malware is surging
YARA/Sigma rules	Detection engineering is now a core analyst skill
ARM architecture	Mobile and IoT malware
AI-assisted analysis	LLM-powered disassembly annotation, automated triage

The book assumes Windows x86 PE malware. That was 95% of the threat landscape in 2012. Today it is maybe 60-70%.

Should You Read It?

Yes, if you are starting in malware analysis. No other single resource builds the foundational methodology as well. Read it, do every lab, and you will have a solid base.

Supplement with modern resources for the gaps:

Go/Rust binaries: GoReSym, redress, and practice on modern samples from MalwareBazaar
Linux malware: ELF analysis (readelf, objdump) and REMnux
Detection engineering: YARA and Sigma rule writing
Fileless attacks: PowerShell deobfuscation and .NET analysis with dnSpy

The book gives you the thinking framework. Modern tools and samples give you current relevance. You need both.

Originally published at MalwareIntel. MalwareIntel is a free threat intelligence platform monitoring 13 public CTI sources.

Free resources:

Defense Kit — Sigma + YARA + IOCs per malware family
Detection Gap Analyzer — Check your MITRE ATT&CK coverage
CTI Assessment — Rate your threat intel maturity in 5 min

La IA inventa datos: así detecto alucinaciones antes de usarlas

David Moya — Fri, 18 Sep 2026 09:00:00 +0000

La IA miente con confianza, formato perfecto y, a veces, citas inventadas. No lo hace con intención. Un modelo de lenguaje genera la continuación más probable de un texto; no consulta automáticamente una base universal de hechos verdaderos.

Eso cambia mi forma de usarla. No trato a la IA como un oráculo. La trato como un colaborador rápido cuyo trabajo necesita un nivel de revisión proporcional al riesgo.

Para resumir mis propias notas, el riesgo es bajo. Para citar una ley, calcular una cifra financiera o aconsejar sobre salud, la respuesta no se publica ni se ejecuta sin verificarla.

Qué aspecto tiene una alucinación

No siempre es una afirmación absurda. Las más peligrosas parecen razonables:

una sentencia con número, fecha y tribunal que no existen;
un enlace real cuyo contenido no respalda lo afirmado;
una estadística plausible sin fuente primaria;
una función de software que pertenece a otra versión;
una conclusión correcta construida con datos inventados.

La fluidez no es evidencia. Tampoco lo son las comillas, una tabla o una bibliografía bien formateada.

Cuando pido «háblame del mercado de formación en IA», dejo cientos de huecos. ¿Qué país? ¿Qué periodo? ¿Qué cuenta como formación? Si el modelo no tiene acceso a datos actuales, puede completar esos huecos. El primer control, por tanto, ocurre antes de recibir la respuesta.

Técnica 1: separar hechos, inferencias y dudas

Uso este prompt cuando necesito un primer mapa de un tema:

Analiza la cuestión siguiente:
[pegar cuestión]

Separa la respuesta en tres apartados:
1. HECHOS: afirmaciones que puedas respaldar con una fuente
   primaria identificable.
2. INFERENCIAS: conclusiones derivadas de esos hechos.
3. INCERTIDUMBRES: datos que no puedes confirmar o que pueden
   haber cambiado.

Para cada hecho incluye fuente, autor u organismo, título,
fecha y URL directa. Si no puedes verificar una fuente, escribe
"NO VERIFICADO". No inventes referencias ni rellenes huecos.

Esto no garantiza que las fuentes sean correctas. Sí obliga a que las afirmaciones verificables queden separadas de la interpretación. Después abro cada enlace y compruebo que el texto original diga realmente lo que la IA atribuye.

Una referencia existe y aun así puede estar mal usada. Leo el párrafo relevante, reviso la fecha y busco el alcance: una encuesta de 80 empresas estadounidenses no demuestra automáticamente cómo se comportan todas las pymes españolas.

Técnica 2: convertir la respuesta en una lista de comprobación

Verificar un texto largo línea por línea es lento. Primero extraigo solo las afirmaciones que podrían cambiar una decisión:

TEXTO A REVISAR:
[pegar respuesta de la IA]

Extrae todas las afirmaciones factuales verificables. Prioriza
cifras, fechas, nombres propios, requisitos legales, citas,
capacidades de producto y comparaciones.

Devuelve una tabla con:
- ID
- Afirmación exacta
- Impacto si fuera falsa (alto/medio/bajo)
- Fuente necesaria para comprobarla
- Consulta de búsqueda recomendada

No evalúes todavía si son verdaderas.

Empiezo por las de impacto alto. Si preparo una presentación interna, que falle una fecha secundaria puede ser molesto. Si esa fecha define un plazo regulatorio, el mismo error puede cambiar una decisión y merece revisión primaria.

Esta priorización evita dos extremos: confiar en todo o perder una hora verificando detalles decorativos.

Técnica 3: pedir una revisión adversarial

Una segunda pasada con la misma conversación tiende a conservar los supuestos iniciales. Para trabajos importantes abro una sesión nueva o uso otro modelo. No le pido «¿estás seguro?», porque suele responder con otra muestra de seguridad. Le doy el papel de revisor adversarial:

Actúa como revisor independiente. No intentes defender el texto.
Tu objetivo es encontrar motivos para NO publicarlo.

BORRADOR:
[pegar texto]

Identifica:
1. Afirmaciones sin respaldo.
2. Fuentes que deben abrirse y comprobarse.
3. Saltos lógicos entre evidencia y conclusión.
4. Datos posiblemente desactualizados.
5. Lenguaje que exprese certeza excesiva.

Propón una corrección para cada problema. No añadas ningún dato
nuevo que tampoco puedas verificar.

El valor de la segunda IA no es que sea infalible. Es que ofrece otra distribución de errores. Si ambos modelos coinciden, sigo necesitando una fuente; dos predicciones parecidas no convierten una frase en un hecho.

Un flujo concreto para investigar

Mi proceso para un artículo con datos externos tiene cinco pasos:

Defino qué pregunta quiero responder y el periodo relevante.
Pido un mapa inicial con hechos, inferencias e incertidumbres.
Convierto el borrador en afirmaciones verificables.
Consulto las fuentes primarias: organismo oficial, documentación del fabricante, paper o datos originales.
Reescribo con enlaces y un nivel de certeza honesto.

Cuando una fuente no está disponible, no disimulo la ausencia. Puedo eliminar la afirmación, presentarla como hipótesis o explicar la limitación.

Para resumir una fuente concreta uso una instrucción todavía más cerrada:

Responde usando únicamente el documento incluido abajo.

PREGUNTA: [pregunta]
DOCUMENTO: [pegar contenido]

Incluye para cada conclusión una cita literal breve y la sección
donde aparece. Si el documento no contiene la respuesta, di
"el documento no permite responder". No uses conocimiento
externo ni completes información ausente.

Así reduzco el espacio para inventar, aunque todavía compruebo que las citas sean literales.

Señales que me hacen parar

Desconfío cuando aparecen cifras muy precisas sin metodología, referencias que no enlazan al documento original, nombres de estudios demasiado convenientes o frases como «está demostrado» sin explicar por quién. También paro cuando la respuesta evita reconocer incertidumbre en un asunto reciente o discutido.

Otra señal es el cambio de respuesta al reformular la misma pregunta. Puedo probarlo así:

Revisa tu respuesta anterior. Enumera las tres afirmaciones con
mayor probabilidad de ser incorrectas o estar desactualizadas.
Explica qué evidencia primaria necesitarías para mantener cada
una. Si no tienes esa evidencia, retírala del texto revisado.

No uso este prompt como sello de calidad. Lo uso para descubrir puntos que merecen comprobación humana.

La regla depende del riesgo

No todos los outputs requieren el mismo control. Clasifico el uso antes de empezar:

Bajo riesgo: lluvia de ideas, reformulación, borradores internos. Revisión rápida.
Riesgo medio: contenido público, análisis comercial, comparativas. Fuentes abiertas y contraste.
Alto riesgo: legal, salud, finanzas, empleo, seguridad. Especialista responsable, fuentes primarias y trazabilidad.

La IA acelera la producción. La responsabilidad no se transfiere al modelo. Quien firma, publica, recomienda o ejecuta sigue siendo una persona o una organización.

En IAcademy enseñamos esta alfabetización práctica dentro de 290 módulos y 23 especializaciones. Los Founding Members entran desde 19 EUR —Itinerario 19, Pro 99 y Pro+Mentoría 249— con precio bloqueado hasta el 15 de octubre de 2026 y garantía de 30 días o 5 horas ahorradas.

Si quieres ir más allá

Empieza por los módulos gratuitos y consulta los planes Founding. La próxima vez que uses una cifra generada por IA, abre primero la fuente original.

Why Windows Internals by Russinovich Is Essential for Malware Analysts

David Moya — Tue, 15 Sep 2026 14:00:00 +0000

About 80% of malware in the wild targets Windows. If you analyze malware professionally, you will eventually hit a wall where your tools stop explaining why something works. That wall is Windows internals knowledge, and this book is how you climb it.

What This Book Is (and Is Not)

Windows Internals by Mark Russinovich, David Solomon, and Alex Ionescu is not a malware analysis book. It is a 1,500+ page, two-volume deep dive into how Windows actually works at the kernel level: processes, memory, I/O, security, networking, and the registry.

The reason it matters for malware analysis: every technique that malware uses (process injection, token manipulation, rootkit hooking, registry persistence) exploits a documented Windows mechanism. This book documents those mechanisms.

The Chapters That Matter Most for Malware Analysis

You do not need to read all 1,500 pages. Here is a prioritized reading guide:

Must-read (Part 1)

Chapter	Topic	Why it matters
Processes & Threads	EPROCESS, ETHREAD, job objects	Understand process hollowing, injection, and how tools like Process Explorer work
Memory Management	Virtual memory, page tables, memory-mapped files	Essential for memory forensics with Volatility
Security	Tokens, ACLs, privileges, integrity levels, UAC	Explains privilege escalation, token theft, and why some malware needs admin

Read when needed (Part 2)

Chapter	Topic	When to read
I/O System	Drivers, IRPs	When analyzing rootkits or malicious drivers
Networking	Winsock, TDI, NDIS	When reverse engineering C2 communication
Registry	Internal structure, hive format	When investigating persistence mechanisms

How to Actually Apply It

Reading about EPROCESS structures is useless if you do not connect it to real analysis. Here is how to bridge theory and practice:

1. Process hollowing (CreateProcess + WriteProcessMemory)

The book explains how CreateProcess builds the EPROCESS structure and maps the executable. Malware creates a process in suspended state, unmaps the original image, writes its payload, and resumes. Knowing the internal sequence tells you exactly where to set breakpoints in a debugger.

2. Token manipulation

Chapter on Security explains access tokens, impersonation levels, and privilege constants. When you see malware calling AdjustTokenPrivileges or DuplicateTokenEx, the book tells you what those tokens contain and what the attacker gains.

3. Memory forensics

The Memory Management chapter maps directly to Volatility plugins. Understanding VADs (Virtual Address Descriptors) and PTE (Page Table Entries) makes Volatility output meaningful instead of just rows of hex.

Sysinternals: The Companion Toolkit

Russinovich created Sysinternals. The book frequently references these tools, and they are your daily drivers for dynamic analysis:

Process Explorer  → Live process tree, DLL list, handles
Process Monitor   → Real-time file/registry/network activity
Autoruns          → Persistence mechanisms across 30+ locations
TCPView           → Active network connections per process
Handle            → Open handles (files, registry keys, mutexes)

These tools are the practical application layer of the book. If the book explains how Windows manages processes, Process Explorer lets you see it happening.

The Honest Downsides

It is dense. Some chapters read like kernel source documentation. Take breaks.
No malware examples. You have to make the connections yourself. Pair it with Practical Malware Analysis for the applied side.
Two volumes, expensive. The 7th edition covers Windows 10/11, which is what you want.

Verdict

If you are serious about malware analysis on Windows, this book is not optional. It is the difference between knowing what malware does and understanding why it works. Read Part 1 first, keep Part 2 as a reference, and use Sysinternals daily.

Pair it with Practical Malware Analysis for the hands-on complement.

Originally published at MalwareIntel. MalwareIntel is a free threat intelligence platform monitoring 13 public CTI sources.

Free resources:

Defense Kit — Sigma + YARA + IOCs per malware family
Detection Gap Analyzer — Check your MITRE ATT&CK coverage
CTI Assessment — Rate your threat intel maturity in 5 min

Curso interactivo de APIs: de base a nivel profesional

David Moya — Sun, 13 Sep 2026 09:00:06 +0000

Las APIs son el idioma común de la integración moderna: cada LLM se consume por API, cada agente llama a herramientas que son endpoints, cada webhook devuelve el control a tu sistema. Y sin embargo, mucha gente que trabaja con ellas no ha repasado nunca los fundamentos: qué convierte una API en un contrato, por qué 401 no es 403, qué problema resuelve Problem Details, o por qué el riesgo número uno del OWASP API Security Top 10 no está en la ruta sino en el objeto.

He estado revisando Básicos API, un curso interactivo gratuito publicado en GitHub Pages, y me ha sorprendido su enfoque. No es un tutorial de "cómo llamar a una API REST"; es un recorrido completo por el ciclo de vida de una API real, apoyado en fuentes primarias (RFC 9110, RFC 9457, OpenAPI 3.2.0, OAuth 2.0 BCP) y con práctica en el navegador.

Lo que cubre

Un mapa interactivo del ecosistema API con 14 componentes: cliente, contrato, gateway, autenticación, validación, handler, datos, respuesta, rate limit, webhooks, observabilidad, versionado y amenazas. Cada nodo explica sus hechos clave con enlaces a la especificación.
Un simulador de 9 pasos desde el caso de uso hasta la operación en producción, con un caso guía consistente (consultar pedidos de un usuario) y comprobaciones concretas en cada etapa.
Anatomía técnica: endpoint, contrato, auth, validación, errores, operación y evolución, con matices que delatan experiencia real ("un gateway no sustituye autorización en el servicio", "un webhook también es una API y debe firmarse").
Un laboratorio local que audita endpoints: describes método, ruta, auth, estado, cabeceras y cuerpo JSON, y obtienes un informe con hallazgos. Detecta rutas verbales, falta de versión, ausencia de paginación, credenciales reutilizables, CORS abierto, SQL en cabeceras y claves sensibles como passwordHash o isAdmin en el cuerpo.
Una checklist puntuada del OWASP API Security Top 10: BOLA vale 30 puntos, auth débil 28, exposición excesiva y mass assignment 24... llegas a un nivel de riesgo bajo, medio o alto.
Quiz de 8 preguntas con explicación inmediata, guía de repaso, glosario y 15 referencias oficiales filtrables.

Por qué me importa desde el lado de la IA

Las mismas APIs que habilitan la integración habilitan el ataque. Un agente con un token de scopes amplios es exactamente el escenario de "scopes amplios elevan el impacto de tokens filtrados". El curso convierte el OWASP API Top 10 en señales que puedes marcar y puntuar sobre cualquier API que mantengas — incluida la que conecta tu próximo agente.

Todo es HTML, CSS y JavaScript plano, sin frameworks ni cuentas, y el análisis ocurre íntegramente en tu navegador. En el artículo completo desgloso el curso sección a sección y propongo un plan de estudio de tres días.

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-apis/

Curso interactivo de firewalls: análisis en profundidad

David Moya — Sun, 13 Sep 2026 09:00:00 +0000

Un firewall no protege por magia: aplica política sobre tráfico observable

Basic Firewalls es un curso interactivo en español que enseña firewalls desde la perspectiva defensiva: política, zonas, ACLs, filtrado con estado, NAT, proxies, WAF, NGFW, logging y revisión operativa.

Lo que lo hace diferente

Un mapa interactivo con once componentes del ecosistema (de la política al zero trust) conectados por relaciones reales: los logs convergen en todo, la revisión alimenta la política.
Un simulador de decisión de flujo en seis pasos: entrada por zona, normalización, coincidencia de reglas, inspección profunda, acción y evidencia. Es la parte que falta en la mayoría de cursos: qué pasa dentro del motor.
Una anatomía de regla en siete partes: origen, destino, servicio, acción, estado, logging y ciclo de vida. Esa séptima parte (propiedad y caducidad) es la que separa un diseño serio de una lista de puertos.
Un laboratorio local donde describes tu regla en lenguaje natural y un motor con heurísticas te devuelve decisión, severidad, puntuación de riesgo y hallazgos. Bloquea RDP desde Internet, detecta puertos de base de datos, DNS sin control y lenguaje excesivamente amplio.
Una checklist de dieciséis riesgos en cinco modos: exposición, deriva, visibilidad y capa 7. La categoría deriva (reglas sombra, excepciones eternas, cambios sin ticket) nombra los riesgos que aparecen meses después del despliegue.

Por qué importa si trabajas con IA

Desplegar un servicio de inferencia local o una API de modelo plantea primero una pregunta de firewall: por dónde entra el tráfico y quién llega a cada puerto. Zonas de administración separadas, terminación en DMZ, reglas específicas para bases de datos vectoriales: en cloud, los grupos de seguridad son ACLs con otro nombre, y la deriva de excepciones existe igual.

Construcción

HTML, CSS y JavaScript plano, sin frameworks ni build, con Cytoscape.js para el grafo y fallback si la CDN falla. Todo el contenido educativo vive como estructuras de datos legibles en script.js, lo que facilita reutilizar la mecánica.

Repositorio: pedri77/Basic_Firewalls

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-firewalls/

Modelo OSI: guía interactiva de las 7 capas

David Moya — Sat, 12 Sep 2026 07:30:06 +0000

Del «no conecta» a una hipótesis comprobable

Cuando una conexión falla, el mensaje visible suele ser ambiguo: tiempo de espera, servidor no encontrado, conexión rechazada o una respuesta imposible de interpretar. El modelo OSI convierte ese caos en un mapa de siete niveles. En vez de cambiar configuraciones al azar, permite preguntar qué parte del recorrido funciona y dónde aparece la primera evidencia de fallo.

El curso Modelo OSI interactivo de David presenta las siete capas mediante varias vistas complementarias. El explorador reúne función, PDU, ejemplos, dispositivos y pistas de memoria. El mapa relaciona capas con protocolos, documentos oficiales y organismos de normalización. El simulador permite seguir la encapsulación al enviar, desde Aplicación hasta Física, y la desencapsulación al recibir, en sentido inverso. Finalmente, un quiz de seis preguntas ofrece corrección y explicación inmediatas.

La secuencia esencial es sencilla de recordar: las capas superiores manejan datos; Transporte usa segmentos; Red, paquetes; Enlace, tramas; y Física, bits. Pero el valor no está en recitarla. Está en convertirla en un procedimiento de diagnóstico.

Pensemos en un agente de inteligencia artificial que no consigue llamar a una API. En Red preguntamos si el destino se resuelve y existe una ruta. En Transporte comprobamos si abre el puerto correcto o aparece un timeout. En Presentación revisamos TLS, codificación y JSON. En Sesión observamos si el contexto o token sigue vigente. En Aplicación examinamos endpoint, método, credenciales, cuota y carga útil. Si recibimos un 401, ya sabemos que muchas responsabilidades inferiores funcionaron lo suficiente para obtener una respuesta HTTP; el foco debe subir, no volver al cable.

El curso es una web estática construida con HTML, CSS y JavaScript plano. Cytoscape.js alimenta el grafo, con una alternativa estática si no carga. No hay backend, cuenta ni persistencia de puntuación: al recargar, el quiz se reinicia. Solo la preferencia de tema claro u oscuro queda guardada. Esa sencillez mantiene el foco en aprender.

Una forma concreta de estudiarlo es dividir el trabajo en tres sesiones. Primero, recorrer las capas y anotar función, PDU, ejemplos y una pregunta de diagnóstico. Después, usar el simulador en ambos sentidos y predecir qué información se añade o se retira antes de avanzar. Por último, completar el quiz y aplicar el mapa a un incidente: distinguir un fallo de resolución, un puerto inaccesible, un certificado inválido, un JSON incompatible o un error HTTP. La puntuación importa menos que poder justificar por qué cada síntoma pertenece a una responsabilidad distinta. El mapa incluye además referencias a ISO, ITU-T, RFC, IEEE, Ecma y especificaciones abiertas de Microsoft, una buena puerta de entrada para contrastar el resumen con fuentes primarias.

OSI no es una reproducción rígida de Internet. TCP/IP agrupa funciones y algunos protocolos modernos atraviesan fronteras pedagógicas. Aun así, continúa siendo un excelente lenguaje común para desarrolladores, operaciones y seguridad: ayuda a clasificar síntomas, pedir evidencias y evitar soluciones peligrosas, como desactivar TLS ante un error de certificado.

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/modelo-osi-guia-interactiva/

Seguridad en sistemas IA: el curso Basic Seguridad IA, a fon

David Moya — Sat, 12 Sep 2026 07:30:00 +0000

Cuando empecé a integrar LLMs en proyectos reales descubrí que el problema no era el modelo: era todo lo que había alrededor. El prompt al que pegábamos cualquier cosa, el RAG que indexaba documentos sin curar, el agente con permisos de más "para que funcionara". Basic Seguridad IA es un curso interactivo gratuito que ordena exactamente ese territorio.

Qué cubre

El curso parte de una tesis sencilla: un sistema IA es software, datos, decisiones y permisos trabajando juntos, y la seguridad aparece cuando cada pieza tiene límites claros. Con esa base, presenta un grafo navegable de ocho activos (prompt, datos, modelo, RAG, herramientas, identidad, monitorización y el sistema), ocho amenazas con severidad y controles (prompt injection, divulgación sensible, poisoning en RAG, agencia excesiva, salida insegura, cadena de suministro, abuso del modelo y sobreconfianza), y seis etapas de controles por ciclo de vida.

La joya es el laboratorio de exposición: configuras un caso con cuatro dimensiones (datos usados, fuente de contexto, acciones del sistema y supervisión) y observas cómo el nivel de riesgo escala en vivo. La ejecución de herramientas suma 3 puntos por sí sola; la supervisión humana es el único factor que resta.

Normativa incluida

No se queda en lo técnico: siete marcos normativos (AI Act, RGPD y LOPDGDD, AEPD, ENS, AESIA, NIS2 y ciberresiliencia) con obligaciones concretas y enlaces a las fuentes oficiales en BOE y EUR-Lex. Más una checklist persistente de 14 puntos y un quiz con explicación inmediata.

Todo es HTML, CSS y JavaScript plano sin frameworks, así que el código mismo es material de estudio si además desarrollas.

Lee el artículo completo en IAcademy.

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-seguridad-ia/

YARA Rules for Beginners: Writing Your First Malware Detection Signature

David Moya — Fri, 11 Sep 2026 10:59:34 +0000

YARA Rules for Beginners: Writing Your First Malware Detection Signature

TL;DR: YARA is a pattern-matching engine used by malware analysts, incident responders, and SOC teams to identify malicious files based on textual or binary signatures. In this tutorial, you'll learn YARA's syntax, write your first rule against a real-world sample (the EICAR test file and a WannaCry-style indicator), test it with the yara CLI, and avoid common pitfalls like false positives and performance bottlenecks. By the end, you'll have a working detection signature and a mental model for iterating on it.

What Is YARA and Why Should You Care?

YARA is a free, open-source tool originally developed by Victor Alvarez at VirusTotal. It lets you describe malware families in a readable, rule-based syntax and then scan files, memory, or processes to see if they match. Think of it as grep for binary data — but with boolean logic, wildcards, regex, and a scoring system.

It's used everywhere:

VirusTotal uses YARA to tag samples.
MalwareBazaar and MISP distribute YARA rules alongside IOCs.
EDR and AV vendors embed YARA-style logic (or an equivalent) in their engines.
Incident responders drop YARA into Velociraptor, Loki, or THOR to sweep endpoints for known threats.

If you work in threat intel or DFIR, YARA is a baseline skill. For a broader overview of how YARA fits alongside Sigma and Suricata in a detection stack, this YARA rules guide covers the detection-triangle concept well.

Let's write a rule.

Anatomy of a YARA Rule

Every YARA rule has three parts (plus optional metadata):

rule RuleName
{
    meta:
        author = "you"
        description = "what it detects"
        date = "2024-01-01"

    strings:
        $a = "malicious string"
        $b = { 4D 5A 90 00 }        // hex
        $c = /regex[0-9]{3}/i        // regex

    condition:
        $a and $b
}

Key rules:

Rule names must start with a letter or underscore and contain only alphanumerics and underscores.
Strings start with $. You can have up to 10,000 of them per rule (but don't).
Condition is a boolean expression returning true or false.
Modifiers like nocase, wide, ascii, fullword change how strings match.

String types at a glance

Type	Example	Notes
Text	`$a = "cmd.exe"`	Case-sensitive by default
Text + `nocase`	`$a = "cmd.exe" nocase`	Case-insensitive
Wide	`$a = "cmd.exe" wide`	UTF-16LE — common in Windows binaries
Hex	`$a = { 4D 5A }`	Raw bytes, supports wildcards `??`
Regex	`$a = /https?:\/\/[a-z0-9.]+/i`	Slower than plain strings

Condition operators

Logical: and, or, not
Comparison: ==, !=, <, >, <=, >=
Counting: #a > 5 (string $a appears more than 5 times)
Size: filesize < 1MB
Location: $a at 0 (string is at offset 0)
Sets: any of them, all of ($a*), 2 of ($b*)

Writing Your First Rule: The EICAR Test File

EICAR is a harmless 68-byte string that AV engines intentionally flag as malware. It's perfect for a first rule because the signature is unambiguous.

The EICAR string is:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Create eicar.yar:

rule EICAR_Test_File
{
    meta:
        author = "dev.to reader"
        description = "Detects the EICAR antivirus test file"
        reference = "https://www.eicar.org/download-anti-malware-testfile/"
        date = "2024-11-01"

    strings:
        $eicar = "X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"

    condition:
        $eicar
}

Note the escaped backslashes: because YARA strings interpret \ as an escape character, a literal backslash must be \\.

Save the EICAR payload:

printf 'X5O!P%%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > sample.txt

Install YARA (Ubuntu/Debian):

sudo apt install yara

Run it:

yara eicar.yar sample.txt

Output:

EICAR_Test_File sample.txt

You just wrote and executed a detection rule. If it doesn't match, verify the file contents with xxd sample.txt — off-by-one characters are the usual culprit.

A More Realistic Example: Detecting WannaCry-Style Indicators

The EICAR rule is trivial. Real malware families require layered logic — anchoring on file structure, unique strings, and behavioral telltales.

WannaCry (2017) spread via EternalBlue (MS17-010), encrypted files with AES-128, and demanded Bitcoin payment. Its binary contains several distinctive artifacts. Even though AV coverage is universal now, it's a great teaching sample because its indicators are well-documented.

Here's a simplified rule inspired by public WannaCry detections:

rule WannaCry_Ransomware_Indicators
{
    meta:
        author = "dev.to reader"
        description = "Detects WannaCry-style dropper artifacts"
        reference = "https://www.cisa.gov/news-events/alerts/2017/05/12/wannacrypt-ransomware"
        date = "2024-11-01"
        tlp = "white"

    strings:
        // PE header
        $mz = { 4D 5A }

        // WannaCry kill switch domains (historical)
        $killswitch = "iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com" nocase
        $killswitch2 = "ifferfsodp9ifjaposdfjhgosurijfaewrwergwea.com" nocase

        // Ransom note filename
        $note = "@Please_Read_Me@.txt" nocase

        // Bitcoin wallet strings used in the original campaign
        $btc1 = "13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94"
        $btc2 = "12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw"

        // Tor client artifacts
        $tor = "taskdl.exe" nocase
        $tor2 = "taskse.exe" nocase

        // Encryption-related imports
        $crypto = "CryptEncrypt" ascii
        $crypto_w = "CryptEncrypt" wide

    condition:
        $mz at 0 and
        (2 of ($killswitch*) or
         $note or
         any of ($btc*) or
         (2 of ($tor*) and 1 of ($crypto*)))
}

Let's unpack the design choices:

$mz at 0 anchors the file as a PE. Without it, a text file quoting the BTC address would match — a textbook false positive.
nocase on domains catches case variations that survive string obfuscation.
any of ($btc*) uses wildcarded set matching, so adding more wallets later is cheap.
The condition is an OR of independent clusters. Malware mutates; requiring all indicators would miss variants. Requiring some combination balances recall and precision.
$crypto and $crypto_w handle both ASCII and UTF-16LE import tables; Windows API strings often appear in either form.

This rule is intentionally illustrative — production rules would also factor in entropy, PE section anomalies, and signed-certificate checks. For a broader writeup on building detection logic from threat intel feeds, the team at Riskitera's blog publishes hands-on analyses worth following if you want to see how rule authors source their indicators.

Test it against any WannaCry sample in a safe sandbox (never on a production host):

yara -r wannacry.yar /path/to/samples/

Flags you'll use often:

-r — recurse directories
-s — print matching strings (essential for tuning)
-w — disable warnings
-p N — parallel scan with N threads
-d name=value — define external variables

Example with string output:

yara -s wannacry.yar suspicious.exe

You'll see exactly which strings fired, which tells you whether the match is real or a coincidental string in an unrelated binary.

Best Practices for YARA Rule Quality

Writing a rule that matches once is easy. Writing one that survives in production for years is hard. These habits matter:

1. Anchor on file structure

Always include uint16(0) == 0x5A4D (MZ header) when targeting Windows executables. For scripts, anchor on shebangs. For documents, anchor on magic bytes.

condition:
    uint16(0) == 0x5A4D and
    filesize < 5MB and
    $unique_string

2. Prefer multiple short strings over one long one

Long strings break on trivial mutations. Four independent 8–15 byte strings joined by 3 of them are more robust.

3. Use `fullword` and `nocase` deliberately

fullword prevents cmd.exe from matching inside xcmd.exe. nocase triples performance cost in some engines — use when case obfuscation is realistic (domain names, CLI arguments), not for every string.

4. Beware of common strings

Strings like "This program cannot be run in DOS mode" and "kernel32.dll" appear in millions of benign files. Never condition on them alone. Combine with a filesize bound or a rare companion string.

5. Add metadata and TLP

Future-you will thank present-you. Include author, description, date, reference, hash (of the reference sample), and tlp. Most sharing platforms (MISP, OpenCTI, ThreatFox) parse these fields.

6. Test for false positives before publishing

Run your rule against a clean corpus — /usr/bin on Linux, C:\Windows\System32 on Windows — and confirm zero hits. A quick smoke test:

yara -r myrule.yar /usr/bin 2>/dev/null | head

If anything matches, inspect it with -s and tighten the condition.

7. Version your rules

Track changes in Git. Use semantic versioning on rule sets. A rule you tweak to catch variant B might silently stop catching variant A.

8. Use `include` and modules

YARA supports modules like pe, math, hash, and elf that expose parsed file metadata:

import "pe"
import "hash"

rule Suspicious_Packed_PE
{
    condition:
        pe.is_pe and
        pe.number_of_sections > 0 and
        for any section in pe.sections : (
            section.characteristics & pe.SECTION_MEM_EXECUTE and
            math.entropy(section.offset, section.size) > 7.0
        ) and
        hash.md5(0, filesize) != "d41d8cd98f00b204e9800998ecf8427e"
}

That's a real, generic heuristic: packed executables often exhibit high entropy in executable sections, which is a common sign of runtime unpacking.

Common Pitfalls and How to Avoid Them

Forgetting to escape backslashes. "C:\Windows" in YARA is a literal backslash followed by W. You want "C:\\Windows". Regex strings use different escaping.

Using $a without context in condition. YARA treats $a as "string defined AND found." If you write not $a, it returns true when $a is undefined — probably not what you meant. Use explicit #a == 0 for clarity.

Overusing regex. Regex is slow and error-prone. Prefer hex wildcards { 4D 5A ?? ?? 00 } for binary signatures and nocase strings for text.

Ignoring filesize. Limiting to filesize < 10MB often eliminates a huge class of false positives (archives, media files) without losing real matches.

Scanning the filesystem blindly. On production endpoints, scan only file types you can act on (executables, scripts, office docs) and exclude caches. Use -N to skip .git, node_modules, and the like.

Copying rules without attribution. Public rules from vendors and researchers carry licenses and TLP markings. Respect them.

Conclusion

YARA is a deceptively simple language that scales from one-line text matches to complex PE-aware heuristics. The path to competence is:

Write a trivial rule (EICAR) to learn syntax.
Model a real family (WannaCry) to learn layered conditions.
Test against clean corpora to build intuition for false positives.
Iterate with -s output to see why something matched.
Version and document so your rules survive the next analyst.

The tooling is straightforward: apt install yara, drop a .yar file, run yara rule.yar target. The craft is in the condition blocks. Start small, anchor on structure, and treat every rule as a hypothesis you have to falsify against a clean system before trusting it on an infected one.

Once you're comfortable, look into YARA-X (the Rust rewrite from VirusTotal), integrate rules into your SIEM or EDR, and pair them with behavioral detections. Static signatures catch known families; behavioral logic catches their mutations. You want both.

Deja de usar la IA como un buscador glorificado

David Moya — Fri, 11 Sep 2026 09:00:00 +0000

El 90 % de la gente usa ChatGPT como un buscador glorificado. Escribe una frase, espera una respuesta brillante y se decepciona cuando recibe generalidades.

No suele fallar el modelo. Falla el encargo.

Si le digo a una persona nueva en mi equipo «dame ideas para el negocio», tampoco puede adivinar qué vendo, a quién, con qué presupuesto ni para qué fecha necesito resultados. La IA parte con la misma desventaja, pero rellena los huecos con una seguridad que hace parecer útil una respuesta mediocre.

La buena noticia es que corregirlo no exige programar. Exige aprender a dar un buen brief.

El antes y el después

Este es el tipo de prompt que veo cada día:

Dame ideas para mi negocio.

La respuesta será una lista intercambiable: publicar en redes, crear una newsletter, colaborar con influencers. Podría servir para una cafetería, una consultora o una tienda de zapatos.

Ahora prueba esto:

Eres un consultor senior de estrategia con 15 años de
experiencia en SaaS B2B.

Contexto: vendemos software de control horario a empresas
españolas de 20 a 100 empleados. Facturamos 18.000 EUR al mes,
el 70 % de los leads llega por Google Ads y el churn mensual es
el 4 %. Tenemos dos desarrolladores y una persona de marketing.

Tarea: propón tres iniciativas para crecer durante los próximos
90 días sin aumentar el gasto publicitario.

Para cada iniciativa incluye impacto esperado, esfuerzo,
principal riesgo y primera acción esta semana.

Formato: tabla. Máximo 500 palabras. No propongas abrir nuevos
países ni contratar personal.

No hay magia. He añadido rol, contexto, tarea, formato y restricciones. La IA ya no necesita inventar el escenario y puede dedicar su capacidad a resolverlo.

Los siete componentes de un prompt profesional

Yo uso una lista de siete componentes. No incluyo siempre los siete, pero los reviso antes de enviar una petición importante.

Rol. Desde qué especialidad debe abordar el problema.
Contexto. Qué necesita saber sobre la empresa, audiencia o situación.
Tarea. Una acción concreta expresada con un verbo.
Formato. Tabla, lista, email, JSON o cualquier salida que pueda usar directamente.
Restricciones. Límites de longitud, alcance, presupuesto o temas prohibidos.
Ejemplos. Muestras de lo que consideras correcto.
Tono. El registro que necesita la audiencia.

Una plantilla reutilizable evita empezar desde cero:

Rol: actúa como [perfil y experiencia relevante].

Contexto:
- Empresa/proyecto: [datos]
- Audiencia: [quién recibirá el resultado]
- Objetivo: [qué decisión o acción debe facilitar]

Tarea: [un verbo + un entregable concreto].

Formato: [estructura exacta].
Restricciones: [límites y exclusiones].
Tono: [registro].

Antes de responder, indica qué dato crítico falta. Si no falta
ninguno, entrega directamente el resultado.

La última frase es útil porque evita que el modelo finja precisión cuando el encargo está incompleto.

Los ejemplos enseñan mejor que los adjetivos

Pedir «un texto profesional y cercano» deja mucho margen. Dos ejemplos reales definen mejor el patrón que diez adjetivos. Esta técnica se llama few-shot prompting.

Imagina que quiero clasificar tickets de soporte. En vez de describir durante un párrafo cada categoría, muestro decisiones anteriores:

Clasifica cada ticket como FACTURACIÓN, SOPORTE o VENTA.

Ejemplos:
"Necesito cambiar el CIF de la factura" -> FACTURACIÓN
"La exportación CSV se queda al 80 %" -> SOPORTE
"¿Tenéis precio para 40 usuarios?" -> VENTA

Ticket nuevo:
"Nos han cobrado dos veces la renovación"

Responde solo con la categoría y una frase de justificación.

El modelo ve el formato, las etiquetas válidas y el criterio. Esto mejora especialmente tareas repetitivas: clasificar solicitudes, adaptar titulares, extraer campos o mantener una voz editorial.

Una tarea por prompt

Otro error habitual es pedir investigar, decidir, redactar y maquetar en una sola instrucción. Cuantas más operaciones mezclo, menos control tengo sobre cada una.

Para una propuesta comercial prefiero tres pasos:

PASO 1
Analiza este briefing y extrae en una tabla: problema,
resultado deseado, requisitos, restricciones, dudas abiertas y
criterios de compra. No redactes aún la propuesta.

BRIEFING:
[pegar texto]

Reviso la tabla y corrijo cualquier interpretación equivocada. Después pido el esquema de la propuesta. Solo cuando ese esquema es correcto solicito la redacción final. Este encadenamiento tarda unos minutos más que el mega-prompt, pero ahorra rehacer un documento entero.

Cómo mejoro un prompt que ya existe

No intento escribir el prompt perfecto a la primera. Uso la propia IA como revisora, sin delegarle la decisión final:

Evalúa el prompt siguiente antes de ejecutarlo.

PROMPT:
[pegar prompt]

Detecta:
1. Ambigüedades que obliguen a hacer suposiciones.
2. Contexto que falte.
3. Conflictos entre instrucciones.
4. Un formato de salida más útil.

Después escribe una versión mejorada. No inventes datos: marca
cada dato necesario como [POR COMPLETAR].

La clave está en revisar las marcas [POR COMPLETAR]. Si permito que el modelo complete esos datos, vuelvo al punto de partida: una respuesta elegante construida sobre suposiciones.

Mi regla práctica

Antes de pulsar Enter me hago una pregunta: ¿una persona competente que acaba de llegar al equipo podría ejecutar este encargo sin preguntarme nada esencial?

Si la respuesta es no, añado contexto. Si no sabría cuándo ha terminado, aclaro la tarea. Si podría entregar algo que no puedo usar, especifico el formato. Si existen límites reales, los escribo.

Eso es prompting profesional. No consiste en memorizar palabras secretas ni en escribir instrucciones kilométricas. Consiste en reducir ambigüedad y convertir una intención difusa en un encargo verificable.

En IAcademy hemos organizado esta habilidad dentro de 290 módulos y 23 especializaciones. Los Founding Members pueden entrar desde 19 EUR —Itinerario 19, Pro 99 y Pro+Mentoría 249— con el precio bloqueado hasta el 15 de octubre de 2026. La garantía es de 30 días o de 5 horas ahorradas.

Si quieres ir más allá

Puedes empezar con los recursos gratuitos y ver los planes Founding. Elige un proceso real de esta semana y mejora ese prompt antes de aprender otra técnica.

Curso interactivo de HTTP: guía completa

David Moya — Fri, 11 Sep 2026 07:30:05 +0000

Cuando un agente de inteligencia artificial consulta una herramienta, una aplicación llama a una API o un navegador solicita una página, HTTP suele convertir la intención en una operación concreta. El curso Básicos HTTP interactivo ayuda a entender ese contrato sin reducirlo a una lista de verbos y códigos.

El recorrido comienza con un mapa del ecosistema. Conecta agente de usuario, URI, origen, transporte, petición, cabeceras, intermediarios, caché, servidor y respuesta. También incorpora las políticas del navegador y la superficie de ataque. Esa visión es útil porque muchos errores atribuidos a «la API» pertenecen en realidad a DNS, TLS, una CDN, una regla de caché o una cabecera aceptada fuera de su frontera de confianza.

Después, una ruta de siete pasos sigue la petición desde la preparación de la URI hasta la aplicación de CORS, cookies y CSP en el navegador. La anatomía del mensaje distingue línea inicial, campos, contenido, respuesta y versiones. HTTP/1.1, HTTP/2 y HTTP/3 conservan la semántica, aunque cambien el framing, la multiplexación y el transporte.

El laboratorio es el centro práctico. Permite cargar y editar una petición o respuesta cruda. El analizador reconoce método, objetivo, versión, estado, cabeceras y cuerpo; después señala problemas de caché, cookies y seguridad. Detecta, entre otros casos, Content-Length duplicado, Transfer-Encoding junto a Content-Length, cookies sin atributos defensivos, CORS peligroso, cabeceras Forwarded, falta de Host y ausencia de HSTS o CSP.

El curso también presenta ocho riesgos frecuentes y un quiz de cinco preguntas con corrección inmediata. La evaluación cubre GET, 304, request smuggling, multiplexación de HTTP/2 y Vary. La preferencia de tema se conserva, pero el progreso del quiz no persiste tras recargar, una distinción importante al describir exactamente la experiencia.

El valor pedagógico está en relacionar elementos. Cache-Control no se estudia solo: se contrasta con Authorization, Set-Cookie, ETag y Vary. CORS no se confunde con autorización. TLS protege el tránsito, pero no corrige una política de caché pública ni una cookie accesible desde JavaScript. Forwarded puede describir el cliente original, aunque solo resulta confiable cuando un proxy controlado elimina el valor entrante y lo reconstruye.

Una forma útil de estudiar el recurso es predecir antes de pulsar «Analizar». Se puede eliminar Host de la petición, duplicar Content-Length con valores distintos o retirar Secure de la cookie de respuesta. Al cambiar una sola condición cada vez, la advertencia deja de ser teoría y se convierte en una relación visible entre configuración y riesgo. Después conviene llevar ese mismo método a una traza real, siempre eliminando tokens y datos privados. El objetivo no es memorizar todas las RFC, sino saber dónde mirar y cómo separar semántica, transporte, navegador e infraestructura.

Para profesionales de IA, la lección es directa: un token en Authorization, un 429, una redirección o una respuesta privada almacenada en una caché compartida cambian el comportamiento y la seguridad del sistema. HTTP no es simple fontanería. Es parte del contrato, del modelo de confianza y del diagnóstico.

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-http/

Curso interactivo de HTTP y HTTPS: TLS en la práctica

David Moya — Fri, 11 Sep 2026 07:30:00 +0000

HTTPS protege el canal, no la aplicación

He analizado a fondo Básicos HTTP/S, un curso interactivo que enseña HTTP y HTTPS desde lo básico hasta nivel profesional. Su modelo mental de partida condensa todo: HTTP define mensajes. TLS protege el canal. HTTPS une ambos.

El curso recorre el ecosistema completo con un mapa conceptual interactivo de trece nodos (incluido, acertadamente, el atacante en la ruta) y un simulador de nueve pasos que sigue la vida de una petición: URL y origen, resolución DNS, transporte TCP o QUIC, handshake TLS, validación de certificado, negociación ALPN, solicitud cifrada, respuesta con políticas y caché del navegador.

Lo más útil es el laboratorio local: introduces una URL, el estado TLS observado, el estado del certificado y un bloque de cabeceras, y un motor de análisis que corre íntegramente en tu navegador evalúa esquema, HSTS, redirecciones de downgrade, cookies sin Secure o HttpOnly, Cache-Control en rutas sensibles, CORS incompatible con credenciales y Alt-Svc con HTTP/3. Todo sin enviar un byte a ningún servidor.

Completan el conjunto un checklist ponderado de ocho señales de riesgo (login por HTTP: 30 puntos; error de certificado aceptado: 28; redirección a http://: 24...), un quiz autocorregido de ocho preguntas con explicación, quince referencias RFC/IANA filtrables y un glosario esencial.

Para quien trabaja con IA, el ángulo es directo: cada vez que un agente llama a una API de terceros, la clave y los datos viajan en mensajes HTTP. Un certificado autofirmado puede cifrar, pero no autentica. Un token en la query string acaba en logs e historial aunque el canal vaya cifrado. Y desactivar la verificación de certificados "solo en desarrollo" es exactamente el fallo que este curso enseña a no cometer.

Detalle técnico que aprecio: la app es código abierto, HTML/CSS/JS plano sin frameworks ni build, con escapeHtml aplicado a todo el contenido dinámico — un curso de seguridad web que se protege a sí mismo de inyección de HTML.

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-https/

Curso interactivo de email: SPF, DKIM y DMARC

David Moya — Thu, 10 Sep 2026 07:30:06 +0000

El correo es infraestructura, no solo una interfaz

Pulsamos «Enviar» y parece que el mensaje salta de una aplicación a otra. En realidad intervienen un cliente MUA, un servidor de submission MSA, uno o varios MTA, consultas DNS, un agente de entrega MDA y el buzón final. El curso interactivo Básicos Email convierte esa cadena invisible en un mapa que se puede explorar y en una simulación de siete pasos.

La lección más importante es separar el mensaje RFC 5322 del sobre SMTP. El From visible pertenece al mensaje; MAIL FROM pertenece al sobre y se utiliza para rebotes y SPF. Por eso spf=pass no significa automáticamente que el dominio mostrado al usuario sea auténtico. DKIM añade una firma verificable sobre cabeceras y cuerpo. DMARC conecta esos resultados con el dominio del From mediante alineación y permite publicar una política.

El curso no se limita a definiciones. Su laboratorio permite pegar cabeceras o cargar una muestra con Return-Path, Received, Authentication-Results, From, Reply-To, Message-ID y Content-Type. El análisis ocurre localmente en el navegador. Señala ausencias, discrepancias de dominios, resultados de SPF, DKIM y DMARC, número de saltos y presencia de ESMTPS. Son pistas orientativas, no un veredicto forense.

También propone una evaluación de phishing que combina nombre visible, dominios parecidos, Reply-To distinto, fallos de autenticación, urgencia, enlaces engañosos, adjuntos peligrosos y rutas Received incoherentes. El enfoque es acertado: ninguna señal aislada basta. Incluso un DKIM válido puede firmar contenido malicioso, y DMARC no detecta dominios visualmente similares ni analiza adjuntos.

Para quienes construimos agentes de IA, este conocimiento es operacional. El agente puede generar contenido y conectarse a un proveedor, pero alguien debe autorizar la fuente en SPF, habilitar DKIM y asegurar que al menos un mecanismo se alinee con el From para DMARC. Cambiar de proveedor o subdominio obliga a revisar esa cadena. La automatización amplifica tanto los aciertos como los errores de configuración.

La experiencia está construida con HTML, CSS y JavaScript plano, sin backend ni instalación. Incluye ocho preguntas autocorregidas con explicación inmediata. No guarda progreso: la puntuación vive en memoria; solo persiste la preferencia de tema. Es un recurso directo para pasar de «el correo llega» a entender por qué llega, qué identidad acredita y qué revisar cuando algo parece sospechoso.

Lee el artículo completo en IAcademy

Lee el artículo completo en IAcademy: https://iacedemy.com/blog/curso-interactivo-email/

DEV Community: David Moya

Practical Malware Analysis: Still the #1 Book in 2026?

What the Book Covers

The 60+ Labs Are the Real Value

What's Timeless

What's Outdated

Should You Read It?

La IA inventa datos: así detecto alucinaciones antes de usarlas

Qué aspecto tiene una alucinación

Técnica 1: separar hechos, inferencias y dudas

Técnica 2: convertir la respuesta en una lista de comprobación

Técnica 3: pedir una revisión adversarial

Un flujo concreto para investigar

Señales que me hacen parar

La regla depende del riesgo

Si quieres ir más allá

Why Windows Internals by Russinovich Is Essential for Malware Analysts

What This Book Is (and Is Not)

The Chapters That Matter Most for Malware Analysis

Must-read (Part 1)

Read when needed (Part 2)

How to Actually Apply It

1. Process hollowing (CreateProcess + WriteProcessMemory)

2. Token manipulation

3. Memory forensics

Sysinternals: The Companion Toolkit

The Honest Downsides

Verdict

Curso interactivo de APIs: de base a nivel profesional

Lo que cubre

Por qué me importa desde el lado de la IA

Curso interactivo de firewalls: análisis en profundidad

Un firewall no protege por magia: aplica política sobre tráfico observable

Lo que lo hace diferente

Por qué importa si trabajas con IA

Construcción

Modelo OSI: guía interactiva de las 7 capas

Del «no conecta» a una hipótesis comprobable

Seguridad en sistemas IA: el curso Basic Seguridad IA, a fon

Qué cubre

Normativa incluida

YARA Rules for Beginners: Writing Your First Malware Detection Signature

YARA Rules for Beginners: Writing Your First Malware Detection Signature

What Is YARA and Why Should You Care?

Anatomy of a YARA Rule

String types at a glance

Condition operators

Writing Your First Rule: The EICAR Test File

A More Realistic Example: Detecting WannaCry-Style Indicators

Best Practices for YARA Rule Quality

1. Anchor on file structure

2. Prefer multiple short strings over one long one

3. Use fullword and nocase deliberately

4. Beware of common strings

5. Add metadata and TLP

6. Test for false positives before publishing

7. Version your rules

8. Use include and modules

Common Pitfalls and How to Avoid Them

Conclusion

Deja de usar la IA como un buscador glorificado

El antes y el después

Los siete componentes de un prompt profesional

Los ejemplos enseñan mejor que los adjetivos

Una tarea por prompt

Cómo mejoro un prompt que ya existe

Mi regla práctica

Si quieres ir más allá

Curso interactivo de HTTP: guía completa

Curso interactivo de HTTP y HTTPS: TLS en la práctica

HTTPS protege el canal, no la aplicación

Curso interactivo de email: SPF, DKIM y DMARC

El correo es infraestructura, no solo una interfaz

3. Use `fullword` and `nocase` deliberately

8. Use `include` and modules