DFIR - HUNTING

.

KILL CHAIN, DIAMOND, RESILIENCE, DETECT...

Normas, métodos, buenas prácticas.

SONDAS, AMENAZAS, INCIDENTES, ANALISIS

Productos, configuraciones y análisis.

CYBERWARFARE, GOBIERNOS, APT AVANZADO

Los mejores casos en Conexión Inversa.

CIBERGUERRA, MALWARE

Te contamos como se diseñan y como se aplican.

ATAQUES EN RED, INTRUSIONES, MALWARE Y APTs

Todo lo necesario para minimizar el impacto.

miércoles, 17 de febrero de 2010

Protocolo de respuesta ante incidentes

Hola lectores,

Hoy vamos a tratar los temas relacionados con la respuesta ante incidentes. Tema muy importante dentro de una organización.

En nuestro día a día es mejor prevenir que curar, y la seguridad no es una excepción. Cuando se produce un incidente de seguridad, se debe garantizar que se minimice su repercusión. Para minimizar la cantidad y repercusión de los incidentes de seguridad, debe seguir estas pautas:
  • Establecer claramente y poner en práctica todas las directivas y procedimientos. Las directivas y los procedimientos se deben probar exhaustivamente para garantizar que son prácticos y claros, y que ofrecen el nivel de seguridad apropiado.
  • Evaluar de forma regular las vulnerabilidades del entorno. Las evaluaciones deben ser realizadas por un experto en seguridad con la autoridad necesaria (con derechos de administrador de los sistemas) para llevar a cabo estas acciones.
  • Establecer programas de formación sobre la seguridad tanto para el personal de TI como para los usuarios finales.
  • Se deben enviar mensajes. Carteles de seguridad que recuerden a los usuarios sus responsabilidades y restricciones, junto con la advertencia de que se pueden emprender acciones legales en caso de infracción.
  • Comprobar con regularidad todos los registros y mecanismos de registro. Cortafuegos, IDS's, etc.
  • Comprobar los procedimientos de restauración y copia de seguridad.

Particularmente he realizado un procedimiento de comunicación que nos puede ser útil para estos casos, va por ustedes:

PROTOCOLO DE COMUNICACION

Cuando un problema o incidencia en las instalaciones, medios técnicos o recursos humanos tenga como consecuencia previsible no poder prestar alguno o todos los servicios encomendados se entrará en situación de EMERGENCIA.

Niveles de emergencia


Para establecer los protocolos de actuación se definen los siguientes Niveles de emergencia:

Nivel Descripción Ejemplos
 0 (Prealerta)
Detectada la incidencia pero se prevé su resolución en un periodo inferior a 15 minutos o no afecta de manera importante a los servicios prestados
1 (Básica)
Fallo en las instalaciones o sistemas informáticos que dificultan de manera importante o impiden la prestación de algunos servicios  Pérdida de la conexión a internet, Fallo de algún aplicativo,...
 2 (General)
Fallos en las instalaciones o sistemas informáticos que impiden la prestación de la mayoría de los servicios Caídas de centralita, caídas de corriente eléctrica, pérdida de las comunicaciones , intrusiones
 3 (Crítico)
 Situaciones que exigen al abandono del puesto de trabajo por razones de seguridad  Incendio, emergencias generales del edificio, ...


La valoración del nivel de emergencia en el que se encuentra el departamento de TI y, por tanto, el protocolo de actuación a aplicar será determinado por el Responsable de TI o del Call Center cuando estén presentes en el centro de trabajo ó por el operador que detecte la incidencia, si no se encuentra en el Centro ninguno de los responsables (en adelante, a esta persona la denominaremos COORDINADOR DE LA EMERGENCIA).

Protocolos de actuación

Las acciones a realizar en un supuesto de emergencia son las siguientes:

  1. Identificación del problema y gestión de su resolución
  2. Comunicación a la Dirección de la empresa
  3. Comunicación a Usuarios
  4. Registro y documentación de la incidencia

Identificación del problema y gestión de su resolución (Niveles 0,1,2,3)

Para analizar el nivel de emergencia en el que se encuentra el departamento de TI y la celeridad con la que se deben iniciar las diferentes acciones de este protocolo de actuación, el COORDINADOR DE LA EMERGENCIA deberá evaluar los siguientes aspectos del problema:

  1. Instalaciones y medios técnicos afectadosServicios comprometidos
  2. Duración previsible de resolución

En el caso de que estemos en situación Crítica (Nivel 3), deberá proceder a notificar la incidencia al 112 y seguir las instrucciones, en la medida de lo posible, procederá al apagado ordenado de los equipos de trabajo, siempre y cuando esto no comprometa la seguridad de los trabajadores.
En el resto de los niveles de emergencia, se procederá a informar del problema al personal encargado para su resolución:

  1. Problemas con las instalaciones (electricidad, climatización, ...)
  2. Medios técnicos (centralita, comunicaciones, ordenadores,...)
  3. Personal (accidentes, enfermedad)

