5.4 · Respuesta a incidentes y recuperación

10 min de lectura · blue-team / incident-response / dfir-forense / deteccion / hardening · ⎙ PDF

Panorama#

Detectar no es responder. Cuando la detección o la cacería (5.1) confirman un compromiso —el correo de 5.3 que resultó real, el token robado que ya está dentro—, empieza la función Respond: el conjunto de acciones que investiga, contiene, erradica y recupera. Sin un proceso formal para hacerlo, la organización paga dos precios. El primero es de tiempo: el personal técnico agota horas tratando un ataque como si fuera una falla operativa —«el servidor va lento»— antes de darse cuenta de que es una intrusión. El segundo es de daño: reacciona por instinto, apaga lo primero que ve, y con eso arruina la evidencia y espanta al atacante hacia una madriguera más profunda. Este capítulo desarrolla el ciclo que evita ambos, y su lección central no es qué hacer sino cuándo: la velocidad de la respuesta importa, pero la remediación prematura es peor que la lenta.

Es la contraparte exacta del bloque rojo. Donde la metodología de pentest (3.1) describió la cadena del atacante eslabón por eslabón, la respuesta a incidentes es el defensor recorriéndola al revés para cortarla —pero cortarla entera y a la vez, no de a un eslabón—. Y como enseñó el método OSINT (2.1), sin evidencia documentada «el incidente nunca ocurrió»: la respuesta que no preserva la prueba no sirve ni para el aprendizaje ni para el tribunal.

flowchart LR
  P["Preparación\n(telemetría 5.2 · baseline ·\nCSIRT · playbooks)"] --> DA["Detección\ny análisis\n(5.1–5.3)"]
  DA --> T["Triaje + scoping\n(¿es real? alcance ·\ncronología · adversario)"]
  T --> R["Remediación táctica\ncontener → restaurar →\nerradicar (TODO a la vez)"]
  R --> REC["Recuperación\n(DR/BCP · RTO/RPO ·\nbackups offline)"]
  REC --> LL["Post-incidente\n(lecciones + causa raíz →\nremediación estratégica)"]
  LL -.->|"fortalece"| P
  T -.->|"remediar antes de acotar\n= whack-a-mole"| X["✗ alerta al adversario"]
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  classDef bad fill:#3f1d1d,stroke:#b91c1c,color:#fecaca;
  class P,DA,T,R,REC,LL n;
  class X bad;

El ciclo de vida del incidente#

El marco de referencia es el ciclo de vida del incidente del NIST, cuatro fases que se repiten: preparación, detección y análisis, contención, erradicación y recuperación, y actividad post-incidente. La preparación es todo lo que se hace antes: la telemetría que 5.2 mandó habilitar, la línea base de normalidad —«no se puede saber qué es anómalo si no se sabe qué es normal»—, la conformación de un equipo de respuesta (CSIRT) con autoridades y umbrales de severidad definidos, los playbooks por escenario, y la retención de servicios forenses externos para las crisis mayores. Una organización que solo arma su proceso durante el incidente ya perdió. La detección y análisis es el objeto de los capítulos anteriores de P5. Este capítulo se concentra en lo que viene después de confirmar: el triaje, la remediación y la recuperación.

Triaje y scoping: acotar antes de actuar#

El primer paso tras una alerta confirmada es el scoping: acotar el problema. Buena parte de los supuestos incidentes resultan ser fallas de rendimiento o de hardware, y despachar analistas forenses a cada una desperdicia un recurso escaso y produce fatiga. Pero acotar no es acumular: «más datos no significa mejor investigación», porque toda esa telemetría sigue exigiendo correlación, y una recolección masiva sin foco entierra la señal. El triaje bien hecho determina tres cosas —el alcance del compromiso, la cronología de los eventos y la identidad del adversario— extrayendo los artefactos que reconstruyen la línea de tiempo: los Event IDs críticos (un 4688 que revela mimikatz.exe o PSExec.exe, un 1102 que confirma que el atacante borró las bitácoras de seguridad), el historial de dispositivos USB en HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR, las ubicaciones de red y el historial de ejecución.

