Archive for the ‘Detección’ Category

Newer Entries »

Breve análisis de mail engañoso - II

Friday, September 21st, 2007

Siguiendo con el análisis sintetizado del malware anterior, se observó el siguiente hallazgo en VirusTotal.


Análisis del archivo Software.BBVAperu.exe recibido el 21.09.2007 22:44:45 (CET)

Motor antivirus Versión Última actualización Resultado
AhnLab-V3 2007.9.22.0 2007.09.21 -
AntiVir 7.6.0.15 2007.09.21 -
Authentium 4.93.8 2007.09.21 -
Avast 4.7.1043.0 2007.09.21 -
AVG 7.5.0.485 2007.09.21 -
BitDefender 7.2 2007.09.21 -
CAT-QuickHeal 9.00 2007.09.21 W32.Brontok.Q
ClamAV 0.91.2 2007.09.21 -
DrWeb 4.33 2007.09.21 -
eSafe 7.0.15.0 2007.09.19 suspicious Trojan/Worm
eTrust-Vet 31.2.5154 2007.09.21 -
Ewido 4.0 2007.09.20 -
FileAdvisor 1 2007.09.21 -
Fortinet 3.11.0.0 2007.09.21 -
F-Prot 4.3.2.48 2007.09.21 -
F-Secure 6.70.13030.0 2007.09.21 -
Ikarus T3.1.1.12 2007.09.21 -
Kaspersky 4.0.2.24 2007.09.21 -
McAfee 5125 2007.09.21 -
Microsoft 1.2803 2007.09.21 -
NOD32v2 2544 2007.09.21 -
Norman 5.80.02 2007.09.21 W32/Suspicious_M.gen
Panda 9.0.0.4 2007.09.21 Suspicious file
Prevx1 V2 2007.09.21 -
Rising 19.41.42.00 2007.09.21 -
Sophos 4.21.0 2007.09.21 Mal/Packer
Sunbelt 2.2.907.0 2007.09.20 VIPRE.Suspicious
Symantec 10 2007.09.21 -
TheHacker 6.2.5.064 2007.09.21 W32/Behav-Heuristic-066
VBA32 3.12.2.4 2007.09.20 -
VirusBuster 4.3.26:9 2007.09.21 Packed/MEW
Webwasher-Gateway 6.0.1 2007.09.21 Win32.Malware.gen#MEW (suspicious)
Información adicional
Tama?rchivo: 77878 bytes
MD5: e620a25ba56dea87fe6bb1004284298e
SHA1: 980a1074bf19c7e1f9bc4d6b0a0160ba64ceb157
packers: MEW
packers: MEW
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

Un ranking nada malo, para un malware que no tiene mucha complejidad de evasión (UPX, anti-debugging, etc). Esto último debido a que usa un artificio bastante viejo (quizás todavía útil), al modificar el archivo host del sistema infectado c:\windows\system32\drivers\etc, como sigue:

66.227.127.163 www.[nombre-banco].com
66.227.127.163 [nombre-banco].com]

Dirección que pertenece a otro proveedor de hosting web en Exton, PA (USA). Una réplica exacta al sitio web original.

Sin embargo, haciendo un examen muy sutil de los enlaces, se determinó que en el sitio web falso no enviaba a sitios ajenos al de la compañía original. Algo muy extraño, para tan elaborado esquema de fraude.

Una idea posible es, la intención del atacante de sensar el número de usuarios que van a caer en esta trampa.

Posted in Detección, Knowledge | No Comments »

Breve análisis de mail engañoso - I

Friday, September 21st, 2007

Desde hace varias semanas atrás, varios escritores de malware están aprovechando la imagen de instituciones, de las que se supone se preocupan por la seguridad de sus usuarios informáticos o del público en general (generalmente con el ardid de una herramienta anti-phishing). Prueba de ello es el siguiente correo que llegó a un dominio peruano, hace unas pocas horas.

Al analizar rápidamente el mensaje engañoso se descubre:

1. Dirección IP del host donde se halla el malware, siendo este uno como “http://xx.yyy.201.115/Software.BBVAperu.exe, proveniente de un aparente servidor de hosting web hackeado en Chicago, IL (USA), en la que además se observa una imagen muy sugerente que proviene de un servidor aparentemente aislado a estos hechos (FantasyMundo.com).

2. Dirección IP del host de donde fue emitido el correo, siendo éste uno como xx.yyy.150.29, proveniente de un servidor (también, posiblemente hackead) ubicado en España, que redirecciona a una aplicación webmail (Horde) en el mismo servidor.

3. Direcciones IP (dentro del código html fraudulento) de la imagen relativa a la entidad que se procura falsificar, que responde DiaDeNegocios.com.ar y VisaNet Perú, una buena forma de evadir la técnica de contra phishing que publicase este blog en pasadas fechas.

Posted in Detección, Knowledge | 1 Comment »

Cómo descubrir al ciber-delincuente de un phishing