El COORDINADOR DE LA EMERGENCIA se encargará de comprobar que los incidencia es resuelta y los servicios se vuelven a prestar con normalidad.

Comunicación a la Dirección

La cadena de mando es la siguiente:

  1. Responsable del servicio de emergencias
  2. Director de Recursos Humanos
  3. Director General

Dependiendo del nivel de emergencia, el COORDINADOR DE LA EMERGENCIA deberá actuar de la siguiente forma:

Nivel Acción
1 (Básica) Localizar mediante llamada al teléfono móvil al Responsable de TI o mandos superiores o a uno de los Directores superiores siguiendo el orden de la cadena de mando
2 (General)
3 (Crítico)
Localizar mediante llamada al teléfono móvil al Responsable de TI o a uno de los Directores siguiendo el orden de la cadena de mando.
La persona contactada deberá informar al resto de la cadena de mando

jueves, 11 de febrero de 2010

Depredadores

Una chica de 16 años contactada por Tuenti sufre una agresión sexual en cadiz.

El 'grooming' o acoso a los menores suele ser protagonizado por los adultos que, tras ganarse la amistad o confianza de aquellos a través de Internet, obtienen satisfación sexual mediante imágenes eróticas que el propio menor facilita insconscientemente o bajo amenaza.


En octubre pasado, la BIT detuvo en Cádiz a un depredador que llegó a ocasionar el suicidio de un niño Estonio de 11 años. El hijoputa de agresor se hizo pasar por una adolescente. El chantajista gaditano distribuyo las fotos de este niño ante los amigos de este. Ante la verguenza se pego un tiro con la pistola de su abuelo.

En Agosto un estudiante de 23 años tenía sometido a un bestial asedio a más de 200 adolescentes. Este personaje se pegaba más de 12 horas de caceria por Internet. Una chica de Madrid acosada por este individuo escribio una carta en la que decia "Mamá, no aguanto más. La única salida que veo es el suicidio"

El procedimiento que utilizan es muy simple, buscan un niño o niña que les encaje con sus fantasias sexuales. Les envía un mensaje haciéndose pasar por un adolescente, este solicita su dirección de correo y Messenger (en casi el 95% de los casos) para poder 'intimar' más en su confianza.

Los depredadores son expertos en informática comparados con sus victimas y visitán sitios 'underground' con el objeto de aprender a crear, utilizar y distribuir troyanos a sus victimas para tener el control absoluto. De esta forma tienen acceso a su correo, lista de amigos y demas ficheros.

Como ejemplo voy a poner unas pantallas de un caso que todavía sigue abierto, pero que por motivos etico-morales voy a exponer.

ENTRANDO AL CHAT

Parece ser que este individuo depredador 'habita' por un conjunto de chats de acceso publico y no moderado. La victima de nuestro caso es una adolescente de 16 años y de nombre Eva.

Una vez que nos han pasado sus datos y bajo tutela notarial y judicial nos hacemos pasar por la victima, estos son algunos resultados.

1.- Entramos al Chat (uno muy famoso) a la hora más o menos prevista. El sujeto en cuestión abre una sesión personal de chat conmigo y esta es la conversación. Simplemente le seguimos el juego.


2.- Me invita a una sesión personal en el Messenger. Entro antes que el y el sujeto aparecía como desconectado y con el nombre de 'Carla'. Nada más entrar lo cambia y se llama 'yo'

Comprobamos su perfil publico en Live Messenger, apenas tiene nada, tan solo confirmamos que se hace llamar 'Carla'

 
3.- Seguimos con la conversación y esta sube de tono...la cosa se calienta .
 
 4.- En este punto es cuando 'me seduce'
  
 

Esta conversación la reduzco y vamos al grano. Despues de unos días de conectarnos y hablar durante horas me dice que me manda un albúm de fotos en un fichero. Este se llama "book_barna.jpg.exe.zip" .  Además con objeto de obtener más información de este 'pajarrraco' vamos a obtener como minímo la dirección IP desde donde nos manda el fichero, dado que el envío de archivos no pasa por los servidores de Microsoft.

 

Como nota hay que decir :
  • La videoconferencia, audio, video y llamadas de PC a teléfono utilizan los puertos UDP 5004-65535 (desde el puerto UDP 5004 hasta el puerto UDP 65535). 
  • Compartir aplicaciones y pizarra utiliza el puerto TCP 1503
  • La transferencia de archivos requiere los puertos TCP 5000-6900. Estos puertos permiten hasta 10 transferencias simultáneas por usuario. 
Para ver la IP publica durante la transferencia del fichero hacemos un NETSTAT. He borrado las IP's por confidencialidad, dado que el caso está abierto. En este caso ya lo tenemos.


EL FICHERO BOOK_BARNA.JPG.EXE.ZIP

¿Que nos ha mandado nuestro amigo?. Vamos a ver que opina virustotal.



 

Parece que hay un troyano que solo lo detectan dos casas de antivirus pero indetectable para todos los demas.

Y como se suele decir hasta aquí puedo hablar....

CONCLUSIONES

Hay que incrementar los esfuerzos para proteger a nuestros más jóvenes. Entiendo que con programas de formación o algo parecido. ¿Recordais cuando nuestros padres nos decían?

.- Si un señor te da un caramelo no lo cojas
.- Si te dice que te vayas con el no lo hagas

¿Tan difícil es extrapolar a internet esa concienciación?, ¿Que les pasa a los padres?, ¿saben que hacen sus hijos cuando están horas y horas conectados a internet?.

Creo que es hora de que la concienciación fluya dado que la tecnología nunca podrá solucionar este problema, mas cuando los depredadores aprenden a manejar troyanos como verdaderas pistolas de fuego y es que esta claro, las reglas han cambiado y nuestra forma de actuar también.

lunes, 1 de febrero de 2010

Sesiones restauradas en navegadores y (II)

Hola lectores,

Vamos a continuar con el post de sesiones restauradas.

RESTAURANDO LA SESION DE OPERA

Opera una vez instalado en el sistema, disponemos de la siguiente ruta y ficheros donde almacena las sesiones visitadas.

En Windows XP:

c:\documents and settings\Username\Local Settings\Aplicattion Data\opera\opera\sessions

En Windows 7:

c:\users\Username\AppData\Local\opera\opera\profile\sessions

Y especialmente a los ficheros 'autosave.win' y 'autosave.win.bak'

Estos ficheros están en formato RAW y es tan fácil como editar su contenido con el bloc de notas para obtener la información.


Destacamos la cabecera [session] que contiene la versión de navegador y el número de pestañas que tenia antes de cerrar la sesión.

La información que muestra es muy sugerente y si queremos restaurar las pestañas con todo su contenido podemos iniciar Opera y es el propio navegador quien nos suguiere la restauración entre otras opciones (así de sencillo).




RESTAURANDO LA SESION DE SAFARI

Una vez que este instalado el producto disponemos de las siguientes rutas

Windows XP:

C:\Documents and Settings\\Application Data\Apple Computer\Safari

Windows 7:

C:\Users\antoine\AppData\Roaming\Apple Computer\Safari

Mac OSX:
/Users//Library/Safari

Disponemos de una serie de ficheros con extensión '.plist' especialmente el que se llama 'LastSession.plist' que contiene la sesión a restaurar. Este es el fichero donde se va almacenando las sesiones visitadas.

Si lo editamos con un editor podremos ver los sitios web, posición , Nombre de la ventana, marcadores, etc.

CURIOSIDADES FORENSES DE SAFARI

Ya que estamos, me he puesto a revisar un poquito la estructura de Safari y esto es lo que he visto:

Safari dispone de dos rutas alternativas que contienen los ficheros '.plist' y ficheros con extensión '.db' ambos son auditables y se puede obtener información para un posterior análisis forense. Vamos a ver algunos ejemplos:

He utilizado la utilidad de foundstone 'bintext' para poder parsear de una forma comoda los ficheros en formato binario.

En el fichero 'lastsession.plist' contiene las pestañas a restaurar con su contenido exacto.


En la ruta "C:\Users\antoine\AppData\Roaming\Apple Computer\Safari" nos encontramos con el fichero 'History.plist' como podemos apreciar ha estado en un sitio de contactos

Editando con la utilidad 'SQLite Administrator' el fichero 'database.sqlite3.db' nos encotramos con la tabla 'feeds' con lo que podemos saber a que feeds está suscrito.


Otra forma curiosa que he visto y no distingo para que lo emplea Safari,  es la tabla autores que contiene el nombre y en algún caso el correo electrónico de los sitios visitados.


Estas y otras opciones también se pueden hacer desde el propio navegador una vez iniciado de forma que podemos reconstruir las páginas a las que se ha accedido, por ejemplo el top de páginas visitadas (recordamos que están en el fichero de TopSites.plist)


Y por último el historico (del fichero history.plist)


Espero que os sea de utilidad estos dos post como minímo habremos aprendido algo sobre otros navegadores que no son de la familia Microsoft, y quien sabe si en algún análisis forense nos puede ser de ayuda estos ficheros.

Análisis Forense en profundidad 2.0 - Nuevo Curso -

Buenas lectores, De nuevo y de la mano de @securizame llega una nueva entrega del curso "Análisis Forense en profundidad 2.0" ...