Dossier Operation High Impact

15 Mei
15 mei 2014

Ik, Ralph Broenink, (eventjes) verbalisant in het kader van de Cyber Crime Challenge 2014 dat is georganiseerd voor de werving voor (o.a.) het Team High Tech Crime van de Nationale Politie, heb observeringen gedaan ten einde voornoemde Challenge tot een goed einde te brengen.

In tegenstelling tot de challenge van vorig jaar, waar er twaalf vragen voor ‘iedereen’ waren, bestond deze Challenge uit drie algemene vragen en daarna de keuze om voor vier vragen in het digitaal of een tactisch spoor te gaan. Ik heb beide sporen doorlopen. Dit proces-verbaal beschrijft mijn bevindingen.

Algemeen

Level 1: Wie is er op de intensive care geweest, of probeerde daar te komen, terwijl diegene daar niets te zoeken had?

Onder verdachte omstandigheden is iemand overleden in het ziekenhuis. Deze man werd opgenomen nadat hij een merkwaardig ongeval ternauwernood heeft overleefd. Uit de autopsie blijkt dat het kaliumgehalte in het bloed van het slachtoffer veel te hoog was. In het kader van het onderzoek zijn daarom de gegevens van alle toegangspassen van het ziekenhuispersoneel en de camerabeelden van het beveiligingsbedrijf opgevraagd.

Ik zag dat het dossier informatie miste over de exacte tijd van overlijden, maar ik zag ook dat de opgevraagde camerabeelden op 3 april 2014 tussen 20:18:02 en 21:15:19 zijn gemaakt. In de toegangspasgegevens zag ik in deze periode twee pogingen van een ongeldige toegangspas om binnen te komen:
Toegangspasgegevens

Ik zag dat camerabeelden rond deze tijd (21:01:00 – 21:01:30) niet zijn opgenomen:
Camerabeeld

Ik acht het dan ook aannemelijk dat Saskia Siwalette (alhans haar toegangspas) rond de tijd van de moord geprobeerd heeft de intensive care te bereiken terwijl die daar niets te zoeken had.

Level 2: Waar was de directiesecretaresse ten tijde van de inbraak?

Saskia Siwalette beweert onschuldig te zijn. Volgens eigen zeggen is ze de laatste tijd vaker slachtoffer van dit soort vreemde gebeurtenissen. Enige tijd geleden is er bijvoorbeeld bij haar inge­broken en zijn haar sieraden gestolen. Gelukkig hadden de inbrekers haar laptop en portemonnee laten liggen. Vlak na de inbraak kreeg ze een afschrift van haar creditcard­betalingen. Daarop stonden meerdere Paybuddy-betalingen die zij niet heeft gedaan. Ook hiervan heeft ze aangifte gedaan. De processen-verbaal bevestigen haar verhaal.

