Week 2

Recovering Lost Files

I started out this lab a bit confused. I thought the question in lecture regarding whether or not volitility created the memory dump for us or not was a good one but the conversation around the question was tough to follow. I thought I’d do a little exploration on my own when the lab began and he noted we needed 3 ingredients. OSFMount, the .fat.dd image, and PhotoRec. After looking through the windows vm for a while, I remembered back to the introductory syllabus to the mention of a shared mounted directory for some lab resources. There they were! OSFMount and the memory image to recover from. From here I kicked the lab video off once again and the professor was able to guide me to the PhotoRec executable.

I mounted the image at E:\ and opened up PhotoRec to begin the recovery process. It turned out to be pretty painless with a small hickup. The first attempt I must have tried to write to a directory without correct permissions. I got this error:

I figured I should just try again and make sure to put it in a directory I know that I have control over (the desktop!). Writing there, the recovery process went just fine.

Mayflower

Question Summaries

1) What is/are the cyber targets found on the stick?
S-Oil Onsan Refinery
GS Caltex Oil Yeosu Refinery

2) Investigate possible malware and describe how it works
The malware has some targets, ip addresses and switches in the csv file protected by a password found in the dont tell ms il ung.jpg file. The malware likely opens up the csv with the password, then plugs those targets into the stuxnet backdoor exploit. The malware has some username and passwords baked into it (probably obtained by a password cracker) which they can plug into stuxnet. Once the backdoor is configured, stuxnet is deleted.

3) Display the list of username/passwords

Dayals-1 | London13!
JHKim4-1 | !Tomorrow33
KManku-1 | M@nday77
MMcLean3-1 | @Smiley91

4) What offset value did you find the list at?

XOR key 0x67
OFFSET 0x3ebbd

5) Which relevant files were deleted and can you recover them?

I was able to recover the GOV hacked background file which led me to find the passwords within the .bin malware file. Seems to me that because these files were deleted, that the attackers might have been using part of the SONY attack as a piece of their strategy. Perhaps the SONY attack had a sneaky backdoor that the attacker wanted to use and then once they obtained the backdoor they deleted the SONY malware.
I believe there are other relevant parts of the STUXNET exploit that were deleted but I had a hard time determining which ones were which. A lot of the files deleted there were probably unrelated to the attack, maybe just a user’s old information that they deleted (seems sloppy?).

6) What strategy would you give the targets?

I think it’s reasonable to ask that employees use randomly generated passwords from a character generator instead of using common words. I don’t know how these passwords were obtained but I find it suspicious that each of these 4 were regularish words. These passwords seem like they would be good targets for a password cracking program, so enforcing a randomly generated password policy might have helped obstruct some of the attack.

Investigation Notes

Hint 1:
Passwords recovered from photorec is fake data
Only 2 or 3 recovered files you really need
.bin file is the malware
Username and passwords are hidden within the .bin file

Hint 2:
.zip file contains the targets (answer to #1)
password to zip is hidden in another file
password is in .jpg dont tell ms ung

Hint 3?
wallpaper hacked by GOP holds clues!
Find company who got hacked here and search for the company name

Start - 10:37
Setup share network at \10.100.0.1\share
Install OSFMounts
Mount mayflower to E:\ from the network share
Running photorec on it and extracting to desktop 10:44

I started off by trying to google the file names to see if I could infer anything intersting from them, however my VM was not connecting to the internet and I wasn’t able to copy text from within the vm to my local computer. Probably for the better as if I were able to copy somethign I might accidently run something that I shouldn’t run.

At 11:05, I had a lot of trouble trying to open and unzip the .zip file to get at the csv inside. It wasn’t that I couldn’t find the password, (infected123!) it was that every time I tried to open it to enter in a password, I would get a system error instead. I was finally given a password prompt using 7zip and got in to see the csv contents.

After looking around at the recovered flies a bit more, I was able to find the GOV background. There I could see SPEData.zip as the extension mentioned in the hint. Quick google shows that this is actually Sony pictures!

I took the hint to search the bin for SPE using fileInsights and the XOR-Search plugin to find 4 username and passwords.

Slightly more cleaned up:

Dayals-1 | London13!
JHKim4-1 | !Tomorrow33
KManku-1 | M@nday77
MMcLean3-1 | @Smiley91

Next I started searching for files that could be relevant and were deleted. I used an XOR-search for the term .exe within the bin and came up with an interesting line

cleaned up this reads
wmic.exe / node:”%s” / user: “%s” / password: “%s” PROCESS CALL CREATE “%s” > %s..%d_%d…ProcessId -s.WTSQueryUserToken…wtsapi.dll…

Googled wtsapi.dll and it looks like its a library necessary for running a remote shell. My best guess currently is that this bit of code is attempting to create a backdoor with, substituting the users and passwords in from the list above.

I’m going to run volatility on the mem dump and see if I can see anything interesting.

Running pslist from volatiltiy, we can see evil.exe and svchest.exe running just like our first lab from last week. This is confusing to me, could it be this memory dump was taken from a computer that ran both? Are they actually the same virus? Maybe one virus is using part of the other, but I think evil.exe is something specific to our class and this challenge was given as a sample from a real world case.