By now youve probably heard about Docker, the application containerization tool. Lenny Zeltser has talked about using it for malware analysis, for example, and also looked at the security implications. Last week, however, I ran across my first incident where the system I needed to examine was running Docker. I hadnt used Docker, myself, so I didnt know what difficulties this might introduce into my investigation. I threw a quick note out on the SANS DFIR list to see if anyone else had had to deal with Docker during a forensic investigation and got a couple of responses, but not a lot of usable info, so after a phone call with Derek Armstrong, who was one of the folks who responded to the e-mail, I set out to figure out how Docker was going to complicate my life. What follows is what Ive learned in the last week. I know there is much more that can be done here and hopefully before this is all said and done, Ill write a few scripts that might be helpful in future investigations (hence, titling the post Part 1). So, when I began this investigation, I had a memory image and a disk image. I did not have access to the live system.
Memory Forensics
On first look at the memory image, my fear was that Docker was actually virtualization rather than containerization and that the process details were somewhere inside the process memory of the docker process. When I ran volatility and saw that the docker process didnt have any child processes, I was even more concerned. It turns out, I was worrying needlessly, however. It turns out that on this particular image, there werent any docker containers running at the time the memory image was taken. " />
Unfortunately, the linux_pstree volatility plugin doesnt show those processes as being offspring of the docker process (note this is still using Volatility 2.4 I encountered problems with my Linux profiles for 2.5 and havent had time to figure out how to fix them yet).
$ vol.py --plugins ~investigator/.zrk_cache -f XUbuntu\ 64-bit-Snapshot3\ -\ Copy.vmem --profile=Linux3_13_0_79_generic__123_Ubuntu_SMP_Fri_Feb_19_14_27_58_UTC_2016_x86_64x64 linux_pstree
Volatility Foundation Volatility Framework 2.4
Name Pid Uid
init 1 0
.upstart-udev-br 589 0
.systemd-udevd 593 0
.upstart-socket- 745 0
.dbus-daemon 924 102
.ModemManager 976 0
.systemd-logind 992 0
...snip...?
.docker 51914 0
...snip...
bash 52102 0
.top 52144 0
Even though ps clearly shows the PPID of that bash is PID 51914. However, it is possible to find all the descendants of the docker process using the linux_psenv plugin and grep-ing for the HOSTNAME environment variable. " />
You can also see that there is a docker layered filesystem mounted, but you can" />
Note that mount of /var/lib/docker/aufs/aufs, that wont be present if thre isnt a docker image running and the line for / will be different (showing the /dev/disk/... and ext4 instead of none and aufs). Also, if you do have access to the live system, it is interesting to note that df -h run as an unprivileged user won" />
The last snippet I want to look at is the output from the volatility linux_lsof plugin. This one shows some useful places we" />
That json log looks like something that could be very interesting. Well pick this up there in our next installment.
In the meantime, Im still just getting started trying to figure out how to deal with Docker artifacts, so if you have thoughts or suggestions, Id love to hear them. Feel free to comment here, or use our feedback form, or e-mail me (the address is below). Thanx.
References
https://www.docker.com/
https://zeltser.com/security-risks-and-benefits-of-docker-application/
https://zeltser.com/docker-application-distribution/
https://digital-forensics.sans.org/blog/2014/12/10/running-malware-analysis-apps-as-docker-containers
---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu