Following the recent 0-day in Internet Explorer (Réf Lexsi 12808) and the Operation Aurora, the 16-bit subsystem of Windows is vulnerable to a privilege escalation vulnerability. All Windows versions are vulnerable, from NT 3.1 (!) to Windows 7.

Vulnerability (Réf Lexsi 12828) impacts the VDM (Virtual DOS Machine) component of Windows, whose role is to allow 16-bit real mode applications to run in a 32-bit environment system in protected mode, via the virtual 8086 mode provided by the processor. When the General Protection Fault (0x0d interruption) handler restores the context and stack, it verifies that the context and stack are valid, but bases its verification on 3 assumptions which can be bypassed, allowing an attacker to provides his own context and stack. Tavis Ormandy (Google) has published the details on Full-Disclosure, with an exploitation code.

Here is the scenario:

1. a process in launched (for example cmd.exe)
2. the base address of Ntoskrnl is determined
3. a memory scan is performed to find the offset of Ki386BiosCallReturnAddress() from Ntoskrnl
4. a 16-bit application is run (for example debug.exe) to initialize the NTVDM context
5. a DLL is injected into the ntvdm.exe process

The DLL performs the following operations:

1. the address of Ki386BiosCallReturnAddress() is retrieved via a n environment variable passed by the previous binary
2. a fake kernel stack frame is set with a return address pointing to any function (payload)
3. in the current TEB, VDM_TIB.VdmContext.Esi is set to point to our fake stack and VDM_TIB.VdmContext.Eip to Ki386BiosCallReturnAddress()
4. NtVdmControl() is called to trigger the vulnerability and execute our function in the context of the kernel

Once the vulnerability has been successfully exploited, the payload grabs the security token of the SYSTEM process and overwrites the token of the target process (cmd.exe). On the capture below displaying a Windows 7 system, the token of the initial process on the left maps the Lexsi user, whereas the token of the newly created cmd.exe on the right has become SYSTEM:

Tavis Ormandy did contacted Microsoft in last June, but decided to publish his vulnerability in a non-responsible way. However, a GPO can be deployed to disable the 16-bit subsystem and block the exploitation.

Adobe recently released versions 8.2 and 9.3 of Acrobat/Reader, patching several critical vulnerabilities including the recent "newPlayer()" 0-day (Réf Lexsi 12676).

As system vulnerabilities will become more and more difficult to find and exploit, vulnerabilities in third-party applications will be more and more exploited in massive or targeted attacks. Among these applications, Adobe Flash Player and Adobe Acrobat/Reader are the most exploited. F-Secure has recently indicated that Adobe Acrobat/Reader has been used in almost 50% of targeted attacks using malicious documents in 2009, which is almost twice as much as in 2008.

In this context, it seems interesting to look at how antivirus compare when handling this kind of malicious documents. Let's take the latest Adobe Acrobat/Reader 0-day we mentioned above, for which an exploitation code has been available in the Metasploit framework since the 15th December. According to our tests, the PDF generated by Metasploit is currently detected by 6 antivirus out of the main 19 AV products:

Now, let's make it a bit more real. Using the Origami framework presented at the SSTIC conference (Rennes, France) in 2009, it is easy to inject the exploitation code and a payload from Metasploit into any legitimate PDF. There are many ways to automate the execution of the JavaScript code; here we have chosen to add an annotation to a page. The user will be reading its (apparently) legitimate document, until he reaches the malicious page which will trigger the execution of the payload (this behaviour should enhance the attack credibility :).

With the same exploitation code, it is however somewhat surprising to see that only 2 out of 19 AV now detect the malicious version of this legitimate PDF:

What should we conclude? First, we could say that it is not AV's role to detect exploitation codes, but malicious malware that will be dropped. Namely, it would not be surprising that an antivirus does not raise an alarm on an exploitation code that executes calc.exe. However, most (if not all) antivirus products include such signatures against PDF exploitation codes; detecting them in the first case but not in the second case can therefore be seen as a weakness in document parsing engines.

More and more companies choose to use strong authentication to ensure security, which is no more assured by a simple password. It is indeed easy to find by an attacker, either through social engineering, keylogging, brute force cracking or rainbow table ...

What is called strong authentication is the combination of two authentication factors among these three:

