EVT vs EVTX
Windows XP is no longer supported by Microsoft, but there are still XP
and 2003 systems out there, and as such, some of us are still going to
need to know the difference between Event Logs (XP, 2003), and Windows
Event Logs (Vista+).
Besides the binary differences in the records and Event Log files
themselves, on XP/2003, there were three main Event Log files; System,
Application, and Security. On my Windows 7 system, a 'dir' of the winevt\Logs folder reports 143 files. So, there is a LOT
of information being recorded by default on a Windows 7 system; while
not all of it may be useful to you, there is a great deal of information
that can be extracted from the logs when used properly.
Wevtx.bat
When I released Windows Forensic Toolkit 4/e, one of the things included in the additional materials is a batch file, wevtx.bat. What the batch file does is use LogParser to parse a directory full of .evtx files, and then parse those entries into TLN format for inclusion in a timeline. The tool evtxparse.exe,
used by the batch file, makes use of a mapping file (i.e.,
eventmap.txt) to map event source/ID pairs to an artifact category tag.
As such, when the entry in written to a timeline, records such as
"Microsoft-Windows-Security-Auditing/4624" are prepended with an
appropriate tag (i.e., "[Logon]"), based on the artifact category.
I really love this tool! What I like about it is that it's easy to
update (eventmap.txt is just a text file), I can add comments to it to
show the source of the information I used to map an event record to
something specific, and it acts as a fantastic little repository for all
of my past experiences. Not only is it a great repository, but it's
incorporated right into the tools that I use on just about every
engagement.
Records
Here are some of the event source/ID pairs that I've found to be useful
during investigations, for such things as malware detection, determining
the window of compromise, etc. I'll say up front that these
records are not 100% infallible, and may not have extremely high
fidelity (some do, others don't...), but they've worked quite well for
me at one time or another, so I'll share them here.
Microsoft-Windows-DNS-Client/1014
– DNS name resolution timeout; I've used this one more than once to
help demonstrate that malware was on a system, even in the face of
anti-forensics techniques (time stomping the malware files, deleting the
malware files, etc.). It's not a 100%, infallible indicator, but it's
worked for me more than once. What has also helped is when this
event record was seen; in a timeline, I could see that it occurred
shortly after a user logged into a laptop, and before the user connected
the system to a WAP. This helped me narrow down the persistence
mechanism for the malware.
Microsoft-Windows-Security-Auditing/4720 - user account created; because the bad guys do this from time to time.
McLogEvent/257 – McAfee malware detection - McAfee AV may detect
malware behaviors (i.e., run from a Temp folder, etc.) without actually
detecting the EXE itself. This can be very valuable in helping you
determine how malware got onto a system. Also, the AV product may be
configured to warn only, and take no action..so, correlate the event
records (UTC) to the entries in the McAfee logs (local system time)
Microsoft-Windows-Windows Defender/3004 – Windows Defender malware detection
Service Control Manager/7045 – A service was installed on the system
Service Control Manager/7030 – A service is configured to interact with the desktop
Microsoft-Windows-TaskScheduler/106 - New Scheduled Task registration
Beyond individual event records (source/ID pairs), one of the aspects of
the newer versions of Windows (in particular, Windows 7) is that there
are a lot of events that are being recorded by default, across multiple
Event Log files. What I mean is that when some events occur, multiple
event records are recorded, often across different Event Log files. For
example, when a user logs into a system at the console, there will be
an event recorded in the Security Event Log, a couple in the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx log, and a couple of events will also be recorded in the Microsoft-Windows-TaskScheduler/Operational.evtx
log. Alone, each of these individual events may get little attention
from an analyst, but when placed together in a timeline, they leave an
indelible mark indicating that a user logged into the system.
Now, what's really great about this is that some of the Event Logs "roll
over" faster than others. As such, some of the source/ID pairs that
are part of an indicator cluster may have been expired from their
respective Event Logs. However, the remaining source/ID pairs in the
cluster will still provide a very good indicator that that event in
question took place. This is particular useful for infrequent events,
and I've used this information more than once to demonstrate repeated
activity going back weeks and even months prior to what was thought to
be the date of interest.
Anti-Forensics
Event auditing is one of those things that just happens in the
background on Windows systems. This is great, because sometimes Event
Log records can help us determine if anti-forensics techniques have been
employed. For example, using Event Log records, you can determine if
someone has changed the system time.
During an exam, I found that a system had been infected with malware
that installed as a Windows service, and during the installation
process, the .exe file had been time-stomped. Fortunately, when the
malicious service was installed, an event source/ID pair of "Service Control Manager/7045"
was created, indicating that a new service had been installed on the
system. I was able to correlate that information with other sources
(MFT, etc.) to better determine the correct time of when the malicious
.exe was created on the system, and nail down the infection vector.
Carving
If you need to carve Windows Event Log records, for any reason...from
unallocated space, memory, the pagefile, whatever...the tool to use is
Willi Ballentin's EVTXtract.
The "tool" is really a set of Python scripts that you run consecutively
against the data in order to recover Windows Event Log records. I've
used these scripts a couple of times, and even had a fellow team member
use them on an engagement and quite literally recover the "smoking gun".
When carving for deleted records on a Windows XP or 2003 system, I use a
custom Perl script that I wrote that's based on some of the code I've
released with my books.
Timelines
When all this is said and done, a blog post on just individual Windows Event Log records isn't really
all that valuable. Yes, I've created timelines from just a handful of
*.evtx files, for use in triage, etc. This has proved to be extremely
valuable to me.
Resources
WindowsIR: Timeline Analysis
SANS Reading Room: Detecting Security Events Using Windows Workstation Event Logs
NSA: Spotting the Adversary with Windows Event Log Monitoring
Fuente: http://windowsir.blogspot.com/2014/10/windows-event-logs.html
Mostrando entradas con la etiqueta logs. Mostrar todas las entradas
Mostrando entradas con la etiqueta logs. Mostrar todas las entradas
Representación gráfica Apache access.log con apache2dot y Graphviz
Etiquetas:
apache,
logs,
trafico
0
comentarios
Hemos visto muchas formas de representar el tráfico de red, alertas Snort, scan nmap, etc, de forma gráfica usando AfterGlow y Graphviz (dot, neato, circo, etc).
En esta ocasión vamos a parsear un fichero access.log de Apache para convertirlo en un fichero .dot y crear una gráfica a partir de éste.
Para ello vamos a descargar el fichero script de perl: apache2dot.pl que se encuentra aquí: http://www.chaosreigns.com/code/apache2dot/apache2dot.plParseamos el access.log de esta forma:
cat /var/log/apache/access.log | perl apache2dot.pl > access.dot
para Windows podemos reemplazar el cat por type.
Una vez tengamos el fichero .dot, solo nos resta usar neato, circo, fdp, etc, para crear la gráfica:
neato -Tpng -o access.png access.dot
el resultado:
si hacemos un zoom:
===============================
Agradecimiento a javcasta.com @javcasta por su colaboración en este artículo.
Relacionado:
- Visualización gráfica datos GeoIP con Argus, ra y Afterglow.
- Visualización interactiva de tráfico de red con INAV.
- Argus. Auditando el tráfico de red. Parte 4. Generación de gráficas con AfterGlow.
- Argus. Auditando el tráfico de red. Parte 5. Auditoría de host remoto.
- Argus. Auditando el tráfico de red. Parte I
- Argus. Auditando el tráfico de red. Parte 2
- Argus. Auditando el tráfico de red. Parte 3. Generación de gráficas con ragraph.
- Visualización gráfica Nmap / Scapy Scan con Afterglow / Argus racluster. Clustering y gráficas fdp. Parte 1
- Argus. Auditando el tráfico de red. Parte 6. Argus y Geolocalización con GeoIP
Y hasta aquí por hoy. Hasta la próxima.
===============================
Fuente:https://seguridadyredes.wordpress.com/2011/07/06/representacion-grafica-apache-access-log-con-apache2dot-y-graphviz/
glTail.rb. Visualización gráfica en tiempo real de ficheros logs en servidores.
Etiquetas:
logs,
seguridad,
servicios
0
comentarios
Hemos visto muchas herramientas para visualización gráfica de capturas de red, logs, etc. Tenéis mucha más información y artículos en la serie creada al respecto: Visualización gráfica tráfico de red.
En esta ocasión vamos a estudiar una heramienta desarrollada en ruby que, conectando a un servidor local o remoto mediante SSH, es capaz de mostrar en tiempo real una serie de datos que toma de los ficheros logs. De esta forma es capaz de mostrar datos de logs de herramientas como Apache, Rails, IIS, Postfix/spamd/clamd, Nginx, Squid, PostgreSQL, PureFTPD, MySQL, Tshark, qmail/vmpop3d. Además es capaz de mostrarlos de forma simultánea. Esta herramiente es glTail.rb.
Muestra, en tiempo real, datos como: dirección de orígen/destino, protocolos usados, peticiones por minuto, ancho de banda, etc.
Instalando glTail.rb.
Para instalar glTail.rb he seguido la siguiente secuencia:sudo apt-get install rubygems rake ruby1.8-dev libgl1-mesa-dev libglu1-mesa-dev libglut3-dev build-essential
sudo gem install net-ssh ruby-opengl -r
sudo gem install -y file-tail -r
Ahora descargamos glTail.rb:
wget http://rubyforge.org/frs/download.php/39787/gltail-0.1.8.tgz
tar -zxf gltail-0.1.8.tgz
cd gltail-0.1.8
Ahora tenemos que modificar / personalizar el archivo config.yaml que se ubica en gltail-0.1.8/dist/config.yaml para incluir lo servidores y comentar lo que no proceda. En mi caso y para este primer ejemplo:
servers:
site1:
host: 192.168.1.96
user: preludeids
password: tatachintatachan
command: tail -f -n0
#files: /var/log/apache/access_log
files: /var/log/apache2/other_vhosts_access.log
parser: apache
color: 0.2, 1.0, 0.2, 1.0
# rails:
# host: anotherfunsite.com
# user: anotherfunuser
# port: 222
# command: tail -f -n0
# files: /var/www/apps/funapp/current/log/production.log
# parser: rails
# color: 0.2, 0.2, 1.0, 1.0
# dev:
# host: clockingit.com
# source: local
# files: /var/www/clockingit/logs/production.log
# parser: rails
# color: 0.2, 0.2, 1.0, 1.0
¿ Qué hemos hecho ?.Hemos indicado para el site1 la IP del host remoto, usuario y contraseña para conectar mediante SSH y en files la ubicación del archivo log de apache.
Este sería una configuración de los más simple. Podríamos configurar dos fuentes de datos. Por ejemplo logs de Apache y Tshark:
Observad como he sustutuido el por defecto site1 por algo más personalizado para mi server donde se ubica prewikka (SIEM Prelude IDS / IPS) y otro para la ubicación de un log de Tshark donde estoy ejecutando esta herramienta en tiempo real.
La línea de comandos simple para volcar la salida de tshark en un fichero log sería:
tshark -ieth0 > tshark.log
También podemos, en el tag config, modificar dimensiones, tamaño de nodos, etc.
Ejecutando glTail.rb.
Ejemplo.1
En este primer ejemplo voy a usar un solo site. Un servidor HTTP Apache:
prewikka_1:
host: 192.168.1.96
user: preludeids
password: tatachintatachan
command: tail -f -n0
#files: /var/log/apache/access_log
files: /var/log/apache2/other_vhosts_access.log
parser: apache
color: 0.2, 1.0, 0.2, 1.0
Una vez salvado el archivo y dentro de la carpeta bin donde se encuentra gl_tail, ejecutamos de la forma:alfon@alfonubuntu:~/gltail-0.1.8/bin$ ./gl_tail ../dist/config.yaml
El resultado es:
Tenemos 3 columnas:
- Columna izquierda. Tenemos información del site o sites. En este caso el site (prewikka_1). Vemos un resúmen del contenido de las peticiones (imagenes, hojas de estilo, javascript..). Status HTTP y usuarios, en este aso dos IP que realizan peticiones al servidorHTTP Apache junto a las peticiones o requests por minuto (r/m).
- Columna central. Representa la información grafica, en tiempo real de los request o peticiones (de izquierda a derecha) y las respuestas del servidor mediante nodos en 3D. El tamaño corresponde al “volumen” de la petición. Como respuesta del servidor, tendremos otros nodos que irán de derecha a izquierda.
- Columna derecha. Información sobre las URLs requeridas por el origen de las peticiones junto a requests/minuto. Información de User Agent usado por el user o usuario que realiza las peticiones.
Sobre visualización gráfica de logs de apache tenéis también:
Representación gráfica Apache access.log con apache2dot y Graphviz
Ejemplo.2
Bien, ahora vamos a usar Inguma-0.4 y nikto para realizar una auditoría del sitio web y vamos a observar el tráfico. El resultado es:
Observad la cantidad de requerst / minuto que genera nikto y en la columna de la derecha aparece una nueva columna: WARNINGS. código 404.
El User Agent, que no se aprecia bien en la captura, es Python urllib/2.6. GlTail ha detectado que se trata de un script de python.
Si realizáis esta prueba veréis en movimiento (tiempo real) todas estas “transacciones” y los nodos más pequeños de respuestas del servidor (de derecha a izquierda).
Ejemplo.3
Ahora voy a desactivar le site prewikka_1 y activar el site y parser Tshark. Ponemos en marcha Tshark.sudo tshark -ieth0 > tshark.log
Ahora para probar realizo un scan con nmap.
En este caso solo tendremos información en columna izquierda y central:
Aquí vemos un nuevo tag de información que es TYPE. Referidos a los protocolos. En este caso TCP con 293.04 r/m.
==========
Hasta aqui por hoy. Hasta la próxima.
Fuente:https://seguridadyredes.wordpress.com/2011/09/16/gltail-rb-visualizacion-grafica-en-tiempo-real-de-ficheros-logs-en-servidores/
Espiar cambios en un fichero de log
Etiquetas:
linux,
logs,
trucos
0
comentarios
Recientemente ando enfrascado en un pequeño proyecto personal (e informático, que de otras índoles tengo más 
Como me he sorprendido usando un comando (que explicaré en breve) que me permita desde la terminal ir visualizando los cambios sin tener que estar abriendo continuamente el fichero o haciendo un cat del mismo, y recordando que al principio usaba alguno de los dos métodos anteriores (con lo “cansados” que son), he optado por ofreceros la solución por si a alguno le viene bien.
Un poco de culturilla “general”
Un fichero de log o registro es un archivo en el que se van anotando todos los sucesos que ocurren en determinado sistema.
Ésta no es una gran definición (pero para hacernos una idea puede servir) puesto que depende del programa que haga uso del fichero: no es lo mismo un fichero de registro de una aplicación en su fase de desarrollo que el log de un keylogger
Mostrando en pantalla los cambios de un fichero
A estas alturas nos dará igual que se trate de un fichero de registro como de cualquier otro fichero cuyo contenido cambie en el tiempo (imagina que estás redireccionando la salida de determinado comando a un fichero y te interesa ver lo que está escribiendo/haciendo).
Para poder ver los cambios en “tiempo real” bastará con lanzar
tail -f RUTA-AL-FICHERO
Sirva de ejemplo
tail -f /opt/joomla1.5/apache2/logs/error_log
Donde estoy espiando los cambios que se produzcan en el fichero error_log que se encuentra en el directorio /opt/joomla1.5/apache2/logs/ y que se correponde (podría haber puesto cualquier otro ejemplo) al servidor Apache que instalé en mi equipo con el stack de Bitnami para Joomla.
Marcando puntos de interés en el log
Aunque cada anotación en el fichero de log suele venir acompañada de la hora y fecha en la que se produjo
Cuando llevamos un rato trabajando con él puede resultar especialmente complicado (y cansado) encontrar dónde comienza la última anotación desde que miramos el fichero por última vez.
Una técnica que suelo utilizar es
- colocarme en la ventana en la que se muestran los cambios del fichero
- dejar pulsado un rato la tecla del guión (puedes usar la que más cómoda te resulte y/o guste
- pulsar el retorno de carro
NOTA: no tengas miedo que no se va a fastidiar el comando tail ni te vas a cargar el contenido del fichero de log.
Con ello conseguimos localizar rápida y fácilmente los cambios que se han producido: bastará con encontrar la última ristra de guiones y todo lo que esté debajo es nuevo
Conclusión
Método sencillo y rápido con el que conocer (conforme se producen) todos los cambios de un fichero.
Espero os sea de utilidad y evitéis (como sufrí en mis inicios) tener que estar abriendo y cerrando ficheros de log para ver los cambios.
FUENTE:http://andalinux.wordpress.com/2009/03/10/espiar-cambios-en-un-fichero-de-log/
Suscribirse a:
Entradas (Atom)
Entradas