Aquí aparece una tensión que decide el orden de las operaciones: la evidencia digital es efímera, y la recolección tardía pierde información crucial —sobre todo la que vive en memoria—. El forense en vivo (live, sobre el sistema encendido, capturando datos volátiles con procdump, Wireshark o un volcado de RAM) recupera lo que el post-mortem (sobre un clon del disco apagado) ya perdió. Por eso la captura de memoria precede al aislamiento —el tema de 5.5—. Y todo lo recolectado se preserva bajo cadena de custodia: la documentación secuencial de la adquisición, el transporte y la conservación inalterada de la evidencia, sin la cual —como en el reporte OSINT de 2.1— la prueba no sostiene una investigación ni un juicio.

El orden importa: capturar la memoria RAM forense antes de aislar el equipo de la red. Aislar mata las conexiones y los procesos en vuelo que solo existen en memoria —el beacon de C2, el código fileless inyectado, las credenciales en claro que Volatility podría extraer—. Un buen playbook autoriza el aislamiento automático de red únicamente después de haber preservado los datos volátiles. La prisa por «desconectar» destruye la evidencia que iba a explicar el incidente.

La regla del tempo: por qué la remediación prematura fracasa#

El error más común y más caro de la respuesta propia es el pánico: ante el primer síntoma, la organización intenta erradicar al atacante de inmediato. La consecuencia es la contraria a la buscada. Bloquear un indicador aislado —una IP, un dominio, una cuenta— le avisa al adversario que fue detectado antes de que el defensor conozca el alcance total, y el atacante reacciona: se atrinchera en los accesos que el defensor todavía no vio, despliega su carga destructiva antes de perderlo todo, o cambia de herramientas. El resultado es el juego de whack-a-mole —tapar un agujero mientras aparecen otros—: «este enfoque alargará la investigación, causará una erradicación incompleta y puede llevar a ataques repetidos». La regla que se sigue es contraintuitiva pero firme: contener solo cuando el alcance técnico esté acotado, y hacerlo completo y simultáneo, no incremental.

La remediación táctica —la respuesta aguda— se estructura en tres movimientos que se ejecutan juntos: contención (limitar el movimiento del atacante y el daño colateral, asegurar la red temporalmente), restauración (rehabilitar rápido los servicios de negocio afectados) y erradicación (purgar sistemáticamente todo rastro del adversario: bloquear su infraestructura, invalidar credenciales, eliminar la persistencia). La clave es la simultaneidad, y es exactamente el punto que 5.3 anticipó para la identidad: no basta con resetear la contraseña si sobreviven el token OAuth y la cookie de sesión; hay que revocar tokens, sesiones, delegaciones y reglas de buzón a la vez, o el atacante sigue dentro por la puerta que se dejó abierta. En Active Directory, la erradicación completa incluye el doble reset de krbtgt y la revocación de los certificados de AD CS que sobreviven a la rotación de contraseñas, como desarrolló la defensa de AD (4.9). Para escalar esta fase sin perder velocidad se apoya en el IOC sweep —barrer el entorno entero con los indicadores conocidos para encontrar todos los sistemas comprometidos, no solo el primero— y en la orquestación SOAR, que automatiza los barridos y la recolección para que el analista se concentre en las decisiones que exigen criterio humano.

«Es muy común que las organizaciones que hacen su propia respuesta a incidentes entren en pánico e intenten una remediación prematura.» El instinto de «apagar todo ya» es el que más incidentes empeora: convierte una intrusión acotada en una campaña destructiva. La contención se planifica sobre un alcance conocido y se ejecuta de una vez; nunca se improvisa bloqueando indicadores sueltos mientras la investigación sigue abierta.

La respuesta en la nube: responsabilidad compartida#

La migración a la nube cambia una premisa básica de la investigación: quién controla la evidencia. Bajo el modelo de responsabilidad compartida, el proveedor y el cliente se reparten el control forense según el servicio contratado, y eso limita el acceso directo a los registros —en un SaaS, el cliente puede no tener el log de sistema que sí tendría en un servidor propio—. El contraste operativo es claro: en un incidente on-premise el analista recolecta manualmente las bitácoras y reconstruye los eventos a mano (Visor de Eventos, 4688 → mimikatz.exe, VirusTotal para validar el hash); en un entorno híbrido, una consola como Azure Security Center ingiere la telemetría de forma continua, consolida las alertas dispersas en un diagrama del incidente y permite búsquedas sintácticas (search "mimikatz" en Log Analytics) que acortan el triaje. La consecuencia procedimental es concreta: el proceso de respuesta debe actualizarse para incluir al proveedor de nube como contacto técnico autorizado, con los canales y permisos de recolección de evidencia acordados de antemano —otra tarea de la fase de preparación—.

