1.3 Principios operacionales irrenunciables
Hay principios que no son negociables. No dependen de tu nivel de amenaza ni de tu adversario concreto. Son las reglas que aplicas siempre, en toda operación, sin excepciones — porque las excepciones son exactamente donde ocurren los compromisos.
1.3.1 Compartimentalización radical (need-to-know real)
La compartimentalización es el principio de aislar operaciones, identidades, sistemas e información en compartimentos estancos — de forma que el compromiso de uno no afecte a los demás. Es el principio más fundamental del OPSEC y el que más se viola en la práctica.
El término viene de la arquitectura naval: los barcos se construyen con compartimentos herméticos separados por mamparas. Si entra agua en uno, los demás se mantienen intactos. El barco no se hunde. Aplicado a operaciones: si un compartimento es comprometido, los demás permanecen seguros.
Need-to-know real
El principio need-to-know significa que nadie — ninguna persona, ningún sistema, ninguna herramienta — accede a información que no necesita para cumplir su función específica. No "probablemente no la necesita". No "podría ser útil algún día". Si no la necesita ahora para esta tarea concreta, no la tiene.
La palabra clave es real. El need-to-know se viola constantemente de formas que parecen razonables en el momento:
- "Le cuento a X lo que estoy haciendo por si acaso": X ahora es un punto de exposición. Si X es comprometido, coaccionado o simplemente indiscreto, tu operación está en riesgo.
- "Uso el mismo servidor para dos proyectos para ahorrar": si uno de los proyectos es comprometido, el adversario tiene acceso al servidor entero y a todos sus proyectos.
- "Dejo las credenciales del cliente A en el mismo gestor que las del cliente B": una sola brecha en el gestor compromete ambos clientes.
- "Le doy acceso de administrador porque es más cómodo": si esa cuenta es comprometida, el adversario tiene acceso total.
Las cuatro dimensiones de la compartimentalización
| Dimensión | Qué se compartimenta | Implementación práctica |
|---|---|---|
| Operaciones | Cada engagement, proyecto u operación | VPS dedicado, identidad dedicada, dispositivo dedicado (o VM dedicada) por operación |
| Identidades | Cada alias o perfil que usas | Dispositivo o perfil de navegador separado, email único, nunca cruzar entre identidades |
| Información | Datos sensibles de cada contexto | Base de datos KeePass separada por identidad, volúmenes VeraCrypt independientes |
| Personas | Colaboradores, contactos, equipos | Cada persona sabe solo lo necesario para su rol. Sin briefings globales innecesarios. |
Los fallos de compartimentalización más comunes
En la práctica, la compartimentalización falla por tres razones principales:
- Comodidad: mantener compartimentos separados requiere más esfuerzo que trabajar en uno solo. La tentación de "solo esta vez uso el mismo dispositivo" es constante — y cada excepción debilita el sistema.
- Confianza excesiva: "Confío en X, así que no importa que sepa todo." La confianza es irrelevante para el OPSEC. X puede ser comprometido, coaccionado, engañado o simplemente cometer un error. La compartimentalización protege tanto a X como a ti.
- Fatiga de gestión: mantener múltiples identidades, múltiples dispositivos y múltiples conjuntos de credenciales es cognitivamente costoso. La solución no es reducir los compartimentos — es construir sistemas y hábitos que hagan la gestión más llevable.
Implementación mínima recomendada
1.3.2 Principio del menor privilegio en tus propias operaciones
El principio del menor privilegio (Principle of Least Privilege, PoLP) es un concepto clásico de seguridad informática: cada usuario, proceso o sistema debe tener acceso únicamente a los recursos y permisos estrictamente necesarios para cumplir su función, y nada más.
En seguridad defensiva se aplica a sistemas y usuarios. En OPSEC del operador se aplica a ti mismo y a tus propias operaciones. La pregunta no es "¿qué acceso podría necesitar?" sino "¿qué acceso necesito específicamente para completar este objetivo concreto?"
Aplicaciones del PoLP al operador
En el contexto del operador, el principio del menor privilegio se aplica en múltiples niveles:
Privilegios en el sistema objetivo:
- No escalar a SYSTEM/root si no es necesario: si el objetivo es leer un archivo en un directorio concreto, no necesitas privilegios de administrador. Escalar innecesariamente aumenta la huella, activa más detecciones y amplía el daño potencial si eres detectado.
- No comprometer más sistemas de los necesarios: el objetivo del engagement determina el alcance. Comprometer sistemas adicionales "porque puedes" es OPSEC deficiente y trabajo deficiente.
- No persistir más tiempo del necesario: cada minuto que un implante está activo es un minuto más de exposición. Cuando el objetivo está completado, limpia y sal.
Privilegios en tu propia infraestructura:
- No uses root para tareas que no lo requieren: opera con usuario no privilegiado y eleva solo cuando sea necesario. Un error de configuración o un exploit en una herramienta que usas como root tiene consecuencias mucho mayores.
- No des acceso a tus servidores a más personas de las necesarias: cada persona con acceso es un vector de compromiso adicional.
- Segmenta los permisos de tus herramientas: una herramienta de escaneo no necesita acceso a tus credenciales de VPS. Un script de automatización no necesita acceso a tus claves PGP.
Privilegios de información:
- No recopilas datos que no necesitas: en una operación, si encuentras credenciales que no son relevantes para el objetivo, no las almacenas. Cada dato que recopilas es un dato que puedes perder.
- No compartes más información de la necesaria en reportes: el cliente necesita saber qué vulnerabilidades encontraste y cómo remediarlas — no necesita los detalles completos de cada credencial comprometida.
El concepto de radio de daño (blast radius)
El principio del menor privilegio está directamente relacionado con el concepto de blast radius: el radio de daño máximo que puede causar un compromiso. Si operas siempre con privilegios mínimos, un compromiso — de tu cuenta, de tu herramienta, de tu servidor — tiene un impacto limitado y contenido. Si operas con privilegios máximos "por comodidad", un compromiso puede ser catastrófico.
Implementación práctica
## ANTES DE CADA ACCIÓN, PREGUNTA:
¿Necesito este nivel de acceso para ESTA tarea?
→ Si la respuesta es no: reduce los privilegios
¿Necesito acceder a ESTE sistema para este objetivo?
→ Si la respuesta es no: no lo toques
¿Necesito GUARDAR estos datos para completar el objetivo?
→ Si la respuesta es no: no los almacenes
¿Cuánto tiempo necesito estos privilegios/acceso?
→ Revoca o cierra en cuanto termines, no antes ni después
## SEÑALES DE ALARMA (PoLP violado):
✗ Operando como root cuando un usuario normal bastaría
✗ Implante activo semanas después de completar el objetivo
✗ Credenciales almacenadas que no son relevantes al engagement
✗ Servicios expuestos "por si acaso" que no se están usando
✗ Más personas con acceso del necesario a la infraestructura
1.3.3 Segregación de identidades: nunca mezclar contextos
La segregación de identidades es el principio que establece que cada contexto operacional debe tener su propia identidad digital completamente independiente de las demás. Una identidad para tu vida personal. Una identidad para tu trabajo como consultor. Una identidad por cada operación sensible. Y entre ellas, cero puntos de contacto.
No es paranoia. Es arquitectura. Del mismo modo que un arquitecto diseña paredes cortafuegos en un edificio para que el fuego no se propague entre plantas, el operador diseña identidades separadas para que el compromiso de una no se propague a las demás.
Qué debe estar completamente separado
Dos identidades están verdaderamente segregadas cuando ninguno de los siguientes elementos es compartido entre ellas:
- Dispositivo o perfil de navegador: operar dos identidades desde el mismo dispositivo, aunque sea en pestañas diferentes, crea riesgo de contaminación por fingerprinting, cookies, caché y comportamiento del sistema
- Dirección IP: si ambas identidades se conectan desde la misma IP — aunque sea una VPN — pueden ser correlacionadas por tiempo de conexión y patrones de uso
- Email o cuenta de recuperación: el email de registro de una identidad no puede tener ninguna relación con el email de otra
- Número de teléfono: ni para verificación SMS ni para recuperación de cuenta
- Método de pago: si pagas la infraestructura de una identidad con el mismo método que otra, están vinculadas financieramente
- Estilo de escritura: la estilometría puede vincular a un autor entre identidades si el patrón lingüístico es consistente
- Horarios de actividad: si ambas identidades son siempre activas en el mismo horario y zonas horarias, pueden correlacionarse
- Nicknames o referencias cruzadas: nunca mencionar una identidad desde otra, ni siquiera de forma implícita
Cómo se vinculan las identidades sin que te des cuenta
Los puntos de contacto entre identidades raramente son obvios. Los más peligrosos son los que parecen inocuos:
| Vector de vinculación | Cómo ocurre | Cómo evitarlo |
|---|---|---|
| Browser fingerprint | Mismo navegador con mismas extensiones, resolución y configuración identifica al usuario aunque cambies de cuenta | Perfil de navegador separado por identidad, o navegador distinto (Tor Browser para alta sensibilidad) |
| Timing correlation | Identidad A y B están siempre activas en las mismas franjas horarias exactas | Variar horarios, usar sistemas amnésicos que no guardan patrones de uso |
| Metadatos de archivos | Documentos publicados desde diferentes identidades con el mismo autor en los metadatos EXIF o de Office | Limpiar metadatos con mat2/exiftool antes de publicar cualquier archivo |
| Estilometría | Mismo patrón de puntuación, palabras preferidas, longitud de oraciones, errores tipográficos habituales | Herramientas de anonimización de estilo, revisión manual consciente del estilo |
| Reutilización de contraseñas | Misma contraseña o patrón de contraseña entre cuentas de diferentes identidades | Contraseñas generadas aleatoriamente por KeePassXC, nunca reutilizar |
| Geolocalización implícita | Referencias a lugares locales, eventos, noticias de una zona geográfica específica | Coherencia con la historia ficticia de cada identidad, sin referencias al mundo real del operador |
En la práctica: el modelo de identidades
Una arquitectura de identidades típica para un operador activo tendría al menos estos niveles:
## NIVEL 0 — Identidad real
Uso: Vida personal, relaciones, trámites oficiales
Huella: La que ya existe. No se puede eliminar, solo contener.
Regla: NUNCA vinculada a ninguna identidad operacional
## NIVEL 1 — Identidad profesional pública
Uso: Trabajo como consultor/investigador, conferencias, publicaciones
Huella: Controlada y deliberada. LinkedIn, perfil de empresa, CV.
Regla: No vinculada a operaciones sensibles ni a identidades de nivel 2+
## NIVEL 2 — Identidades operacionales
Uso: Una por cada operación o contexto sensible
Huella: Mínima y controlada. Solo lo necesario para la operación.
Regla: Dispositivo/VM dedicado, IP dedicada, email único,
método de pago separado. Ciclo de vida definido.
## NIVEL 3 — Identidades de alta sensibilidad
Uso: Operaciones de máximo riesgo, investigación encubierta
Huella: Prácticamente inexistente. Hardware dedicado, Tails o Whonix,
Tor, Monero, sin rastro de creación.
Regla: Absolutamente ningún punto de contacto con ningún nivel anterior.
1.3.4 Minimización de datos en reposo, en tránsito y en uso
No puedes perder lo que no tienes. La minimización de datos es el principio de recopilar, almacenar y transmitir únicamente la información estrictamente necesaria para el objetivo — y destruirla en cuanto deja de serlo.
En el mundo corporativo este principio se aplica por regulación (GDPR, por ejemplo). En el contexto del operador se aplica por supervivencia operacional: cada dato que conservas es un dato que puede ser interceptado, confiscado, filtrado o comprometido.
Datos en reposo — lo que almacenas
Los datos en reposo son los que están almacenados en disco, en bases de datos, en backups, en dispositivos físicos. Son el objetivo más valioso para un adversario con acceso físico o capacidad forense.
Principios de minimización en reposo:
- Si no lo necesitas, no lo guardes: credenciales encontradas durante un engagement que no son relevantes para el objetivo, capturas de pantalla que documentan información sensible de terceros, conversaciones que ya cumplieron su propósito
- Define una vida útil para cada dato: ¿hasta cuándo necesito este dato? Cuando llegue esa fecha, se destruye. No "probablemente ya no lo necesite" — se destruye.
- Cifra todo lo que conserves: cualquier dato en reposo que no puedas permitirte que lea un adversario debe estar cifrado. Esto incluye backups, notas, credenciales, reportes, logs propios.
- Destrucción segura cuando ya no se necesita: borrar un archivo no basta. Los datos en SSDs y HDDs sobreviven al borrado simple. Se requiere cifrado desde el primer día o herramientas de borrado seguro específicas.
Datos en tránsito — lo que transmites
Los datos en tránsito son los que se mueven: comunicaciones, transferencias de archivos, tráfico de red, exfiltración. Son el objetivo del adversario con capacidad de interceptación de red.
- Cifrado extremo a extremo siempre: cualquier comunicación que contenga información sensible debe ir cifrada de forma que ni el proveedor del canal pueda leerla
- Minimiza el volumen de datos transmitidos: transmitir menos es exponer menos. Si puedes procesar los datos en el origen y transmitir solo el resultado, hazlo.
- Considera los metadatos de tráfico: incluso si el contenido está cifrado, los metadatos (con quién te comunicas, cuándo, cuántos bytes, con qué frecuencia) son información. Un adversario con capacidad de análisis de tráfico puede deducir mucho del patrón aunque no pueda leer el contenido.
- No transmitas lo que no necesitas transmitir: si la información puede mantenerse localmente y solo transmitir una referencia o un hash, mejor.
Datos en uso — lo que procesas activamente
Los datos en uso son los que están en memoria RAM mientras los procesas: credenciales cargadas en un gestor de contraseñas, claves de cifrado activas, documentos abiertos en un editor. Son el objetivo de los ataques de volcado de memoria (RAM dumps, cold boot attacks) y de técnicas de extracción en vivo.
- Minimiza el tiempo que los datos sensibles están en memoria: abre el documento sensible, extrae lo que necesitas, ciérralo. No lo mantengas abierto horas.
- No copies credenciales al portapapeles si puedes evitarlo: el portapapeles es accesible a cualquier proceso del sistema. KeePassXC limpia el portapapeles automáticamente después de un tiempo configurable.
- Considera los volcados de memoria: en sistemas que no están cifrados o en situaciones de confiscación en caliente (dispositivo encendido), la RAM puede ser analizada. Los sistemas como Tails no escriben nada en disco y limpian la RAM al apagar.
- Cierra sesiones cuando no estás activo: una sesión abierta es datos sensibles en estado activo. Bloquea el sistema o cierra la sesión siempre que te alejes del dispositivo.
Destrucción segura: el paso que más se salta
La minimización sin destrucción segura es incompleta. Eliminar un archivo con rm o moverlo a la papelera no borra los datos — marca el espacio como disponible, pero los datos permanecen en disco hasta que son sobrescritos.
# Borrado seguro de un archivo (HDD)
shred -vzu -n 3 archivo_sensible.txt
# Borrado seguro de un directorio completo
find /ruta/directorio/ -type f -exec shred -vzu -n 3 {} \;
rm -rf /ruta/directorio/
# Limpiar espacio libre en disco (para sobrescribir datos "borrados")
sfill -v /ruta/punto_de_montaje/
# IMPORTANTE: En SSDs, shred no es fiable por el wear leveling
# La solución correcta es cifrado completo desde el primer uso (LUKS)
# y destrucción física cuando ya no se necesita el dispositivo
shred no es fiable en SSDs. La única contramedida efectiva es cifrado completo de disco desde el primer uso — si el disco está cifrado, los datos "borrados" son ilegibles aunque se recuperen físicamente.
1.3.5 Plausible deniability técnica y operativa
La negación plausible (plausible deniability) es la capacidad de negar de forma creíble la participación en una actividad o el conocimiento de cierta información — porque técnica u operativamente es imposible demostrar lo contrario.
No es mentir. Es diseñar los sistemas y procesos de forma que la imposibilidad de atribución sea una propiedad estructural del sistema, no una afirmación posterior.
Deniability técnica
La deniability técnica se implementa mediante herramientas y arquitecturas que hacen imposible —o inviable— atribuir técnicamente una acción a un individuo específico.
Volúmenes ocultos con VeraCrypt:
VeraCrypt permite crear un volumen cifrado con dos contraseñas independientes: una que abre el volumen "normal" (con información inocua) y otra que abre un volumen oculto (con información real) dentro del mismo espacio en disco. Criptográficamente es imposible demostrar que existe un volumen oculto — el espacio podría ser simplemente datos aleatorios o el volumen exterior podría llenarlo completamente.
# Crear un volumen VeraCrypt con volumen oculto
# (usar la GUI de VeraCrypt para el wizard completo)
veracrypt --text --create /ruta/volumen.vc
# Al crear: elegir "Hidden VeraCrypt volume"
# Contraseña 1 → abre volumen exterior (contenido inocuo)
# Contraseña 2 → abre volumen oculto (contenido real)
# Montar el volumen exterior (lo que muestras bajo coacción)
veracrypt --text /ruta/volumen.vc /mnt/punto_montaje/
# Introducir contraseña 1 → volumen inocuo
# Montar el volumen oculto (uso normal)
veracrypt --text /ruta/volumen.vc /mnt/punto_montaje/
# Introducir contraseña 2 → volumen real
Sistemas amnésicos (Tails):
Tails no escribe nada en disco durante su ejecución — todo ocurre en RAM y se borra al apagar. No hay logs persistentes, no hay historial de navegación, no hay rastro de las aplicaciones que se usaron. Técnicamente, es imposible demostrar qué hiciste en una sesión de Tails porque la evidencia no existe.
Tor y la imposibilidad de atribución de tráfico:
El diseño criptográfico de Tor hace que ningún nodo individual conozca tanto el origen como el destino de una comunicación. El nodo de entrada conoce el origen pero no el destino. El nodo de salida conoce el destino pero no el origen. Sin comprometer simultáneamente ambos extremos (y correlacionar el timing), la atribución es inviable.
Deniability operativa
La deniability operativa no depende de herramientas técnicas sino de procedimientos y comportamientos que evitan la creación de evidencia atribuible.
- Comunicación por canales que no dejan registro: conversaciones en persona en espacios sin vigilancia, comunicaciones verbales en lugar de escritas para información de alta sensibilidad
- Uso de intermediarios sin conocimiento del conjunto: el mensajero que entrega el paquete no sabe lo que contiene ni quién lo envía ni quién lo recibe
- Compartimentalización como mecanismo de deniability: si no tienes acceso a la información, no puedes revelarla voluntariamente ni bajo coacción
- Acción a través de infraestructura comprometida de terceros: operar desde sistemas de terceros que han sido comprometidos añade una capa de indirección — aunque tiene implicaciones legales y éticas serias
Los límites de la deniability
La deniability también tiene un límite práctico: requiere que el sistema esté diseñado para ella desde el principio. No puedes añadir deniability retroactivamente. Si ya existen logs, metadatos, registros o testimonios que te vinculan a una actividad, la deniability técnica del contenido no elimina esa evidencia contextual.
1.3.6 Las siete capas del anonimato: del dispositivo al mundo físico
En el apartado 1.1.4 introdujimos el modelo de capas como forma de entender por qué OPSEC no es anonimato. Aquí vamos a profundizar en cada capa con detalle técnico y operacional — qué amenazas enfrenta, qué contramedidas existen y cómo se implementan.
Las siete capas son acumulativas y complementarias. Ninguna es suficiente por sí sola. Cada una añade fricción al adversario y reduce la probabilidad de que pueda trazar un camino desde tu actividad hasta tu identidad real.
Capa 1 — Dispositivo
El dispositivo es la capa más profunda y la más difícil de atacar remotamente, pero también la que puede comprometer todo lo demás si es accesible físicamente.
Amenazas:
- Vinculación por número de serie: el número de serie del hardware puede aparecer en registros de compra, garantías, reparaciones
- Dirección MAC: identificador único de la tarjeta de red, visible en redes locales y en logs de puntos de acceso WiFi
- Firmware comprometido: malware a nivel de BIOS/UEFI o controladores que persiste incluso tras reinstalar el sistema operativo
- Evil maid attack: acceso físico al dispositivo para instalar hardware o software malicioso mientras no está vigilado
Contramedidas:
- Comprar hardware en efectivo, en tiendas físicas, sin registro ni garantía vinculada a identidad real
- Cambiar la dirección MAC antes de conectarse a cualquier red:
macchanger -r eth0 - Usar dispositivos dedicados por nivel de sensibilidad — no el portátil personal para operaciones de nivel 2+
- Para nivel máximo: verificar integridad del firmware, considerar hardware conocido y auditado (Purism Librem, System76)
- Tamper-evident tape en puertos y carcasa para detectar accesos físicos
# Ver MAC actual de todas las interfaces
ip link show
# Cambiar MAC a una aleatoria (interfaz abajo, cambio, interfaz arriba)
ip link set eth0 down
macchanger -r eth0
ip link set eth0 up
# Verificar el cambio
macchanger -s eth0
# Para WiFi
ip link set wlan0 down
macchanger -r wlan0
ip link set wlan0 up
Capa 2 — Sistema operativo
Amenazas: logs persistentes de actividad, telemetría enviada al fabricante, rastros de uso en archivos temporales, historial del sistema que sobrevive entre sesiones, identificadores únicos del sistema (machine-id, UUID de disco).
Contramedidas por nivel:
| Nivel de sensibilidad | Sistema recomendado | Por qué |
|---|---|---|
| Bajo | Linux con hardening básico | Sin telemetría de Windows, logs controlables, sin Microsoft Account |
| Medio | VM dedicada por operación (Kali, Debian) | Aislamiento entre operaciones, snapshot y destrucción post-operación |
| Alto | Tails OS (live, amnésico) | No escribe en disco, RAM se limpia al apagar, todas las conexiones por Tor |
| Máximo | Whonix o Qubes OS | Compartimentalización a nivel de sistema, gateway Tor separado del workstation |
Capa 3 — Red
Amenazas: exposición de IP real, fugas DNS (consultas que salen fuera del túnel), fugas WebRTC, correlación de tráfico por ISP, análisis de metadatos de red (volumen, timing, destinos).
Arquitecturas de red por nivel:
## NIVEL BÁSICO
Tú → VPN (no-log, Mullvad/IVPN) → Internet
# Oculta IP al destino. ISP ve tráfico cifrado a VPN.
# Proveedor VPN puede ver destinos si guarda logs.
## NIVEL MEDIO
Tú → VPN → Tor → Internet
# VPN oculta a ISP que usas Tor.
# Tor añade anonimidad al destino.
# Proveedor VPN ve que vas a Tor pero no el destino.
## NIVEL ALTO
Tú (Tails) → Tor → Internet
# Sistema amnésico + todo el tráfico por Tor.
# ISP ve que usas Tor (puede ser problemático en algunas jurisdicciones).
# Usar bridges Tor (obfs4) si hay que ocultar el uso de Tor al ISP.
## NIVEL MÁXIMO
Tú (Whonix Workstation) → Whonix Gateway (Tor) → VPN de salida → Internet
# Gateway Tor separado. Imposible bypassear Tor por error.
# VPN de salida opcional: oculta que el exit node de Tor es el origen.
Capa 4 — Identidad
Amenazas: reutilización de nicknames, emails vinculados a identidad real, credenciales en bases de datos de leaks, estilometría, metadatos en archivos publicados, referencias cruzadas entre cuentas.
Contramedidas: ya desarrolladas en el apartado 1.3.3 (Segregación de identidades). El principio central es que cada identidad es una isla — ningún elemento compartido con ninguna otra.
Capa 5 — Comportamiento
Amenazas: patrones de horario consistentes, estilometría, errores tipográficos habituales, referencias a entorno geográfico real, términos o expresiones idiomáticas que localizan al autor, frecuencia y ritmo de publicaciones.
Contramedidas:
- Variar horarios de actividad: no operar siempre en el mismo rango horario desde la misma identidad
- Adaptar el estilo de escritura: cada identidad tiene un estilo deliberado y diferente. Usar herramientas de análisis de estilometría sobre tus propios textos para detectar marcadores
- Eliminar referencias geográficas: sin menciones a clima local, eventos locales, horarios de negocios de tu zona, o cualquier referencia que localice
- Coherencia de la historia ficticia: cada identidad operacional tiene una historia, ubicación y contexto que son internamente consistentes y que se mantienen en todas las comunicaciones
Capa 6 — Financiero
Amenazas: trazabilidad de pagos de infraestructura (VPS, dominios, VPNs) hasta la identidad real, análisis de blockchain en criptomonedas con historial público (Bitcoin), KYC en exchanges.
Contramedidas:
- Monero (XMR) como estándar: a diferencia de Bitcoin, Monero oculta emisor, receptor y cantidad por diseño. Es la criptomoneda de privacidad más robusta actualmente.
- Obtención sin KYC: P2P (Bisq, LocalMonero), cajeros automáticos con límites bajos, intercambio en persona
- Proveedores que aceptan Monero: Mullvad VPN, Njalla (dominios), 1984 Hosting, Incognet — permiten pagar infraestructura sin vincular un método de pago a la identidad
- Tarjetas regalo: compradas en efectivo en tiendas físicas, canjeables por servicios digitales sin registro
Capa 7 — Físico
Amenazas: cámaras de vigilancia que ubican al operador en el momento de la actividad, geolocalización del teléfono móvil, lectores de matrículas (ANPR), redes WiFi que registran conexiones con el tiempo, testigos, rutinas predecibles.
Contramedidas:
- Teléfono en modo avión o en Faraday bag: un teléfono encendido emite señales que pueden usarse para geolocalización incluso sin GPS activo
- Variar ubicaciones de operación: no operar siempre desde el mismo lugar (casa, café habitual, biblioteca)
- Conciencia de cámaras: en espacios públicos, especialmente en zonas urbanas, la cobertura de CCTV puede ser densa. Esto no significa que sea necesario evitarlas en todo caso — solo que forma parte de la superficie de ataque física
- Rutinas no predecibles: el adversario con capacidad de vigilancia física necesita predecir dónde estarás. Las rutinas rígidas lo facilitan enormemente.