Pávlov el zombie - Un caso de extorsión (I)

de Pedro Sánchez

Hola lectores,

Arturo y Eli son socios y jóvenes emprendedores dedicados en cuerpo y alma a un proyecto que idearon en la universidad hace cinco años. Se dedican en exclusiva a desarrollar aplicaciones en modo SaaS para empresas en el ámbito de medio ambiente y desde que comenzó el proyecto hoy cuentan con setenta empleados que no es poco en la crisis que vivimos.

El único problema digno de mención surgió hace dos años con un empleado que resaltaba por su brillantez a la hora de programar. Tenia un hueco y futuro en la empresa pero dado su carácter y forma de ser no acepto tener una mujer como responsable de equipo. Con el tiempo las relaciones entre los componentes fueron a peor y Arturo y Eli decidieron tras una gran discusión con este que debería de irse aún perdiendo un estupendo programador. La cosa se hizo de mutuo acuerdo y se despidió.

El tiempo pasa y la vida continua y esta magnífica empresa empieza a dar muy buenos resultados abriendo delegación en Brasil. Arturo y Eli mientras tanto son premiados por la Cámara de Comercio por su buena trayectoria. Deciros que hoy en día esta empresa tiene novios con objeto de ser comprada.

UN ZOMBI EN MI BUZON DE CORREO

El pasado mes de Noviembre Eli recibe un correo con una mala traducción al Español indicando que debe de pagar 90.000€ a una mafia ubicada en Rusia. En caso contrario "Pávlov el Zombie" que es como se hace llamar, le comunica que tras el plazo de siete días procederá a apagar los servidores de la empresa.

Por su puesto Eli, ve en el correo una broma y decide olvidar el asunto hasta que efectivamente al séptimo día y como bien dice ella "se forjo la maldición" y uno de los servidores de Active Directory se apago ordenadamente en plena ebullición de trabajo a las 12:00h.

En estos casos ya sabéis lo que ocurre. El responsable de sistemas empezó a recibir alertas, llamadas de sus compañeros y llamadas desde Brasil. Arturo que es alertado por el móvil no le da importancia y Eli la mínima (estas cosas pasan en todos los días en las empresas, pensó).

Pero la sorpresa fue mayúscula, cuando el administrador inicio sesión en el servidor y apareció el escritorio, se encontró con una fotografía de Eli con su familia de fondo de pantalla. Algo raro está pasando.

Esa misma mañana deciden reunirse y ver lo ocurrido Eli comenta que fue advertida por un tal "Pávlov" llegando a la conclusión de lo que pensó que era una mal broma la cosa empezaba a convertirse en cruda realidad. Paralelamente en la tarde del suceso Eli recibe más correos de 'Pávlov el Zombie' reclamando el dinero.

Para no hacer muy extenso el post os diré que hasta ahora esto es lo que ocurrió en la empresa y que esto ocurre en Septiembre y que por 'motu' propio de la empresa y tras hablar con sus abogados deciden realizar las siguientes acciones hasta primeros de noviembre:

• Poner una denuncia. La operativa por parte de las fuerzas de seguridad y tras orden judicial se solicita a Google que de información de esa cuenta de correo. Esto además de ser un proceso arduo y duro viene a costar entres uno y tres meses dependiendo del tipo de maldad o fraude cometido.
• Analizar las cabeceras de los correos recibidos (que por cierto son de Gmail)
• Revisar el servidor y puestos de trabajo en busca de troyanos
• Cambiar las contraseñas de todos los dispositivos, servidor y puestos de trabajo

Pero lo peor estaba por venir en Noviembre "Pávlov" alias "El zombie" reaparece y anunciaba que si no recibía el pago en cinco días antes de las 12:00h del Viernes, procedería a borrar información aleatoriamente del servidor.

Lo que antes fue una advertencia ahora se convertía en un reto dado que se supone que el control lo tiene la empresa.

ESTORNUDAR ES SIMBOLO DE INFECCION ZOMBIE

Bueno, pues lo dicho aquí es donde entramos a colaborar y allí estamos desde el Miércoles. El escenario que nos encontramos es el siguiente:

• Cortafuegos Juniper en alta disponibilidad con balanceador de carga y dos servidores Windows 2008 con Active Directory, IIS publicando varias aplicaciones que se gestionan desde ayuntamientos y otras empresas por medio de una VPN. SQL Server 2008 como base de datos y replicadas en Barcelona en sendos servidores Windows Server 2008.