Recuperación y resiliencia: sin plan, el ransomware gana#

Ninguna organización puede proteger preventivamente todos sus activos, de modo que la supervivencia depende de la recuperación planificada. Dos documentos la gobiernan: el plan de recuperación ante desastres (Disaster Recovery, DR), que restaura la infraestructura tras un evento destructivo, y el plan de continuidad del negocio (Business Continuity Plan, BCP), que mantiene las funciones críticas operando durante la interrupción. Ambos se dimensionan con un análisis de impacto (Business Impact Analysis, BIA) que prioriza los sistemas críticos y fija dos métricas: el RTO (Recovery Time Objective, el tiempo máximo tolerable de inactividad) y el RPO (Recovery Point Objective, la pérdida máxima tolerable de datos). Las estrategias de contingencia se ordenan por disponibilidad —sitios fríos (equipamiento a instalar), cálidos, calientes y espejados (asumen la carga al instante)—, con el respaldo en la nube ofreciendo escalabilidad elástica a menor costo; y la recuperación en vivo (live recovery) permite reparar configuraciones dañadas —por ejemplo, purgar una contraseña del SAM con chntpw desde un Live CD— sin reinstalar.

La lección que ata la recuperación al resto del capítulo la dio WannaCry: los planes estáticos, atados a calendarios rígidos, resultaron inútiles ante un ransomware que cifró sistemas en más de 150 países en horas —«un plan documental obsoleto representa un riesgo mayor que la ausencia de defensas»—. Y hay un detalle que el playbook de AiTM (5.3) ya adelantó: el ransomware moderno, antes de cifrar, ataca los backups (borra las shadow copies, desactiva el EDR) para inhibir la recuperación y forzar el pago. Por eso el respaldo que salva es el offline / desconectado, fuera del alcance del atacante que ya está dentro de la red; un backup en línea que el ransomware puede cifrar junto con todo lo demás no es un backup. Validar periódicamente la restauración desde esos respaldos —con simulacros funcionales reales, no solo ejercicios de escritorio— es lo que convierte el plan en resiliencia efectiva.

Cierre: el post-incidente cierra el ciclo#

La contención del atacante no es el final. La fase de lecciones aprendidas ejecuta un análisis de causa raíz, identifica los fallos procedimentales, y actualiza los manuales, las políticas y la arquitectura —es la remediación estratégica, distinta de la táctica: no repara este incidente sino que impide el próximo idéntico (MFA resistente al phishing, eliminación de privilegios, segmentación)—. Y ese aprendizaje no se archiva: realimenta la inteligencia y la detección de 5.1, cerrando el lazo del programa de defensa —el incidente de hoy se vuelve la regla de detección de mañana, igual que el hunt-to-detection—. La respuesta a incidentes es, así, el punto donde converge todo P5: consume la telemetría de 5.2, la contención de identidad de 5.3 y el forense de memoria (5.5) y de disco, y produce el conocimiento que fortalece la postura. Sin evidencia, el incidente «nunca ocurrió»; sin proceso, la evidencia se pierde y el atacante vuelve.

Referencias#

blue-dfir/attack-defense/cap-02 — Incident Response Process: el ciclo de vida del NIST, el CSIRT y los umbrales de severidad, la respuesta en la nube bajo responsabilidad compartida, y las lecciones aprendidas como motor de madurez (caso WannaCry).
blue-dfir/defenders-advantage/cap-06 — Respond: el ciclo triaje → investigación/scoping → remediación, la distinción táctica (contener/restaurar/erradicar) frente a estratégica, la naturaleza efímera de la evidencia, el IOC sweep y el SOAR, y la advertencia central sobre la remediación prematura (whack-a-mole).
blue-dfir/attack-defense/cap-13 — Investigating an Incident: el scoping inicial, «más datos no es mejor investigación», los artefactos clave (4688 mimikatz/PsExec, 1102 borrado de logs, USBSTOR), la cadena de custodia y el contraste on-premise vs nube (Azure Security Center / Log Analytics).
blue-dfir/attack-defense/cap-14 — Recovery Process: DR y BCP, el BIA y las métricas RTO/RPO, las estrategias de backup y sitios (frío/cálido/caliente/espejado), la live recovery y la lección de resiliencia ante ransomware.
NIST SP 800-61r2 — Computer Security Incident Handling Guide, el marco canónico del ciclo de vida del incidente referenciado en el capítulo.