• What I know: the password is in this category;
• What I own: it may be a smart card, magnetic stripe, RFID, or a USB token;
• What I am: this is biometrics, which may be the fingerprint, the iris, or the palm of the hand.

So, if you wish to implement a strong authentication mechanism, it must meet two of these factors. A combination often encountered is the combination of a smart card or USB token (containing the data identifying the user, usually an X.509 certificate), with a PIN code to unlock it (combination "What I have" + "What I know").

However, biometrics appears more and more in the chain, especially fingerprints, replacing the PIN to unlock the smart card (combination "What I have" + "What I am "). This biometrics has several advantages compared with the password:

• the user does not need to remember a complex password;
• it is more difficult to steal the user's fingerprint.

The user feels much more secure, in addition to acquire a certain ease of use. But is he really more secured?

Firstly, it has been proven that it is easy to reconstruct a fingerprint found e.g. on a glass, to spoof a simple fingerprint reader.

Secondly, the use of biometrics in France is regulated by the CNIL. Regarding access management by fingerprint, the CNIL states that a user's biometric information must not be centralized in a database. In our case, they must be stored on the smart card. This can then cause a problem when implementing the software for the strong authentication.

When strong authentication is based on a couple smart card / PIN, it may be interesting for the convenience of users to add the ability to unlock the smart card by using their fingerprint. The verification of biometric data can then be made in the application managing the authentication, on the user's host. This implementation raises the following issues:

• the user's biometric data must be available on the smart card for reading for everyone (so the program can access it for comparison). It may of course be encrypted, and the application has the key to decipher it;
• once the user identified, the application must be able to send information (e.g. PIN) to the card to unlock the information it contains, and thus authenticate the user. For this, the application must know this information. This is naturally stored, available for reading for everyone (encrypted again) on the smart card.

The introduction of biometrics then decreases the system's security, having the smart card is sufficient to retrieve information (often the PIN, having recovered the cryptographic key of the application ), and then authenticate.

A secure way to implement this type of strong authentication (biometric + smart card) is the Match On Card technology, which allows verification of the fingerprint directly within the chip. This ensures that the card manages the unlocking of the authentication certificate, only if the fingerprint presented corresponds to the one recorded.

Biometrics is an interesting technology with its advantages and limits to manage authentication, but as always, everything depends on implementation.

Reading one of the last ISC's diaries reminds a trick we recently encountered during a malicious PDF document's analysis.

It explains a somewhat special shellcode method in a PDF exploiting the latest 0-day vulnerability in Adobe Reader (Lexsi Ref. 12676). Indeed, it is very small (38 bytes only), and will search through the memory pages of the process to find a certain pattern, then jump to its address to continue execution. The pattern is in a compressed stream object within the malicious PDF document. The second shellcode decodes and runs two executables, also contained in the PDF. The first will open a non-malicious PDF document, while the second is a malware attempting to connect to a control channel.

The method we encountered is substantially identical. The vulnerability exploited is a heap-based buffer overflow in U3D file management (Lexsi Ref. 12415), and the heap-spraying trick is used to format the heap for the execution redirection. A quick look at the document shows that the injected shellcode in the heap is as follows:

Once loaded into the debugger, we face with a rather conventional beginning (for details, see this previous shellcode analysis):

• a loop is responsible for deciphering the shellcode by XOR-ing all the bytes with the value "0xF9"

• then, it will look for the addresses of several Windows API functions

The next step is more interesting: the shellcode will perform a brute-force of open file descriptors until finding one whose header corresponds to a PDF file, then check for some patterns located at certain offsets.

This will allow the shellcode to obtain a handle to the malicious PDF document, and to extract and decode a second shellcode by reading it at a specific offset. The result is very similar to the ISC's analysis: the second shellcode will open a non-malicious PDF document and run a downloader binary included in the malicious PDF.

This method allows to search a second stage shellcode more reliably than by browsing the memory pages of the process, in which there is a risk of finding a sequence of bytes corresponding to the desired pattern without being the beginning of the shellcode, or trigger an error by accessing unmapped memory.

A worm is currently spreading on jailbroken iPhones, exploiting the hardcoded root account exposed by the SSH server.

Jailbreaking an iPhone (or an iPod Touch) consists in getting out of the sandbox the user and his applications normally run into, so as to execute code as root and take complete control over the device. Once performed, installing packets is usually done via Cydia, a graphical packet management interface. Problems arise when the user decides to install an OpenSSH server, opening remote access to his device via hardcoded iPhone accounts, as the famous root:alpine.

The attack method is trivial: scan IP looking for opened 22/tcp ports, try to connect with SSH as root:alpine and execute your commands as root. Recently, a user in the Netherlands used this method to compromise iPhones and blackmailed the victims into paying 5 euros to secure their device (he now decided to stop and his web page only indicates how to remove his malicious application).

Then comes the Ikee worm, exploiting the same method. Its source code has been made public for a few hours but its access has now been suspended. Several variants are already spreading (four at time of writing).

To spread, Ikee uses several IP addresses generation methods:

• addresses "near" the IP address of the device it is currently running on

   char *locRanges = getAddrRange(); // NB: this function calls getifaddrs() to retrieve IP addresses for each interface
   char *lanRanges = "192.168.0.0-192.168.255.255";

• hardcoded ranges, mainly in Autralia (Vodaphone, Optus and Telstra operators)

   char *vodRanges1 = "202.81.64.0-202.81.79.255";
   char *vodRanges2 = "23.98.128.0-123.98.143.255";
   char *vodRanges3 = "120.16.0.0-120.23.255.255";
   char *optRanges1 = "114.72.0.0-114.75.255.255";
   char *optRanges2 = "203.2.75.0-203.2.75.255";
   char *optRanges3 = "210.49.0.0-210.49.255.255";
   char *optRanges4 = "203.17.140.0-203.17.140.255";
   char *optRanges5 = "203.17.138.0-203.17.138.255";
   char *optRanges6 = "211.28.0.0-211.31.255.255";
   char *telRanges = "58.160.0.0-58.175.255.25";

• random IP addresses

A device may only be infected by this particular worm if it has an Internet routable IP address. Once an opened 22/tcp port has been found, it attempts to connect as root:

asprintf(&execLine, "sshpass -p %s ssh -o StrictHostKeyChecking=no root@%s 'echo 99'", VULN_PASS, host);