• Una sospecha por parte de Eli y Arturo, del antiguo empleado que se marcho de la empresa de forma 'poco ejemplar'

• y tres días solo para la hora 'H'

MIERCOLES

Con objeto de monitorizar se realizó (a la puta carrera) lo siguiente (no recuerdo muy bien el orden):

• Se puso el Switch en modo 'port mirroring' en dos 'bocas'. En una de ellas se puso un detector de intrusos paralelamente con Wireshark a saco para capturar tráfico. En la otra se puso Spectrum de NetWitness

• Se aplico una regla en los Juniper con un 'trigger' en log que vigilase todo el tráfico de entrada y salida de los dos servidores y del servidor de OpenVPN.

• Se aplico una regla en los cortafuegos de Windows que comprobase todo el tráfico de salida con objeto de comparar con los Juniper

• Se aplico la última actualización de los servidores (solo había una crítica del navegador)

• Se desinstalo el antivirus actual y se instalo otro más agresivo y que fuera diferente a los de la red corporativa. Es posible que 'Pávlov' pudiera saltarse la detección del antivirus si había realizado un malware 'a medida' y mas si sospechamos del antiguo empleado.

• Se hizo pasar la navegación de los servidores por un proxy con autenticación. De esta forma si el atacante utiliza un malware de upsss 'conexión inversa' con algún puerto no estándar quedaría registrado en el proxy y no tendría efecto.

• Se deshabilito el servicio de terminal server (empleado solo por los administradores) y se instalo Wireshark en los servidores (si , ya se que fue un poco bruto). Esto se debe a que si el malware utiliza algún tipo de cifrado, nos sería mas sencillo de ver en la capa de red y usuario que es lo que envía y recibe. Por ultimo instalamos varias utilidades para monitorizar los procesos (decidimos no utilizar los propios del sistema operativo por si este estuviera comprometido) entre ellos Restarter y LogLady. También instalamos un syslog para que nos mandara los eventos de Windows a un pc de la instalación.

• Con el monitor de actividad de SQL Server se comprobó el uso y funcionamiento.

• Un compañero se dedico 'a saco' a revisar posibles vulnerabilidades en los aplicativos web

• Tras diversas discusiones y aun sabiendo que no resultaría muy efectivo se virtualizo en VMware los servidores y sin seguir las recomendaciones de Microsoft (ver) (cosas del modo paranoico)

Y así pasamos un bonito Miércoles...

JUEVES

Vuelta a revisar todo de arriba abajo y de abajo arriba, reuniones y modo paranoico en 'ON'.

VIERNES 8:10h

Me llama Arturo y Eli casi simultáneamente indicando que han vuelto ha recibir un email avisando de que se va a proceder al borrado de datos a la hora indicada. Se informa y adjunta el email a la denuncia que se realizó a las fuerzas de seguridad. Vuelta a re-e-e-e actualizar el antivirus y revisar las actualizaciones de Windows

10:00h

Vuelta a revisar todo. Se estudia la posibilidad de avisar a los clientes, se diseña un protocolo y correo que nunca se llega a enviar. Volvemos a cambiar las contraseñas. La locura se hace evidente. La dirección de la empresa piensa en apagar los sistemas para que no se produzca el borrado. Es decir hacer un 'haraquiri' o auto-denegación de servicio. Cosa por mi parte inadmisible dado que mueves el problema a otra fecha y no lo resuelves, además de perder datos de investigación muy relevantes. Vuelta hacer Backups por si acaso.

11:00h

Todo el mundo atento. Todo el mundo firmes y en posición de batalla, sensores, Log's y nuestra atención al filtrado de los cortafuegos, proxy's e IDS's

11:28h

Silencio total. Todos mirando el monitor. El 'acojone' y los apretones de tripa 'se huelen'

12:00h

Silencio. Todo funciona con normalidad. No se oye nada de vez en cuando un teléfono. La tecla F5 (actualizar) va 'a toda hostia'

12:05h

Revisión de log's, revisión de controles y vuelta a monitorizar

12:30h

Caras de alegría. El tipo no puede entrar. No tiene control. Todo va normal

13:00h

Alegría tensa. Primera reunión después de DEFCON 1. Pensamos que todo ha sido una 'mala pasada' y que si antes tenia el control ahora es evidente que no lo tiene. Pasamos a DEFCON 2. (Perdón por la jerga militar). Esperamos hasta la hora de comer ya hacemos hasta bromas pero no dejamos de mirar las pantallas

