Estructura Interna de Ejecutables ELF (Linux) y PE (Windows): Tablas PLT/GOT, Imports y Entropía de Shannon

1. Disección Forense de Secciones y Segmentos en un Binario

Todo ejecutable nativo en Linux (ELF - Executable and Linkable Format) o Windows (PE - Portable Executable) separa código, datos y tablas de enlace dinámico: - .text: Instrucciones de máquina ejecutables (r-x). - .rodata / .data / .bss: Constantes de solo lectura, variables globales inicializadas y no inicializadas (rw-). - PLT (Procedure Linkage Table) & GOT (Global Offset Table) / IAT (Import Address Table): Mecanismo de resolución de funciones externas de libc o kernel32.dll. Auditar la tabla de importaciones revela de inmediato las capacidades de un binario sospechoso (ej. VirtualAllocEx, WriteProcessMemory, CreateRemoteThread indican inyección de procesos; memfd_create indica ejecución fileless en memoria).

2. Detección Matemática de Binarios Empaquetados o Cifrados (Packed Malware) vía Entropía de Shannon

Calculamos la entropía de información de Shannon $H(X) \in [0, 8]$ bits por byte sobre cada sección del binario:

$H(X) = -\sum_{i=0}^{255} P(b_i) \log_2 P(b_i)$

- Código nativo compilado normal (.text): $H \in [5.2, 6.4]$. - Sección comprimida (UPX) o payload cifrado AES/XOR: Distribución casi uniforme de bytes con $H > 7.20$ y ausencia casi total de funciones en la tabla de importación (excepto LoadLibraryA y GetProcAddress para reconstruir la IAT en memoria).'

Ingeniería Inversa con Ghidra/Radare2: Grafos de Flujo de Control (CFG) y Reglas YARA de Alta Precisión

1. De Ensamblador x86_64 / ARM64 a Representación Intermedia (P-Code) y Reglas YARA

Las firmas basadas en hashes estáticos (SHA-256) son trivialmente evadibles cambiando un solo bit del binario. Las Reglas YARA de Grado Forense combinan condiciones sobre la estructura del encabezado PE/ELF, secuencias de opcodes con comodines de registros y patrones de constantes criptográficas:

import "elf"
import "math"
rule Linux_Fileless_Memfd_Dropper_Strict {
    meta:
        author = "Principal Threat Research"
        severity = "CRITICAL"
    strings:
        $sys_memfd = "memfd_create" ascii
        $proc_self = "/proc/self/fd/" ascii
        $opcode_syscall = { 48 C7 C0 3F 01 00 00 0F 05 } // mov rax, 319 (sys_memfd_create); syscall
    condition:
        uint32(0) == 0x464C457F and
        ( ($sys_memfd and $proc_self) or $opcode_syscall ) and
        math.entropy(0, filesize) >= 6.8
}

Análisis Dinámico en Sandboxes Aislados (MicroVMs), Desempacado en Memoria y Técnicas Anti-Evasión

1. Cómo el Malware Moderno Detecta Sandboxes y Cómo Neutralizarlo

El malware avanzado ejecuta comprobaciones de entorno antes de descifrar su payload en memoria: 1. Inspección de Hipervisor y Hardware: Instrucción CPUID buscando cadenas KVMKVMKVM o VMware, conteo de núcleos $< 2$, RAM $< 4\text{ GB}$ o MAC addresses de proveedores virtuales. 2. Evasión Temporal (Time-Bombing / Fast-Forward Detection): Ejecuta sleep(600000) y verifica mediante la instrucción de procesador RDTSC (Read Time-Stamp Counter) o consulta NTP si el sandbox aceleró artificialmente la llamada sleep. 3. Volcado del Payload Desempaquetado (Memory Dumping): Interceptando la transición desde el stub desempacador hacia el OEP (Original Entry Point) cuando la memoria cambia de permisos RW a RX (mprotect / VirtualProtect), extraemos el binario limpio directamente de la RAM para su análisis estático.

Vectores de Ataque a la Cadena de Suministro: Dependency Confusion, Typosquatting y Compromiso de Build