If it receives back a message containing 99, it means that the remote device is vulnerable and the worm proceeds with the infection procedure. Current variants are not really malicious and only change the background image used in lock mode to a picture of Rick Astley. The worm also terminates the OpenSSH service and even deletes the /usr/sbin/sshd binary, thus preventing another attacker or worm from exploiting the same weakness:

    if (!(in = popen("rm -f /usr/sbin/sshd; killall sshd", "r"))) {

Ironically enough, the device is more secure after its infection than before

Obviously, the recommendations here are not to jailbreak an iPhone containing sensitive data (such as a professional device), not to install an SSH server, or not to forget to change the root password.

An email which seems to come from the Facebook team has been circulating for a few days. Its attachment is yet another variant of the Bredolab downloader, already known for installing other malware (Waledac, Daurso, Koobface, etc).

Here is an example (you are likely to have received it as well):

The attachment is a simple ZIP file (Facebook_Password_6dd19.zip in our example) and contains a malicious binary.

A quick analysis of the executable reveals that it injects itself into Windows processes, via the traditional OpenProcess/VirtualAllocEx/WriteProcessMemory/CreateRemoteThread method:

On the picture above, the binary asks for a handle on process 0x478 (explorer.exe on our test system). After calling WriteProcessMemory to copy its malicious code into this process, the remote thread is created:

Bredolab is only a downloader; this sample connects to the mmsfoundsystem[dot]ru domain via HTTP to download other malware:

To ensure it will run at startup, it simply drops itself in the user's Startup folder:

As said in a previous bulletin, the MSRT is documented as supporting Bredolab; indeed, our sample is detected as TrojanDownloader:Win32/Bredolab.X:

Two weeks ago, Microsoft fixed (Ref Lexsi 12420) a flaw disclosed at the Black Hat by Moxie MarlinSpike in late July regarding X.509 certificates which did not get a big attention.

The flaw itself is simple: most libraries handling X.509 certificates, such as NSS libraries used by Firefox or CryptoAPI in Windows, do not take into account the possibility to insert a null character (\0) in the CN (Common Name) field of an X.509 certificate. Thus, the display stops at this null character when handling a certificate.

As an example, the CN field « lexsi.com\0maliciousdomain.com » is seen as « lexsi.com » by vulnerable software.

Valid certificates using this vulnerability have been published, one for www.paypal.com and the other for * (!).

However, Microsoft has given an exploitability index of 3 (= functional exploits are unlikely).

In order to understand why this index is so low although the exploitability has been proved at Black Hat, let's see what are the requirements to take advantage of this vulnerability.

Let's imagine the case of an attacker who wants to decipher the data exchanged with the website https://www.benevolent.fr which is authenticated and ciphered by SSL protocol.

In the client side, the web browser checks 3 elements to authenticate a website using SSL:

1. The certificate has not expired
2. The certificate is signed by a certification authority present in the trusted authorities list embedded in the browser
3. The domain name is identical to the CN field of the certificate

So, the attacker must own a valid certificate for the www.benevolent.fr domain. It can not be self-signed (condition 2) and therefore it must be obtained from a certification authority. But this is not possible because when buying such a certificate, the certification authority will check that the domain belongs to the attacker.

This is where the vulnerability enters the game, because it is possible to buy a certificate for www.benevolent.fr\0malicious.fr (supposing the attacker owns the domain malicious.fr).

Once in possession of this valid certificate, the attacker can set a page (redir.malicious.fr) which acts as a gateway to the legacy www.benevolent.fr website, with the purpose of silently decipher the victim's packets without raising his suspicion.

This leaves us with our third condition, which prompts a warning when the CN content (considered here as being www.benevolent.fr) is different from the URL set by the user.

The attacker has to manage a way (DNS Cache or ARP Poisoning for example) to get the user forwarded to the IP address of redir.malicious.fr when it types www.benevolent.fr in the address bar.

This step is the one which explains that a massive exploitation did not happen despite the 2 months and a half that Microsoft took to fix it. This also explains the exploitability index of 3.

It is required to forge a specific certificate for each target, and also to be in a man-in-the-middle scenario.

Furthermore, Microsoft states that it ensured the certification authorities listed in its browser do not accept anymore a null character in the certificates they deliver.

But what about the valid wildcard « * » certificate ?

In fact, Internet Explorer do not consider this domain as valid, and a warning is displayed (hoping to increase victim's alertness).

However, the Mozilla foundation browser do not reacts to this wildcard and versions prior to 3.0.13 are vulnerable to this attack without the need for an attacker to forge a specific certificate for each victim.

The flaw has been fixed two days after the conference in the Firefox browser (version 3.0.13, the 3.5 is not affected), in early September by Opera (release of the version 10) and in mid-October by Microsoft in the MS09-056 bulletin. Regarding Safari, the Windows version relies on the Microsoft's CryptoAPI library and therefore is not vulnerable if the MS09-056 fix is applied. Several tools handling certificates have been fixed (thunderbird, mutt, openldap, proftpd, wget, curl, fetchmail, neon, kdelibs, qt ...), and some mobile browsers (BlackBerry).

However, as it is explained by Moxie MarlinSpike, Firefox embeds an automatic update mechanism in which all the protection relies on the website from where the updates are retrieved. And this site is authenticated ... via SSL. If the exploitation requirements are met, an attacker is able not only to decipher SSL data, but also to install whatever he wants to on the victim's computer! The exploitation of a vulnerability in the OCSP protocol in order to prevent the revocation of the certificate is also worth noting.

Let's finish with the Mac version of Safari. In its actual version (4.0.3), its behaviour is different from other browsers (even those which are not patched). Indeed, the null character is ignored. Our certificate "www.benevolent.fr\0malicious.fr" is seen by Safari as being for the domain www.benevolent.frmalicious.fr. However, the example of a certificate with the CN field "sitekey.ba\0nkofamerica.com" given during the presentation shows that exploitation is still feasible, just adding more constraints.

This flaw allows to decrypt SSL traffic (obviously, as we own the certificate offered to the victim), and without him being aware of it as all of the usual signs (lock, green address bar...) are the same. The title of this blog entry is not to take too seriously, as the finding (done concurrently by Dan Kaminsky) is great.

Yet the need to perform a man-in-the-middle attack is a major hindrance for a massive exploitation. Thus, the certificate issued for paypal is not enough to perform a large scale phising. Still, targeted attacks in a corporate network are possible ...

Details of the vulnerability are available in the slides.

Microsoft has just released its security bulletins for September. Eight vulnerabilities have been fixed, all rated critical. The 0-day affecting IIS has not been fixed.

MS09-045: vulnerability in the Windows JScript scripting engine (Ref Lexsi 12234)

MS09-046: vulnerability in the Windows DHTML editing component ActiveX control (Ref Lexsi 12233)

MS09-047: two vulnerabilities in Windows Media (Ref Lexsi 12236)

MS09-048: three vulnerabilities in the Windows TCP/IP stack (Ref Lexsi 12235). One of them, allowing an attacker to cause a remote denial of service with very little resource, was disclosed in 2008 by Outpost24 and the affected vendors have just released their patches in a coordinated manner. This patch will not be available on Windows 2000 due to the huge modifications that it would imply. But surprisingly enough, it will not be available on Windows XP either, Microsoft justifying it by the fact that no service is listening for incoming remote connections on this system by default... Another vulnerability in Vista and 2008 when parsing a TCP field can potentially allow remote code execution. This is the same kind of vulnerability as the 0-day affecting SMBv2 discovered yesterday.

MS09-049: vulnerability in the Wireless LAN AutoConfig Service (Ref Lexsi 12232). It can be remotely exploited without user interaction to execute arbitrary code, the only condition being that the user has its wireless interface up! However, it only affects Vista and 2008.

Like every month, the MSRT has been updated and now supports Bredolab and Daurso. The former is a downloader, installing other malicious software; the latter is a password stealer and can be installed by the former. It searches for connection information stored by several popular FTP clients (FileZilla, CuteFTP, etc), as well as in the Windows Protected Storage. This can be critical if the webmaster's system becomes infected, thus allowing access to the web site by the attacker, for example to add a malicious iframe.

Yesterday, a vulnerability (Lexsi Ref. 12225) announced as a remote denial of service affecting Microsoft Windows Vista, Seven and 2008 has been published by a security researcher. It affects the driver for the SMBv2 protocol, a new version of the well-known SMB. By changing a single parameter of a "negotiation protocol" SMB query, a remote attacker could cause a BSOD.

But let's have a more closer look...

The execution of the exploitation code against one of our test machines causes the following blue screen:

We note that the impacted driver is srv2.sys and that the instruction causing the PAGE_FAULT is located at 0x8E18A749. If we open the driver using a disassembler, we observe the following code:

We can see that the modified value in the packet (here eax) is then directly used as an index of a functions array! The vulnerability could then be exploited to redirect the execution flow to a memory area we control, allowing remote execution of arbitrary code with the privileges of the kernel ...

It is unfortunate that the researcher has not adopted the practice of responsible disclosure, by reporting the vulnerability to Microsoft without publishing it, to give time to the editor to correct it before any exploitation in the wild occurs. Perhaps he thought that a simple denial of service was not "that" critical ...

The first half of 2009 has seen the following main virus threats: Conficker, Virut and Neeris. The latter is a worm which spreads like Conficker by exploiting the MS08-067 vulnerability. It was far from receiving the same media attention as Conficker but did succeed in infecting many companies. Different ways of spotting the first infected machine on a network, namely the infection source, are described in this post.

It is assumed that all machines are synchronized with a time server; comparing time between machines then makes sense and our problem boils down to determining the infection date of each machine. This can be determined from the modifications the worm made on the system, mainly on the filesystem, events and registry (NB: a filter like "Category is Write" in Process Monitor is a good starting point).

Filesystem

The worm begins by copying itself in C:\WINDOWS\system under a randomly chosen name, netmon.exe in this case. NTFS attributes give the file creation date and time, that is to say an infection date (NB: first, fls is used to get the index of the file in the MFT, then istat is used to retrieve the information):

$ fdisk -ul neeris_disque.raw
neeris_disque.raw1   *          63     8369864     4184901    7  HPFS/NTFS

$ fls -o 63 -r neeris_disque.raw | grep netmon
++ r/r 9433-128-3:	netmon.exe

$ istat -o 63 neeris_disque.raw 9433
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:33 2009
File Modified:	Mon Aug 31 18:02:32 2009
MFT Modified:	Tue Sep  1 06:36:38 2009
Accessed:	Mon Aug 31 18:02:33 2009

Similarly, the worm drops a rootkit in C:\WINDOWS\system32\drivers\sysdrv32.sys. The properties of this file also give us an infection date:

$ fls -o 63 -r neeris_disque.raw | grep sysdrv32.sys
+++ r/r 9437-128-3:	sysdrv32.sys

$ istat -o 63 neeris_disque.raw 9437
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:36 2009
File Modified:	Mon Aug 31 18:02:36 2009
MFT Modified:	Mon Aug 31 18:02:36 2009
Accessed:	Mon Aug 31 18:02:36 2009

This gives us another time, showing us that this action occurred a few seconds after the other one.

We have another option: prefetch files. Prefetch is a functionality of the Windows Memory Manager which aims at speeding up the boot and application load process, enabled by default and configurable via the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters registry key (refer to chapter 7 of the Windows Internals book for more details). Like every application, the worm is also impacted by this mechanism and Windows will create the appropriate files in C:\WINDOWS\Prefetch:

$ fls -o 63 -r neeris_disque.raw | grep NETMON
++ r/r 9436-128-4:	NETMON.EXE-0D87B210.pf

$ istat -o 63 neeris_disque.raw 9436      
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:34 2009
File Modified:	Mon Aug 31 18:02:44 2009
MFT Modified:	Mon Aug 31 18:02:44 2009
Accessed:	Mon Aug 31 18:02:34 2009

The filesystem timeline (the capture below was taken with PTK) shows that at the time determined above, temporary Internet files have been written under the NetworkService account. This is a sign of a successful exploitation of a vulnerability in a Windows network service:

All directories and files in the capture above, if their names are not system dependent, can be used to determine the infection date.

Events

The rootkit is loaded via the Windows Service Control Manager and this will generate a 7035 event in the System event log, providing us with an infection date:

Searching for this event is trivial as the rootkit always installed itself as Play Port I/O Driver. The only issue we may face would be the overwrite of these events. However, the time given by this method is relatively late (10s after the main executable was dropped).

Registry

Several modifications are made in the registry:

1. new value in the HKLM\SOFTWARE\CurrentVersion\Run key under a randomly chosen name (netmon here), pointing to a copy of the worm in C:\WINDOWS\system
2. new firewall exception (new value in the HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List key)
3. kernel rootkit (new HKLM\SYSTEM\CurrentControlSet\Services\sysdrv32 key)
4. the worm runs even in safe mode with or without network support (new HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\{Minimal,Network}\netmon keys)

In the registry, dates and times are stored, but they correspond to keys and not values. Indeed, the LastWriteTime is stored in a _CM_KEY_CONTROL_BLOCK structure:

lkd> dt nt!_CM_KEY_CONTROL_BLOCK
  +0x038 KcbLastWriteTime : _LARGE_INTEGER

We are looking for a registry key specifically created by the worm which we will be able to extract the LastWriteTime (last modification time) from, and not a new value in an existing key. The second and third points above meet this requirement. The date and time can be extracted manually with regedit by exporting the key in text format:

The procedure can be automatized via the RegQueryInfoKey function which returns the information in its lpftLastWriteTime field.

Another method would be to analyze the RAM. The task has recently become easy thanks to the possibility of using RegRipper plugins against memory dumps via Volatility. First, let's list the hives available in our RAM dump via the hivelist plugin:

$ ./volatility hivelist -f neeris_ram.raw
Address      Name
0xe17ff008   \Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe17f7b60   \Documents and Settings\<user>\NTUSER.DAT
0xe13112b0   \WINDOWS\system32\config\software
0xe1311b60   \WINDOWS\system32\config\default
0xe1309008   \WINDOWS\system32\config\SECURITY
0xe1309758   \WINDOWS\system32\config\SAM
0xe101b008   \WINDOWS\system32\config\system

Now, our plugin can be executed against these hives and will return the information, for example from the SYSTEM hive:

$ perl rip.pl -p neeris_lexsi -r neeris_ram.raw@0xe101b008

ControlSet001\Services\sysdrv32
[Mon Aug 31 16:02:41 2009]

ControlSet001\Control\Safeboot\Minimal\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Control\Safeboot\Network\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
[Tue Sep  1 04:36:38 2009]

In these examples, the given time doesn't take into account the time zone (this is a memory dump from a French system at UTC+2). The time of the sysdrv32 key matches the one extracted from the event log. However, the AuthorizedApplications\List key has been modified afterwards and doesn't give a correct time.

This RegRipper plugin is available for download (please note that the plugin is not exhaustive and is only a proof of concept).

If these keys were removed by the antivirus, it is still possible to apply the LastWriteTime method on a key where the worm only added a value, such as HKLM\SOFTWARE\CurrentVersion\Run or HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List, rather than on a key it created. This will surely returns a result, but it may not be correct due to legitimate modifications of these keys by other programs, which also affect the date and time (see the example above about the RAM dump). Anyway, if these dates match, chances are that this is the right infection date.

Processes

By analyzing the RAM, it is also possible to determine the time when the netmon.exe process was launched via the psscan2 Volatility plugin (NB: pslist will not work here due to the rootkit which hides this process):

$ ./volatility psscan2 -f neeris_ram.raw
PID    PPID   Time created             Time exited              Offset     PDB        Remarks
  1352    556 Mon Aug 31 11:07:23 2009                          0x00f79228 0x00f66000 spoolsv.exe     
   916    556 Mon Aug 31 11:06:55 2009                          0x0102f6b0 0x06a00000 svchost.exe     
   852    556 Mon Aug 31 11:06:53 2009                          0x0103b020 0x0643a000 svchost.exe     
   772    556 Mon Aug 31 11:06:48 2009                          0x0104da90 0x05c50000 svchost.exe     
   568    484 Mon Aug 31 11:06:41 2009                          0x0106b938 0x057d7000 lsass.exe       
   556    484 Mon Aug 31 11:06:41 2009                          0x0106d090 0x057cb000 services.exe    
  1664   1608 Mon Aug 31 16:02:34 2009                          0x0107d670 0x06f26000 netmon.exe      
   356      4 Mon Aug 31 11:06:34 2009                          0x0108c4d0 0x047dc000 smss.exe        
   460    356 Mon Aug 31 11:06:37 2009                          0x010b5488 0x052ae000 csrss.exe       
   484    356 Mon Aug 31 11:06:38 2009                          0x011b7020 0x05473000 winlogon.exe    
     4      0                                                   0x011f29c8 0x00039000 System          
  1964    556 Mon Aug 31 11:08:13 2009                          0x0604cb00 0x001c4000 alg.exe         
  1924    556 Mon Aug 31 11:08:09 2009                          0x060c8020 0x024a0000 svchost.exe     
  1036    556 Mon Aug 31 11:07:06 2009                          0x078e9508 0x0791e000 svchost.exe     
  1208   1140 Mon Aug 31 11:07:16 2009                          0x07d29020 0x07de8000 explorer.exe    
  1204   1208 Mon Aug 31 11:19:46 2009                          0x07d92820 0x0554a000 cmd.exe

Modulo the 2-hour time difference, this gives us the same date and time as determined above.

Network connections

Finally, sockets also have a creation date. By listing the sockets associated with our process (PID 1664), we are given the connections corresponding to the exploitation of the MS08-067 vulnerability on remote hosts; the first of these dates is the first exploitation attempt, and the date matches (modulo 2 hours again):

$ ./volatility sockets -f neeris_ram.raw | grep 1664 
Pid    Port   Proto  Create Time
1664   4637   6      Tue Sep 01 04:39:01 2009  
1664   4641   6      Tue Sep 01 04:39:02 2009  
1664   4645   6      Tue Sep 01 04:39:02 2009  
1664   1664   6      Tue Sep 01 01:10:06 2009  
1664   2866   6      Mon Aug 31 22:01:10 2009  
1664   4634   6      Tue Sep 01 04:39:00 2009  
1664   4638   6      Tue Sep 01 04:39:02 2009  
1664   3502   6      Tue Sep 01 01:52:38 2009  
1664   4642   6      Tue Sep 01 04:39:02 2009  
1664   4646   6      Tue Sep 01 04:39:02 2009  
1664   3762   6      Tue Sep 01 01:53:03 2009  
1664   14575  6      Mon Aug 31 16:02:36 2009  
1664   3495   6      Tue Sep 01 01:52:37 2009  
1664   1669   6      Tue Sep 01 01:10:07 2009  
1664   4635   6      Tue Sep 01 04:39:00 2009  
1664   4639   6      Tue Sep 01 04:39:02 2009

Conclusion

Different ways of determining the date when a system has been infected by Neeris have been described, through disk and RAM analysis. These methods have their own advantages and drawbacks, but their efficiency can be decreased by the actions performed by the antivirus which may remove pieces of evidence when removing the worm. Analyzing the RAM can be useful, provided the first responder doesn't arrive too late...