Thursday, September 13th, 2007

Esta es una excelente y sencilla lección para aquellos bancos que se están iniciando en la búsqueda y cacería de las mafias de phishing, vea http://seguridad.internautas.org/html/4315.html

Un trabajo similar realizamos hace varios años en un laboratorio educativo de análisis de phishing contra un banco famoso. Vea: http://www.jacksecurity.com/publicacion.php?idpub=4

Posted in Detección, Knowledge | No Comments »

“Decode or encipher”

Tuesday, September 4th, 2007

Un lugar para visitarRecientemente, en una amena conversación tecnológica con unos colegas de internetworking acerca de una tecnología de comunicaciones de señal abierta (inalámbrica), descubrimos que más de una persona de redes confunde la dificultad entre decodificar (decode) y descifrar (encipher), ambas cosas no son lo mismo.

Aunque una señal que viaja por el aire, puede estar codificada con un protocolo propietario, ello no significa que no pueda ser desmenuzado a fin de obtenerse la data que viaja dentro de ella. Una posibilidad es hacerlo con un analizador de protocolo propietario, es decir, de la misma compañía que lo diseñó, o con una copia pirata de la trama o framework del protocolo en mención. De ello no nos cabe la menor duda, pues hace unos años atrás conocimos a un colega de análisis de protocolos que desarrolló un decodificador, usando un módulo avanzado de un software de olfateo de red.

En resumen, no hay ninguna seguridad al respecto de cualquier data que viaja inalámbricamente, sólo porque el protocolo es propietario.

Una situación muy diferente es si la data dentro de la trama del protocolo inalámbrico propietario, o mejor aún todo el tráfico viajase cifrado. Si ciframos, con la ayuda de un buen protocolo criptográfico, no tendríamos problemas en la seguridad de transmisión, aún si alguien tuviese acceso a la constitución del tramado de los paquetes que viajan en dicho protocolo propietario.

Esta confusión no es de esperarse en alguien que en su rato libre, ha visitado un lugar como el Museo del Espionaje en (Washington, DC), o que se ha preparado bien (en el módulo de criptografía) para su examen CISSP. El próximo examen CISSP en Lima auspiciado por JaCkSecurity será el 28 de octubre.

Posted in Detección, Knowledge | No Comments »

Macro comando para detectar intrusos: TCP[13]=0×02

Wednesday, August 29th, 2007

TCP-13th-byte
TCP[13]=0×02 ó TCP[13:1]=0×02

Este sencillo, pero extremadamente útil comando de tcpdump, es la navaja suiza en la mente de un especialista en detectar intrusos.

Sólo en ésta semana, el haberlo tenido grabado en nuestra mente, ayudó a uno de nuestros clientes a detectar con rapidez los centros de ataque de un problema muy serio que golpease su red.

Sin duda, no nos equivocamos hace más de 2 años atrás, cuando -a estos macro comandos- le diseñáremos un arte nmemónico para imprimirlo en un estilizado polo de baseball via Cafepress, y se lo obsequiáremos -como premio- el primer colega peruano en obtener localmente su certificado GCIA (GIAC Certified Intrusion Analyst).

De igual manera, usted tampoco se equivocará en invertir en el curso de detección de intrusos de SANS Institute que viene promoviendo localmente JaCkSecurity.


SEC 503 Intrusion Detection In-Depth
Inscríbase pronto.

Posted in Detección, Knowledge, SANS-SEC503 | No Comments »

Análisis de Internet durante el terremoto peruano

Monday, August 20th, 2007

Se esperaba que luego del lamentable terremoto que dañara el sur del Perú, el pasado 15 de agosto, el consumo del Internet local disminuyera a sus niveles más bajos, producto de las masivas evacuaciones que se realizaron en las oficinas y hogares conectados a la red. Sin embargo, esta suposición quedó desacreditada luego de observar las gráficas de intercambio del NAP Perú, hecho que a su vez provocó una interrogante: ¿qué generó ese tráfico?

Aunque parte de este remanente pudo haber sido generado por personas no afectas al terremoto (población norteña del Perú) -además de usuarios proclives al Internet como alternativa de comunicación (Ej. correo), es altamente probable que mucho de éste tráfico haya sido generado por código autómata. En ese sentido, varios colegas tienen interesantes teorías al respecto:

Nota: Entre un 30 y 50 porciento del tráfico normal, fue el remanente de consumo que permaneció entre los 7 de los 9 proveedores de Internet conectados al NAP Perú.

Tráfico autómata no malicioso:
- Actualizaciones de herramientas antivirus
- Actualizaciones de sistemas operativos y aplicaciones
- Correo electrónico encolado
- Conexiones a radios en-línea
- Conexiones a TV en-linea
- Telefonía IP
- Similares