14:30h.

Eli y Arturo nos hacen pedir para todos unas Pizzas y coca colas. Hoy todos comemos en la sala de reuniones. La invitación a una comilona se hace palpable, pero hoy no y como dijo José Mota: mañaaaaaaaana. (NOTA: La comida se produjo pero no tan pronto como nos hubiera gustado)

16:00h.

Todos nos relajamos, el Tsunami no llego a serlo. Mas y mas bromas, somos los mejores

16:22h

LOS ZOMBIES NO DISCRIMINAN, TE COMEN SI VAS LENTO

El administrador de dominio en una copia de datos rutinaria le da error la carpeta de origen. Comprueba alertado que los datos no están. Han desaparecido delante de nuestra cara y estupefacto me quedo al comprobarlo.

También faltan las carpetas de "Archivos de Programa" aunque algunos ficheros no se han borrado debido a que están en uso. Entre los desaparecidos están los ficheros raíz y muchos archivos de la carpeta Windows. Aquí el único que se ha enterado es el visor de eventos de Windows que nos ha enviado el evento a una máquina remota.

FAIL!!!

¿Pero que cojones ha ocurrido?, ¿Como es posible?.

Ninguna alerta, ninguna alarma, el IDS's ni se entera. Los logs's de lo Juniper a cero bytes, ningún proceso ha sido creado, nadie ha tocado nada, las conexiones de red las normales con acceso y peticiones http y https. Ningún tráfico de salida desde los dos servidores y aún así este tipo ha conseguido acceso y borrado datos tal y como predijo.

Las preguntas vuelan y la perplejidad de Eli y Arturo que con la mirada lo dicen todo, hacen ver que la derrota es muy amarga. Aunque los datos se han podido recuperar y realmente ha sido lo de menos, lo que verdaderamente mas me ha dolido en mi orgullo es que he perdido la apuesta (moral) con esta empresa con un 0-2 para 'Pávlov'. La verdad es que me senti derrotado.

Las dudas y mareos

¿Me estaré enfrentando realmente a un hacker contratado por la mafia?, ¿Se me ha pasado por alto algún control?, ¿dispone 'Pávlov el zombie' de algún 0Day? o he subestimado el potencial de un ex-empleado...

Es momento de volcar la memoria de los servidores, analizar lo poco que tenemos,volver a recapacitar y revisar con mas profundidad los controles. Cuando se toca fondo solo hay un camino y es tirar hacia arriba.

************

Bueno el resultado técnico final y con pantallas lo tendréis para la semana que viene... no os lo perdáis por que la cosa va por SQL SERVER y no es un ataque web, ni de SQL-Injection ni por asomo un 0day, ni malware que se le parezca. También es la historia de un empeño por descubrir que ha pasado

¿Que será?...

En este mundo de Zombies veremos quien caza a quien...

Fuente: http://conexioninversa.blogspot.com

¿QUÉ ES LA HIPAA?

La Ley de responsabilidad y transferibilidad de los seguros médicos (Health Insurance Portability & Accountability Act) de 1996 (21 de agosto 21), ley pública 104-191, que modifica el código del Internal Revenue Service de 1986. También conocida como la Ley de Kennedy-Kassebaum.

El Título II incluye una sección, Simplificación administrativa, que exige:

1. Mayor eficiencia en la asistencia médica por medio de la estandarización del intercambio electrónico de datos, y
2. La protección de la confidencialidad y seguridad de los datos médicos, a través del establecimiento y cumplimiento de estándares.

Más específicamente, la HIPAA pide:

1. La estandarización de los datos electrónicos administrativos, financieros y de salud de los pacientes
2. Identificadores médicos únicos para personas, empleados, planes de salud y proveedores de cuidados médicos
3. Normas de seguridad que protejan la confidencialidad y la integridad de la "información médica identificable a nivel personal" pasada, presente o futura.

En resumen: cambios radicales en la mayoría de los sistemas de información administrativos y de transacciones médicas.

¿A QUIÉN AFECTA? A todas las organizaciones de salud. Esto incluye a todos los proveedores de asistencia médica, contando a los consultorios de un solo médico, a los planes de salud, empresas, autoridades de salud, compañías de seguros, cámaras de compensación, agencias de facturación, proveedores de sistemas de información, organizaciones de servicios y universidades.

