After reading the Microsoft Malware Protection Center Threat Report: Rootkits I have included new keys that affect to HKLM.
Added: HKLM\System\ControlSet\Services\Tcpip\Parameters.
Values: DataBasePath and DhcpNameServer.
Reference: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Win32/Alureon
Added: All keys under HKLM\System\ControlSet\Services\Tcpip\Parameters\Interfaces.
Values: DhcpNameServer and NameServer.
Reference: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Win32/Alureon
After reviewing the keys that can be used by the malware to avoid the firewall:
Added: HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile.
Value: EnableFirewall.
Added: HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile.\AuthorizedApplications\List.
Values: All.
Added: HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile\GloballyOpenPorts\List.
Values: All.
Added: HKLM\System\ControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List.
Values: All.
New values included in the list of "justified":
Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\WindowsFirewall\DomainProfile.
Value: EnableFirewall.
Data: 1.
Key: HKEY_LOCAL_MACHINE\System\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.
Value: EnableFirewall.
Data: 1.
Malware strings added:
Strings: msqpdx and msliksur.
Reference: Win32/Alureon.
Strings: glaide32.sys and lzx32.sys.
Reference: Win32/Rustock.
Strings: runtime.sys and runtime2.sys.
Reference: Win32/Cutwail.
23 Nov 2012
16 Nov 2012
List of "safe" values.
I have been studying the values that remain unchanged over the time in a typical registry hive in order to populate the list of "safe" values to use with Regkeval.
When I reviewed the timestamps of the registry keys in Windows 7 and Windows XP I found basically the same behaviour but with a significant difference. In Windows 7 there are between 60 and 70 thousand keys that remain over the years with the date of the compilation, that is, 2009-07-14.
I guess that it must be the date of my localized version as it is said in the Wikipedia (http://en.wikipedia.org/wiki/Windows_7 ) :
Windows 7 RTM is build 7600.16385.090713-1255, which was compiled on July 13, 2009...
In Windows XP there are between 60 and 70 thousand keys that remain unchanged over the years but in this case the oldest timestamp is the moment of the installation.
There are few keys with new timestamp per month and the only big increase occurs when it is installed or updated the Microsoft Office suite. Then there is an increase of 30 to 40 thousand keys timestamped.
Of course that I can say this because then again they remain unchanged over the months.
What I have included in the list as trusted or safe values are all the values under this keys that remain unchanged from the initial installation. And furthermore I have considered in the last version of the tool that all the values in this list that don't match the expected value will be marked as suspicious.
In my experience I have around four hundred of this suspicious keys in the output but they are motivated by differences in version numbers. Because the expected value is showed in the column of the timestamp between square brackets It is very easy to discard this warnings.
All this said you can expect using the list provided a 33% of the output classified as "safe".
Now it is up to you to include more values to finally have a list that can save you time based on the configuration of your environment or simply by adding values of well known software installations.
And remember that this evaluation based only in the name of the values is intended to be only a very first impression of what might be happening in the system.
If you want give it a try: http://code.google.com/p/regkeval/
When I reviewed the timestamps of the registry keys in Windows 7 and Windows XP I found basically the same behaviour but with a significant difference. In Windows 7 there are between 60 and 70 thousand keys that remain over the years with the date of the compilation, that is, 2009-07-14.
I guess that it must be the date of my localized version as it is said in the Wikipedia (http://en.wikipedia.org/wiki/Windows_7 ) :
Windows 7 RTM is build 7600.16385.090713-1255, which was compiled on July 13, 2009...
In Windows XP there are between 60 and 70 thousand keys that remain unchanged over the years but in this case the oldest timestamp is the moment of the installation.
There are few keys with new timestamp per month and the only big increase occurs when it is installed or updated the Microsoft Office suite. Then there is an increase of 30 to 40 thousand keys timestamped.
Of course that I can say this because then again they remain unchanged over the months.
What I have included in the list as trusted or safe values are all the values under this keys that remain unchanged from the initial installation. And furthermore I have considered in the last version of the tool that all the values in this list that don't match the expected value will be marked as suspicious.
In my experience I have around four hundred of this suspicious keys in the output but they are motivated by differences in version numbers. Because the expected value is showed in the column of the timestamp between square brackets It is very easy to discard this warnings.
All this said you can expect using the list provided a 33% of the output classified as "safe".
Now it is up to you to include more values to finally have a list that can save you time based on the configuration of your environment or simply by adding values of well known software installations.
And remember that this evaluation based only in the name of the values is intended to be only a very first impression of what might be happening in the system.
If you want give it a try: http://code.google.com/p/regkeval/
13 Nov 2012
Regkeval output
There are now a total of 179 paths to registry values in the two files provided with the application. Every path can include from one to more than one hundred values because of the wildcards.
Those registry values are mainly autostart locations and because the program provides information of any CLSID obtained the total number of lines in the output can reach almost three thousand.
That is the reason to provide an html output with colors: red for malware, green for trusted values, yellow and blue for values of interest and gold for unknown values. The line in dark gray is the value of the filter:
When there is a match the matching value and the information included about the malware in the file is displayed in the column of the timestamp.
In the above example the value ServiceDll of the service Browser is marked as unknown because the known value included in the file is %SystemRoot%\System32\browser.dll.
In the next few days I will provide files with known values obtained from fresh installs of Windows XP and Windows 7.
http://code.google.com/p/regkeval/
Those registry values are mainly autostart locations and because the program provides information of any CLSID obtained the total number of lines in the output can reach almost three thousand.
That is the reason to provide an html output with colors: red for malware, green for trusted values, yellow and blue for values of interest and gold for unknown values. The line in dark gray is the value of the filter:
When there is a match the matching value and the information included about the malware in the file is displayed in the column of the timestamp.
In the above example the value ServiceDll of the service Browser is marked as unknown because the known value included in the file is %SystemRoot%\System32\browser.dll.
In the next few days I will provide files with known values obtained from fresh installs of Windows XP and Windows 7.
http://code.google.com/p/regkeval/
Regkeval published.
Finally I have published Regkeval. The tool is intended to facilitate the initial examination of computers by retrieving and classifying specific key values of the registry.
The aim is to help forensic analysts in the initial phase when reviewing the Windows registry by inspecting keys of interest, e.g. the registry keys and values involved in malware persistence, prior to start searching in deep with Regripper or any other tool of your choice.
The values are read from a list that can be customized using wildcards. When all the values have been read they are classified using two more lists. The first one contains those values that the investigator considers normal or pertaining to the system. The second one has values that are considered malware and values that are considered of special relevance.
The tool it's written in Perl and works on offline registry hives. The description included on the file says:
# Two arguments are required: full path to System and Software hives and full path to all users hives.
# e.g.: perl regkeval.pl d:\cases\C1\hives d:\cases\C1\hives\users
# perl regkeval.pl d:\cases\C2\allhives d:\cases\C2\allhives
#
# System, software and ntuser hives must contain those words in their own file names.
# The selection of the CurrentControlSet is made reading the registry.
# In order to assist the analyst when reviewing the output the tool automatically retrieves this
# information of any CLSID contained in the data of a value:
# InprocHandler32,InprocServer32,LocalServer32,ProgID - Default values
#
# The output consist of three files:
# Raw output: all registry values retrieved.
# Revised output: like the raw output plus the calification of the data based on the information
# contained in "regkeval_val_malw_espec.tsv" and "regkeval_val_justif.tsv".
# HTML output: For easy inspection of results.
#
# The output is classified as:
# Cero - Known values.
# Uno - Unknown values.
# Dos - Malware values.
# Cuatro - Special values of interest.
#
# The classification is based on the values provided in the files "regkeval_val_justif.tsv" and
# "regkeval_val_malw_espec.tsv".
# All values in "regkeval_val_justif.tsv" are Cero class and the match must be exact to get it out.
# All values in "regkeval_val_malw_espec.tsv" have their own classification and the match is based
# only in the value from the column "Indicator".
#
# List of possible filters for retrieving data from values in subkeys of the hive:
# :::vk::: - Retrieves all values and keys
# :::v::: - Retrieves all values
# :::*::: - Any key
# :::*any_word*::: - Filter keys containing "any_word"
# value1&&value2&&value3... - Filter values
# The filters must end with the value/s to retrieve.
#
#
# Files needed:
#
# regkeval_html.dat - Main part of the html output.
# regkeval_val_malw_espec.tsv - List of known malware values of interest.
# You must maintain the format when modifiying the content.
# regkeval_val_justif.tsv - List of known good values that can be discarded at this moment.
# You must maintain the format when modifiying the content.
# regkeval_HKLM.csv - List of HKLM of interest. You must maintain the format when modifiying the content.
# regkeval_HKU.csv - list of HKU values of interest. You must maintain the format when modifiying the content.
http://code.google.com/p/regkeval/
The aim is to help forensic analysts in the initial phase when reviewing the Windows registry by inspecting keys of interest, e.g. the registry keys and values involved in malware persistence, prior to start searching in deep with Regripper or any other tool of your choice.
The values are read from a list that can be customized using wildcards. When all the values have been read they are classified using two more lists. The first one contains those values that the investigator considers normal or pertaining to the system. The second one has values that are considered malware and values that are considered of special relevance.
The tool it's written in Perl and works on offline registry hives. The description included on the file says:
# Two arguments are required: full path to System and Software hives and full path to all users hives.
# e.g.: perl regkeval.pl d:\cases\C1\hives d:\cases\C1\hives\users
# perl regkeval.pl d:\cases\C2\allhives d:\cases\C2\allhives
#
# System, software and ntuser hives must contain those words in their own file names.
# The selection of the CurrentControlSet is made reading the registry.
# In order to assist the analyst when reviewing the output the tool automatically retrieves this
# information of any CLSID contained in the data of a value:
# InprocHandler32,InprocServer32,LocalServer32,ProgID - Default values
#
# The output consist of three files:
# Raw output: all registry values retrieved.
# Revised output: like the raw output plus the calification of the data based on the information
# contained in "regkeval_val_malw_espec.tsv" and "regkeval_val_justif.tsv".
# HTML output: For easy inspection of results.
#
# The output is classified as:
# Cero - Known values.
# Uno - Unknown values.
# Dos - Malware values.
# Cuatro - Special values of interest.
#
# The classification is based on the values provided in the files "regkeval_val_justif.tsv" and
# "regkeval_val_malw_espec.tsv".
# All values in "regkeval_val_justif.tsv" are Cero class and the match must be exact to get it out.
# All values in "regkeval_val_malw_espec.tsv" have their own classification and the match is based
# only in the value from the column "Indicator".
#
# List of possible filters for retrieving data from values in subkeys of the hive:
# :::vk::: - Retrieves all values and keys
# :::v::: - Retrieves all values
# :::*::: - Any key
# :::*any_word*::: - Filter keys containing "any_word"
# value1&&value2&&value3... - Filter values
# The filters must end with the value/s to retrieve.
#
#
# Files needed:
#
# regkeval_html.dat - Main part of the html output.
# regkeval_val_malw_espec.tsv - List of known malware values of interest.
# You must maintain the format when modifiying the content.
# regkeval_val_justif.tsv - List of known good values that can be discarded at this moment.
# You must maintain the format when modifiying the content.
# regkeval_HKLM.csv - List of HKLM of interest. You must maintain the format when modifiying the content.
# regkeval_HKU.csv - list of HKU values of interest. You must maintain the format when modifiying the content.
http://code.google.com/p/regkeval/
11 Nov 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.
7 Nov 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)
Subscribe to:
Posts (Atom)