Comment on page
Case 001 - Szechuan Sauce
I'm aiming to tackle this CTF with both open source and commercial software. Volatility for the memory analysis, Wireshark for the PCAP analysis, Magnet AXIOM for the entire case, and if I have time, Autopsy as well. This is an ongoing project which is time intensive.
Analysts are presented with the following files.
- DESKTOP-SDN1RPT-Protected Files.zip
Questions to Answer / Goals
- What’s the Operating System of the Server?
- What’s the Operating System of the Desktop?
- What was the local time of the Server?
- Was there a breach?
- What was the initial entry vector (how did they get in)?
- Was malware used? If so what was it? If there was malware answer the following:
- What process was malicious?
- Identify the IP Address that delivered the payload.
- What IP Address is the malware calling to?
- Where is this malware on disk?
- When did it first appear?
- Did someone move it?
- What were the capabilities of this malware?
- Is this malware easily obtained?
- Was this malware installed with persistence on any machine?
- What malicious IP Addresses were involved?
- Were any IP Addresses from known adversary infrastructure?
- Are these pieces of adversary infrastructure involved in other attacks around the time of the attack?
- Did the attacker access any other systems?
- Did the attacker steal or access any data?
- What was the network layout of the victim network?
- What architecture changes should be made immediately?
- Did the attacker steal the Szechuan sauce? If so, what time?
- Did the attacker steal or access any other sensitive files? If so, what times?
- Finally, when was the last known contact with the adversary?
This is a long string, so we'll set $DC01 to /mnt/c/DF/CTF/DFIRMadness/EvidenceFiles/DC01-memory/citadeldc01.mem
$ echo $DC01
First, obtain a profile using kdbgscan as we'll rely on this later on when running other commands.
$ python vol.py -f /mnt/c/DF/CTF/DFIRMadness/EvidenceFiles/DC01-memory/citadeldc01.mem kdbgscan
Volatility Foundation Volatility Framework 2.6.1
Instantiating KDBG using: Unnamed AS Win2012R2x64_18340 (6.3.9601 64bit)
Offset (V) : 0xf800cba9ba20
Offset (P) : 0x249ba20
KdCopyDataBlock (V) : 0xf800cb9dd6d8
Block encoded : Yes
Wait never : 0xb59702001c3eb201
Wait always : 0x387d79fd32e1c000
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win2012R2x64_18340
Version64 : 0xf800cba9bd80 (Major: 15, Minor: 9600)
Service Pack (CmNtCSDVersion) : 0
Build string (NtBuildLab) : 9600.17031.amd64fre.winblue_gdr.
PsActiveProcessHead : 0xfffff800cbab40a0 (40 processes)
PsLoadedModuleList : 0xfffff800cbace2d0 (154 modules)
KernelBase : 0xfffff800cb804000 (Matches MZ: True)
Major (OptionalHeader) : 6
Minor (OptionalHeader) : 3
KPCR : 0xfffff800cbaea000 (CPU 0)
KPCR : 0xffffd0019fd55000 (CPU 1)
From this we can identify the most appropriate profile suggestion based on the kernel debug header, identify the number of processes running and loaded modules. If kdbgscan returned 0 values, it would not be an appropriate profile. I personally prefer to use instantiated profiles which containing a specific build number. Volatility modules/plugins work nicely with specified builds. For example, if we run hivelist using Win2012R2x64 instead of Win2012R2x64_18340, it does not contain any results. The latter shows our required hives.
Q 1. We can obtain this from the memory dump from DC01. Our results above suggest the most appropriate profile is Windows Server 2012 R2, but let's see how we can confirm that with registry artefacts. Since Windows 2000, operating system information is stored in the registry at the following location; HKLM\Software\Microsoft\Windows NT\CurrentVersion. Armed with that location and an OS profile from Volatility, we can query the registry and print the following keys;
$ python vol.py -f $DC01 --profile=Win2012R2x64_18340 hivelist
Virtual Physical Name
------------------ ------------------ ----
0xffffc001f30e0000 0x000000001e6ab000 \??\C:\Users\Administrator\ntuser.dat
0xffffc001f326b000 0x00000000166ec000 \??\C:\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat
0xffffc001f1f00000 0x0000000028b27000 \??\C:\Users\Administrator\ntuser.dat
0xffffc001f1f2a000 0x000000002281d000 \??\C:\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat
0xffffc001f1e41000 0x000000002e696000 \??\C:\Users\Administrator\ntuser.dat
0xffffc001f1e94000 0x0000000035846000 \??\C:\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat
0xffffc001f0c1e000 0x0000000000972000 [no name]
0xffffc001f0c28000 0x00000000009fd000 \REGISTRY\MACHINE\SYSTEM
0xffffc001f0c55000 0x0000000000930000 \REGISTRY\MACHINE\HARDWARE
0xffffc001f1166000 0x0000000000bfc000 \Device\HarddiskVolume1\Boot\BCD
**0xffffc001f117a000 0x000000000cc96000 \SystemRoot\System32\Config\SOFTWARE**
0xffffc001f3c1a000 0x00000000732f5000 \SystemRoot\System32\Config\DEFAULT
0xffffc001f76b8000 0x0000000007a66000 \SystemRoot\System32\Config\SECURITY
0xffffc001f773b000 0x000000007204e000 \SystemRoot\System32\Config\SAM
0xffffc001f7735000 0x00000000717f3000 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
0xffffc001f1200000 0x00000000714ba000 \SystemRoot\System32\Config\BBI
0xffffc001f129d000 0x0000000070ed3000 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
0xffffc001f3208000 0x000000001d156000 \??\C:\Users\Administrator\ntuser.dat
0xffffc001f3216000 0x000000001d25c000 \??\C:\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat
We don't want to dump the SOFTWARE hive itself (we would use hivedump for that). We just want to query the current values.
$ python vol.py -f $DC01 --profile=Win2012R2x64_18340 printkey -K "Microsoft\Windows NT\CurrentVersion"
Legend: (S) = Stable (V) = Volatile
Key name: CurrentVersion (S)
Last updated: 2020-09-17 18:05:43 UTC+0000
REG_SZ SystemRoot : (S) C:\Windows
REG_SZ SoftwareType : (S) System
REG_SZ RegisteredOwner : (S) Windows User
REG_DWORD InstallDate : (S) 1600361039
REG_SZ CurrentVersion : (S) 6.3
REG_SZ CurrentBuild : (S) 9600
REG_SZ RegisteredOrganization : (S)
REG_SZ CurrentType : (S) Multiprocessor Free
REG_SZ InstallationType : (S) Server
REG_SZ EditionID : (S) ServerStandardEval
REG_SZ ProductName : (S) Windows Server 2012 R2 Standard Evaluation
REG_SZ ProductId : (S) 00252-10000-00000-AA228
InstallDate is in epoch timestamp (number of seconds since 01/01/1970). Converted = GMT: Thursday, September 17, 2020 4:43:59 PM
While we have the profile up and running, we'll query current processes to identify anything suspicious.
$ python vol.py -f $DC01 --profile=Win2012R2x64_18340 pstree -v
$ python vol.py -f $DC01 --profile=Win2012R2x64_18340 netscan > netscan.txt
Client interview identified compromised systems were located in 10.42.0.0 (client said 'something something', but it's this CIDR).
Remove references to IPv6
$ grep -v "dns.exe\|v6" netscan.txt
We identify the following connections from local processes to remote hosts;
0x20fc7590 TCPv4 10.42.85.10:62613 18.104.22.168:443 ESTABLISHED 3644 coreupdater.exe
0x60182590 TCPv4 10.42.85.10:62613 22.214.171.124:443 ESTABLISHED 3644 coreupdater.exe
$ whois 126.96.36.199
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
% Information related to '188.8.131.52 - 184.108.40.206'
% Abuse contact for '220.127.116.11 - 18.104.22.168' is '[email protected]'
inetnum: 22.214.171.124 - 126.96.36.199
descr: Netway Communication Co.,Ltd.
descr: 72 4th Floor, Telecom Tower, Charoen Krung Road,
descr: Bangrak, Bangkok 10500,Thailand
descr: Tel (662) 639-7700 Fax: (662) 639-7706
status: ALLOCATED PORTABLE
(We can check this IP against our captured PCAP shortly).
Q 2. What’s the Operating System of the Desktop?
For this we'll use Magnet Forensics' AXIOM. We've already created a case and ingested our E01, memory dumps, and PCAP files. For information on how to create a case and add data plesae see Magnet CTF Week 0.
As you can see, AXIOM makes light work of processing images and presenting information in a single pane of glass. On the left hand side under 'Operating System', select 'Operating System Information'. Clearly this has been identified as Windows 10 Enterprise, build 19041. On the right hand side we have a tonne of information which has been extracted from the registry and parsed. If required, we could export a copy of both the SYSTEM and SOFTWARE registry hives to verify and validate the information being presented, however that is outside the scope of this guide.
Q 3. What was the local time of the Server?
This question itself is a bit ambiguous. Time at the point of the breach? Of the acquisition? At shutdown? For this, we'll look at local time zone information and also the last modified file on the file system (lastalive0.dat).
Back to artefacts. Bottom left hand corner, we can see Timezone Information.
We can see a wealth of information regarding AXIOM's data source. This shows the timezone was UTC -8:00 Pacific Time.