¿HAY SANCIONES? La HIPAA pide sanciones civiles y penales graves en caso de incumplimiento, como multas de hasta 25,000 dólares por violaciones reiteradas del mismo estándar en un solo año, multas de hasta 250,000 dólares o hasta 10 años de prisión por el mal uso consciente de la información de salud identificable a nivel personal.

PLAZOS DE APLICACIÓN La mayoría de las entidades disponen de 24 meses desde la fecha de entrada en vigor de la regla final, para cumplirla en su totalidad. Normalmente, la fecha de entrada en vigor es 60 días después de la publicación de una regla. La Regla sobre transacciones se publicó el 17 de agosto de 2000. Por lo tanto, la fecha de cumplimiento de esa regla es el 16 de octubre de 2002. La Regla sobre confidencialidad se publicó el 28 de diciembre de 2000, pero debido a pequeños problemas técnicos, no entró en vigor hasta el 14 de abril de 2001. El cumplimiento de la regla sobre confidencialidad se exige a partir del 14 de abril de 2003.


¿CÓMO SE APLICARÁ? De manera amplia y profunda. Las respuestas de cumplimiento exigidas no son estándar, ya que las organizaciones tampoco lo son. Por ejemplo, una organización con una red de cómputo deberá poner en funcionamiento uno o más mecanismos de acceso con autenticación de seguridad, basados en los usuarios, las funciones o el contexto, dependiendo del entorno de red.

Un cumplimiento efectivo requerirá de una aplicación en toda la organización. Los pasos incluirán:

Fomentar el conocimiento inicial de la HIPAA en toda la organización.
Evaluar de forma completa los sistemas de seguridad de la información, los reglamentos y los procedimientos de la organización.
Desarrollar un plan de acción con plazos y fechas límite.
Desarrollar una infraestructura técnica y de administración para poner el plan en funcionamiento.
Poner en marcha un plan de acción completo que incluya
el desarrollo de nuevos reglamentos, procesos y procedimientos
Crear acuerdos de "cadena de confianza" con la organización de servicios.
Rediseñar una infraestructura de información técnica que cumpla los requisitos.
Adaptar o adquirir nuevos sistemas de información
Desarrollar nuevas comunicaciones internas
Capacitación y aplicación
Ahora, exploraremos el siguiente nivel de particularidades de la HIPAA que, para muchos de nosotros, son más fuente de confusión que de entendimiento. Intentemos simplificar la "Simplificación administrativa".

La disposición sobre "Simplificación administrativa" de la HIPAA consta de cuatro partes, cada una de las cuáles genera varias "reglas" y "estándares". Muchas de las reglas y estándares están aún en la fase de "propuesta" (por el DHHS); sin embargo, está previsto que la mayoría de ellas se conviertan en reglas "finales" en el año 2000. Para complicar el asunto aún más, cuando las reglas sean finales, la mayoría de ellas tendrá diferentes fechas de aplicación.

Las cuatro partes de la simplificación administrativa son:
ESTÁNDARES PARA TRANSACCIONES ELECTRÓNICAS RELACIONADAS CON LA SALUD
IDENTIFICADORES ÚNICOS
ESTÁNDARES DE SEGURIDAD Y FIRMAS ELECTRÓNICAS
ESTÁNDARES DE PRIVACIDAD Y CONFIDENCIALIDAD

I. ESTÁNDARES PARA TRANSACCIONES ELECTRÓNICAS RELACIONADAS CON LA SALUD
El término "transacciones electrónicas relacionadas con la salud" incluye las reivindicaciones médicas, la elegibilidad para los planes de salud, la inclusión y exclusión, los pagos de primas de los planes de salud y asistencia, el estado de las reclamaciones, los primeros informes de lesiones, la coordinación de prestaciones y las transacciones relacionadas.

En la actualidad, los proveedores de cuidados y los planes de salud usan un gran número de formatos electrónicos distintos. La aplicación de un estándar nacional significa que todos usaremos un solo formato, lo que "simplificará" y mejorará la eficiencia de las transacciones en todo el país. La regla propuesta exige el uso de formatos electrónicos específicos desarrollados por el ANSI (American National Standards Institute) para la mayoría de las transacciones, con excepción de las reclamaciones y los primeros informes de lesión. La reglamentación propuesta para estas excepciones aún no se conoce.

