Description

I acquired some information about my PC because I think someone messed up with it…

You can find everything attached.

Please find out what’s wrong about these captures.

Have fun!

Resolution

We were given a zip file containing 2 files:

Archive:  taking-a-look-inside.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
1073278016  2018-04-02 12:17   taking-a-look-inside.dmp
   7662116  2018-04-02 12:18   taking-a-look-inside.pcap
---------                     -------
1080940132                     2 files

We began with the pcap as it’s probably the easiest part.
It’s an exchange between 2 hosts: 192.168.56.101 & 192.168.56.1 (VirtualBox Host-Only Network ;))
192.168.56.101 is sending data to 192.168.56.1 like this:

• data [len: 4] (length of the data to retrieve?)
• data (first part): SCN|…
• data …
• data (last part): …|NCS
• etc.

We managed to retrieve all the data using tshark:

$ tshark -r taking-a-look-inside.pcap -T fields -e data -Y 'ip.src == 192.168.56.101 && !(data.len == 4)' > taking-a-look-inside.out
$ xxd -r -p taking-a-look-inside.out > taking-a-look-inside.b64
$ cat taking-a-look-inside.b64| sed -e 's/|NCSSCN|/|NCS\nSCN|/g' > taking-a-look-inside.txt

Apart lines containing “SCN|…|NCS” there was nothing interesting here, we jumped to the dump.

$ strings taking-a-look-inside.dmp| grep 'Linux version' | uniq
...
Linux version 4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

Searching for GCC 6.3.0-18+deb9u1 & Kernel 4.9.82-1+deb9u3 we got:
https://packages.debian.org/stretch/gcc-6
https://packages.debian.org/stretch/linux-image-4.9.0-6-amd64
Both packages are available in Debian Stretch, which is a fresh Debian 9.4.

We generated the Volatility profile using:

$ cd volatility/tools/linux/
$ make
$ zip Debian_9.4_4.9.0-6-amd64.zip module.dwarf /boot/System.map-4.9.0-6-amd64
$ mkdir volatility/plugins/profiles
$ mv volatility/tools/linux/Debian_9.4_4.9.0-6-amd64.zip volatility/plugins/profiles/

Then we checked the processes:

$ ./vol.py  -f taking-a-look-inside.dmp --profile=LinuxDebian_9_4_4_9_0-6-amd64x64 linux_pstree              
Volatility Foundation Volatility Framework 2.6
Name                 Pid             Uid            
[...]
..gnome-terminal-    1162            1000           
...zsh               1168            1000           
....su               1355            1000           
.....zsh             1356                           
......python3        2530                           
......python3        4524                           
.......[python3]     4645                           
...zsh               1226            1000           
....gimp             2079            1000           
.....script-fu       2270            1000           
...zsh               2283            1000           
....su               2321            1000           
.....zsh             2322                           
......insmod         4638                           
...zsh               3301            1000           
....su               4168            1000           
.....zsh             4169                           
......tshark         4505                           
.......dumpcap       4523
[...]

We exported the files list with linux_enumerate_files and retrieved the zsh history using :
$ ./vol.py -f taking-a-look-inside.dmp –profile=LinuxDebian_9_4_4_9_0-6-amd64x64 linux_find_file -i 0xffff97e9c78883e8 -O history

What we found was quite identical to these commands:

./vol.py  -f ../taking-a-look-inside.dmp --profile=LinuxDebian_9_4_4_9_0-6-amd64x64 linux_psaux
Pid    Uid    Gid    Arguments
[...]
2079   1000   1000   gimp                                                            
2270   1000   1000   /usr/lib/gimp/2.0/plug-ins/script-fu -gimp 14 13 -run 0
2530   0      0      python3 ./goggles
4505   0      0      tshark -i enp0s8 -w taking-a-look-inside.pcap                   
4523   0      0      /usr/bin/dumpcap -n -i enp0s8 -Z none -w taking-a-look-inside.pcap
4524   0      0      python3 ./goggles --host=192.168.56.1                           
4638   0      0      insmod lime-4.9.0-6-amd64.ko format=lime path=/media/sf_vms-share/taking-a-look-inside.dmp
[...]

The goggles python script was the one generating traffic and dumped to the pcap file…but we haven’t managed to retrieve it with linux_find_file.

We looked for the string “–host” in the dump and using the filter “sed ‘s,\x1B\[[0-9;]*[a-zA-Z],,g'” we found:

from screenshot import grab # PIL + imagemagick needed
from Crypto.Cipher import AES
# =============================================================================
#  CONFIGURATION
# =============================================================================
AES_KEY = 'd3Adb3Efc4Feb4Be'
# =============================================================================
#  FUNCTIONS
# =============================================================================
def interrupt_hdlr(*args):
    exit(1)
def encrypt(data):
    cipher = AES.new(AES_KEY, AES.MODE_ECB)
    pad_sz = 16 - len(data) % 16
    pad_chr = hex(pad_sz)[2]
    pad = pad_sz * pad_chr.encode()
    return cipher.encrypt(data + pad)
def parse_args():
    p = ...

Our main idea was: data is the base64 thing between SCN|…|NCS and it’s screenshots.
We created a python script to parse our taking-a-look-inside.txt file and decode the AES part:

from Crypto.Cipher import AES
key = 'd3Adb3Efc4Feb4Be'
i = 0
with open('taking-a-look-inside.txt') as f:
  for line in f:
    line = line.replace('SCN|', '').replace('|NCS','')
    cipher = line.decode('base64')
    aes = AES.new(key, AES.MODE_ECB)
    content = aes.decrypt(cipher)
    file = open('img_'+str(i)+'.png','w')
    file.write(content)
    file.close()
    i = i + 1

It gave 36 images:

Some of these are showing parts of flags. 🙂

Flag was : INSA{aa80467558a76019b99ecec7b4f6d0c7}