Tráfico autómata producto de efectos del mundo cibercriminal:
- Amplificación de código malicioso (gusanos) a través de diversos puertos (P.e.1433, 5900, 2967, 2968)
- Abuso de proxies abiertos (puertos 3128, 8080)
- Descargas peer-to-peer no permitidas
- Tráfico tunelizado vía puerto 80 (para disfrazar tráfico no permitido)
- Tráfico de señalización y comandos de botnets (80 ó 6667)
- Port scan y host scans
- Tráfico de shells reversos, backdoors y similares (puertos muy bajos o muy altos)

Ante éste interesante escenario, se recomienda a los administradores de sistemas el examinar los registros de monitoreo de sus redes en dicha fecha. La probabilidad de hallar tráfico autómata malicioso es alto, y beneficiará en mejorar la seguridad de su compañía. JaCkSecurity sugiere ésta labor, especialmente, a aquellas personas que van a participar del curso SEC 503 Intrusion Detection In-Depth.

Descargue el análisis de las gráficas de Internet desde el portal

Posted in Knowledge, SANS-SEC503, Zombis | 1 Comment »

Cómo protejes los -suyos- de tu red

Monday, July 9th, 2007

No, esto no es un error de redacción, tampoco es un artículo del cuidado infantil por Internet. La palabra “suyos”, acá, viene a colación del idioma oficial que hablaban los antiguos peruanos, los creadores de Machu Picchu, el ombligo del Tahuantisuyo (hoy, una de las 7 Nuevas Maravillas del Mundo).

Zonas del Imperio Inca

Suyo es una palabra del quechua, que significa zona o territorio. Como soñar no cuesta nada, (estimado compatriota): ¿se imagina qué palabra emplearía hoy un ingeniero de sistemas, hablando de DMZ | zonas | perímetros de red, si el quechua hubiese llegado a convertirse en el idioma predominamente de la Tierra? Es probable que en las conferencias de seguridad se hablarán más de SUYOS y PUCARÁS, que de DMZs y firewalls. Por esa razón, como peruano, oso preguntarle ¿cómo protejes los -suyos- de tu red?

Para aquel buen porcentaje de dueños de firewalls, que suelen no conformarse con adquirirlo, sino -además- configurarlo, es altamente probable, que la mejor configuración que le hayan propuesto los “expertos” el día de su instalación, fuese sólo la de filtrar el tráfico que ingresa, mas no el que sale. Si ese es su caso, continúe leyendo.

Si bien todo lo externo a la red es por definición hostíl y desconocido, lo cierto es, que aún las redes internas pueden ser un nido de zombis, botnets, y piratas. Por ello, filtrar el tráfico que sale, es tan o más útil que el filtro de entrada. ¿Por que puede ser “tan o más útil”? La razón es simple: el día que deje de tener servidores importantes en su red y las termine llevando a un proveedor de hosting, para lo único útil que servirá su firewall, es para pasar paquetes. En vez de eso, se debe aprovechar al máximo la tecnología. Es así que, son necesarios, los filtros salientes.

Un filtro saliente, asegura que nadie esté pasando tráfico (e información) hacia el exterior. Hoy, en los tiempos en donde casi las botnets han desplazado a los antiguos troyanos, es doblemente real la amenaza de tráfico saliente. Una red con PCs zombis, tiene de todas formas tráfico que sale, esto es, aquel tráfico que procura enganchar el PC zombi con el cuartel general de la “botnet” (A.K.A. “cc” o comando y control de zombies), para recibir nefastos comandos.

Por otro lado, un filtro saliente, no sólo protege el segmento de estaciones de su red, también protege a los servidores. Un filtro saliente, bien afinado (sin cometer errores de protocolos) con la red de servidores, ayudará a que éstos no sean usados por una varidad de formas de abuso, por ejemplo, los proxies (encapsulamientos), o por las conexiones provocadas por shells en servidores web (cmds, tftps, xp_cmd…) y otras estimulaciones generados a servidores de correo o aplicación web (típicamente para provocar la fuga de información), vía vulnerabilidades o facilidades de los sistemas.

Proteger de esta forma sus -suyos- hace que su red sea más segura, y no tenga que ser sorprendido un día con que sus servidores y estaciones se dedican a enviar SPAM, cuando los usuarios apenas si saben usar el Windows. Esto es todavía mejor, si en el supuesto que su red sea traspasado por intrusos, el bloquear todo (o casi todo) el tráfico saliente, eliminaría toda chance para que le retorne un prompt/shell al villano que la penetró. La cosa no para allí nada más, imagínese todo lo que puede hacer en términos de “análisis de detección de intrusos” con aquellos registros de negación de sesiones que son generados por sus servidores y estaciones detrás del firewall (si activa correctamente el filtro y registro). Si desea aprender más técnicas de detección de intrusos, lo invito a inscribirse al curso que dictaré para SANS Institute, ahora en octubre.

J.R.
SANS Local Mentor

Posted in Detección, Knowledge, SANS-SEC503 | No Comments »

Newer Entries »