1. Anatomía del Ataque de Dependency Confusion (Alex Birsan)

Si una organización utiliza un paquete interno privado @corp/auth-core o corp-internal-utils con versión 1.2.0 y el gestor de paquetes (pip, npm, mvn) está configurado para consultar tanto el registro privado como el registro público oficial: - Un atacante registra el mismo nombre en el repositorio público con versión 99.0.0. - El resolvedor de dependencias elige la versión superior (99.0.0) del repositorio público y ejecuta su script postinstall dentro de los servidores de CI/CD de la empresa.

Mitigación Determinista: 1. Reservar el namespace/scope en el registro público y configurar el proxy de artefactos interno (Artifactory / Nexus) para bloquear la resolución pública de cualquier prefijo interno. 2. Exigir Lockfiles Inmutables con Verificación Criptográfica de Hash SHA-512 (pnpm install --frozen-lockfile, pip install --require-hashes).

Estándar SLSA (Niveles 1 a 3), Atestaciones in-toto, SBOM (CycloneDX/SPDX) y Documentos VEX

1. Garantía de Procedencia No Falsificable con SLSA Build Level 3

flowchart LR
    GIT["Commit Firmado (Git SHA)"] --> BUILD["Runner Efímero Aislado (SLSA L3)"]
    BUILD --> ART["Imagen OCI Compilada (Digest sha256:8f9a...)"]
    BUILD --> SBOM["SBOM CycloneDX JSON + VEX"]
    BUILD --> PROV["Atestación SLSA Provenance (in-toto JSON)"]
    PROV --> SIG["Firma Keyless Sigstore Cosign + Registro en Rekor Transparency Log"]

- SBOM (Software Bill of Materials - CycloneDX / SPDX): Inventario completo del árbol de dependencias transitivas con sus hashes criptográficos y coordenadas purl. - VEX (Vulnerability Exploitability eXchange): Atestación firmada que declara si una CVE presente en una librería transitiva es realmente explotable o no alcanzable (Not Affected - Vulnerable code not in execute path), eliminando el $85\%$ de falsos positivos de escáneres de contenedores.

Firma Criptográfica sin Claves Largas (Keyless Signing): Sigstore Cosign, Fulcio CA, Rekor y Admisión K8s

1. Por Qué Guardar Claves Privadas PGP/RSA en Variables de CI/CD Es un Riesgo Crítico

Si almacenas una clave privada estática de firma en los secretos de CI/CD, cualquier filtración obliga a revocar todas las imágenes pasadas. Sigstore (Cosign + Fulcio + Rekor) elimina las claves privadas permanentes mediante Keyless Signing con OIDC: 1. El pipeline de CI solicita un token OIDC de corta vida (5 minutos) que prueba criptográficamente qué repositorio, rama y workflow está ejecutándose. 2. Cosign genera un par de claves efímero en RAM; la autoridad certificadora Fulcio emite un certificado X.509 válido por 10 minutos vinculado a la identidad OIDC. 3. Cosign firma el digest sha256 de la imagen y registra la prueba en el libro mayor inmutable de árbol de Merkle Rekor, destruyendo inmediatamente la clave privada de la RAM. 4. En Kubernetes, el Admission Controller (Kyverno / Sigstore Policy Controller) rechaza cualquier Pod cuya imagen no esté referenciada por @sha256:... y firmada en Rekor por el workflow oficial.

Reducción de la Superficie del Kernel Linux: Capabilities Mínimas, Seccomp-BPF y Archivos Inmutables

1. De 350+ Syscalls del Kernel Linux a una Lista Blanca Estricta con Seccomp-BPF

La mayoría de los exploits de escalada de privilegios y escape de contenedor (Container Escape) abusan de llamadas al sistema exóticas (keyctl, unshare, ptrace, userfaultfd, bpf, mount).