Mencionado en

1.1 · El programa de inteligencia: niveles, ciclo y requerimientosEl capítulo-marco que abre P1. Su tesis: la inteligencia no se define por el dato que contiene sino por la decisión que habilita, de modo que un programa sin requerimientos explícitos no produce inteligencia sino feeds. Desarrolla los tres niveles de consumo —táctico, operativo y estratégico— como tres productos distintos con tres consumidores distintos, el ciclo de seis fases como disciplina que impide la acumulación estéril de indicadores, y el criterio de madurez que separa a la organización que compra inteligencia de la que la produce a partir de sus propios incidentes.
1.5 · CTI operativa: del feed a la detección en el SOCEl puente entre el programa de inteligencia y el centro de operaciones: los tres puntos donde cada nivel se inyecta, el caso canónico de extremo a extremo y los tres lugares donde falla en la realidad, el bucle de realimentación que convierte al equipo de respuesta en productor, la célula de análisis y su única condición de existencia, y las métricas que distinguen un programa que cambia decisiones de uno que solo ingiere indicadores.
1.6 · El panorama de amenazas: actores, cibercrimen e IAEl producto estratégico del ciclo, y el único capítulo del manual con fecha de vencimiento. Antes que las cifras —que caducan— desarrolla cómo se lee un informe de panorama sin heredar el sesgo de visibilidad de quien lo publica, y luego las tres direcciones del cambio en 2025-2026: acceso sin malware, ejecución sin binario propio e industrialización del intermediario. Cierra con lo que no cambió, que suele ser lo más caro, y con el cierre de la Parte 1.
5.1 · El programa de defensa: detección y threat huntingEl capítulo-marco que abre P5 y da vuelta el manual: del atacante que necesita todos los eslabones al defensor que solo necesita fallar uno. La defensa no es una suma de herramientas sino un programa activo de funciones que interoperan —inteligencia, detección, respuesta, validación, cacería y control— bajo el mismo supuesto de compromiso que gobierna al atacante. Su tesis operativa: la detección se construye por comportamiento (TTP), no por artefacto atómico (la pirámide del dolor de Bianco), y la cacería dirigida por hipótesis retroalimenta la detección en un ciclo cerrado (hunt-to-detection). Es el espejo azul de la metodología de pentest (3.1) y del método OSINT (2.1).
5.2 · Telemetría y SIEM: Windows Event Logs, Sysmon y PowerShellLa capa de datos sobre la que corre toda la detección de P5. No se detecta lo que no se registra —pero registrar todo indiscriminadamente ahoga al analista—, de modo que la telemetría se elige guiada por las TTP que se quieren ver (el principio de 5.1) y se habilita ANTES del incidente. El capítulo sistematiza las tres fuentes de host de Windows que hacen visible casi cualquier ataque de endpoint —Windows Event Logs, la ejecución de procesos (4688 + Sysmon 1) y PowerShell (4104, el que desnuda lo fileless)— y la correlación multi-fuente que las une con la telemetría de red y perimetral en el SIEM. Es la base de datos que 4.9 aplicó al dominio y que los capítulos 5.6–5.11 aplican técnica por técnica.
5.3 · Detección de amenazas de identidad y correoLa identidad es el nuevo perímetro y el correo su puerta de entrada: el 41% de los accesos iniciales empiezan en un buzón. Este capítulo recorre la cadena de identidad de afuera hacia adentro —el correo entrante (phishing/BEC y el análisis forense de cabeceras SPF/DKIM/DMARC), la autenticación (el léxico de Event IDs 4624/4625/4776/4771 que distingue el brute-force del password spraying), los ataques modernos a la identidad en la nube que ni roban la contraseña ni burlan técnicamente el MFA (OAuth consent abuse, AiTM y robo de token de sesión) y el abuso de identidad en el dominio (Kerberoasting visto por el 4769 con RC4)— bajo un principio rector: una autenticación exitosa NO implica legitimidad; se evalúa el comportamiento en contexto, no el evento aislado. Es el espejo azul del OSINT de identidad (2.2) y del Kerberos ofensivo (4.2/4.9).
5.5 · Forense de memoriaEl quinto y último capítulo-fundamento de P5, y el que destapa lo que el disco no ve. La RAM es evidencia volátil que muere en el reinicio —procesos activos, conexiones establecidas, credenciales en claro, código inyectado sin archivo—, de modo que se captura en vivo antes de apagar, con cuidado de no corromperla. Sobre el volcado, Volatility perfila el sistema y triangula lo oculto: pslist frente a psscan expone el proceso que un rootkit borró de la lista del kernel, malfind localiza el código inyectado en regiones RWX sin archivo de respaldo, netscan recupera el canal de C2 y hashdump las credenciales. Es el espejo forense de la inyección in-memory (3.11) y de los rootkits (3.14): las técnicas que ganaron contra el escaneo de disco pierden en memoria, porque para ejecutar tienen que estar ahí. Cierra los fundamentos 5.1–5.5; los binarios que extrae alimentan el análisis de malware de 5.8.
5.6 · Detección de movimiento lateral en el SIEMEl primero de los seis capítulos que cierran, desde el lado azul, las técnicas del bloque rojo. El movimiento lateral es la fase que convierte un equipo comprometido en una red comprometida, y no puede ejecutarse en silencio: toda ejecución remota en Windows deja un rastro característico —un inicio de sesión de red, un servicio recién instalado, un recurso administrativo tocado, un proceso hijo que no corresponde—. Recorre la telemetría de cada vía (PsExec y admin shares, WMI y WinRM, RDP, pass-the-hash) insistiendo en la regla que las une: el evento se lee correlacionando origen y destino, nunca en una máquina sola. Cierra con la contracara arquitectónica —la segmentación reduce el blast radius y obliga al tráfico este-oeste a cruzar un punto donde se lo puede ver— y con los dos casos donde el lateral es el punto de detección final. Es el espejo azul de 4.8, 4.9 y 3.13.
5.9 · Detección de exfiltración y estegoanálisisSi 5.7 siguió el canal, este capítulo sigue el dato. La exfiltración tiene una anatomía estable —recolección, staging local, compresión, salida y repliegue— y el mejor punto de detección no está en la salida sino antes: el staging es local, anómalo y visible para el EDR. Recorre la jerarquía de canales por dificultad creciente hasta el caso más incómodo, la exfiltración nativa de la nube, donde el dato se va sin que ningún paquete cruce el perímetro. Trata el scraping por API, el insider —el escenario sin IOC, donde solo queda el comportamiento— y los límites honestos del DLP, que se derrota cifrando antes de salir. Cierra con el estegoanálisis como problema estadístico y no de firmas: gana contra el LSB ingenuo y pierde contra el cifrado previo, razón por la cual el plano fuerte sigue siendo el conductual. Cierra 3.12.
5.10 · Detección de persistencia en LinuxEl espejo azul de 3.14. La persistencia tiene una debilidad que la exfiltración y el C2 no tienen: deja un artefacto quieto en disco, y los disparadores que el sistema honra son finitos, por lo tanto enumerables. De ahí que la detección sea auditoría de un conjunto acotado contra una línea base, y no persecución de un comportamiento fugaz. Recorre la telemetría nativa de Linux y su hueco más grande —no hay auditoría de creación de procesos por defecto—, auditd y AIDE con sus límites honestos, la señal que rinde en cada familia de disparador, y la verificación de paquetes como línea base criptográfica gratuita. Cierra con el caso donde la regla se invierte: cuando el host miente, hay que observarlo desde fuera. Cierra 3.14.
5.11 · Detección en runtime de contenedoresEl espejo azul de 3.16 y el capítulo que cierra P5. El contenedor de propósito único invierte el problema que hacía caro todo lo anterior: su comportamiento permitido es tan pequeño y está tan declarado que la línea base deja de ser un proyecto y pasa a derivarse de la definición del workload. Sobre esa ventaja se apoya el IDS de runtime por eBPF, con sus tres límites honestos. Pero el sensor de host solo cubre la mitad: el adversario que roba un token de service account no ejecuta nada en ningún nodo, y ahí el audit log del API server pasa de complemento a fuente primaria. Cierra con lo que la efimeridad le hace al forense y con la propiedad más aprovechable del modelo: en Kubernetes el ataque se declara antes de ejecutarse. Cierra 3.16 y la Parte 5.
6.4 · Tabletop y ejercicios de crisisEl capítulo que desplaza el sujeto de la validación. Los tres anteriores validan controles —sensores, reglas, telemetría—; este valida decisiones, y el sujeto ya no es el sensor sino la organización. Sostiene que lo que falla en una crisis real rara vez es el EDR: es quién tiene autoridad para desconectar, cuándo se declara el incidente, quién habla en nombre de la empresa y con qué se cuenta si la infraestructura de respuesta también está caída. Distingue el tabletop técnico del ejecutivo, expone el error del plan que asume su propia infraestructura viva, y ordena las decisiones incómodas que solo sirven si se ensayan en frío.
7.1 · El marco de gobernanza: NIST CSF 2.0 y la función GOVERNEl capítulo que abre la Parte 7. Sostiene que la ciberseguridad no es un dominio técnico aislado sino un componente de la gestión de riesgo empresarial, y que el NIST CSF 2.0 ofrece una taxonomía de resultados —qué lograr, no cómo— cuya innovación estructural, la función GOVERN, es exactamente la capa que el manual no había construido: todo lo anterior implementó las cinco funciones operativas —identificar, proteger, detectar, responder, recuperar—, y GOVERN es el techo que las decide, las financia y las rinde. Presenta la jerarquía del Core, los perfiles organizacionales como instrumento de análisis de brechas que consume la validación de la Parte 6, y los cuatro Tiers de madurez como una decisión de apetito de riesgo, no como una escalera donde más siempre es mejor.
7.4 · Controles de amenaza interna: administrativos, humanos y de ciclo de vidaEl capítulo que cierra la Parte 7 bajando el programa de amenaza interna a las veintidós prácticas del CERT, y sostiene que no son veintidós herramientas sino tres planos que tienen que operar integrados —humano, técnico y de ciclo de vida—. El plano que más rinde y que el resto del manual no había cubierto es el humano, porque actúa aguas arriba de todo lo demás, en la motivación y no en el comportamiento ya desviado: conducta preocupante desde la contratación, gestión del estrés, concientización, y sobre todo justicia organizacional e incentivos positivos, la contramedida más barata y menos usada. El plano técnico se referencia a las Partes que ya lo construyeron —control de cuentas privilegiadas, UEBA y correlación, separación de funciones y least privilege— porque el aporte de la gobernanza es la política que los ordena, no la técnica. El plano de ciclo de vida cierra el eje temporal abierto en 7.3 con el control de cambios contra las bombas lógicas, el respaldo protegido del propio administrador y el deprovisionamiento en la terminación, el momento de máximo riesgo empírico. Y la última práctica —aprender de los incidentes— es el lazo de mejora que devuelve la Parte entera a la validación. Cierre: la gobernanza no se compra, se ejerce.
9.2 · IA defensiva: ML en el SOC y respuesta autónomaEl capítulo azul de la Parte 9: la inteligencia artificial como herramienta del defensor. Recorre el aprendizaje automático en el corazón del centro de operaciones —el modelo supervisado que clasifica lo conocido, el no supervisado que detecta la anomalía que nunca vio— y la arquitectura que lo sostiene: el pipeline de ingesta, feature y modelo sobre un data lake, y las plataformas que lo materializan (NGAV, EDR, XDR, NDR, UEBA, SOAR). Su eje es el espectro delicado de la respuesta autónoma —de la sugerencia a la aprobación al bloqueo automático— y la supervisión humana como el freno que ninguna madurez elimina, porque la automatización a escala puede convertirse en una denegación de servicio autoinfligida. Cierra con los límites honestos que separan la IA defensiva real del ruido de mercado: los falsos positivos y la fatiga de alertas, la degradación del modelo por data drift, el problema de la explicabilidad, y la incómoda verdad de que el propio modelo defensivo es una superficie de ataque nueva. La tesis: la IA no reemplaza al analista ni a la detección que la Parte 5 construyó; le pone una capa encima, y esa capa hay que gobernarla.