martes, 6 de enero de 2015
miércoles, 19 de diciembre de 2012
Regkeval
No tengo tiempo para actualizar este blog de momento ya que estoy volcado en actualizar Regkeval y las claves que utiliza, además del blog de soporte.
Para más información:
http://gotosec.blogspot.com.es/
http://code.google.com/p/regkeval/
http://gotosec.blogspot.com.es/
http://code.google.com/p/regkeval/
sábado, 10 de noviembre de 2012
Regkeval
He comenzado por fin la publicación de mi herramienta de busqueda y clasificación de claves y valores de archivos de registro offline. El nombre es Regkeval y la estoy subiendo a GoogleCode.
Me ha decidido a escribirla ya que no encontraba una herramienta que se adaptara a lo que quería totalmente. Hay muchas que hacen lo mismo y seguro que mejor pero ninguna me permitía definir las claves y valores a examinar, o bien no funcionaban sobre registros offline, o bien solo tenian GUI y no linea de comandos... para gustos los colores ¿no?
Creo que al ser abierta y facilmente configurable al gusto de cada uno puede ser util para alguien, y asi de paso contribuyo un poquito a la comunidad.
Me ha decidido a escribirla ya que no encontraba una herramienta que se adaptara a lo que quería totalmente. Hay muchas que hacen lo mismo y seguro que mejor pero ninguna me permitía definir las claves y valores a examinar, o bien no funcionaban sobre registros offline, o bien solo tenian GUI y no linea de comandos... para gustos los colores ¿no?
Creo que al ser abierta y facilmente configurable al gusto de cada uno puede ser util para alguien, y asi de paso contribuyo un poquito a la comunidad.
martes, 6 de noviembre de 2012
Esta entrada va a ser un repaso del funcionamiento del LastAccessUpdate de los archivos a cuenta de que me lo he encontrado al revisar un registro. El valor en concreto es el que establece si debe actualizarse el atributo Last Access Time del sistema de archivos.
La descripción de la clave y valor del registro la he encontrado en:
http://msdn.microsoft.com/en-us/library/ee377058%28v=bts.10%29.aspx
NTFSDisableLastAccessUpdate
Me parece muy importante destacar que el valor por defecto es 0 en XP pero 1 en Vista/7.
Parece que este valor ha generado mucha discusión en los foros ya que se afirma en muchos de ellos que el S.O. no actualiza el valor de LastAccessUpdate como debiera.
Creo que la confusión puede deberse en muchos casos al hecho de que ese valor no se actualiza de forma instantanea siempre que se accede a un archivo o directorio: la actualización depende de si el acceso es de solo lectura o no. Si es éste el caso no se actualiza de forma inmediata precisamente para evitar que todas las operaciones se conviertan en accesos de escritura, degradando el rendimiento del sistema.
Donde sí se actualiza es en memoria y se vuelca ese valor si se modifica otro atributo del archivo o si desaparece la referencia de la memoria. El retraso máximo que el sistema acepta para actualizar el valor es de una hora por lo que si leemos un archivo a las 14:00 y de nuevo a las 14:50 el sistema no lo actualiza. Si volvemos a leerlo a las 15:01 sí se actualiza el valor en disco para reflejar las 15:01.
El otro lugar donde se almacena el LastAccessUpdate de un archivo es en el índice del directorio. En este caso el sistema solo actualiza el valor cuando detecta que la diferencia entre el valor en el índice y el almacenado en memoria difieren en más de una hora, lo que ocurre cuando se elimina la referencia al mismo. También cuando se modifica otro de los atributos del archivo se actualiza el LastAccessUpdate con el valor que estaba en memoria. (Fuente: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true)
Como digo puede que se deba a esto pero no lo he comprobado personalmente.
Un ejemplo de malware que modifica este valor:
W32/Virut.n.gen!D4F31486AF8E
(http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=317086)
La descripción de la clave y valor del registro la he encontrado en:
http://msdn.microsoft.com/en-us/library/ee377058%28v=bts.10%29.aspx
NTFSDisableLastAccessUpdate
| Key: | HKLM\SYSTEM\CurrentControlSet\Control\FileSystem |
| Value: | NTFSDisableLastAccessUpdate |
| Data Type: | REG_DWORD |
| Range: | 0 – 1 |
| Default value: | 0 |
| Recommended value: | 1 |
| Value exists by default? | No, needs to be added. |
Me parece muy importante destacar que el valor por defecto es 0 en XP pero 1 en Vista/7.
Parece que este valor ha generado mucha discusión en los foros ya que se afirma en muchos de ellos que el S.O. no actualiza el valor de LastAccessUpdate como debiera.
Creo que la confusión puede deberse en muchos casos al hecho de que ese valor no se actualiza de forma instantanea siempre que se accede a un archivo o directorio: la actualización depende de si el acceso es de solo lectura o no. Si es éste el caso no se actualiza de forma inmediata precisamente para evitar que todas las operaciones se conviertan en accesos de escritura, degradando el rendimiento del sistema.
Donde sí se actualiza es en memoria y se vuelca ese valor si se modifica otro atributo del archivo o si desaparece la referencia de la memoria. El retraso máximo que el sistema acepta para actualizar el valor es de una hora por lo que si leemos un archivo a las 14:00 y de nuevo a las 14:50 el sistema no lo actualiza. Si volvemos a leerlo a las 15:01 sí se actualiza el valor en disco para reflejar las 15:01.
El otro lugar donde se almacena el LastAccessUpdate de un archivo es en el índice del directorio. En este caso el sistema solo actualiza el valor cuando detecta que la diferencia entre el valor en el índice y el almacenado en memoria difieren en más de una hora, lo que ocurre cuando se elimina la referencia al mismo. También cuando se modifica otro de los atributos del archivo se actualiza el LastAccessUpdate con el valor que estaba en memoria. (Fuente: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true)
Como digo puede que se deba a esto pero no lo he comprobado personalmente.
Un ejemplo de malware que modifica este valor:
W32/Virut.n.gen!D4F31486AF8E
(http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=317086)
miércoles, 24 de octubre de 2012
Evidencias de programas ejecutados: Shellbags y UserAssist.
La situación es tener que demostrar la utilización de programas desde equipos, de los cuales tenía alertas en los IDS sobre la utilización de determinado programa, en los que al revisarlos el administrador de turno no encontraba rastro de ellos en la lista que Windows le ofrece de programas instalados.
Parece que se trata entonces de programas que o bien no necesitan instalación o bien son versiones portables, que se han configurado y preparado para no necesitarla, y que en muchos casos presumen de eliminar todo rastro de su ejecución en el equipo desde el que se lanza.
Para detectar este tipo de software hay una serie de carpetas y artefactos del sistema operativo que pueden evidenciar su uso como son:
Bueno, empezando por los "Shellbags": se trata de claves del registro en las que el sistema guarda las preferencias de los usuarios sobre las aplicaciones y las carpetas. Esta información se guarda en el registro del usuario, el NTUSER.DAT, y como novedad en Windows Vista/7 hay que tener en cuenta el nuevo registro específico de cada usuario denominado USRCLASS.DAT y que se encuentra en :
%user profile%\AppData\Local\Microsoft\Windows.
Las claves específicas son:
Sin embargo tal y como refiere Chad Tilbury en el artículo que referencio tampoco he encontrado las claves correspondientes a ShellNoRoam en equipos con Windows 7.
Imprescindible leer al menos lo que se dice en las siguientes referencias:
Referencias fundamentales:
Y aparte de las herramientas referenciadas lo que nunca debe faltarnos a la hora de examinar el registro:
Nota: Para el caso concreto de unidades U3 hay un buen estudio en Edith Cowan University - The Impact of U3 Devices on Forensic Analysis.
Por último decir que efectivamente en el caso que me ocupó encontré evidencias del uso de ejecutables portables en la clave UserAssist del usuario.
Parece que se trata entonces de programas que o bien no necesitan instalación o bien son versiones portables, que se han configurado y preparado para no necesitarla, y que en muchos casos presumen de eliminar todo rastro de su ejecución en el equipo desde el que se lanza.
Para detectar este tipo de software hay una serie de carpetas y artefactos del sistema operativo que pueden evidenciar su uso como son:
- Las claves del registro conocidas como "Shellbags".
- Claves del registro UserAssist.
- Archivos Prefetch.
- Carpeta de archivos temporales del usuario.
- Carpeta de archivos recientes del usuario.
- Búsqueda de archivos borrados (MFT e INDX de carpetas).
- Registros de eventos del sistema.
Bueno, empezando por los "Shellbags": se trata de claves del registro en las que el sistema guarda las preferencias de los usuarios sobre las aplicaciones y las carpetas. Esta información se guarda en el registro del usuario, el NTUSER.DAT, y como novedad en Windows Vista/7 hay que tener en cuenta el nuevo registro específico de cada usuario denominado USRCLASS.DAT y que se encuentra en :
%user profile%\AppData\Local\Microsoft\Windows.
Las claves específicas son:
- NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
- NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags
- NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam\BagMRU
- NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam\Bags
- USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
- USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags
- USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\ShellNoRoam\BagMRU
- USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\ShellNoRoam\Bags
Sin embargo tal y como refiere Chad Tilbury en el artículo que referencio tampoco he encontrado las claves correspondientes a ShellNoRoam en equipos con Windows 7.
Imprescindible leer al menos lo que se dice en las siguientes referencias:
- Windows Incident Response: Shellbag analysis
- TZWorks: sbag.
- Sans Computer Forensics: Windows 7 Shellbags.
- Willi Ballenthin: Windows shellbag forensics.
- Yuandong Zhu, Pavel Gladyshev, Joshua James: Using shellbag information to reconstruct user activities.
- NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
Referencias fundamentales:
- Didier Stevens: UserAssist.
- AccessData: Understanding the UserAssist Registry Key.
- Nirsoft: UserAssist_View.
Y aparte de las herramientas referenciadas lo que nunca debe faltarnos a la hora de examinar el registro:
Nota: Para el caso concreto de unidades U3 hay un buen estudio en Edith Cowan University - The Impact of U3 Devices on Forensic Analysis.
Por último decir que efectivamente en el caso que me ocupó encontré evidencias del uso de ejecutables portables en la clave UserAssist del usuario.
domingo, 21 de octubre de 2012
NTFS $MFT slack
Hal Pomeranz ha publicado en SANS Computer Forensics un artículo muy interesante sobre la posibilidad de recuperar datos del slack de las entradas de la MFT.
Se trata de la información que queda residente en la entrada de la MFT en el atributo $DATA cuando ésta pasa de ser residente a no residente.
Para la comprobación se sugiere en el artículo probar con una extensión de datos del archivo inferior a 700 bytes de forma que sea residente y posteriormente ampliar su tamaño para comprobar los datos residuales que quedan en la entrada de la MFT.
Referencia: Resident $DATA Residue in NTFS MFT Entries
Se trata de la información que queda residente en la entrada de la MFT en el atributo $DATA cuando ésta pasa de ser residente a no residente.
Para la comprobación se sugiere en el artículo probar con una extensión de datos del archivo inferior a 700 bytes de forma que sea residente y posteriormente ampliar su tamaño para comprobar los datos residuales que quedan en la entrada de la MFT.
Referencia: Resident $DATA Residue in NTFS MFT Entries
NTFS INDX Buffers
Acaban de publicar en el blog de Mandiant la cuarta entrega dedicada a los NTFS Index Buffers:
The Internal Structures of an INDX Attribute.
Se trata de una descripción de la estructura y comportamiento de los B+Tree que ayuda a entender este concepto. Es un buen complemento para entender el follón de ese tipo de estructura que se añade a las lecturas:
The Internal Structures of an INDX Attribute.
Se trata de una descripción de la estructura y comportamiento de los B+Tree que ayuda a entender este concepto. Es un buen complemento para entender el follón de ese tipo de estructura que se añade a las lecturas:
- El libro de Brian Carrier: File System Forensic Analysis
- La herramienta INDXparse de Willi Ballenthin: INDXparse.
- Del blog de SANS Computer Forensics el artículo de Chad Tilbury: NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files
- La herramienta wisp de TZWorks.
Suscribirse a:
Entradas (Atom)