Un perfil de seguridad de producción para cualquier microservicio aplica: 1. allowPrivilegeEscalation: false y readOnlyRootFilesystem: true (impide que un atacante descargue y escriba un binario malicioso en el contenedor). 2. capabilities: { drop: ["ALL"] } (elimina incluso CAP_NET_RAW para impedir spoofing ARP/ICMP). 3. Perfil Seccomp-BPF Estricto: Un filtro Berkeley Packet Filter adjunto al proceso que intercepta cada número de syscall en el kernel y devuelve EPERM (o mata el hilo con SECCOMP_RET_KILL_PROCESS) ante cualquier syscall fuera de las $\approx 45$ requeridas por la aplicación.

Detección y Bloqueo en el Kernel con eBPF (Cilium Tetragon / Falco): Frenando Ataques Fileless en Vivo

1. Por Qué los Agentes en Espacio de Usuario o LD_PRELOAD Son Evadidos y eBPF en el Kernel No

Un atacante que logra ejecución remota de código (RCE) puede usar binarios estáticos para evadir LD_PRELOAD o saturar el buffer de eventos asíncronos. Cilium Tetragon engancha programas eBPF verificados directamente en los hooks internos del kernel Linux (LSM - Linux Security Modules y kprobes): - Enforcement Síncrono In-Kernel (Sigkill antes de que la syscall retorne): Si un proceso Node.js o Java intenta invocar execve("/bin/sh") o leer un socket fuera de su política, o abrir /etc/shadow, el programa eBPF envía SIGKILL directamente desde el contexto del kernel antes de que la instrucción maliciosa llegue a completarse, reduciendo la ventana de explotación a 0 milisegundos.'

Aislamiento de Cargas No Confiables: gVisor (User-Space Kernel) y MicroVMs con AWS Firecracker (KVM)

1. Cuando los Contenedores Estándar No Bastan (Ejecución de Código de Terceros / AI Code Sandboxes)

Los contenedores Docker/containerd estándar comparten el mismo kernel Linux del host. Si ejecutas código enviado por usuarios o generado por agentes de IA, una sola vulnerabilidad 0-day en el kernel permite escapar al nodo físico. - gVisor (runsc): Intercepta todas las syscalls de la aplicación en un kernel escrito en Go en espacio de usuario (Sentry), exponiendo solo $\approx 20$ syscalls al host. - AWS Firecracker (MicroVMs KVM): Levanta una máquina virtual ligera con su propio mini-kernel aislado por virtualización de hardware (VT-x / AMD-V) en $< 125\text{ ms}$ con apenas $5\text{ MB}$ de sobrecarga de memoria.

Forense de Contenedores Comprometidos: Checkpoint de Memoria (CRIU) Sin Destruir la Evidencia Volátil

Ante una alerta de ejecución fileless en un pod, matar o reiniciar el contenedor destruye el malware que reside únicamente en la RAM. El playbook forense aplica primero una NetworkPolicy de aislamiento total (Quarantine Egress/Ingress Deny-All) e invoca kubelet checkpoint (basado en CRIU) para congelar y exportar la imagen completa de la memoria RAM y descriptores de archivo hacia un bucket forense inmutable.

Laboratorio Práctico: Detección Forense de Binarios Empaquetados (Alta Entropía) y Sin Firma Sigstore

Contexto del Desafío de SecOps & Malware Analysis

Nuestro escáner de admisión de artefactos ha inspeccionado los binarios ELF contenidos en las imágenes antes del despliegue y volcó los resultados en la tabla binary_forensics_scan: - artifact_name (TEXT) - shannon_entropy (NUMERIC(4,2): entropía de Shannon medida en bits por byte, de 0.00 a 8.00) - imported_symbols_count (INTEGER: cantidad de funciones en la tabla de importación dinámica) - sigstore_verified (INTEGER: 1 si posee firma Cosign válida en Rekor, 0 si no está firmado)

Un binario se clasifica como sospechoso de empaquetado/cifrado o compromiso de cadena de suministro si: - Su shannon_entropy >= 7.20, O BIEN - sigstore_verified = 0.

Objetivo de la Consulta SQL

Evaluación de Certificación: SEC-601

Comprueba tu dominio de análisis de binarios ELF/PE, entropía de Shannon, firma Keyless con Sigstore y seguridad en kernel con eBPF/Seccomp.