### Cynet Incident Response Challenge 2020 WriteUp

I came to know about and started on the Cynet IR Challenge https://incident-response-challenge.com, quite late and was focused more on doing a writeup for it. However, Cynet released their writeup yesterday. I decided to continue with my writeup anyways and compare it against Cynet’s solution and see where I went wrong.

I thought it was a good idea to write my analysis and highlight some of the issues with the Cynet IR Challenge questions. I also hope to learn more from my esteemed colleagues in the DFIR industry and open to discussion on the approaches and investigation direction I took for the challenges.

EASY ONES

Challenge #1

Time Machine

Story

GOT Ltd CTO claimed that he found out a suspicious activity on his laptop.

He stated that some of his files suddenly moved from one location to another, when other files seem to be modified on illogical dates. He asked us to check if we can find anomaly indicators which is relevant to his desktop files.

We found out that he was right and there is clear indication of anomaly, using a well-known technique. Try to examine the following  $MFT file, focusing the CTO’s Desktop files. Can you find the anomaly, which is relevant to the time in which file’s changes/modifications have been made, based on the provided$MFT File?

This challenge was pretty straightforward, as we were supposed to find sign of usage of time stomping technique (ATT&CK T-), which is a common anti-analysis (anti-forensic) technique. I usually use mft2csv (https://github.com/jschicht/Mft2Csv) and then compared the $FN ($FILE_NAME) and $SI ($STANDARD_INFORMATION) attributes timestamps to find the anomaly. Remember that $FN can only be changed by a kernel level process, so it is a bit tricky to stomp these timestamps by attacker. The answers is below, we can see the file creation timestamp for the two attributes, which differ: SI_CTIME - 1/1/2019 1:01:01 AM FN_CTIME - 1/19/2020 11:51:19 AM Challenge#2 Hello DoK Story Podrick claims that last Monday (February 3, 2020), at lunch time (around 12:00 PM) a USB device of a malicious entity was plugged into his personal computer. He has also mentioned that he saw one of his colleagues – Theon G, leaving his (Podrick’s) office with the USB in his hand. Theon claims that he entered the office to visit Aria (who sits in the same office). When he saw Aria was not there, he left the office immediately. Podrick regularly doesn’t lock his computer and suspects that Theon took advantage of this to steal some of his personal data. We were invited to examine Podrick’s PC. Was a USB Device connected to Podrick’s PC on February 3, 2020? Instructions Submit the Serial/UID of the suspected USB device Top of Form Serial/UID Challenge#2 We were provided the following pieces of evidence. I used the tool regripper to rip the hives and analyzed the output to find evidence of USB usage during the asked time period. I was able to find the evidence of USB usage along with its serial number on Feb 3rd at 12:12 (UTC). It is to be kept in mind that registry and Window event logs are stored in UTC time zone. The local time zone (Israel Standard Time) will therefore will be Feb 3rd 14:12. Challenge #3 Bling-Bling Story Lord Varys, director of the finance department in GOT-Research Ltd, found out that certain information about the senior employees’ salaries were leaked and reached other employees of the organization. This financial information is saved on a network shared folder. Permissions to this network folder have been given to Lord Petyr Baelish, and 2 former employees: John Snow, and Daenerys Targaryen. Both John and Daenerys work as external consultants to GOT and aren’t part of the finance department anymore. Their permissions to the finance shared folders haven’t been revoked yet. Petyr Baelish, John, and Daenerys were never in a good relationship, and Varys suspects them as the cause of the leak. He assumes that one of them wanted to hurt his name and make people think that he leaked the information. GOT-Research CEO asked John and Daenerys about the mentioned event, when both claimed that they didn’t access the finance folder for almost a year (since leaving the finance department). Important Information: To examine if John or Daenerys have accessed the financial data, which includes that Management-Salaries.xlsx file that contains the data which has been leaked. GOT invited us to investigate the Consultants’ PC. Instructions Submit the main suspect’s first name + filename of the suspicious finance file, found on the suspect's host. Filename Format:File-Name.ext First Name Filename We were provided with jumplist forensic artifacts for both Jsnow and Daenerys. I used the awesome Zimmerman’s tool JLECmd.exe tool to parse AutomaticDestinations and CustomDestinations I also used JumpListsView from Nirsoft to find the suspected secret files (Finance-Summary.rar and Varys-Secret.txt) on Jsnow desktop While you can stick to a certain tool to analyze forensic artifacts, sometimes you might come across a situation where the tool of your choice will not provide the desired output and that why your forensic arsenal and toolkit should be composed of multiple parsers and tools. Challenge #4 Is that you? Story We were asked to come as soon as possible to GOT Ltd. main site in Japan to investigate their Windows Server 2012 R2 – Domain Controller. The organizational security experts claimed that lately the server has crashed a few times and that other errors have also occurred frequently. Their attempts to find a reasonable explanation have failed and they suspect that malicious activity on this server has been taking place. To investigate this issue, Podrick, GOT Ltd. VP invited us as DFIR experts. As the first step in the investigation, before our arrival to Japan, GOT Ltd. , sent us a raw memory dump which has been taken from the Domain Controller at 17:40. The organizational security experts have noticed that the server crashes have occurred each time around 17:45 and tried to get the best raw memory they could for our investigation. Can you recognize the suspected process in memory? Instructions Submit the PID and PPID of the suspected process PID: 3-4 Decimal Digits value PPID: 3-4 Decimal Digits value PID PPID For this challenge, we were provided the memory image of the suspect endpoint. One of the first things during memory analysis is to identify signs of malicious process(es) running or hidden and this can be achieved by using various volatility plugins. Just by using pstree I could see isass.exe running as a child process of explorer.exe. So first, it is masquerading as genuine lsass.exe process and secondly lsass.exe parent is nor explorer.exe but wininit.exe. So this is most probably our malicious candidate process. The process id is 232 and parent process id is 912. Challenge #5 B4 Catch ### Story Aria, Head of Security and IT at GOT Ltd. noticed some suspicious SIEM alerts. The alerts mentioned a suspicious file named Scvhost.exe which has been recognized on some organizational hosts. Right as she started to examine this issue, the files were deleted from the hosts. Aria suspects that Scvhost.exe is a malicious file (probably some kind of malware) and that the attacker is currently in the organizational network. GOT Ltd management wants us to determine if the Scvhost.exe has been executed on the organizational hosts, when the execution occurred, and how it was deleted. Instructions Submit the last execution time of the suspicious file + number of executions on the examined host. Time Format: DD-MM-YYYY HH:MM (no seconds) Number of executions Time Stamp In this challenge Cynet is asking us to provide the: Last execution time stamp of the suspicious file (but did not clarify whether this is to be in UTC or Local timezone) Number of executions of the malicious file on the examined host From the question itself, we can know that we need to parse and analyze prefetch files to get the answer. I used another one of EZ (Eric Zimmerman) tool called PECmd.exe to parse the prefetch files We can easily see the malicious file and the number of time of execution. More importantly we can see the latest execution timestamp which is 7th of Feb 2020 21:26 (UTC) and 23:36 (Local) To answer on how was the file deleted, I looked at the timeline output of the PECmd.exe tool and could see execution of sysinternal tool sdelete.exe, which is a tool to securely deleted files. This might be the tool used to securely delete the malicious file. Challenge #6 Titan Story The Master of Whispers has ears everywhere. The kingdom has decided it is time to do something about it. We are going from server to server fo find his little birds who keep talking, repeatedly. This Ubuntu server has been suspected to be compromised. We need to know the IP of the listener. Instructions Submit the IP of the malicious C2 Bottom of Form We are to provide the ip address of the C2 server to which the Ubuntu server is talking to. The evidence provided are some select folders and files from the file system of the compromised server. One of the first thing we should be looking at to look for signs of beacon on a *nix box are the scheduled jobs (cron jobs) which are one of the persistence mechanisms used by *nix malware/backdoors etc. Inside this file “Margaery” I was able to find the reverse shell going to ip 17.71.29(.)75:443 Challenge #7 Sports Story Sansa went on a trip to The Eyrie. Upon her return she seems to be feeling unwell. We think she has been infected with a bug. When she wakes up, she starts coughing up commercials for Anti-Marriage campaigns. Please look at her profile and see what the issue is. Instructions Submit the malicious file executed using the persistence mechanism on the station: Filename Format: filename.ext (ext stands for a 3 letter file extension) File name In this challenge we are asked to submit the name of the file which is malicious and is being executed using a persistence mechanism. The evidence provided is the user profile of user “sansa” The first thing I did was to rip the registry hives from the user’s profile. We know that the registry contains various evidence of executions, so I started looking at the regripper output and I could see the malicious file 213123.exe under temp folder executed on March 18th 20:57 UTC. This was of course the wrong answer as I observed from the Cynet’s writeup. I realized that if it were a user level persistence then it would not really be under appcompat or recentapps forensic artifacts because this is where the applications are shown which were interactively executed by the user and not automatically by malicious persistence. Correct answer: Lessons Learned: Never “Assume” as assuming makes an …… (we know the rest). Never assume that a file with strange name and suspicious location is the evidence. It could be the evidence but we need to delve deeper and hit the right evidence. This was easy to answer if one does not stumble on the first piece of evidence and then does not look further. Challenge #8 LNK Files Story Someone has been spreading rumors about how much everyone makes in the kingdom. Upon, further investigation we found that the salaries file accidently had its permissions set to everyone. Sansa believes that someone is Littlefinger. We need to find evidence that he had accessed the salaries file. This way we can finally have leverage against him. Instructions Submit the flag located in the same artifact source as the evidence against Littlefinger: File In this challenge we are supposed to submit the flag related to evidence that littlefinger accessed the salaries file. The evidence provided to us was the user profile of user “littlefinger”. I used the wrong approach to look for the flag by looking at the browsing history as I thought that the user accessing the confidential file “Salaries.docx” from a network share would leave some evidence on the browsing history of IE. I wrongly submitted the filename as the flag. The correct answer I realized from Cynet’s writeup was to look for lnk (shortcuts) created as this would indicate access. Even though I did find the evidence of accessing the salaries file however the question was to find a FLAG, which was situated along with the lnk files. The lesson learned: There are “questions” at the startup of a forensic investigation. The “Who”, “What”, “When” and sometimes the “Why” J. Time and energy should be diverted to focus on the question and what artifacts can help in answering the question. MEDIUM ONES Challenge #9 Can’t touch this Story Podrick was satisfied from our first investigation, in which we proved that Theon has probably plugged his USB device to Podrick’s PC when he was away. As we remember, we proved that someone (Theon) plugged a USB device to Podrick’s PC on February 3, 2020 – around 12 PM (12:15-12:45 PM according to our findings of Suspicious USB usage – Hello DOK). Podrick claims that some of his files/directories have changed, he thinks that the changes have also made by Theon on his first access to his machine which we have already proved as probably happened. He wants us to find out which files were changed/touched by Theon, focusing on the Projects folder which according to Podrick has been completely emptied. We said that we would do our best and continue with our investigation, to find which files have been watched/copied by Theon. Instructions Submit the time in which the “Projects” folder was recreated by Theon. Note: it is recommended you solve Challenge No.2 before starting this challenge. Time Format: HH:MM:SS Time Stamp Again in this challenge, we are asked to provide the timestamp (Cynet should have mentioned the timezone UTC or local) for submission, when “Project” folder was “recreated”. Evidence provided were Windows Event Logs and registry hives from user profile. I answered this one wrongly as well. I took the wrong approach of looking at the NTUSR.DAT for evidence of “recreation of project” folder. I did found some files which were accessed around the time of intrusion on Feb 3rd 12:41:53 UTC. Regripper output shows last write timestamp in UTC. Ref: https://www.sans.org/blog/regripper-ripping-registries-with-ease/ The correct approach is to use Shellbags parsing to get the evidence of creation time (born time) of files and folders, which below clearly shows the correct timestamp. 12:41:26 Lesson Learned: Use the right tool for the job and always focus on the forensic investigation QUESTION “recreation timestamp” -> “creation/born timestamp” Challenge #10 Copy PaSTe Story Theon, one of GOT Ltd. Employees has been fired due to many disciplinary issues. Theon was a member of the Help-Desk team and supported the company employees on the following aspects: Computing hardware problems Software installations Email support Theon’s hearing before dismissal took place on February 5, 2020. And he was officially fired on February 8, 2020. Right after Theon’s dismissal, some private emails of GOT’s CEO (John Snow) and VP (Daenerys) has been published. Theon claims that he has nothing to do with that. Varys, Theon former boss, claims that Theon didn’t have any access to the CEO’s and VP’s emails. But he also suggested to give us Theon’s PC which hasn’t yet been formatted for us to investigate. Varys already checked Theon’s Desktop and said that it’s totally empty, which means that Theon has probably moved/deleted some files. Can you find the specific file that has been deleted/moved which can indicate that Theon had access to John’s (CEO) E-Mail data? In this challenge we are supposed to find the specific file which has been deleted/moved related to the CEO email data. The evidence provided to us was the$J of UsnJrnl, $Logfile,$Max and $MFT. I decided to use the ANJP tool. Since we have to look for signs of email files of JSnow, which Theon Accessed, we will look for common email files in the filter. We can see the filename JohnSnowPST.pst created on the desktop of Theon and later moved to recycle bin: Challenge #11 WhoaMI Story The SOC analysts of the GOT organization reported that they have found some anomalies. The analysts assume that the attacker still exists on the organization but can’t find any backdoor signs. They asked us for help and sent us the disk image copy to investigate. The head of the SOC team stated that according to his observation there has been massive PowerShell and CMD usage throughout the organization, including in hosts which are not being used by technical employees. One of the most suspicious hosts is Lady Brienne’s host. Brienne (GOT's accountant) stated that she has never used PowerShell or CMD, while the SOC team stated that her machine is probably the “noisiest” in the last few days. Can you find the backdoor technique which has being used by the attacker on Lady Brienne’s PC? Instructions Submit the full path of the file executed by the persistence mechanism. Full path Format: C:\path\to\malicious\file.ext Backdoors name One of the challenges of WFH: My kid decided to respond to this challenge with his answer XD! So I lost a couple of points. We are asked about the file executed by a persistence mechanism and we are provided with wbem folder, which contains the WMI repository. We can try to finds WMI persistence via FitlerToConsumerBindings, by searching the OBJECTS.DATA file I used the following python script to parse the OBJECTS.DATA file and I can see the WMI Consumer and Filter bindings:$ python PyWMIPersistenceFinder.py ../OBJECTS.DATA

Challenge #12

Kiwi

Story

Jaime, known as the King-Slayer is head of HR in GOT Ltd. He recognized, or at least thinks that he recognized, some suspicious activity on his PC.

Yesterday – February 8, 2020, around 15:00, he recognized a file with a kiwi logo appeared on his desktop. According to him, the file suddenly disappeared not long after its first appearance on his desktop. Later that day, he started getting messages saying he needs to re-activate Windows Defender. He activated Windows Defender and got the same message again a few hours later.

King-Slayer decided to tell this to his friend in the IT department – Chris. When Chris heard the story, he reported it immediately to the Cyber Security department of GOT Ltd.

The organization’s CISO didn’t want to waste time and called us right away.

GOT Ltd main office is in Switzerland. The CISO sent us all the event logs from King-Slayer’s PC and from the Domain Controller.

Can you help us to find the relevant anomaly?

• Jaime’s user account (KingSlayer) is Local Admin on his host.
• Domain Name -> GOT.Com
• DC Server name -> WIN-IL7M7CC6UVU
• Jaime (King Slayer) host -> DESKTOP-HUB666E (172.16.44.135)

Instructions

Submit the domain user account which the attacker used (other than King-Slayer) and the IP Address of the host which he accessed to using this user account.

In this challenge we need to provide the domain user account which was used by attacker and the ip address of the host which was accesed by the attacker using the compromised account. As evidence we are provided the windows event logs of the Domain Controller and the machine of the head of HR (Jaime).

From the pivot timestamp of Feb 8th 2020 15:00 (local time), we can start investigating the event logs of Jaime’s Host. I noticed an EventID 4624 where we can see a user Daenerys logging on Jaime’s machine, logon type is 9 (runas) and the logon process is “seclogo”, this is highly indicative of “pass-the-hash” attack Ref: https://blog.stealthbits.com/how-to-detect-pass-the-hash-attacks/.

Subsequently, we can see below eventid 4648 where user Daenerys is used to login to WIN-IL7M7CC6UVU (Domain Controller) on SMB protocol on 9th Feb 2020 13:59 UTC (15:59 local time).

Next we can see that psexec was being used to login to WIN-IL7M7CC6UVU (Domain Controller) using Daenerys username (compromised user). Most probably mimikatz was used on Jaime’s machine and the Daenerys account was compromised. This was then used to move laterally to DC.

User: Daenerys

Moved Laterally to: WIN-IL7M7CC6UVU 172.16.44.132

Strangely the Cynet’s writeup does not mention the username and the ip address of the attacked host. Not sure if the answer submitted by me was accepted as correct or not.

Challenge #13

### Story

The great web server has been showing signs of weird activity lately.

Some weird cronjobs have been created and there has been some unexpected outgoing traffic.

The cronjobs were created using a web-server user. We suspect someone managed to create a backdoor using the website itself.

Instructions

Find the flag in the reverse shell.

Flag

In this challenge, we have to find a hidden webshell created by an attacker and we are provided the file structure of the web server. We have to find the hidden flag. The challenge was that the web application (/src/usr/local/www) was pfsense (open source firewall) and the source php files have webshell like functionalities.

I used a simple approach where I grepped for various webshell related strings (eval, exec, /bin/bash etc), and narrowed to some suspicious files. I found the following file “resettable”. There was a pastebin URL in this file.

$grep -rHn exec | grep -v execu | grep -v mwexec$ grep -rHni "/bin/bash" | more

src/usr/local/sbin/resettable:1:#!/usr/local/bin/bash

When I went to this site I saw the FLAG.

It was clear that the FLAG string was base64 encoded, so I decoded it:

I submitted the string “WebShellFound” as the response, which undortunately differs from what is mentioned in the Cynet writeup.

The investigation methodology used in the Cynet writeup was different and they used the timestamp way to find a file with different timestamp. However the FLAG found is the same but they did not decoded the base64 string. And submitted the encoded FLAG.

Lesson Learned: When one have to submit a “FLAG” in a CTF, it has to be preceded by flag keyword. There is no need to further decrypt/decode and just submit the flag as it is.

Challenge #14

Sneak

### Story

The Army of the North believes it might have a spy amongst them.

They have clear indication that the enemy anticipates their movement.

We must find the suspicious process that keeps sending data outside.

Instructions

Find the suspicious process name.

Process Name Format: Process.exe

Process name

The challenge asks us to find the process, which keep sending data outside (exfiltration). The evidence provided to us is a memory image.

I first found went through the metadata of the memory image to identify the OS, which I can use as profile while running volatility plugins.

Since data exfiltration means some sort of network connection to C2 server, I immediately use the netscan plugin to look for connections.

$python ./volatility/vol.py -f DESKTOP-HUB666E-20200203-130818.dmp --profile=Win10x64_15063 netscan I can immediately pick up that chrome.exe process (PID 5820) is proxing RDP inside a 443 (SSL) tunnel.$ python ./volatility/vol.py -f DESKTOP-HUB666E-20200203-130818.dmp --profile=Win10x64_15063 netscan | egrep '932|5820'

Volatility Foundation Volatility Framework 2.6.1

0xab0000093500     UDPv4    127.0.0.1:59734                *:*                                   932      svchost.exe    2020-02-03 09:53:10 UTC+0000

0xc60fd6693500     UDPv4    127.0.0.1:59734                *:*                                   932      svchost.exe    2020-02-03 09:53:10 UTC+0000

0xc60fd6ae6e00     TCPv4    0.0.0.0:3389                   0.0.0.0:0            LISTENING        932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd6850640     TCPv4    172.16.109.155:49853           172.16.109.155:3389  CLOSED           5820     chrome.exe

0xc60fd72b1a40     TCPv4    172.16.109.155:49854           172.16.109.155:3389  ESTABLISHED      5820     chrome.exe

0xc60fd72f16a0     TCPv4    172.16.109.155:3389            172.16.109.155:49854 ESTABLISHED      932      svchost.exe

0xc60fd80775a0     UDPv4    0.0.0.0:3389                   *:*                                   932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd80775a0     UDPv6    :::3389                        *:*                                   932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd80995d0     UDPv4    0.0.0.0:3389                   *:*                                   932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd94ebec0     UDPv4    0.0.0.0:0                      *:*                                   932      svchost.exe    2020-02-03 12:38:34 UTC+0000

0xc60fd94ebec0     UDPv6    :::0                           *:*                                   932      svchost.exe    2020-02-03 12:38:34 UTC+0000

0xc60fd94fe770     UDPv4    0.0.0.0:5355                   *:*                                   932      svchost.exe    2020-02-03 12:53:35 UTC+0000

0xc60fd94fe770     UDPv6    :::5355                        *:*                                   932      svchost.exe    2020-02-03 12:53:35 UTC+0000

0xc60fd97f62b0     TCPv4    0.0.0.0:3389                   0.0.0.0:0            LISTENING        932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd97f62b0     TCPv6    :::3389                        :::0                 LISTENING        932      svchost.exe    2020-02-03 13:05:50 UTC+0000

0xc60fd9a25a00     UDPv4    0.0.0.0:5353                   *:*                                   932      svchost.exe    2020-02-03 12:38:34 UTC+0000

0xc60fd9a25a00     UDPv6    :::5353                        *:*                                   932      svchost.exe    2020-02-03 12:38:34 UTC+0000

0xc60fda053620     UDPv4    0.0.0.0:5353                   *:*                                   932      svchost.exe    2020-02-03 12:38:34 UTC+0000

0xc60fda1e01d0     TCPv4    172.16.109.155:49831           172.16.109.149:443   ESTABLISHED      5820     chrome.exe

0xc60fdaaad6b0     UDPv4    0.0.0.0:5355                   *:*                                   932      svchost.exe    2020-02-03 12:53:35 UTC+0000

I also calculated md5sum of the process 5820 (chrome.exe)

sansforensics@siftworkstation -> ~/D/M/M/C/5820

$md5sum * 4fbfd6af5aa3e8b2a85dc533e103edcc executable.5820.exe Looking the hash up in VT shows that it is a metasploit reverse shell Attack Steps: · Process svchost.exe PID 932 is RDP service listening on port 3389 on · Victim 172.168.109.155 connected through meterpreter reverse shell to attacker 172.16.109.149:443. The reverse shell process is masquerading as chrome.exe · Meterpreter command “portfwd” was used for port forwarding local 3389 to compromised host 3389. Something like (from meterpreter shell): · meterpreter > portfwd add –l 3389 –p 3389 –r 172.169.109.155 · The reverse shell (SSL tunnel) hides the RDP traffic from attacker to victim and also effective in bypassing any firewall rules blocking port 3389 on victim. Our theory is further substantiated by running “malfind” plugin, which shows us signs of malicious code injection inside the chrome.exe (PID 5820)$ python ./volatility/vol.py --plugins=/usr/lib/python2.7/dist-packages/volatility/plugins -f DESKTOP-HUB666E-20200203-130818.dmp --profile=Win10x64_15063 malfind

The malicious process is chrome.exe

Challenge #15

Universal

Story

We have been getting reports from a concerned user about unusual behavior on his workstation. CMD windows occasionally popup, and sometimes the station is reset.

The behavior seems to persist after these restarts.

We believe some malicious software has implemented a persistence mechanism, but our team has not been able to find it so far.

Instructions

Submit the persistent process

Process Name Format: Process.exe

File name

In this challenge we have to find a persistent process, which is the cause of the unusual behavior.

The evidence provided to us are the user profiles of users admin, default and Tyrion and other system hives.

SilentProcessExit is a persistent mechanism set up by using GlobalFlag. I was able to find this setup when I ripped the software registry hive. This is monitoring for process exit of notepad.exe. Whenever a notepad.exe process ends/exits, this malicious file runs.

Malicious process: ZmxhZy17Rm91bmRJdH0.exe

Challenge #16

Notes

Story

He has successfully connected to Kings Landing (DC) using the GOT\varys-adm of the IT team Domain Admin account credentials.

It is yet unclear how he found those credentials.

We suspect it to be the entry point of the attacker to the whole organization.

Instructions

In this challenge, we were asked to find out the password of varys-adm. Evidence provided to us are the Windows Event Logs and the user profile of littlefinger user.

The first thing I noticed that there was an RDP connection (EventID 4624 and logontype 10) from the Security event logs from the littlefinger’s computer. There is a useful artifact called RDP Client Cache, which can be used to see some graphical remnants of the RDP session from the client. I used the script below “bitmapcache_bin_parser.ps1” to parse the Cache bin file located at: littlefinger\AppData\Local\Microsoft\Terminal Server Client\Cache

I extracted the tiles in the following folder and while going through the tiles, I found an interesting one where I can see the username GOT\varys-adm and a potential password below it.

Challenge #17

Psss

Story

Same old story.

The master of whispers has ears everywhere.

Cersei is paranoid…

We have another station which might be compromised.

Help us find the IP of the listening C2 server.

Instructions

Submit the IP of the reverse shell server.

We are supposed to find the ip address of the reverse shell server and we are provided the evidence of Windows Event Logs. This was an easy one as we were provided the Powershell Logs, where we can see a very suspicious powershell in the script block logging logs. We can see the ip address of the C2 server in the logs clearly.

Challenge #18

Roots

Story

We have found the following pdf running around our infrastructure.

It clearly has legs.

We believe the attacker has hidden a password to one of his services in the code and we need that password.

Instructions

In the PDF there is a word file and in the word file there is a macro that contains the flag in ascii.

Note: The password to unzip the file is R00tsChall3nge

This was another easy one, where we were supposed to find the flag in ascii. I saved the doc file from the pdf and opened the doc file and stepped into the macro. The macro downloaded a powershell from the pastebin. I downloaded the powershell and I could see the link to the secret inside the github site. This secret is a string and an array is created out of it. I took the PS in the Ise debugger and placed some breakpoints

The resultant charcode after processing is then converted into ascii and we can see the Flag.

Challenge #19

2nd Base

Story

Once again, we have found ourselves with some malware running amuck our peasants.

However, this time we have made an image of a clean machine. Use it to compare the infected machine with the clean machine. Maybe it could help?

What is the malicious process?

Instructions

Submit the name of the malicious process.

Process Name Format: ProcessName.exe

This challenge was a bit unique where we were provided two memory images, one of clean system and the other one of infected system. We are supposed to compare both and find out the malicious process.

I answered this wrong and went into an overdrive thinking mode J . The answer was simple as we could see whatsapp.exe and cmd.exe as child process in the infected image, which were not present in the baseline image.

Baseline

0x00008a82ff8b6ef0  27870      1 RW-r-d \Device\HarddiskVolume3\ProgramData\Microsoft\Windows Defender\Network Inspection System\Support\NisLog.txt

0x00008a82ffd4a400      2      0 R--rwd \Device\HarddiskVolume3\Users\JonSnow\Desktop\Flag!.txt

0x00008a82ffc94080  29961      1 RW---- \Device\HarddiskVolume3\Windows\appcompat\Programs\Amcache.hve

0x00008a82fdace7f0      1      1 -W-rw- \Device\HarddiskVolume3\Windows\debug\ESE.TXT

0x00008a82ff630ef0  30066      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SAM

0x00008a82ff3afcf0  30093      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SECURITY

0x00008a82feb54060  22271      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SOFTWARE

0x00008a82feb7b590  28570      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SYSTEM

0x00008a8300426ef0     11      0 RWD--- \Device\HarddiskVolume3\Windows\System32\sru\SRUDB.dat

0x00008a82fff8fef0  32768      1 R--rwd \Device\HarddiskVolume3

0x00008a82ffd58420     16      0 R--rwd \Device\HarddiskVolume3滐齗폰顥릊

0x00008a82fffd2a00  32768      1 R--rw- \Device\HarddiskVolume3䯐顙릊꼁릊꼁릊꼁릊

Infected

0x000080061e564950     25      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\squirrel.exe

0x000080061de5a830     15      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\WhatsApp.exe

0x000080061dfe2420      1      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\WhatsApp.exe

0x000080061dfe5d50      1      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\WhatsApp.exe

0x000080061f137780     25      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\Update.exe

0x000080061e0f9b70     21      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\WhatsApp.exe

0x000080061e8169b0      1      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\WhatsApp.exe

0x000080061f79def0      1      0 R--r-d \Device\HarddiskVolume3\ProgramData\JonSnow\WhatsApp\app-0.4.315\WhatsApp.exe

0x000080061deb96d0      1      0 R--r-- \Device\HarddiskVolume3\ProgramData\Microsoft\Windows\ClipSVC\tokens.dat

0x000080061e057670  32259      1 RW-r-d \Device\HarddiskVolume3\ProgramData\Microsoft\Windows Defender\Network Inspection System\Support\NisLog.txt

0x000080061f7a16e0     16      0 R--rwd \Device\HarddiskVolume3\ProgramData\Microsoft\Windows\WER\Temp\WERCEE1.tmp.csv

0x000080061ea97670     16      0 R--rwd \Device\HarddiskVolume3\ProgramData\Microsoft\Windows\WER\Temp\WERCF40.tmp.txt

0x000080061f550080     15      0 RW---- \Device\HarddiskVolume3\ProgramData\Microsoft\Windows\WER\Temp\WERE93E.tmp.csv

0x000080061f52e2a0     15      0 RW---- \Device\HarddiskVolume3\ProgramData\Microsoft\Windows\WER\Temp\WERE94F.tmp.txt

0x000080061dfa2ef0  32214      1 RW---- \Device\HarddiskVolume3\Users\JonSnow\NTUSER.DAT

0x000080061e179dd0  32231      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SAM

0x000080061e141c70  32240      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SECURITY

0x000080061d7d2060  31773      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SOFTWARE

0x000080061d7d6060  32081      1 RW---- \Device\HarddiskVolume3\Windows\System32\config\SYSTEM

0x000080061ebd69c0

Pstree

0xffff80061f65e080:WhatsApp.exe                     5392   4524     37      0 2020-02-09 16:23:30 UTC+0000

. 0xffff80061f031780:WhatsApp.exe                    5612   5392      4      0 2020-02-09 16:23:34 UTC+0000

. 0xffff80061f70e080:WhatsApp.exe                    4816   5392     15      0 2020-02-09 16:23:34 UTC+0000

. 0xffff80061f613080:cmd.exe                         3352   5392      1      0 2020-02-09 16:23:34 UTC+0000

.. 0xffff80061f036080:conhost.exe                    4740   3352      1      0 2020-02-09 16:23:34 UTC+0000

. 0xffff80061f738080:WhatsApp.exe                    5496   5392      0 ------ 2020-02-09 16:23:49 UTC+0000

. 0xffff80061f61a080:WhatsApp.exe                    4116   5392     24      0 2020-02-09 16:23:40 UTC+0000

However, I used the approach of using processbl volatility plugin which is meant to identify process differences between the baseline and infected memory images. Below I executed this plugin.

$python ../volatility/vol.py --plugins=/usr/lib/python2.7/dist-packages/volatility/plugins -B DESKTOP-HUB666E-20191101-155228.dmp -f ../Infected/DESKTOP-HUB666E-20200209-162404.dmp --profile=Win10x64_15063 processbl –U In the output, I noticed onedrive.exe (Pid 5784) running which is showing to be different in the infected image as compared to the base image. 0xffff80061ddb3080 wininit.exe c:\windows\system32\wininit.exe 472 388 False 0xffff80061ef57080 googlecrashhan c:\program files (x86)\g...ooglecrashhandler64.exe 1888 1800 False 0xffff80061f2d1780 shellexperienc c:\windows\systemapps\sh...shellexperiencehost.exe 4080 712 False 0xffff80061f7bc080 onedrive.exe c:\users\jonsnow\appdata...t\onedrive\onedrive.exe 5784 1636 False 0xffff80061f65e080 whatsapp.exe c:\programdata\jonsnow\w...pp-0.4.315\whatsapp.exe 5392 4524 False 0xffff80061f031780 whatsapp.exe c:\programdata\jonsnow\w...pp-0.4.315\whatsapp.exe 5612 5392 False 0xffff80061f70e080 whatsapp.exe c:\programdata\jonsnow\w...pp-0.4.315\whatsapp.exe 4816 5392 False 0xffff80061f613080 cmd.exe c:\windows\system32\cmd.exe 3352 5392 False 0xffff80061f61a080 whatsapp.exe c:\programdata\jonsnow\w...pp-0.4.315\whatsapp.exe 4116 5392 False 0xffff80061f73d080 smartscreen.ex c:\windows\system32\smartscreen.exe 4588 712 False 0xffff80061f74b780 trustedinstall c:\windows\servicing\trustedinstaller.exe 5516 616 False 0xffff80061e62a780 tiworker.exe c:\windows\winsxs\amd64_...b46f67bb63\tiworker.exe 4568 712 False I took a Procdump of (pid 5784) MD5sum=714ea5145b7a2f7517a28de8e0ee4be3 and checked the md5 in VT and found it to have a score of 3/72. I then procdumped onedrive.exe 6168 from baseline image and found it to be a different hash and a VT score of 1/72. This made me think that maybe this process onedrive.exe is the malicious process. Prodump – baseline (pid 6168) MD5sum=f1511c7de618aafdee3aec91d3831ef8 It is strange that whatsapp.exe process was the answer as per Cynet writeup. I procdumped the Whatsapp.exe process also and checked its hash but it was a genuine whatsapp desktop file. Not sure on what basis Whatsapp.exe was the answer. Lesson Learned: Nothing to learn here Challenge #20 Meow Story We have met quite an advanced adversary. Multiple accounts have been compromised on the network. We think an attacker gained access to the DC and harvested the credentials. We have imaged the domain controller and we think there should be some leftovers which can indicate which relevant tool has been used by the attacker. Can you find them? Instructions Submit the tool's name, which has been used by the attacker Filename Format: FILE.EXT (ext stands for a 3-letter file extension) In this challenge we were asked to find out the tool used by the attacker on the DC for credentials harvesting. The disk image of DC was provided to us as evidence. This was a tricky one. I downloaded he execution artifacts from the image and analyzed them but could not find any evidence of malicious execution except for PSEXESVC.exe, which indicates that the psexec.exe was used to remote execute something on the Domain Controller. But what was executed was not clear from simple forensic artifacts analysis. I analyzed prefetch, amcache, registry hives, MFT, JumpList, autoruns output and event logs but could not find anything solid. So I responded wrongly “psexesvc.exe” as the answer to this question, thinking that this is also form of a tool, which was used during the credentials compromise. Amcache Parsing > AmcacheParser.exe -i -f "G:\Windows\AppCompat\Programs\Amcache.hve" --csv "c:\temp" –nl MFT – mft2csv Autoruns Evtx analysis However, as per Cynet writeup, they used the approach of carving prefetch files from the raw disk image. If that was done then a deleted prefetch file of mimikatz.exe is supposed to be found, indicating that mimikatz.exe is the tool used by the attacker on the DC. Let us try this approach out. Bulk extractor (an overkill in this situation), did not give any result trying to carve out prefetch files I then tried a different tool: # prefetch-carve.py -f DC.001 -o output And got the result showing a file with name mimikatz executed. However my argument is and which I think Cynet should consider, is that just seeing a file with name mimikatz.exe executed can only work as a “corroborative” evidence but not “substantial” evidence that this was a malicious file and part of the toolkit of the attacker. In DFIR, we are to get hold of the best quality of evidence to reconstruct what happened in the past. While evidence of execution of PSEXESVC.EXE was much more substantive and established when compared to carving out deleted prefetch files and just by looking at their names. We can also see other “names” in the results like powershell2.exe and sdelete64.exe, which also very well could be part of the intruder’s toolkit. Lesson Learned: In parallel to using tools, also try raw carving of artifacts from disk images, using tools like bulk_extractor etc. This might not always be necessary but in cases where investigation direction is not providing any leads. Challenge #21 Sad Story There is a station infected with ransomware (desktop-hub666e). This station has some very valuable files. All of our transactions with the Iron Bank are kept there. We have captured a PCAP and a memory dump of the station for some analysis. We can't afford to pay the current ransom. We need the data inside that encrypted file. Instructions Submit the data in the encrypted file. This challenge was interesting. It asked us to decrypt a file encrypted with a ransomware, indicated in the challenge as “Wannacry”. Evidence provided to us was a PCAP (during download of malicious ransomware binary) and a memory dump of the host. It is to be noted that the memory dump of the host was post-execution of the ransomware and there was no sign of a running ransomware. The first thing I did was to export HTTP objects from PCAP and got hold of the ransomware sample, called Salary-2019.exe Turns out that it was not “wannacry” but “hidden tear” ransomware, which resulted in infection. While using Filescan volatility plugin, I could see that the malware wrote itself in a folder called Rans123 under the JonSnow profile, which further confirmed that this was a “hidden tear” ransomware sample and not wannacry. 0x00008a82ff973e70 9 0 R--r-d \Device\HarddiskVolume3\JonSnow\Rand123\local.exealary-2019.exe 0x00008a8301027ad0 14 0 R--r-d \Device\HarddiskVolume3\JonSnow\Rand123\local.exealary-2019.exe I tried hunting for mutex handles, indicated in the malware analysis report in VT for the sample, in the memory image and see which process has the handle, but they all turned out to be false positives. PID and TID -> 660 and 8108 # python /home/sansforensics/Desktop/volatility/vol.py --plugins=/usr/lib/python2.7/dist-packages/volatility/plugins -f DESKTOP-HUB666E-20200113-141824.dmp --profile=Win10x64_15063 pstree root@siftworkstation -> /h/s/D/H/Challenge While looking at the registry I noticed the timestamp when the ransomware was accessed Jan 13th 14:16 UTC and 16:16 (Local) # python /home/sansforensics/Desktop/volatility/vol.py --plugins=/usr/lib/python2.7/dist-packages/volatility/plugins -f DESKTOP-HUB666E-20200113-141824.dmp --profile=Win10x64_15063 userassist REG_BINARY C:\Users\JonSnow\Downloads\Salary-2019.exe : Count: 1 Focus Count: 0 Time Focused: 0:00:00.500000 Last updated: 2020-01-13 14:16:24 UTC+0000 Raw Data: 0x00000000 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000010 00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf ................ 0x00000020 00 00 80 bf 00 00 80 bf 00 00 80 bf 00 00 80 bf ................ 0x00000030 00 00 80 bf 00 00 80 bf ff ff ff ff 60 a0 a1 09 ............`... 0x00000040 1c ca d5 01 00 00 00 00 ........ I did string search by using the strings from the ransom note to find related strings in the memory. I was hoping to see if I could find Key and IV used during the AES CBC encryption. While doing so, I discovered an interesting URI, which showed data being exfiltrated and there was a pssword there as well. # strings --radix=x DESKTOP-HUB666E-20200113-141824.dmp | grep -i "1LLubVvDAXd3RoSAKUFbLdv4EAWH37NEcu" -A1 -B1 >> bitcoinadd.txt # strings --radix=x DESKTOP-HUB666E-20200113-141824.dmp | grep -i "Yarraq" -A1 -B1 >> yarraq.txt 11163297 BTC Wallet: 1LLubVvDAXd3RoSAKUFbLdv4EAWH37NEcu 111632c8 2) write on our e-mail : cyborgyarraq@protonmail.ch 11163400 FILE0 Password = iXGwWakNXnnm06( Since “hidden tear” source code was open sourced and published, I got hold of the source code and opened up it in Visual Studio. I hardcoded the encrypted file and the password and ran the decryptor. It is to be noticed that I kept the iterator value at 1000 (default). This iterator value could have been changed by the attacker while compiling the ransomware and it would have been trickier to decrypt the encrypted file. I placed some breakpoints and got hold of the values of the SHA256 key and IV (Initialization Vector). passwordBytes = SHA256.Create().ComputeHash(passwordBytes); Key: SHA256 = 846aba5db07bcbf0934a5c220d333f333d38c90b2c816ed2c2e1e4c4660b55a5 IV: e7 4e 41 80 0a 78 a3 f0 4e 9f 7b ba 6d b8 47 dc dd ee a0 51 fc 4d 8f c8 4f 1d 9b c5 4d b9 10 c7 Encrypted bytes: 08 a5 db dd f3 bf 28 6e a0 57 c2 24 0f 5a 9d 7c c9 2f a7 ce 41 16 17 c9 ef 89 2d 5f 50 16 65 fc e2 d6 f1 a4 f8 ff 01 ac a1 74 6c 21 3e e0 4a e0 Got the flag below: Challenge #22 Insurance Story The user Robert had his wallpaper changed to a life insurance ad. Robert says he did not do it. We assume someone connected to his machine and did so! We have no idea how the insurance wallpaper got to the station. Any help? Instructions Submit the time stamp of the lateral movement technique used: In this challenge, the wallpaper of a victim was changed and we are asked to provide the time stamp of the lateral movement technique “used”, which changed the wallpaper on the victim’s machine. Again It was not indicated which timezone is to be used when submitting the timestamp. Evidence provided were: user profiles of various users, Amcache, prefetch folder and system registry hives and windows event logs. From registry it was clear that the local time zone of the host was “Israel Standard Time”. During any forensic investigation, we have to keep the following points in mind, in relation to timestamps: • Most of the timestamps recorded natively by OS (Event Logs and registry) are stored in UTC • Then there is local time (the timezone configured on the host machine). In this case the local time is Israel Standard time which is UTC+2 • We also need to keep in mind the tools used for viewing/parsing forensic artifacts. Some of the tools will output the original timestamps stored inside the artifacts by the OS (UTC) and some of the tools might provide the output with timestamps in local time of the machine (timezone configured on the machine) and some tools like Event Viewer will show the timestamps of events according to the timezone of the “viewing machine”. So, for example, If I view the logs provided in these challenges, using the Windows Event Viewer, and if a particular event occurred at 11:13:00 as per the local time (timezone configured on the investigated host, that is Israel Standard Time), then I will see in the raw (Details->XML View) view of the event that the event timestamp was stored in UTC (9:13:00) by the OS and in the regular view (General tab) I can see that the event viewer automatically offset the timestamp and shows me the timestamp according to my timezone (UTC+4), which is 13:13:00 (UTC+4). While analyzing the registry, I came across the following two instances of psexecsvc.exe service getting installed. 2/4/2020 1:13:38 PM (My Local time UTC+4) 2/4/2020 11:13:38 AM (Israel Standard Time) b. 2/4/2020 1:13:00 PM (My Local time UTC+4) 2/4/2020 11:13:00 AM (Israel Standard Time) When I parsed prefetch files, I can see the corroborative evidence that psexesvc.exe service was installed/executed on the machine 2 time. The two timestamps are highlighted in yellow below: c. Prefetch  PSEXESVC.EXE-AD70946C.pf 5/8/2020 3:56:25 PM 2/4/2020 1:13:48 PM 5,497 PSEXESVC.EXE \VOLUME{01d5c9a5b09bb375-34b0b891}\WINDOWS\PSEXESVC.EXE 2/4/2020 1:13:38 PM, 2/4/2020 1:13:00 PM (My local time UTC+4) 2/4/2020 11:13:39 AM, 2/4/2020 11:13:00 AM (Israel Standard Time) Further evidence of this can be seen while analyzing Windows Events Logs: We can see that the account Robert was used to install/run psexecsvc.exe on the subject host and the timestamp on the event viewer on my machine shows the timestamp according to my timezone (UTC+4). This is: 2/4/2020 1:13:39 PM (My local timezone) 2/4/2020 11:13:39 AM (Israel Standard Time) So I submitted the timestamp of “2020-02-04 11:13” as this was the execution timestamp of psexecsvc.exe when offsetted according to Israel Standard Time. The Cynet writeup, however, says the answer is “2020-02-04 09:13”, which is actually UTC timestamp. Typically a forensic timeline is created and presented in the local timezone of the country/region where the incident took place. This makes it easy to infer various other conclusions and provide further investigative leads. Not sure why Cynet expected UTC timestamp submission. Lesson Learned: In order to maintain a consistent view and reconstruction of events during the investigation, a timezone needs to be selected and all timestamps of events should be offset to the selected timezone. Challenge #23 Layers Story We had an attacker on the network, we think we flushed him out, but we think there are still some other stations he had infected or had access to. We ran Autoruns using Kansa on the stations, and saved each station's output on the following format: -Autorunsc.csv. hopefully we can see if any station looks suspicious. Instructions Submit the most suspected computer name + name of suspicious artifact(filename). Filename Format: filename.ext (ext stands for a 3-letter file extension) This challenge provided us evidence from Kansa autoruns output and we were supposed to use the concept of LFO (Least Frequency of Occurrence) to hunt for malicious persistence on the workstation(s). I was too lazy to import these in an ELK so I resorted on bash-fu. However, I must say that I made a blunder in this one. I could see the psexecsvc.exe on only LANNISTER machine. Nevertheless, I thought this was too easy and it cannot be the answer so I actually discovered a unique unsigned driver (.sys) file, which I found only on one computer and I gave that as the answer. WRONG! Some bash-fu # strings --encoding=l *.txt | awk -F',' '{print$19,$2,$3,$5,$7,$8,$10,$12,$13,$18}' | sort | uniq -c | sort -nr -k1 | sed s/\"//g strings --encoding=l *.txt | awk -F',' '{print$3}' | sort | uniq -c | sed s/\"//g

strings --encoding=l *.txt | egrep -o '[A-Z0-9]{32}' | sort | sed s/\"//g | sort | uniq -c | sort -nr -k1

Correct Answer: LANNISTER PSEXESVC: PsExec Service

Lesson Learned: Sometimes the answer is easy and right in front of you. Many times even advance attackers uses simple open source offensive tools J

Challenge #24

Story

Classic case. We have a frog running loose and its running havoc.

We have clear indication of malicious outgoing traffic to a host on the digital ocean.

We can’t seem to find the malicious process on the system.

We know there is a frog hidden in the malicious executable.

Find the process, extract the frog.

Instructions

Find the flag inside the malicious process.

This challenge was interesting, as we were provided a memory dump and we were supposed to find the malicious process communicating to a digital ocean host (C2 server). And then we were supposed to find a frog (flag) from inside the malicious process.

As I mentioned before that during memory forensic investigation, one of the first few things I do is to try to identify malicious process. I ran a couple of volatility plugins and identified chrome.exe (pid 1996) as the suspicious process. The reasons I found it to be suspicious are as below:

Malprocfind output shows that it is running without a parent. Parent PID 6324 cannot be found

Malfind output shows it as a candidate for malicious code injection

Procdump was used to dump pid 1996, calculated its MD5 hash and looked it up in VT and found that it was the malicious process.

\$ python /home/sansforensics/Desktop/volatility/vol.py --plugins=/usr/lib/python2.7/dist-packages/volatility/plugins -f THEEYRIE.dmp --profile=Win10x64_15063 pslist

Malfind output

Process: chrome.exe Pid: 1996 Address: 0x140000000

Flags: PrivateMemory: 1, Protection: 6

0x140000000  4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00   MZ..............

0x140000010  b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00   ........@.......

Malprocfind output

0xffffbf8a4d4287c0 svchost.exe      3596 True  True  True  True      False   False True  False True  True    True

0xffffbf8a4f02a7c0 conhost.exe      2976 False True  True  True      False   True  True  True  False True    True

0xffffbf8a4d4157c0 sihost.exe       3588 False False False True      False   False True  False True  True    True

Processes without running parent process:

-----------------------------------------

PID 6240 Offset: 0xffffbf8a4bda77c0 Name: MpCmdRun.exe

PID 3624 Offset: 0xffffbf8a4d6747c0 Name: GoogleCrashHan

PID 3068 Offset: 0xffffbf8a4ecbe7c0 Name: explorer.exe

PID 1996 Offset: 0xffffbf8a4be88080 Name: chrome.exe

PID 8032 Offset: 0xffffbf8a4d9516c0 Name: GoogleCrashHan

PID 6140 Offset: 0xffffbf8a4c680080 Name: MpCmdRun.exe

Md5sum of pid 1996

3715f8e2486410afd5e66ca9410e5632  executable.1996.exe

I then looked for the strings inside the process executable and found the flag:

Flag is: “Frog-FWGA142FS”

Challenge #25

Story

WAF logs show an unusual spike in SQL Injection attempts on our domain Westeros.GOT.com in the last days (since 4.2.2020).

We are afraid an attacker might have been able to access the server using the SQL Injection.

Please make sure whether the attacker was able or not to successfully use the SQL injection to gain access to the server.

If he did, what is the time he did so?

Instructions

Time format: YYYY-MM-DD HH:MM (no seconds)

In this challenge we were provide with limited evidence (Windows Event Logs) and SQL Server ERROR logs. We are asked to provide the timestamp when the attacker “gained access to the OS”. This would be OS of the server hosting the SQL server.

I thoroughly looked into the logs and I could find a couple of suspicious leads. I could see the advance options were tuned on and the SQL stored procedure to execute commands on the OS was also enabled at 2020-02-05 11:02 (Israel Standard Time), 13:02 (My UTC+4 time) and 09:02 (UTC time). However, enabling xp_cmdshell does not mean that the intruder ran a command on the OS or accessed the OS. The SQL Server ERROR logs did not provide any further evidence and I wanted to find a solid evidence of execution of a command on OS by the attacker. I turned to Windows Event Logs to see if I can find any anomalous event. I focused on Security.evtx and filtered out EventID 4907. Then I started looking for events which occurred after the xp_cmdshell was enabled.

The only event of some interest was the following and therefore the timestamp I submitted was 2020-02-05 12:53 (Israel Standard Time). This is wrong as per Cynet writeup where they say that the timestamp of enabling xp_cmdshell stored procedure is the time when intruder accessed the OS. But I do not agree as this is just enabling the SP and not really running a command on the backend OS.

Lesson Learned: Nothing to learn here.