Use CryptoLocker to train your incident response team (part 3)

Train your incident response team

This is the third part in a post describing how to train your team for incident response and incident investigations.

The first part for training incident response and incident investigations covered how to analyze the e-mail headers and information in a suspicious e-mail. The second part analyzed the attachment which turned out to be a CryptoLocker.F variant.

Networked VM

The last step of my analysis involved executing the CryptoLocker virus in a fully networked VM. After resetting the Windows XP virtual machine I enabled networking and started capturing the network packets.

It took a couple of minutes before I started to notice unusual behavior but then this showed up in the virtual machine


The notice is in Dutch, basically saying that your files are now locked and you have 96 hours to do a payment. This means the machine is now fully infected.

I do not know why the notice was in Dutch. Maybe because the analysis was done from an IP that is geo-located in Belgium (Flanders) or because of the fact that the malware was maybe specifically aimed at Dutch speaking users?

Network capture

The network traffic was captured in a pcap file. This allows me to have a detailed look at the connections without having the need of keeping the machine running. In the capture below, is the infected Windows machine and is the default route for that machine.

The first thing I noticed in the capture was a DNS query for the domain with a DNS response of (both located in the US). Immediately after the DNS request, there was a request to on tcp/443 (https). During the https conversation there was a request for the PTR record of ( I’m not sure if the request for the PTR record was caused by the malware or because of normal operation of the Windows host.

19:21:10.265447 IP > 23427+ A? (37)
19:21:11.031868 IP > 23427 1/13/0 A (264)
19:21:11.033897 IP > Flags [S], seq 3369729607, win 64240, options [mss 1460,nop,nop,sackOK], length 0
19:21:11.192678 IP > Flags [S.], seq 1816156004, ack 3369729608, win 64240, options [mss 1460], length 0
19:21:11.542592 IP > Flags [P.], seq 919:970, ack 261, win 64240, length 51
19:21:11.583938 IP > 13061+ PTR? (45)
19:21:11.643981 IP > Flags [P.], seq 919:970, ack 261, win 64240, length 51
19:21:11.925041 IP > 13061 1/6/0 PTR (211)

Downloading the certificate information revealed this might be a Synology device.

openssl s_client -connect

subject=/C=TW/ST=Taiwan/L=Taipei/O=Synology Inc./OU=FTP Team/
issuer=/C=TW/ST=Taiwan/L=Taipei/O=Synology Inc./OU=Certificate Authority/CN=Synology Inc. CA/

There have been reports of SynoLocker Ransomware Affecting Synology DiskStation. I could not confirm if this was the case for this host but it does not seem to be unlikely. Also remember that in the previous part I noticed that the website of (hosted at was in an abandoned or at least in a “not finished” state. This makes it more likely to be a target.

19:21:12.468442 IP > Flags [P.], seq 970:1558, ack 442, win 64240, length 588
19:21:12.470807 IP > Flags [FP.], seq 1558:1624, ack 442, win 64240, length 66
19:21:12.471526 IP > Flags [.], ack 1625, win 64240, length 0
19:21:12.472408 IP > Flags [R.], seq 442, ack 1625, win 0, length 0

Subsequent similar network behavior

The network communication with consisted of

  • Doing a DNS query for the domain
  • Receiving the DNS reply
  • Starting a connection on tcp/443 (https) to the IP
  • Requesting the PTR record for the IP

Having a look at the other three listed domains revealed the same network pattern.

19:21:17.479276 IP > 24966+ A? (28)
19:21:17.517892 IP > 24966 1/13/0 A (255)
19:21:17.519091 IP > Flags [S], seq 3421975270, win 64240, options [mss 1460,nop,nop,sackOK], length 0
19:21:17.545014 IP > Flags [S.], seq 3198389694, ack 3421975271, win 64240, options [mss 1460], length 0
19:21:17.615556 IP > 56835+ PTR? (44)

The certification information was as follows

subject=/OU=Domain Control Validated/OU=PositiveSSL/
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2

19:21:22.649647 IP > 15239+ A? (28)
19:21:22.803797 IP > 15239 1/13/0 A (255)
19:21:22.804598 IP > Flags [S], seq 3319478930, win 64240, options [mss 1460,nop,nop,sackOK], length 0
19:21:22.858941 IP > Flags [S.], seq 1829101853, ack 3319478931, win 64240, options [mss 1460], length 0
19:21:23.560461 IP > 37378+ PTR? (44)
19:21:23.622886 IP > 37378 1/6/0 PTR (186)

The -expired- certificate had this information

subject=/C=ES/ST=Catalunya/L=Barcelona/O=Tirabol Produccions
issuer=/C=ES/ST=Catalunya/L=Barcelona/O=Tirabol Produccions

19:21:28.061769 IP > 57220+ A? (31)
19:21:28.090268 IP > 57220 1/13/0 A (258)
19:21:28.090787 IP > Flags [S], seq 1209465814, win 64240, options [mss 1460,nop,nop,sackOK], length 0
19:21:28.160456 IP > Flags [S.], seq 4167533275, ack 1209465815, win 64240, options [mss 1460], length 0
19:21:28.299664 IP > 53762+ PTR? (44)

The certificate had this information

subject=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/
issuer=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/

The requests for the PTR requests of the IPs belonging to the command and control domains resulted in an extra set of domains to watch :,, and

( domain name pointer 
( domain name pointer
( domain name pointer
( domain name pointer 

Details of the network capture

I used tshark to get statistics on the TCP conversation. Note that in the output below I omited the traffic that had to do with normal Windows network behavior.

tshark -r xp.pcap -q -z conv,tcp
TCP Conversations
Filter:<No Filter>
                                               |       <-      | |       ->      | |     Total     |    Relative    |   Duration   |
                                               | Frames  Bytes | | Frames  Bytes | | Frames  Bytes |      Start     |              | <->        533    796640     107      6331     640    802971   424.351847000         1.2458 <->         10      4705       8       978      18      5683   413.780151000         0.1197 <->         9      2164       8       881      17      3045   407.294957000         1.4385 <->          8      1602       7       805      15      2407   419.065658000         0.2508

This output of tshark proofs that the communication consisted of

  1. the first 9 frames with
  2. then 10 frames with
  3. then 8 frames with
  4. and finally 533 frames with

In total there was a download of approx. 800 KBytes from the Spanish host That’s more than enough room for a decent payload!

I could not see network traffic to other hosts.

What was downloaded?

Because the traffic was https it is not immediately obvious to see what was downloaded.

One way you can solve this is by setting up an HTTPS-proxy and basically performing a MiTM attack (with a fake certificate for the four command and control sites). I did not do this but used Google search to verify if I could find references for ‘https’ and any of the four sites.

Based on the information at for and for there were requests found for, and So nero.tar.gz and hello.tar.gz is something to keep an eye on. Be warned, “nero” is also an app for KDE. It’s not a very popular package so blocking it will not cause that many issues but it’s something to take into account when reviewing alerts.


The initial goal was to describe a thought process for extracting IOCs for an ongoing incident. This was relatively easy by analysing the e-mail source, using basic Linux commands and having the malware run in a non-networked virtual machine and capture the outgoing network activity. Additional behavior analysis was afterwards done with running the malware in a networked virtual machine.

Uploading the file to Virustotal for further analysis is a quick way for getting extra information but sometimes this is not possible or advisable. By uploading the file you are basically giving away to the “bad guys” that you are doing an investigation, for some malware samples this is not the right thing to do.


The message was received early February (4-February 2015). On the date of the analysis (about 20 days later) it was still possible to activate the ransomware via one of the hardcoded command and control domains.

Leave a Reply

Your email address will not be published. Required fields are marked *