System Forensics

All your artifacts are belong to us.

APTish Attack via Metasploit – Part III – Memory Analysis

INTRO:

Some of you might be familiar with GrrCon [1]. I wasn’t until this year. I found out about them after reading a post by the Volatility guys/gals [2]. In the post they discuss how they used volatility to analyze the GrrCon challenge.

The write up on the analysis was really good and it goes to show the power of memory forensics. I will be using a lot of the same techniques during my analysis of this APTish type attack. If you’re not familiar with this series of posts I have done you can read up on Part I and Part II.

I think one of the most important pieces of information provided by the challenge wasn’t the memory image itself (although it was really good). It was the questions provided to answer the challenge. These same questions can be applied to most any DFIR case/challenge. I will be using those same questions while taking a look at my memory image.

I will be using some of the information that I gathered from the Splunk post from Part II.

The volatility commands will be in red.

IMAGE INFORMATION:

At first I will run the following so I don’t have to use a long command line every time I want to interact with the image.

$ export VOLATILITY_LOCATION=file:///mnt/hgfs/Post/Hacking_7x86-Snapshot6.vmem
$ export VOLATILITY_PROFILE=Win7SP1x86

Once that’s set we can simply run Volatility by typing;

$ python vol.py imageinfo
Volatile Systems Volatility Framework 2.3_alpha
Determining profile based on KDBG search…
          Suggested Profile(s) : Win7SP0x86, Win7SP1x86
                     AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/mnt/hgfs/Post/Hacking_7x86-Snapshot6.vmem)
                      PAE type : PAE
                           DTB : 0x185000L
                          KDBG : 0x82966c28L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0x82967c00L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2012-11-14 02:16:33 UTC+0000
     Image local date and time : 2012-11-14 11:16:33 +0900

1. How was the attack delivered?

It appears that an exe might have been downloaded Via the web. I couldn’t pull anything out of the memory image using the $ python vol.py iehistory command, but I was able to find some hits using src_strings against the memory image.

$ srch_strings aptish.vmem |grep “Visited:”
Visited: malware_win7x86@https://mail.google.com/mail/?shva=1
Visited: malware_win7x86@http://192.168.81.128/AntiVirus_Update_2012.exe

We can take a look at the OpenSavePIDlMRU reg key via Volatility’s printkey plugin and this will give us an idea of whether or not this AntiVirus_Update_2012.exe was saved via a windows shell, which IE or Firefox would fall under. The OpenSaveMRU key tracks whether or not a file has been opened or saved via the windows shell. [3]

$ python vol.py printkey -K “Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\exe”
Volatile Systems Volatility Framework 2.3_alpha
Legend: (S) = Stable   (V) = Volatile
—————————-
Registry: \??\C:\Users\malware_win7x86\ntuser.dat
Key name: exe (S)
Last updated: 2012-11-14 00:43:21 

Subkeys:

