So the description for this challenge briefly explains what amcache is, and also gives a link to a file.

If you want more information on Amcache, this is a great link.

So upon research, I found RegRipper can be used to do this, however, there are plenty of other great tools out there. The one I decided to use for this challenge was AmCacheParser.

AmCacheParser runs on Windows and is basically a tool to analyse and "parse" Amcache. so the command we run this through the windows command prompt.

AmcacheParser.exe -f "Amcache.hve" --csv OutputFolder

We run the above command in the AmcacheParser folder. To break this down we run AmcacheParser.exe taking the -f argument which tells the tool which file to take as an input, we then specify the file given which was Amcache.hve. We also need to give an output for the files, this is the --csv part of the command and we specify the folder next. This will run the tool and the output will be in the file OutputFolder, or whatever you chose to name it.

So as the above image shows, we now have a lot of Excel files to sort through, I first re-read the description to see what we needed and it led me to look in the 20201017155041_Amcache_UnassociatedFileEntries entry, which looks a bit like this:

Once here i then used the find tool (CTRL + F) to search for mpowers which was the user given to us by the description. Below are the entries for mpowers, more specifically from the full path column.

So as shown above, we have quite a lot of file paths. We were told to find what he installed, so I instantly looked deeper at the python install executables. It is very clear he installed Python on the system so i tried the flag as flag{python} and we scored the flag.

Writeup created by Chris Harris (@cjharris18)

Evil Corp's Child 1:

Briefing:

What is the MD5 hash of the Windows executable file?

NOTE: If you extract any files within this challenge, please delete the file after you have completed the

Link to pcap file:

link: https://tinyurl.com/y3oltdh5
password: hacktober

Right so they started off easy. Opening up the pcap I used the http display filter to show packets of this protocol:

Opening up the details for the first packet, we can see the full request URL at http://www.sinotes.com/wp-content/themes/avada/picture4.png. I then ran wgethttp://www.sinotes.com/wp-content/themes/avada/picture4.pngto download the file. As the brief suggests, this is not a png but rather a windows executable. Therefore renaming it to ecorp.exe and running the command md5sum ecorp.exe gives us the flag of flag{a95d24937acb3420ee94493db298b295}.

Evil Corp's Child 2:

Briefing:

The malware uses four different ip addresses and ports for communication, what IP uses the same port as https?  Submit the flag as: flag{ip address}.

Use the file from Evil Corp's Child.

Here, we need to use some display filters to refine our search. Firstly, we know it uses the same port as HTTPS. This is port 443. Secondly, We're talking about the malware and know that the infected client's ip is 192.168.1.91 from challenge 1. Putting this into a display filter would look like this:

Although there are quite a few packets, there are only so many different ips, so trying about 5 got me the correct answer, which was flag{213.136.94.177} .

Evil Corp's Child 3:

Briefing:

What is the localityName in the Certificate Issuer data for HTTPS traffic to 37.205.9.252?

Use the file from Evil Corp's Child.

This was an interesting one. After some googling, I found out that Certificates are sent during tls handshakes, as TLS is used to encrypt HTTP traffic, making it HTTPS. The Display filter i needed to show these packets was tls.handshake.type == 11.

As said in the brief, we need the packet from the source IP 37.205.9.252 . Therefore expaning this packet's details, then TLSv1.2 Record Layer: Handshake Protocol: Certificate then Handshake Protocol: Certificate then Certificates then subject: rdnSequence (0) finally gives us the LocalityName.

flag{Mogadishu}

By das :)

link to file:

file: https://tinyurl.com/y4z72k5o
Password: hacktober

Remotely Administered Evil 1:

Briefing:

What is the name of the executable in the malicious url? Submit the filename as the flag: flag{virus.bad}.

Simply opening it up in wireshark, we can see the flag-

flag{solut.exe}

Remotely Administered Evil 2:

Briefing:

What MYDDNS domain is used for the post-infection traffic in RATPack.pcap?
Use the file from Remotely Administrated Evil.

All you need to do here is filter for dns traffic. Because there weren't too many packets, I spotted the flag almost immediately and didn't have to filter further.

flag{solution.myddns.me}

Link to file:

File: https://tinyurl.com/y259doyq
Password: hacktober

An Evil Christmas Carol 1:

Briefing:

A malicious dll was downloaded over http in this traffic, what was the ip address that delivered this file?

Like the others, you can just filter for http traffic and get the flag:

flag{205.185.125.104}

An Evil Christmas Carol 2:

Briefing:

What is the domain used by the post-infection traffic over HTTPS?
Use the file from An Evil Christmas Carol.

We're looking for a domain, so it must be a dns query. Therefore filtering for DNS traffic and specifying the ip (10.0.0.163 as this is the infected client from part 1, and the infected client must've made the query) we can get the flag-

flag{vlcafxbdjtlvlcduwhga.com}

By das

For this challenge, you get given a mem.raw file. So initially this along with the title screams memory forensics and so the main program that comes to mind is Volatility, if unfamiliar with this tool, it can be best described as a memory forensics tool to help you look at memory captures of RAM. This tool should be automatically installed on Kali, but other distros should follow install instructions found on the GitHub page (linked above).

It is worth noting I used Volatility 2 in this writeup, the syntax for Volatility 3 is similar, just replace volatility with vol3 it could also be worth noting that depending on your install, you might need to run it as volatility.py