Ik zag in het proces-verbaal van aangifte woningingbraak (nummer #123698741) dat Saskia Alexandra Alida Siwalette, geboren op 12 juni 1964 te Amstelveen, op woensdag 2 april in de namiddag een afspraak had bij Restaurant de IJ-kantine aan de Mt. Ordinaweg 15-17 te Amsterdam.
Proces-verbaal

Level 3: Naar wie leiden de Paybuddy-betalingen?

De directiesecretaresse heeft dus een alibi voor de avond van de inbraak. In het kader van het onderzoek zijn de details van de Paybuddy-betalingen opgevraagd om uit te vinden waarom de inbreker de laptop en de portemonnee heeft achtergelaten.

Ik zag in de opgevraagde gegevens onder andere de volgende transactie:

Transaction Details

Mobile Express Checkout Payment Sent (Unique Transaction ID #7V285F93402944158)

Shopping Cart Contents 
 
Qty	Item			Price			
1	FLEXBOX USB	 	€39,95 EUR

Business Contact Information 
Customer Service Email:	SPYSALES@live.co.uk
Customer Service Phone:	+44 1915555796

Item Total:	€39,95 EUR
Sales Tax:
Shipping:	€5 EUR
Seller discount or charges:	€0,00 EUR

Total amount:	-€44,95 EUR
Fee amount:	€0,00 EUR
Net amount:	-€44,95 EUR
Date:		2 Apr 2014
Time:		12:19:03 PDT
Status:		Completed  

Insurance:	€0,00 EUR

Shipping Address:	

P. NOWAK
Stationsplein 22
2405 BK   
ALPHEN AAN DEN RIJN

Payment To: 	SPYSALES    (The recipient of this payment is Non-U.S. - Verified)
Seller's ID: 	Tak Pimmenberg
Seller's Email:	SPYSALES@live.co.uk

Funding Type:	Credit Card
Funding Source:	€44,95 EUR - Russian Express Credit Card XXXX-XXXXXX-X1002

This credit card transaction will appear on your bill as "PAYBUDDY *TAK PIMMENBERG".


Tracking Number:	
Carrier:	
Order Status:	Shipped (3 APR 2014)

Ik zag dat deze bestelling is bezorgd aan P. Nowak, woonachtig aan het Stationsplein 22 te Alphen aan den Rijn.

Opmerking: vanaf hier kon worden gekozen tussen twee sporen. Ik zal beginnen met de uitleg van het digitale spoor, het tactische spoor staat daaronder.

Digitaal

Level 4: Wat is het mailadres en IP-adres van de opdrachtgever van Pjotr?

Uit politiegegevens blijkt dat het huis bekend staat als woonverblijf van een draaideurcrimineel, ene Pjotr Nowak. Hij is een loopjongen die vaker is opgepakt voor kleinere vergrijpen als diefstal en inbraak. In het kader van het onderzoek is een tap aangevraagd op de thuislijn van dhr. Nowak.

Ik heb de IP-tapgegevens geopend met het programma Wireshark. Met behulp van het venster ‘Protocol Hierarchy Statistics’ zag ik dat de protocollen SMTP en POP voorkwamen:
IP-tap statistics

Ik voerde het filter ‘pop or smtp‘ in en zag een e-mail van Pjotr aan boris@mail.zegzv.be:

Message-ID: <534D1F21.2060704@snel-adsl.nl>
Date: Tue, 15 Apr 2014 13:59:29 +0200
From: Pjotr Nowak <pjotr@snel-adsl.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: boris@mail.zegzv.be
Subject: hee!!
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

nou ben ik het zat, ik heb je die file 2 weken geleden al gemaild, waar 
blijft me geld!!

En de reactie van Boris aan Pjotr:

Return-Path: <boris@mail.zegzv.be>
X-Original-To: pjotr@snel-adsl.nl
Delivered-To: pjotr@snel-adsl.nl
Received: from mail.zegzv.be (monotropa2.zegzv.be [91.199.30.123])
	by mail.snel-adsl.nl (Postfix) with ESMTP id C68B644038
	for <pjotr@snel-adsl.nl>; Tue, 15 Apr 2014 14:26:59 +0200 (CEST)
Received: from mail.zegzv.be (localhost [127.0.0.1])
	by mail.zegzv.be (Postfix) with ESMTP id 546B91022D
	for <pjotr@snel-adsl.nl>; Tue, 15 Apr 2014 14:26:58 +0200 (CEST)
Received: from 195.35.102.33
        (SquirrelMail authenticated user boris)
        by mail.zegzv.be with HTTP;
        Tue, 15 Apr 2014 12:26:58 -0000
Message-ID: <55e5c789e5350e5d1981ebb9a67c3f1a.squirrel@mail.zegzv.be>
In-Reply-To: <534D1F21.2060704@snel-adsl.nl>
References: <534D1F21.2060704@snel-adsl.nl>
Date: Tue, 15 Apr 2014 12:26:58 -0000
Subject: Re: hee!!
From: boris@mail.zegzv.be
To: "Pjotr Nowak" <pjotr@snel-adsl.nl>
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal

gvd ik heb je toch gezegd, mail me niet meer op dit adres

> nou ben ik het zat, ik heb je die file 2 weken geleden al gemaild, waar
> blijft me geld!!
>

Ik zag uit deze conversatie dat Pjotr contact heeft met het e-mailadres boris@mail.zegzv.be. In het antwoord zag ik dat de e-mail via IP-adres 91.199.30.123 is verstuurd.

Level 5: Wat is de naam van het bestand dat Pjotr aan zijn opdrachtgever mailde en welke belangrijke gebruikersnaam en wachtwoord vinden we daarin?

In het kader van het onderzoek is bij de hostingprovider een kopie (harde schijf en geheugen) opgevraagd van de virtuele server waar het mailadres van de opdrachtgever naartoe leidde. Ik probeerde de virtuele machine te openen met behulp van het programma VMWare. Dit lukte echter niet meteen: ik zag dat er om een wachtwoord werd gevraagd om de schijf te ontgrendelen:
Foutmelding lezen VM

Gezien het een Linux-machine betrof, achtte ik het waarschijnlijk dat het om een LUKS-partitie ging. Ik heb daarom het volgende commando op de geheugendump uitgevoerd, in de hoop daarmee het wachtwoord van de partitie te achterhalen:

$ strings mail.zegzv.be.RAWmemory | grep luksOpen
...
echo AglJNaD0DKpLN8pWCJgzzN | cryptsetup --key-file - luksOpen /dev/sdb2 crypted-key

(Met Volatility zou ik de bash history opgevraagd kunnen hebben. Dit zou dezelfde regel opleveren.)

Ik zag in het resultaat een commando dat vermoedelijk nog in het commandogeheugen van de machine stond. Hieruit blijkt dat het wachtwoord van de partitie AglJNaD0DKpLN8pWCJgzzN is. Met behulp van het programma imount heb ik de partitie vervolgens geopend. Ik zag dat dat programma de zesde partitie niet kon openen (wat de LUKS-partitie is) en dat de LUKS-partitie ook een LVM-volume bevatte. Dat leverde uiteindelijk het volgende commando op:

$ imount mail.zegzv.be-flat.vmdk --fstypes=6=luks,6.0=lvm

(Een andere optie zou zijn geweest om de partitie als volgt te openen, maar loopback devices zijn praktischer:)

$ dd if=mail.zegzv.be-flat.vmdk.raw of=partition.dd bs=512 skip=501760
$ sudo cryptsetup luksOpen partition.dd mntpoint

Ik heb vervolgens het volume doorzocht en zag in de map /var/mail/boris de volgende e-mail (met bijlage):

From pjotr@snel-adsl.nl  Fri Apr  4 13:17:21 2014
Return-Path: <pjotr@snel-adsl.nl>
X-Original-To: boris@mail.zegzv.be
Delivered-To: boris@mail.zegzv.be
Received: from mail.snel-adsl.nl (unknown [213.5.232.3])
	by mail.zegzv.be (Postfix) with ESMTP id AA484FDB6
	for <boris@mail.zegzv.be>; Fri,  4 Apr 2014 13:17:21 +0200 (CEST)
Received: from [213.5.232.200] (unknown [213.5.232.200])
	by mail.snel-adsl.nl (Postfix) with ESMTP id 7CC664401D
	for <boris@mail.zegzv.be>; Fri,  4 Apr 2014 13:17:14 +0200 (CEST)
Message-ID: <533E94FB.6000207@snel-adsl.nl>
Date: Fri, 04 Apr 2014 13:18:19 +0200
From: Pjotr Nowak <pjotr@snel-adsl.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: boris@mail.zegzv.be
Subject: Re: bestandje
References: <533E9426.1030309@snel-adsl.nl> <287aaec68fd682892377a401dec57288.squirrel@mail.zegzv.be>
In-Reply-To: <287aaec68fd682892377a401dec57288.squirrel@mail.zegzv.be>
Content-Type: multipart/mixed;
 boundary="------------020001090708010908010102"
X-UID: 4                                     
Status: RO
Content-Length: 1402
X-Status: A

This is a multi-part message in MIME format.
--------------020001090708010908010102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

sorrie haha vergeten, no panic, hier is ie


Pjotr


boris@mail.zegzv.be schreef op 4-4-2014 13:16:
> ik zie geen file... ik heb die file nodig!
>
>> Ha Boris, hier de file zoals afgesproken.
>>
>>
>> Pjotr
>>
>>
>>
>>
>
>


--------------020001090708010908010102
Content-Type: text/plain; charset=windows-1252;
 name="keylogger_recorded_2014-04-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="keylogger_recorded_2014-04-03.txt"

steven_admin[Tab][Shift_L:w]evmwidzikhh[Backspace]bn0[Ent]
goog[Tab][Ent]
[Alt_L:Tab][Ctl_L:c][Alt_L:Tab][Ctl_L:l][Ctl_L:v][Ent]
[Ctl_L:l]www.tweakers.net[Ent]
tweakers.net/form[Backspace]um[Ent]
[Alt_L:Tab][Tab]debian linux installt[Backspace]ation[Ent]
[Ctl_L:c]gmail.com[Ent]
sdepeven[Ent]
[Shift_L:w]evmwidzikhbn0[Ent]
[Ctl_L:c]Hallo Kees,[Ent]
[Ent]
Dank voor je bericht![Backspace]. Ik pak het zo snel mogelijk op.[Ent]
[Ent]
StevenGefeliciteerd![Ent]
[Ent]
Steven[Ent]
Kees[Arrow_D][Ent]
[Tab][Tab]tocle[Backspace][Backspace][Backspace][Backspace]icket afsluiten[Tab]Het is opgelost Kees, kun jij he t[Backspace][Backspace]t ticket afsluiten? Dank, Steven[Ctl_R:Ent]
[Win_L:r]calc[Ent]
5*17[Alt_L:F4][Win_L:l]

Ik zag dat de naam van het gestuurde bestand keylogger_recorded_2014-04-03.txt was. Ik zag dat het een bestand was dat vermoedelijk afkomstig zou zijn van een keylogger. Ik zag dan ook dat de relevante inloggegevens waarschijnlijk steven_admin[Tab][Shift_L:w]evmwidzikhh[Backspace]bn0[Ent] waren. Ik acht het aannemelijk dat de gebruikersnaam steven_admin is en het wachtwoord (rekening houdend met het feit dat [Shift_L:w] een hoofdletter W is en h[Backspace] genegeerd kan worden) Wevmwidzikhbn0.

Level 6: Hoe laat logde Boris in?

We weten nu dat de opdrachtgever, Boris genaamd, de inloggegevens heeft bemachtigd van iemand in het ziekenhuis. In het kader van het onderzoek is de netflow-data opgevraagd van de pc van de gebruiker “steven_admin” in de uren na het mailverkeer tussen Pjotr en Boris.

Met behulp van het programma nfdump heb ik het bestand geanalyseerd. Omdat Boris het IP-adres 91.199.30.123 gebruikte (zie level 4), heb ik de resultaten hier meteen op gefilterd:

$ nfdump -r netflow-62.182.44.17-2014-04-04 "IP 91.199.30.123"
Date flow start          Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
2014-04-04 21:43:10.051    60.021 TCP       62.182.44.17:49996 ->    91.199.30.123:80           6      391     1
2014-04-04 21:43:10.051    60.021 TCP      91.199.30.123:80    ->     62.182.44.17:49996        5     1104     1
2014-04-04 21:44:10.106    60.006 TCP       62.182.44.17:49998 ->    91.199.30.123:80           6      391     1
2014-04-04 21:44:10.106    60.006 TCP      91.199.30.123:80    ->     62.182.44.17:49998        5     1104     1
2014-04-04 21:45:10.105    60.057 TCP       62.182.44.17:49999 ->    91.199.30.123:80           6      372     1
2014-04-04 21:45:10.105    60.057 TCP      91.199.30.123:80    ->     62.182.44.17:49999        6      708     1
2014-04-04 21:45:10.150    60.019 TCP       62.182.44.17:50000 ->    91.199.30.123:80           6      954     1
2014-04-04 21:45:10.150    60.019 TCP      91.199.30.123:80    ->     62.182.44.17:50000        5      546     1
2014-04-04 21:43:09.845    60.211 TCP       62.182.44.17:49995 ->    91.199.30.123:80           6      372     1
2014-04-04 21:43:09.845    60.211 TCP      91.199.30.123:80    ->     62.182.44.17:49995        6     1146     1
2014-04-04 21:46:10.192    60.008 TCP       62.182.44.17:50002 ->    91.199.30.123:80           6      954     1
2014-04-04 21:46:10.192    60.008 TCP      91.199.30.123:80    ->     62.182.44.17:50002        5      546     1
2014-04-04 21:24:10.715  1260.063 TCP       62.182.44.17:3389  ->    91.199.30.123:37240        6      320     1
2014-04-04 21:24:10.715  1260.063 TCP      91.199.30.123:37240 ->     62.182.44.17:3389         7      424     1
2014-04-04 21:44:10.056    60.049 TCP       62.182.44.17:49997 ->    91.199.30.123:80           6      372     1
2014-04-04 21:44:10.056    60.049 TCP      91.199.30.123:80    ->     62.182.44.17:49997        6      708     1
2014-04-04 21:47:10.194    60.051 TCP       62.182.44.17:50003 ->    91.199.30.123:80           6      372     1
2014-04-04 21:47:10.194    60.051 TCP      91.199.30.123:80    ->     62.182.44.17:50003        6      708     1
2014-04-04 21:47:10.236    60.017 TCP       62.182.44.17:50004 ->    91.199.30.123:80           6      954     1
...

Ik zag dat er vaak op poort 80 (HTTP) werd gecommuniceerd, maar één sessie om 21:24 uur op poort 3389 trok mijn aandacht. Deze duurde langer dan alle andere sessies en betrof de standaard TCP-poort van het Windows Remote Desktop Protocol. Vermoedelijk heeft Boris via RDP en de gestolen inloggegevens ingelogd op deze machine.

Level 7: Welk veld in welke databasetabel manipuleerde Boris?

Uit gesprekken met de afdeling systeembeheer bleek dat het systeem niet meer wilde opstarten nadat deze sessie plaats heeft gevonden. In het kader van het onderzoek is de harde schijf van dit systeem in beslag genomen.

Ik zag dat het programma imount niets met deze schijf kon; het programma testdisk detecteerde een NTFS-partitie, maar na verschillende bewerkingen kon ook dit programma de schijf niet leesbaar krijgen. Ik zag met behulp van een hex editor (Bless) dat het grootste gedeelte van de schijf, met name aan het begin, bestond uit nullen. Mij is bekend dat dit zeer ongebruikelijk is voor een schijf en dat er waarschijnlijk mee is gerommeld. De kans is dan ook klein om de schijf weer volledig te herstellen.

Met behulp van het programma photorec heb ik daarop 1017 bestanden uit de schijf gehaald. Deze bestanden konden door photorec worden geëxtraheerd door hun specifieke kenmerken, hoewel hier soms ook wel wat fout gaat. Het kost teveel moeite om elk van deze 1017 bestanden apart te analyseren, dus heb ik gezocht naar kenmerken zoals ‘database’, ‘update’ en ‘patient’, maar dit leverde niets op. Het zoeken naar mail.zegzv.be (wat we eerder hebben gezien) leverde echter wel wat op:

$ grep -r mail.zegzv.be *
Binary file recup_dir.1/f15648072.exe matches
Binary file recup_dir.1/f15675936.dat matches
Binary file recup_dir.1/f15675864.dat matches

Daarop heb ik f15648072.exe geopend met een hex-editor. Ik zag daarin dat blijkbaar een URL werd geopend op http://mail.zegzv.be/getcmd.html en dat het een RAT (Remote Access Tool) leek te betreffen:
Hex RAT

Daarop heb ik een virtuele machine opgestart om het programma uit te voeren. Uit een trace met Wireshark blijkt dat de URL http://mail.zegzv.be/getcmd.html inderdaad wordt opgevraagd op het moment dat het programma start. Omdat deze domeinnaam niet bestaat, werkt dit uiteraard niet. Met behulp van de Windows hosts-file (C:\Windows\System32\drivers\etc\hosts) heb ik er daarom voor gezorgd dat er naar een machine werd verwezen die ik zelf onder mijn beheer had:

192.168.236.129 mail.zegzv.be

Op deze machine draaide ik een simpele webserver:

# python -m SimpleHTTPServer 80

Ik maakte ook een leeg bestand getcmd.html aan. Daarop heb ik het programma opnieuw uitgevoerd. Hoewel de pagina nu succesvol werd opgevraagd, zag ik wederom niet zoveel gebeuren met de RAT. Nadat ik het bestand getcmd.html de inhoud “the cake is a lie” had gegeven gebeurde er wel wat, want het commando ‘<gj‘ werd uitgevoerd:
RAT-invoer 1

De inhoud “abcdefghijklmn” resulteerde erin dat de RAT het commando nmlkjihgfedcba probeerde uit te voeren:
RAT-invoer 2

Ik zag, na enig gespeel, dat de RAT blijkbaar een gegeven commando vrijwel direct uitvoerde op de computer. Hij paste echter ook een soort Caesarrotatie toe op het commando. Doordat ook speciale tekens waren meegenomen, concludeerde ik na enige tijd dat de rotatie slechts de tweede helft van elke byte betreft, waar 0 -> 15 wordt, 1 -> 14, etc. (zie bijvoorbeeld asciitable.com: in de hex-code blijft het eerste karakter hetzelfde en wordt op de tweede ‘gespiegeld’). Het volgende Python-script geeft dit weer:

result = ""
with open("bestand",'r') as f:
    while True:
        byte = f.read(1)
        if not byte:
            break
        if byte == '\n':
            result += '\n'
            continue
        byte = ord(byte)
        result += chr(byte ^ 0x0F)
print result

Ik zag ook dat bij het uitvoeren van het script de uitgevoerde commando’s in een bestand genaamd ‘RAT‘ werden opgeslagen, bij wijze van logboek:

RAT started
+++++++++++++++++++++++++++++++++++++

the cake is a lie
+++++++++++++++++++++++++++++++++++++

abcdefghijklmn
+++++++++++++++++++++++++++++++++++++

Daarop doorzocht ik met de hex-editor de gehele onleesbare schijf naar de tekst ‘+++++++++++++++++++++++++++++++++++++’. Daarop trof ik – aan het einde van het vermoedelijke logbestand – drie relevante logregels aan:
Deel van logbestand

Deze laatste drie commando’s heb ik geconverteerd met behulp van bovenstaand Python-script naar de volgende leesbare tekst:

GET http://medicatiesysteem.intranet/login.php?username=x'%20and%201=0;%20update%20table%20medicatie_db%20set%20dosis=100%20where%20middel=kalium%20and%20patient_bsn=157280898/*&password=bla
GET http://medicatiesysteem.intranet/page.php?id=0'%20union%20all%20select%20patient_bsn,middel,dosis,1,1,null%20from%20medicatie_db/*
dd if=/dev/zero of=\device\harddisk0\partition0 bs=1024

Ik zag dat de RAT is geïnstrueerd om met behulp van een SQL injectie de query update table medicatie_db set dosis=100 where middel=kalium and patient_bsn=157280898 uit te voeren en er dus een wijziging is aangebracht in de tabel medicatie_db en het veld dosis. (Waarna een dd is uitgevoerd om de sporen te wissen).

Opmerking: zie de reactie van Stefan hieronder voor een uitgebreidere analyse van de uitgevoerde commando’s

Tactisch

Level 4: Welk telefoongesprek leidt tot het volgende spoor en ga je nader onderzoeken?

Uit politiegegevens blijkt dat het huis bekend staat als woonverblijf van een draaideurcrimineel, ene Pjotr Nowak. Hij is een loopjongen die vaker is opgepakt voor kleinere vergrijpen als diefstal en inbraak. In het kader van het onderzoek is een telefoontap aangevraagd op de thuislijn van dhr. Nowak.

Ik zag dat de ‘tap’ bestond uit 16 (mp3-)telefoongesprekken van Pjotr met anderen. Ik hoorde dat veel gesprekken gingen over ‘poker’, zoals dit telefoongesprek met ene Daan (+316875418):

Ik hoorde ook een gesprek met ene Boris op telefoonnummer +32484149441 op 21 april 2014 (deze naam was overigens veel beter te verstaan doordat ik eerst digitaal had gedaan):

Level 5: Welk detail valt je op bij het onderzoeken van de verkeersgegevens van het Belgische nummer?

Er zijn meerdere aanwijzingen dat Boris het grote brein is achter het sterfgeval in het ziekenhuis, maar het is nu zaak om meer te weten te komen over Boris. Het Belgische nummer blijkt een prepaid nummer te zijn; in het kader van het onderzoek zijn via een rechtshulpverzoek de historische verkeersgegevens van het nummer opgevraagd.

Ik zag, na veel heen en weer gescroll en gezoek in het bestand met 47 pagina’s, dat het IMEI-nummer op één plek, op 18 maart 2014 om 12:32, afwijkt van de IMEI bij alle andere gesprekken: alleen op dit moment was het 992166820332285:
Telefoonlijst

Level 6: Wie vraag je om meer informatie?

Uit het extra IMEI-nummer blijkt dat Boris een tweede telefoon heeft. Het blijkt dat het toestel is gebruikt met een Nederlands postpaid nummer, maar onderzoek naar de houder loopt dood op een katvanger. Van de provider is een lijst ontvangen van gesprekken die met de telefoon zijn gevoerd.

Ik zag dat het telefoonnummer is gebruikt om een aantal 0900-servicenummers te bellen. Hiertussen zaten bedrijven als Digitenne en Vodafone (wat niet de juiste antwoorden waren). Ik zag echter ook dat is gebeld met het nummer van Marktplaats (waarmee advertenties ‘omhoog’ gebeld kunnen worden):
Telefoonlijst Marktplaats

Level 7: Wat is het adres van Alex? Wat is de relatie tussen Boris en Alex?

De overige rechercheurs hebben bewijzen gevonden waaruit blijkt dat de man in het ziekenhuis inderdaad is vermoord. Het is ook bijna 100% zeker dat Boris daar achter zit. Marktplaats geeft aan dat adverteerder Alexej één van zijn advertenties omhoog heeft laten plaatsen. Het vermoeden bestaat dat er een relatie is tussen Alex en Boris.

In mijn openbronnenonderzoek zag ik op Marktplaats een aantal advertenties van de gebruiker Alex (met gebruikersnaam alexej):
Advertenties Marktplaats

Ik zag vier advertenties, waarvan er één echt uitsprong omdat het een zogenaamde Tonta Fixie-fiets betrof, een merk dat mij in elk geval niet bekend voorkomt. Een zoekopdracht met de afbeelding op Google leverde niets op, maar een Google-zoekopdracht naar ‘alexej fixie’ leverde het Twitter-profiel @alexej7651 op, met onder andere een tweet waarin dezelfde foto werd gebruikt als bij de Marktplaatsadvertentie van Alexej stond. Ik neem dus aan dat dit het juiste Twitter-account is:

Ik zag aan de hand van een andere tweet dat Alexej op Foursquare aan heeft gegeven dat ‘Alexej’s Crib’ op de postcode 8244EZ is. Dit blijkt de Weerribben te Lelystad te zijn:

In een derde bericht plaatste Alexej dat hij ‘113’ een geweldige plaats vindt om te wonen, waardoor ik aannam dat hij op huisnummer 113 woont (en dus woonachtig is op de Weerribben 113 te Lelystad):

Daarnaast zag ik dat Alexej op Twitter aangaf dat hij samen met ene Boris is gaan karten en dat dit een vader-zoon-duel werd:

Ik nam daarom aan dat Alexej en Boris vader en zoon zijn.

Resumé

Recentelijk kreeg het Team High Tech Crime de melding dat er iemand was vermoord in het ziekenhuis. Uit onderzoek is gebleken dat de toegangspas van de directiesecretaresse is gestolen en dat ene Pjotr Nowak met deze inbraak te maken heeft.

Pjotr Nowak lijkt samen te werken met Boris Aleksandr en hem inloggegevens verstrekt te hebben voor een computer in het ziekenhuis. Uit digitaal onderzoek is gebleken dat Boris inderdaad deze inloggegevens heeft gebruikt (op 4 april om 21:24 uur) om de kaliumdosis van het slachtoffer te wijzigen. De relatie tussen Pjotr en Boris wordt versterkt door een telefoongesprek tussen deze twee op 21 april. Uit telefoongegevens blijkt het telefoonnummer van Boris gekoppeld te kunnen worden aan Alexej Aleksandr, wat de vader van Boris lijkt te zijn.

En daarmee is ook deze zaak gesloten:
Einde Operation High Impact

11 reacties
  1. Martijn says:

    Hoi,

    In Level 5 krijg je de VMDisk niet aan de praat maar dit is gewoon mogelijk door het volgende te doen.

    1. Download Oracle VM VirtualBox
    2. Selecteer als OS Ubuntu 64 bit.
    3. Booten maar.

    Alleen had je dan wel de login gegevens nodig gehad voor de gebruiker boris maar die stonden ook in de geheugen dump

    User: boris
    Password: monotropa

    En een grappig detail is dat vorige jaar missmonotropa in de challange aanwezig was 😉

    Uiteindelijk in Ubuntu heb ik de mail bestanden doorzocht met vim om zo de mail te achterhalen.

    Verder mooie beschrijving maar wilde dit nog even toevoegen. Nu afwachten of ik nog in de prijzen ben gevallen 😉

    Reageer
  2. Stefan says:

    Je hebt een gedeelte gemist van digitaal lvl7.
    Er zijn meer relevante regels te vinden in het log. Daarmee wordt ook duidelijk wat er gebeurt en zie je dat jouw aanname: “…en er dus een wijziging is aangebracht in de tabel medicatie_db en het veld dosisdd zichzelf ging verwijderen” niet klopt.

    GET http://medicatiesysteem.intranet/page.php?id=0'%20union%20all%20select%20patient_bsn,middel,dosis,1,1,null%20from%20medicatie_db/*
    GET http://medicatiesysteem.intranet/login.php?username=x'%20and%201=0;%20update%20table%20medicatie_db%20set%20dosis=10000%20where%20middel=kalium%20and%20patient_bsn=157280898/*&password=bla
    GET http://medicatiesysteem.intranet/page.php?id=0'%20union%20all%20select%20patient_bsn,middel,dosis,1,1,null%20from%20medicatie_db/*
    GET http://medicatiesysteem.intranet/login.php?username=x'%20and%201=0;%20update%20table%20medicatie_db%20set%20dosis=100%20where%20middel=kalium%20and%20patient_bsn=157280898/*&password=bla
    GET http://medicatiesysteem.intranet/page.php?id=0'%20union%20all%20select%20patient_bsn,middel,dosis,1,1,null%20from%20medicatie_db/*

    -Eerst wordt de dosis gezet op 10000.
    -Daarna wordt de dosis weer op 100 gezet (waarschijnlijk om de sporen te wissen)

    Reageer
    • Ralph Broenink says:

      Op zich klopt mijn aanname wel, maar er is inderdaad meer interessants dat ik had gemist. Zie wel dat er een stukje tekst was verdwenen, maar dat is nu gefixt. Toch bedankt voor je inzicht!

      Reageer
  3. Stefan says:

    Merkwaardig dat de fiets te zien is bij MP. Toen ik speel kwam de fiets er helemaal niet in voor. Ik heb dus flink zitten te zoeken. Uiteindelijk bracht andere zoekmachine dan Google (Duckduckgo) mij op de weg met resultaat Alexej Crib Lelystad …

    Reageer
  4. Bas says:

    Toen ik de challenge deed was er ook een Marktplaats-advertentie van Alexej met een koelkast. De ‘echte’ advertentie van die koelkast trof ik aan op een andere advertentiesite. Dat was best wel een dwaalspoor 🙂 Dat jij maar vier advertenties te zien kreeg geeft denk ik aan dat ze de misleidende advertentie toch maar verwijderd hebben.

    Reageer
  5. Coen Schalkwijk says:

    Hi Ralph, bedankt voor de NFO. Ik liep zelf stuk op level 7. Ik heb er wel nog een vraagje over; het gaat om een windows executable, had ik deze ook in WINE kunnen uitvoeren? Heb nl. geen enkele windows omgeving tot mijn beschikking. Al helemaal geen om een willekeurige RAT op uit te voeren 😉

    Reageer
    • Ralph Broenink says:

      Dat heb ik niet geprobeerd, maar ik denk dat het zou moeten werken. Ik heb ook write-ups gezien die zonder het uitvoeren van de executable de oplossing hebben bereikt en direct de RAT-log uit de image hebben gehaald en via een xortool hebben ontcijferd.

      Reageer

Laat een reactie achter

Wil je meedoen met de discussie? Je bent vrij om een reactie achter te laten!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *