The LaZagne Project dumps 22 Different Program Passwords

LaZagne Passwords

The LaZagne Project by Alessandro ZANNI is a nifty little utility that displays passwords for 22 Windows and 12 Linux programs. This is a nice tool for penetration testers when you want to quickly dump passwords after you gain access to a system.

For Windows, simply download the standalone version and run it. Running “laZagne.exe all” will dump all the passwords that it can find:

LaZagne 2

You need to have administrator access to pull user login passwords. For “verbose” mode, which adds additional information when it runs, simply add a “-v” switch. If you just want to pull individual passwords, simply run the program using one of the modules below:

LaZagne Password modules

According to the The LaZagne Project webpage it can display the following passwords:

LaZagne Password modules 2

LaZagne works fast and easy!

 

Memory Forensics: Analyzing a Stuxnet Memory Dump (And you can too!)

In the previous article, we learned how to Pull Process & Network Connections from a Memory Dump. It been kind of fun playing around with a memory dump from our own system, but it would be cool to take a look at some memory dumps that are from infected machines.

Well, you can! The Malware Analyst’s Cookbook (exceptional book by the way) has been kind enough to post several memory dumps that you can play with and also additional plug-ins to increase the functionality of Volatility.

So why don’t we take a look at a memory dump from a system with Stuxnet? Simply download the malfind.py plugin, and the Stuxnet memory sample.

First, let’s grab the imageinfo information for the Stuxnet memory dump:

volatility imageinfo -f stuxnet.vmem

Okay, it is a Windows XP SP3 image, so we use that information with the profile switch.

Next, let’s take a look at what processes were running on the Stuxnet infected machine:

volatility pslist –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile, for some reason only one is showing)

Looking at this list you can see one of the signs of a stuxnet infection. There are three copies of lsass.exe running, there should only be one. The lsass process authenticates users for the Winlogon service. Let’s do a process tree list and see if all three instances of lsass correspond to Winlogon:

volatility pstree –profile=WinSP3x86 -f stuxnet.vmem (two dashes in front of profile)

Looking at the PPID column, you can see that two of the processes connect to PPID 668 and on connects to 624. Looking at the PID you can see that the third instance does in fact tie to Winlogon (624). But the two other instances connect to Services.exe (628). Something is not right.

Let’s run the plugin command “malfind” and see what it detects. According to the Volatility Wiki Command Reference,  malfind can find hidden or injected code or DLLs in user mode memory. We will run malfind against the whole memory dump and see if it can find any suspicious code. To do so, because we are using the standalone exe version of Volatility, we need to tell volatility where to find the malfind.py file. We do so by using the –plugin switch:

volatility –plugins=PluginDirectory malfind –profile=WinSP3x86 -f stuxnet.vmem -D OutputFolder (two dashes in front of profile and plugins)

It finds something it didn’t like in explorer.exe right away, but continued to run for quite a while and kicked out two more. Something suspicious in the two copies of lsass.exe – suprise, suprise!

Going to the output directory you see all three suspicious files stored as .dmp files. You can take these files and upload them to VirusTotal to see if it detects anything suspicious.

The first explorer.exe file when run against Virus Total did not return anything malicious. But uploading the two lsass files to virus total returns some interesting results:

Two virus scanners detected something they don’t like in the files. Comodo detects it as a Packed.Win32.MUPX. Gen and VirusBuster detects a Trojan. And indeed there is something fishy there. The real lsass.exe does not have an executable section in its data region, but both of these files do. In the Malfind return above you can see that both copies of the malicious lsass have Page_Execute_ReadWrite permissions. This means exactly what it says, this code has execute and read write permissions.

We could go on and find Stuxnet registry key settings, hidden Dll’s, file objects and numerous other artifacts in this memory sample all with using Volatility. But I will end this simple overview of analyzing stuxnet here.

If you want to see a complete dismantling of Stuxnet with Volatility by an expert analyst. Check out Michael Hale Ligh’s post “Stuxnet’s Footprint in Memory with Volatility 2.0“.

Want to learn a lot more about analyzing malware? Then look no further than the “Malware Analyst’s Cookbook“, written by Michael Hale Ligh, Steven Adair, Blake Hartstein, and Matthew Richard.

Memory Forensics: Pull Process & Network Connections from a Memory Dump