Prácticamente todos los planes de salud tendrán que adoptar estos estándares, aunque la transacción se realice en papel, por teléfono o por fax. Los proveedores que usan transacciones no electrónicas no tendrán que adoptar los estándares, pero si no lo hacen, deberán contratar a un centro de cambio y compensación que proporcione los servicios de conversión.

Las organizaciones de salud también deben adoptar CONJUNTOS DE CÓDIGOS ESTÁNDAR para utilizarlos en todas las transacciones médicas. Por ejemplo, los sistemas de codificación que describen las enfermedades, las lesiones y otros problemas de salud, así como sus causas, síntomas y medidas adoptadas deberán ser uniformes. Todas las partes de una transacción deberán usar y aceptar los mismos códigos. Una vez más, esto tiene como fin reducir, a la larga, los errores, la duplicación de esfuerzos y los costos. Afortunadamente, muchos planes de salud, centros de compensación y proveedores de cuidados de la salud ya utilizan los conjuntos de códigos que se proponen como estándares de la HIPAA, lo que facilitará la transición.

II. IDENTIFICADORES ÚNICOS PARA PROVEEDORES, EMPRESARIOS, PLANES DE SALUD y PACIENTES
El sistema actual nos permite tener varios números de Id. para distintas relaciones entre nosotros; la HIPAA considera que esto es confuso, caro e induce a errores. Se espera que los identificadores estándar reduzcan estos problemas.

III. ESTÁNDARES DE SEGURIDAD DE LA INFORMACIÓN MÉDICA Y FIRMA ELECTRÓNICA
El nuevo estándar de seguridad proporcionará un nivel de protección uniforme a toda la información médica que se aloje o se transmita electrónicamente, y pertenezca a una persona. Además, las organizaciones que usen firmas electrónicas deberán cumplir con un estándar que garantice la integridad del mensaje, la autenticación del usuario y la ausencia de rechazo.

El estándar de seguridad obliga a tener sistemas de protección para el almacenamiento y mantenimiento físicos, para la transmisión y el acceso a la información de salud de una persona. Esto es válido no sólo para las transacciones que se lleven a cabo después de la entrada en vigor de la HIPAA, sino para toda la información de salud de una persona que se conserve o se transmita. El estándar de firma electrónica, sin embargo, sólo se aplica a las transacciones realizadas después de la entrada en vigor de la HIPAA.

El estándar de seguridad no exige el uso de tecnologías específicas; las soluciones variarán de una organización a otra, dependiendo de las necesidades y la tecnología de cada lugar. Asimismo, no se exige actualmente la firma electrónica para ninguna de las transacciones realizadas según la HIPAA.

IV. PRIVACIDAD Y CONFIDENCIALIDAD
La regla final de confidencialidad se publicó cuando terminaba el mandato del presidente Clinton, el 28 de diciembre de 2001. Ciertos problemas de papeleo retrasaron la comunicación al Congreso, por lo que la revisión del Congreso no comenzó hasta febrero, lo que retrasó la fecha de entrada en vigor de la regla hasta el 14 de abril de 2001. El Secretario del DHHS, Tommy Thompson, utilizó ese tiempo para solicitar comentarios adicionales durante el mes de marzo. El DHHS recibió más de 11,000 comentarios y como respuesta, tiene previsto emitir lineamientos y aclaraciones sobre la regla final. A partir del 14 de abril de 2003, se exigirá su cumplimiento por parte de la mayoría de las entidades.

En general, la privacidad se refiere a quién puede tener acceso a la información de salud que permite identificar a una persona. La regla abarca toda la información de salud con datos de identificación personal en manos de las entidades afectadas, independientemente de si dicha información está o estuvo en formato electrónico.

Los estándares de confidencialidad:

limitan el uso no consensuado y la divulgación de la información de salud privada;
dan a los pacientes derecho de acceso a sus registros médicos y a saber quién más ha tenido acceso a ellos;
restringen la divulgación de la información médica a lo mínimo necesario para los fines deseados;
establecen nuevas sanciones civiles y penales por el uso o divulgación indebidos;
establecen nuevos requisitos para el acceso a los registros por parte de los investigadores y otras personas.
La nueva regla refleja los cinco principios básicos planteados en ese momento:

