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.
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
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.
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.
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)
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.
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.
\\kings-landing\share\Secret\F1a9-AFNIEJFJSSE.docx
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
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”.
Lesson Learned: Use the right tool for the job and always focus
on the forensic investigation QUESTION “recreation timestamp” ->
“creation/born timestamp”
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
I can see the c:\temp\addadmin.ps1 and
empddadmin.ps1 consumers above whenever calc.exe is executed.
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.
Seashell
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.
We think maybe someone has gained access to the server.
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.
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.
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
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.
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
An attacker has gained access to
Littlefinger’s session on his computer.
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
Submit the Varys-adm user password.
Varys-adm
user password
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.
IP
address
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.
Ip address: 104.28.32.159
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
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
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)
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.
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 "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).
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
Vad
Tag: VadS Protection: PAGE_EXECUTE_READWRITE
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”
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
Submit the time when the attacker gained
access to the OS.
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.
Comments
Post a Comment