In the previous article, we learned how to pull passwords from a memory dump file. This time, we will cover viewing a process list and network connections out of captured memory files.

Volatility’s “pslist” command can be used to view the processes that were running on a Windows system:

volatility pslist -f memdumpfilename.raw –profile=Win7SP1x86 (Use double dashes in front of profile for some reason they are showing up as a single)

From the output of the command, we see the physical memory location, process name and the PID number of all process that were running on the system. This helps deduce if something was running on the computer that should not have been and as you will see in a future article, allows you to view programs that may be running under the process.

The next step is to view all network connections that were active from the memory dump:

volatility netscan -f memdumpfilename.raw –profile=Win7SP1x86 (Use double dashes in front of profile)

The data returned shows all network connections, including the process name, source and destination IP addresses – including ports. This is just a short snip of what was actually returned, the actual list is easily twice as long. This information helps the analyst see if there were any strange network connections active. Or can help the penetration tester gain valuable information about the network.

The last command that we will look at this time is “bioskbd“.

volatility bioskbd -f memdumpfilename.raw –profile=Win7SP1x86 (Use double dashes in front of profile)

As you can see there is no data returned on this memory dump. But what does “bioskbd” actually do? This interesting command has the ability to pull passwords that are resident from the bios cache buffer. Though most newer systems (like the system that this memory dump was taken from) purge the bios keyboard buffer, many older ones did not. On an old system you might be able to retrieve BIOS boot passwords, or even the passwords for disk encryption systems.

That’s it for this post, on the next Memory Forensics post, we will take a look at pulling malware samples off of a system infected with STUXNET!

Memory Forensics: How to Pull Passwords from a Memory Dump

Last time, we talked about a quick and easy way to get a memory dump on a Windows based PC. This time, we will cover pulling passwords out of captured memory files.

Several programs exist for memory analysis, we will be using “Volatility” from Volatile Systems. If you are performing your analysis on a Windows system I recommend downloading the stand alone .exe version. If you don’t then you will also need to install Python.

Once Volatility is installed, we need to get some information from the memory dump. Open up a command prompt and run the following command:

volatility imageinfo -f memorydumpfilename.raw

This command gives you several pieces of information, for now, we just need to know the profile type of the memory dump, in this case Win7SP1x86. We will use this in the next few steps.

Now, we need the hive list so we can get the starting location in memory of where the registry information resides:

volatility hivelist -f memdumpfilename.raw –profile=Win7SP1x86 (Use double dashes in front of profile for some reason they are showing up as a single)

We now have a list of where several key items are located in the memory dump. Next, we will extract the password hashes from the memory dump. To do this we need to know the starting memory locations for the system and sam keys. We look in the dump above and copy down the numbers in the first column that correspond to the SAM and SYSTEM locations. Then output the password hashes into a text file called hashs.txt:

volatility hashdump -f memdumpfilename.raw –profile=Win7SP1x86 -y 0x87c1a248 -s 0x8bfaa008 > hashs.txt  (double dashes in front of profile)

Open the hash dump file in a text editor and you should see hashes of all the user’s passwords:

Now, if you are using Windows XP and have passwords shorter than 14 characters (LM passwords), you can run them through a password cracker like John the Ripper. Or better yet,  you can copy the long alphanumeric string after the user id number (500 or 1000 numbers) and paste them in Objectif Sécurité’s Online XP Hash cracking program. This utility cracks most LM based password hashes in 5 seconds or less. For more information see  Cracking 14 Character Complex Passwords in 5 Seconds.

This will not work on Windows 7 passwords or XP passwords longer than 14 characters though. These hashes are stored in the more secure NTLM format and can take a lot longer to crack. One cool thing though is that you do not need to crack the NTLM hash to get access to a system. You can log into a system using the hash itself as the password!

The password could be a simple 14 character password or a complex 32 character monster, it does not matter. You can still use the hash to get a command prompt. For more information see NTLM Passwords: Can’t Crack it? Just Pass it!

This really goes to show that passwords really are not as safe as one might think. Dual or multiple authentication systems are really the way to go on secure systems.

Well, that wraps up pulling passwords off of a memory dump, next we will learn how to view the active network connections and processes from a memory dump.

If you enjoyed this tutorial check out my new book, totally updated for 2018!

Basic Security Testing with Kali Linux, 3rd Edition