Control del consumidor: la regla proporciona a los consumidores nuevos derechos críticos de control sobre la divulgación de su información médica
Límites: con pocas excepciones, la información de asistencia médica de una persona debe utilizarse exclusivamente para fines de salud legítimos, incluidos el tratamiento y el pago.
Contabilidad: con la HIPAA, por primera vez, habrá sanciones federales específicas si se viola el derecho a la confidencialidad de un paciente.
Responsabilidad pública: los nuevos estándares reflejan la necesidad de equilibrar la protección privada y la responsabilidad pública de apoyar prioridades nacionales, como la protección de la salud pública, el desarrollo de investigaciones médicas, la mejora de la calidad de la atención, y la lucha contra el fraude y el abuso en los servicios de salud.
Seguridad: es responsabilidad de las organizaciones a las que se confía la información médica protegerla contra el mal uso o la divulgación deliberada o accidental.

Fuente: www.hchdonline.com

MÉTODOS Y TÉCNICAS ANTIFORENSES

Según [Cano, 2007] Son métodos que limitan la identificación, adquisición, análisis y validación de la evidencia digital en cuanto a cantidad y calidad.

Cano, también da un concepto más amplio “Cualquier intento exitoso efectuado por un individuo o proceso que impacte de manera negativa la identificación, la disponibilidad, la confiabilidad y la relevancia de la evidencia digital en un proceso forense.”

Los objetivos de los métodos antiforenses son [Cano, 2007]:

• Limitar la detección de un evento que haya ocurrido.
• Distorsionar la información residente en el sitio.
• Incrementar el tiempo requerido para la investigación del caso.
• Generar dudas en el informe forense o en el testimonio que se presente.
• Engañar y limitar la operación de las herramientas forenses informáticas.
• Diseñar y ejecutar un ataque contra el investigador forense que realiza la pericia.
• Eliminar los rastros que pudiesen haber quedado luego de los hechos investigados.



COMENTARIO:

Entre los métodos antiforenses tenemos desde los más simples e ingeniosos hasta los más tecnificados por ejemplo:
- Uso de programas de freezado de sistema operativo, por ejemplo DeepFreezer
- Uso de CDs booteables que no escriben en el disco rígido y por tanto no dejan rastros.
- Uso de USB con tecnología U3 con propio sistema operativo y programas portables. Una variante en USB que no cuentan con tecnología U3 es el uso de programas portables almacenados en dispositivos USB (Ej. FireFox portable, Emule portable, etc).
- Uso de máquinas virtuales.
- Borrado de históricos del navegador de Internet.
- Ocultamiento de IPs con proxys anónimos.
- Uso de PCs en cibercafes para realizar actividades ilícitas
- Borrar los datos del archivo desde la aplicación. Ejemplo un documento de Word borrar los datos y guardar con el mismo nombre.
- Programas que cambian metadatos. Ej. Fecha de creación, modificación, etc.
- Cambio del dispositivo de almacenamiento (disco rígido utilizado para actividades ilícitas) por uno nuevo de paquete y con los programas que tenía el antiguo.
- Formateo de disco, solo borra el índice que indica donde están los archivos.
- Destrucción de datos (wipeado) mediante la sobreescritura de archivos.
- Ocultar particiones.
- Ocultar archivos mediante cambio de atributo a oculto, cambio de extensión o lo más tecnificado ocultar mediante estenografía en imágenes o audio.
- Encripción de discos y de datos mediante software o mediante hardware.
- Destrucción física es decir romper el disco, imantar, quemar, etc.


Sin embargo de todos los métodos y técnicas mencionados, cabe resaltar que si bien dificultan el trabajo del profesional forense, siempre se podrá recurrir a procedimientos alternativos que encuentren o den indicios de las actividades ilícitas. Por ejemplo: Si se encuentra que un disco rígido fue sometido a técnicas de wipeado se puede presumir que realizaba actividades de las cuales no quería ser descubierto. Si se conectó a Internet se podrá realizar la búsqueda de correos electrónicos, pedir datos a la ISP y es muy posible en algún momento utilizó dispositivos de almacenamiento USB, haber guardado nombres de usuario y contraseña en papeles.

No existe el crimen perfecto pues "siempre" se deja rastros y si existiera algún crimen perfecto, todovía no nos enteramos porque fuen tan perfecto que ocultó o borró bastante bien sus rastros.

También cabe mencionar una frase que me gusta bastante:
"No existe la verdad absoluta y esta frase es una verdad absoluta".



[Cano, 2007], Jeimy Cano. “Estrategias anti-forenses en informática: Repensando la computación forense”, Revista de Derecho Informático, No. 110 - Septiembre del 2007. http://www.alfa-redi.org/rdi-articulo.shtml?x=9608 Consultado 16/10/2010