So to start with you run the following command with a memdump/raw format, the imageinfo plugin will provide basic information on the memory capture:

volatility -f mem.raw imageinfo > raw_imageinfo.txt

Breaking this command down we have the name of the program volatility followed by -f which tells volatility to take in the file mem.raw, then as outlined above the imageinfo plugin gives us basic information on the image. I then personally followed it with > raw_imageinfo.txt just so I have it saved in a text file should i need it earlier. This is not essential, however i reccomend it, especially for when Volatility can have a lot of input, it also gives you the power of tools like grep and awk.

Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x64_17134, Win10x64_14393, Win10x64_10586, Win10x64_16299, Win2016x64_14393, Win10x64_17763, Win10x64_15063 (Instantiated with Win10x64_15063)
                     AS Layer1 : SkipDuplicatesAMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/home/REDACTED/Downloads/mem.raw)
                      PAE type : No PAE
                           DTB : 0x1aa000L
                          KDBG : 0xf8001e43d520L
          Number of Processors : 2
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0xfffff8001d4e2000L
                KPCR for CPU 1 : 0xffffd40032268000L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2020-06-26 15:51:36 UTC+0000
     Image local date and time : 2020-06-26 08:51:36 -0700

Then we take the profile, normally we take the first however it won't always work, luckily ,in this case, it was the first profile which is Win10x64_1734.

We then run the following command as we were told we needed the PID so automatically i decided to look at the processes, now this can be done with either the pstree plugin or the pslist plugin, the difference is mainly that pstree gives us a more visual representation of which process was launched by which, whereas pslist lists them all. I chose pstree, the command is shown below:

volatility -f raw.mem --profile=Win10x64_1734 pstree > raw_pstree.txt 

Breaking this down, we have the volatility -f raw.mem as I mentioned before which initialises Volatility along with specifying the file. The big difference here is that we now specify a profile as shown by the --profile=Win10x64_1734 part of our command, when we ran imageinfo we took the profile and now we need to specify it to Volatility to run further plugins. The next part of our command is pstree which as outlined above creates a tree of all processes on the system. I then also save this in a file again with > raw_pstree.txt which helps me with things like grep but also means I only need to run this command once. Below is a shortened output for the sake of the writeup:

Name                                                  Pid   PPid   Thds   Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
 0xffff87868e88d440:System                              4      0    111      0 2020-06-26 15:07:32 UTC+0000
. 0xffff878690147040:smss.exe                         348      4      2      0 2020-06-26 15:07:32 UTC+0000
. 0xffff87868e975040:Registry                          88      4      3      0 2020-06-26 15:07:23 UTC+0000
. 0xffff878690ccc040:MemCompression                  1168      4     50      0 2020-06-26 15:07:58 UTC+0000
 0xffff878690495080:wininit.exe                       528    424      1      0 2020-06-26 15:07:45 UTC+0000
. 0xffff8786904cd080:services.exe                     648    528      6      0 2020-06-26 15:07:46 UTC+0000
.. 0xffff8786914d2580:TrustedInstall                 2572    648      5      0 2020-06-26 15:43:20 UTC+0000
.. 0xffff878690c8d580:svchost.exe                    1052    648     18      0 2020-06-26 15:07:58 UTC+0000
.. 0xffff878690c2d580:svchost.exe                      60    648     64      0 2020-06-26 15:07:56 UTC+0000
... 0xffff8786909b0580:sihost.exe                    2672     60     15      0 2020-06-26 15:08:51 UTC+0000
... 0xffff87868fa02580:wuauclt.exe                   5288     60      7      0 2020-06-26 15:43:18 UTC+0000
... 0xffff8786909e1580:taskhostw.exe                 2764     60     10      0 2020-06-26 15:08:52 UTC+0000    

Now if we scroll down we see the below process:

.... 0xffff87868f2e1080:winpmem_v3.3.r               3348    784      5      0 2020-06-26 15:51:36 UTC+0000     

I assumed this was the process as we know it was a Windows system from the challenge description. So for the flag, we simply took the PID which was 3348, which we then submitted as the flag in the form specified which was: flag{3348}.

Writeup created by Chris Harris (cjharris).

Flags 1 and 2:

SSHing in and running the command whoami we see we're logged in as luciafer.

Navigating to /home/luciafer/Documents, I ran ls -alt and the output was as follows:

Since luciafer owns both these files, I can simply run cat flag1.txt and cat .flag2.txt to get the flags.

flag 1: flag{cb07e9d6086d50ee11c0d968f1e5c4bf1c89418c} flag 2: flag{728ec98bfaa302b2dfc2f716d3de7869f3eadcbf}

Flags 3 and 4:

After looking around, I found flag3.txt located at /home/spookyboi/Documents/flag3.txt and flag4.txt at /root/flag4.txt. Since luciafer doesn't have sufficient perms to read these files, I ran the command find / -perm -u=s -type f 2>/dev/null to find SUID files.

SUID is a special file permission for executable files, which enables other users to run the file with effective permissions of the file owner. This means we could privilege escalate to root or a higher privileged user, giving us perms to read the flag files.

This was the output:

The program ouija jumped out to me, so i tried running it:

Excellent! it reads files in the /root directory, meaning we simply go

We use the same program to get the flag from flag3.txt as so:

Note: as we start in the /root directory, so must go back one (../) to navigate to flag3.txt.

By das