Values:
REG_BINARY    0               : (S) 
0×00000000  88 00 32 00 00 00 00 00 00 00 00 00 80 00 41 6e   ..2………..An
0×00000010  74 69 56 69 72 75 73 5f 55 70 64 61 74 65 5f 32   tiVirus_Update_2
0×00000020  30 31 32 2e 65 78 65 00 60 00 08 00 04 00 ef be   012.exe.`…….
0×00000030  00 00 00 00 00 00 00 00 2a 00 00 00 00 00 00 00   ……..*…….
0×00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   …………….
0×00000050  00 00 41 00 6e 00 74 00 69 00 56 00 69 00 72 00   ..A.n.t.i.V.i.r.
0×00000060  75 00 73 00 5f 00 55 00 70 00 64 00 61 00 74 00   u.s._.U.p.d.a.t.
0×00000070  65 00 5f 00 32 00 30 00 31 00 32 00 2e 00 65 00   e._.2.0.1.2…e.
0×00000080  78 00 65 00 00 00 28 00 00 00                     x.e…(…
REG_BINARY    MRUListEx       : (S) 
0×00000000  00 00 00 00 ff ff ff ff                           ……..

Next we can get an idea of what was used to open up AntiVirus_Update_2012 via the LastVisitedMRU reg key tracks the executables used to open the files in OpenSaveMRU and also the last file path used. [3]

$ python vol.py  printkey -K “Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU”
Volatile Systems Volatility Framework 2.3_alpha
Legend: (S) = Stable (V) = Volatile
—————————-
Registry: \??\C:\Users\malware_win7x86\ntuser.dat
Key name: LastVisitedPidlMRU (S)
Last updated: 2012-11-14 00:43:21 
Subkeys:
Values:
REG_BINARY 1 : (S)
0×00000000 69 00 65 00 78 00 70 00 6c 00 6f 00 72 00 65 00 i.e.x.p.l.o.r.e.
0×00000010 2e 00 65 00 78 00 65 00 00 00 00 00                    ..e.x.e…..

More data from shimcache plugin:

$ python vol.py shimcache
Volatile Systems Volatility Framework 2.3_alpha
Last Modified: 2012-11-14 00:43:22 , Path: \??\C:\Users\malware_win7x86\Desktop\AntiVirus_Update_2012.exe
Last Modified: 2012-11-14 00:43:17 , Path: \??\C:\Users\malware_win7x86\Desktop\AntiVirus_Update_2012.exe

And info from shellbags verifying it was on the Desktop.

$ python vol.py shellbags
Registry: \??\C:\Users\malware_win7x86\ntuser.dat 
Key: Software\Microsoft\Windows\Shell\Bags\1\Desktop
Last updated: 2012-11-14 01:27:44 
Value                     File Name      Modified Date        Create Date          Access Date          File Attr                 Unicode Name
————————- ————– ——————– ——————– ——————– ————————- ————
ItemPos1280x1024x96(1)    ANTIVI~1.EXE   2012-11-14 00:43:24  2012-11-14 00:43:22  2012-11-14 00:43:22  ARC                       AntiVirus_Update_2012.exe

2. What time was the attack delivered?

$ python vol.py userassist > /home/sansforensics/Desktop/user.txt
REG_BINARY    C:\Users\malware_win7x86\Desktop\AntiVirus_Update_2012.exe
Count:          1
Focus Count:    0
Time Focused:   0:00:00.500000
Last updated:   2012-11-14 00:49:03 
0×00000000  00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00   …………….
0×00000010  00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf   …………….
0×00000020  00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf   …………….
0×00000030  00 00 80 bf 00 00 80 bf ff ff ff ff 70 73 84 d7   …………ps..
0×00000040  01 c2 cd 01 00 00 00 00                           ……..

3. What was that name of the file that dropped the backdoor?

AntiVirus_Update_2012.exe was the infection point.

I dumped some of the suspicious processes with procmemdump. Once I dumped the processes I used Buster Sandbox Analyzer (BSA) to see what kind of information I could pull from it.


$ python vol.py procmemdump -p 3932,3908 -D ../Desktop/cases/
Volatile Systems Volatility Framework 2.3_alpha
Process(V) ImageBase  Name                 Result
———- ———- ——————– ——
0x856418a8 0×00400000 HOtdFs.exe           OK: executable.3932.exe
0x855b6930 0x00f40000 notepad.exe          OK: executable.3908.exe


Output from BSA:

[ General information ]
   * Analysis duration: 00:00:54
   * File name: c:\users\malware_win7x86\desktop\scripts\hotdfs.exe

 [ Network services ]
   * Connects to “192.168.81.128″ on port 4444.

4. What is the IP address of the C2 server?

192.168.81.128

$ python vol.py  netscan
Volatile Systems Volatility Framework 2.3_alpha
Offset(P)      Proto         Local Address                  Foreign Address      State                           Pid      Owner          Created
0xbdf49588 TCPv4    192.168.81.129:49162           192.168.81.128:8043  CLOSED                  1756     svchost.exe    
0xbfba7230 TCPv4    192.168.81.129:49163           192.168.81.128:4444  ESTABLISHED      3932     HOtdFs.exe


5. What type of backdoor is installed?

RAT

Note the internet related dlls. This doesn’t make it malicious, but it can help to support our claims.

$ python vol.py dlllist -p 3932
Volatile Systems Volatility Framework 2.3_alpha
************************************************************************
HOtdFs.exe pid:   3932
Command line : C:\Users\MALWAR~1\AppData\Local\Temp\HOtdFs.exe  
Service Pack 1
Base             Size Path
———- ———- —-
0×00400000    0×16000 C:\Users\MALWAR~1\AppData\Local\Temp\HOtdFs.exe

0x6cac0000     0×7000 C:\Windows\system32\WSOCK32.dll
0x760d0000    0xf5000 C:\Windows\system32\WININET.dll
0×76310000   0×137000 C:\Windows\system32\urlmon.dll

6. What is the mutex the backdoor is using?

I wasn’t able to identify a mutex.

$ python vol.py handles -p 3932,3908,3876,3104 -t Mutant –silent

Volatile Systems Volatility Framework 2.3_alpha
Offset(V)     Pid     Handle     Access Type             Details
———- —— ———- ———- —————- ——-

7. Where is the backdoor placed on the file system?

$ python vol.py filescan |grep HOtdFs.exe

C:\Users\MALWAR~1\AppData\Local\Temp\HOtdFs.exe

8. What process name and process id is the backdoor running in?

If you look at the highlighted items below you will see a couple interesting things. First off, I don’t think i’ve ever seen a HOtdFs.exe as a running process, but that beside the point you can see some interesting PID and PPID information.

It appears that HOtdFs.exe –spawne-d> notepad.exe –spawned-> 7za.exe.

From the looks of it HOtdFs.exe migrated to notepad.exe. Let’s check out and see if notepad.exe has any bad characteristics.

$ python vol.py pslist -p 1756,3932
Volatile Systems Volatility Framework 2.3_alpha
Offset(V)  Name                          PID   PPID   Thds     Hnds   Sess  Wow64 Start                Exit                
———- ——————– —— —— —— ——– —— —— ——————– ——————–
0x85398ad8 svchost.exe            1756   3792      4      105      1      0 2012-11-14 01:32:45                      

0x856418a8 HOtdFs.exe             3932   1444      2      109      1      0 2012-11-14 01:36:29                      
0x855b6930 notepad.exe            3908   3932      4      136      1      0 2012-11-14 01:36:32
0x8549c9a0 7za.exe                     1912   3908      0  ——–      1      0 2012-11-14 02:14:17

You can see here that both the HOtdFs.exe and notepad.exe have strings within them referencing the “C2″ server we identified earlier.

$ python vol.py yarascan -p 3932,3908,1912  -Y “192.168.81″
Volatile Systems Volatility Framework 2.3_alpha

Owner: Process HOtdFs.exe Pid 3932
0x015ee4e4  31 39 32 2e 31 36 38 2e 38 31 2e 31 32 38 00 00   192.168.81.128..
0x015ee4f4  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   …………….
0x015ee504  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   …………….
0x015ee514  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   …………….
Rule: r1
Owner: Process notepad.exe Pid 3908
0x0291b420  31 39 32 2e 31 36 38 2e 38 31 2e 31 32 38 00 00   192.168.81.128..
0x0291b430  26 6b 9a 5f 00 00 00 8c 30 ca 91 02 ff ff ff ff   &k._….0…….
0x0291b440  50 b4 91 02 00 00 00 00 29 6b 9a 5f 00 00 00 88   P…….)k._….
0x0291b450  0c 00 00 00 04 00 00 00 68 b4 91 02 00 00 00 00   ……..h…….

You can see here that HOtdFs.exe and notepad.exe processes have multiple code injection points. I snipped a lot of the output off here so you can just get an idea.


$ python vol.py malfind -p 3932,3908
Volatile Systems Volatility Framework 2.3_alpha

Process: HOtdFs.exe Pid: 3932 Address: 0x5a0000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 84, MemCommit: 1, PrivateMemory: 1, Protection: 6

0x005a0000  4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00   MZ…………..
0x005a0010  b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00   ……..@…….
0x5a0000 4d               DEC EBP
0x5a0001 5a               POP EDX


Process: notepad.exe Pid: 3908 Address: 0×150000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 28, MemCommit: 1, PrivateMemory: 1, Protection: 6

0×00150000  4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00   MZ…………..
0×00150010  b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00   ……..@…….

0×150000 4d               DEC EBP
0×150001 5a               POP EDX

You can dump these exes and hand them off to your malware team for analysis.

$ python vol.py procmemdump -p 3932,3908 -D ../Desktop/cases/
Volatile Systems Volatility Framework 2.3_alpha
Process(V) ImageBase  Name                 Result
———- ———- ——————– ——
0x856418a8 0×00400000 HOtdFs.exe           OK: executable.3932.exe
0x855b6930 0x00f40000 notepad.exe          OK: executable.3908.exe

9. What additional tools do you believe were placed on the machine?

$ python vol.py mftparser > /home/sansforensics/Desktop/parse.txt

2012-11-14 01:43:45  2012-11-14 01:43:45  2012-11-14 01:43:45  2012-11-14 01:43:45  Windows\System32\7za.exe

2012-11-14 01:36:28  2012-11-14 01:36:28  2012-11-14 01:36:28  2012-11-14 01:36:28  Users\malware_win7x86\AppData\Local\Temp\tior.exe
2012-11-14 01:36:27  2012-11-14 01:36:27  2012-11-14 01:36:27  2012-11-14 01:36:27  Users\malware_win7x86\AppData\Local\Temp\HOtdFs.exe
2012-11-14 01:43:45  2012-11-14 01:43:45  2012-11-14 01:43:45  2012-11-14 01:43:45  Windows\System32\7za.exe

2012-11-14 01:36:27  2012-11-14 01:36:27  2012-11-14 01:36:27  2012-11-14 01:36:27  Users\malware_win7x86\AppData\Local\Temp\IqPTTDpRL.exe


$ python vol.py printkey -K “Software\Microsoft\Windows\CurrentVersion\Run”
Registry: \??\C:\Users\malware_win7x86\ntuser.dat
Key name: Run (S)
Last updated: 2012-11-14 00:54:09 
Subkeys:
Values:
REG_SZ        WindowsAudio    : (S) C:\Users\MALWAR~1\AppData\Local\Temp\scvhost.vbs



10. What directory was created to place the newly dropped tools?

Not really “created” by the attacker. More done so by execution of the applications with the exception of using Windows\System32 as what appears to be a staging area for 7zip/

1. Users\malware_win7x86\AppData\Local\Temp\
2. Windows\System32\

11. How did the attacker escalate privileges?

Win7Elevate via Users\malware_win7x86\AppData\Local\Temp\IqPTTDpRL.exe. I pasted the reference code for the Win7Elevate exploit code. I only found this in one place on google - http://pastebin.com/dHiyz9rs

$ python vol.py handles |egrep ’3876|3104′ |more
Volatile Systems Volatility Framework 2.3_alpha

0x8547d7c8   3104       0×60   0x1f0003 Event            ws7Suicide
0x8547d4d0   3104       0×64   0x1fffff Thread           TID 3132 PID 3104
0xa642e750   3104       0x6c    0xf0007 Section          w7e_TIORPath
0x853af278   3104       0×70   0x1a019f File             \Device\NamedPipe\TIOR_In
0x8558cdc0   3104       0×78   0x1a019f File             \Device\NamedPipe\TIOR_Out
0x8549d038   3104       0×80   0x1a019f File             \Device\NamedPipe\TIOR_Err
0xa644bae0   3104       0×84    0xf0007 Section          w7e_TIORShell
0xa644a970   3104       0×88    0xf0007 Section          w7e_TIORArgs
0xa642efd8   3104       0x8c    0xf0007 Section          w7e_TIORDir

0x852e53b8   3876        0×8   0×100020 File             \Device\HarddiskVolume1\Windows\System32

Here is a bit of the code:
  1. //      Preparing shared variables to be used by TIOR that is going to start after we will inject
  2.                 //      and load dll into elevated process.
  3.                 //
  4.                 CInterprocessStorage::Create( TEXT(“w7e_TIORShell”), std::wstring(TEXT(“cmd.exe”)) );
  5.                 CInterprocessStorage::Create( TEXT(“w7e_TIORArgs”), args );
  6.                 CInterprocessStorage::Create( TEXT(“w7e_TIORDir”), std::wstring(TEXT(“C:\\Windows\\System32″)) );
  7.                 W7EInject::AttemptOperation(
  8.                         GetConsoleWindow(),
  9.                         true,
  10.                         true,
  11.                         pid,
  12.                         TEXT(“n/a”),
  13.                         argv[pass_through_index],
  14.                         args.c_str(),
  15.                         TEXT(“C:\\Windows\\System32″),
  16.                         strOurDllPath.c_str(),
  17.                         Redirector);
  18.                 return EXIT_SUCCESS;

$ python vol.py procmemdump -p 3104,3876 -D /home/sansforensics/Desktop/cases
Volatile Systems Volatility Framework 2.3_alpha
Process(V) ImageBase  Name                 Result
———- ———- ——————– ——
0x85318d40 0×01090000 IqPTTDpRL.exe        OK: executable.3104.exe
0x852e57e8 0x013d0000 tior.exe             OK: executable.3876.exe

These appear to be command line options.

$ srch_strings executable.3104.exe |more

Note, ‘elevate stuff’ will be executed in the elevated shell as ‘cmd.exe stuff’
elevate /c [arg1] [arg2] .. [argn]
elevate –pid 1234 /c [arg1] [arg2] .. [argn]
elevate /c
elevate /c c:\path\foo.exe [arg1] [arg2] .. [argn]
elevate –pid 1234 /c c:\path\foo.exe [arg1] [arg2] .. [argn]

12. What level of privileges did the attacker obtain?

$ python vol.py getsids |grep “S-1-5-32-544″
IqPTTDpRL.exe (3104): S-1-5-32-544 (Administrators)
tior.exe (3876): S-1-5-32-544 (Administrators)
HOtdFs.exe (3932): S-1-5-32-544 (Administrators)
notepad.exe (3908): S-1-5-32-544 (Administrators)
7za.exe (1912): S-1-5-32-544 (Administrators)
7za.exe (2916): S-1-5-32-544 (Administrators)

13. How was lateral movement performed?

N/A – There was no lateral movement.

14. What was the first sign of lateral movement?

There was not lateral movement. How do I know? I controlled the lab environment. However, one of the things I looked for when trying to identify lateral movement is the following via Splunk;

LogType=WindowsEventLog (EventID=528 OR EventID=529 OR EventID=540 OR EventID=4624 OR EventID=4625) | eval AUser=lower(UserName) | eval AUser=lower(if(isnull(AUser),TargetUserName,AUser)) | eval AUser=lower(if(isnull(AUser),AccountName,AUser)) | search NOT AUser=”*$” | stats dc(host) as HostCount by AUser | where HostCount>1

You will need to filter your Domain Controllers, or there will be too much noise. Use a NOT statement to filter them after the LogType=WindowsEventLog.

15. What documents were exfiltrated?

Correct me if I am wrong, but I believe that PID 3980 (notepad.exe) is using (or did use, but hasn’t been closed out yet)  the process and file handles for 7za.exe and \Users\malware_win7x86\Documents, which is why you see them listed in the handles section of notepad.exe
For example. If notepad.exe was used to open 7zip because it was injected by HOtdFs.exe, and then 7zip was used to compress the files in Users\malware_win7x86\Documents those handles would exist in the notepad.exe process and that’s why we are seeing them here.
So it’s fair to say that the files that reside (listed below) within \Documents were zipped up with 7zip and more than likely exfiltrated.

$ python vol.py handles |grep ’3908′
Volatile Systems Volatility Framework 2.3_alpha
0x8596bad0 3908 0×268 0×100020 File    \Device\HarddiskVolume1\Users\malware_win7x86\Documents
0x8549c9a0 3908 0×278 0x1fffff Process     7za.exe(1912)

So I can only assume that the following documents were exfiltrated:

$ python vol.py mftparser > /home/sansforensics/Desktop/parse.txt
2012-11-14 00:15:16  2012-11-14 00:15:23  2012-11-14 00:15:23  2012-11-14 00:15:23  Users\malware_win7x86\Documents\Secret.txt
2012-11-14 00:15:16  2012-11-14 00:15:31  2012-11-14 00:15:31  2012-11-14 00:15:31  Users\malware_win7x86\Documents\Financial_Numbers.txt
2012-11-14 00:15:16  2012-11-14 00:15:42  2012-11-14 00:15:42  2012-11-14 00:15:42  Users\malware_win7x86\Documents\SSN_and_CC_Data.txt
2012-11-14 00:15:16  2012-11-14 00:15:16  2012-11-14 00:15:16  2012-11-14 00:15:16  Users\malware_win7x86\Documents\Classified.txt

16. How and where were the documents exfiltrated?

Assuming we are correct on number 15, it would be via 7zip and via the network. I didn’t have a network capture to look at.

17. What additional steps did the attacker take to maintain access?

I can’t say for sure without looking at this vbs script and it’s not in memory. I’m assuming this executes HOtdFs.exe, and attempts to connect back to the C2 server.

$ python vol.py printkey -K “Software\Microsoft\Windows\CurrentVersion\Run”
Registry: \??\C:\Users\malware_win7x86\ntuser.dat
Key name: Run (S)
Last updated: 2012-11-14 00:54:09 
Subkeys:
Values:
REG_SZ        WindowsAudio    : (S) C:\Users\MALWAR~1\AppData\Local\Temp\scvhost.vbs

18. How long did the attacker have access to the network?

I’m not sure where to find anything in memory that would specifically tell us this. Given that network connections were still “ESTABLISHED” in memory the attacker more than likely still had access to the system/network upon memory acquisition.

19. What is the secret code inside the exfiltrated documents?

N/A – No “secret code”, but this could easily be turned around to, “What information was contained in the documents that were exfiltrated?” This might help you decide on what reporting procedures to follow.

You can get an idea of what the files contain by using mftparser.

$ python vol.py mftparser > mft.txt

$ cat ../Desktop/mft.txt | egrep -A 9 ‘Classified.txt|SSN_and_CC_Data.txt’
2012-11-14 00:15:16  2012-11-14 00:15:42  2012-11-14 00:15:42  2012-11-14 00:15:42  Users\malware_win7x86\Documents\SSN_and_CC_Data.txt

$DATA
0000000000: 4a 6f 68 6e 20 44 6f 65 0d 0a 31 32 33 2d 34 35   John.Doe..123-45
0000000010: 2d 36 37 38 39 0d 0a 31 32 33 34 2d 35 36 37 38   -6789..1234-5678
0000000020: 2d 39 31 30 31 2d 31 32 31 33                     -9101-1213

2012-11-14 00:15:16  2012-11-14 00:15:16  2012-11-14 00:15:16  2012-11-14 00:15:16  Users\malware_win7x86\Documents\Classified.txt
$OBJECT_ID

$DATA
0000000000: 49 27 6d 20 63 6c 61 73 73 69 66 69 65 64 2e      I’m.classified.

20. What is the password for the backdoor?

N/A – No password for the backdoor.

SUMMARY

Post IV will be File System forensics. I hope you enjoyed reading.

Tweet

References:
[1]http://grrcon.org/
[2]http://volatility-labs.blogspot.kr/2012/10/solving-grrcon-network-forensics.html
[3]http://computer-forensics.sans.org/blog/2010/04/02/openrunsavemru-lastvisitedmru

, , , , , ,

Comments are currently closed.

One thought on “APTish Attack via Metasploit – Part III – Memory Analysis