[CFP] Digital Investigation: Special Issue on Volatile Memory Analysis
- Malware detection in memory
- Live memory analysis
- Live system introspection
- Memory acquisition
- Memory analysis of large systems
- Userspace and application specific memory analysis
- Cryptographic analysis, key recovery
- Execution history analysis
- Data fusion between memory/disk/network
<div>
</div>
[CFP] CLOUDFOR extended submission deadline
CLOUDFOR 2016: Workshop on Cloud Forensics
In conjunction with the 9th IEEE/ACM International Conference on Utility and Cloud Computing (UCC), Tongji University, Shanghai, China.
6-9 December 2016
Scope and Purpose
=================
As a consequence of the sharp growth in the Cloud Computing market share, we can expect an increasing trend in illegal activities involving clouds, and the reliance on data stored in the clouds for legal proceedings. This reality poses many challenges related to digital forensic investigations, incident response and eDiscovery, calling for a rethink in traditional practices, methods and tools which have to be adapted to this new context.
This workshop aims to bring researchers and practitioners together as a multi-disciplinary forum for discussion and dissemination of ideas towards advancing the field of Cloud Forensics.
Topics of interest comprise, but are not limited to:
* Digital evidence search and seizure in the cloud
* Forensics soundness and the cloud
* Cybercrime investigation in the cloud
* Incident handling in the cloud
* eDiscovery in the cloud
* Investigative methodologies for the cloud
* Forensics readiness in the cloud
* Challenges of cloud forensics
* Legal aspect of cloud investigations
* Tools and practices in cloud forensics
* Case studies related to cloud forensics
* Forensics-as-a-Service
* Criminal profiling and reconstruction in the cloud
* Data provenance in the cloud
* Law enforcement and the cloud
* Big data implications of cloud forensics
* Economics of cloud forensics
* Current and future trends in cloud forensics
* Grid forensics
Important dates
===============
* Paper submission: 15 August 2016 (extended deadline)
* Notification of acceptance: 05 September 2016
* Camera-ready submission: 21 September 2016
Workshop chairs
===============
Virginia N. L. Franqueira
University of Derby, UK
v.franqueira[at]derby.ac.uk
Kim-Kwang Raymond Choo
University of South Australia, AU
Tim Storer
University of Glasgow, UK
Andrew Jones
University of Hertfordshire, UK
Raul H. C. Lopes
Brunel University (GriPP & CMS/CERN), UK
Program Committee
=================
George Grispos, The Irish Software Research Centre (LERO), IE
Andrew Marrington, Zayed University, AE
Kiran-Kumar Muniswamy-Reddy, Amazon Web Services, US
Joshua I. James, Hallym University, KR
Geetha Geethakumari, BITS Pilani, IN
Shams Zawoad, Visa Inc., US
Olga Angelopoulou, University of Hertfordshire, UK
Vrizlynn Thing, Institute for Infocomm Research, SG
Theodoros Spyridopoulos, University of the West of England, UK
Vassil Roussev, University of New Orleans, US
Yijun Yu, Open University, UK
Ibrahim Baggili, University of New Haven, US
Martin Schmiedecker, SBA Research, AT
Ben Martini, University of South Australia, AU
Hein S. Venter, University of Pretoria, ZA
Ruy de Queiroz, Federal University of Pernambuco, BR
Martin Herman, National Institute of Standards and Technology, US
Mark Scanlon, University College Dublin, IE
Submission
==========
Authors are invited to submit original, unpublished work which will be reviewed by three committee members. Submission should be blind, i.e., with no stated authors, or self-references. Papers should comply with the IEEE format, and have a maximum of 6 pages; guidelines are available at: http://www.ieee.org/conferences_events/conferences/publishing/templates.html
All accepted papers will be published in the IEEE conference proceedings – provided they are presented at the workshop.
Submission will be handled through EasyChair: https://easychair.org/conferences/?conf=cloudfor2016
Facebook Capture the Flag Platform Now Available
Facebook’s hacking education platform and capture the flag is now available. See their release single here. Their goal is to educate about different types of web attacks by giving access to CTF infrastructure and letting more groups run hacking competitions. From their github repository:
<div class="separator" style="clear: both; text-align: center;">
</div>
<ul><li>Organize a competition. This can be with as few as two participants, all the way up to several hundred. The participants can be physically present, active online, or a combination of the two.</li><li>Follow setup instructions below to spin up platform infrastructure.</li><li>Enter challenges into admin page</li><li>Have participants register as teams</li><ul><li>If running a closed competition:</li><ul><li>In the admin page, generate and export tokens to be shared with approved teams, then point participants towards the registration page</li></ul><li>If running an open competition:</li><ul><li>Point participants towards the registration page</li></ul></ul><li>Enjoy!</li></ul><div>I’m playing with it now, but it looks like it will be an amazing resource for students.</div>
[How-to] Load a multi-part disk image into FTK Imager
When working with multi-part disk images, it can be confusing to see if your tool has loaded all of the image or just a part. Below is one way to determine if all of your disk image has been loaded, or only the first part in FTK Imager.
<div class="separator" style="clear: both; text-align: center;"><div class='embed-container'><iframe src='https://www.youtube.com/embed//bW7BBcbl_Vc' frameborder='0' allowfullscreen></iframe></div></div>
<h3>Verifying your disk image</h3>When working with your disk image, verification of the data should always be included in your workflow. In the case of a multi-part image, we should have at least two hashes:
<ul><li>A hash for the total disk image</li><li>A hash for each part of the disk image</li></ul><div>This is especially true for raw disk images, since they have no built-in checksum like expert witness format.</div><div>
</div><div>A hash for the total disk image is normally created by your acquisition tool, and can be found in the acquisition report. FTK Imager does not create a hash for each part of a multi-part image.</div><div>
</div><div>In this case, we may need to generate our own hashes using FTK, or another tool.</div><h4>Why do I need hashes for each part?</h4><div>If you have a hash value for the overall disk image, then - in terms of court - you will be able to show that the suspect data has not changed from the time that the disk was first acquired. However, having hashes of each part of the image can help in one major way.</div><div>
</div><div>The Expert Witness Format that EnCase uses has checksums every 32KB that enables verification of parts of a disk image. If one part of a disk image changes, we can potentially still use the other parts of the image that can be verified with their checksum, even if the overall hash can not be verified.</div><div>
</div><div>With a multi-part RAW image, we can get similar functionality by hashing each part. Each part can then be verified, along with the overall hash. If the overall hash is not valid, hashes of each part can be used to determine what part has changed. Other parts that can be verified may still be used.</div><h3>Loading a multi-part image</h3><div>When many tools load a multi-part image, they may only show the filename of the first part of the image. If the tool is made ‘for forensics’, then the tool will likely load the entire image under the first filename. In this case, verify that the tool can:</div><div><ol><li>Detect the full size of the original disk image</li><li>Can generate the correct hash value for the original image</li></ol></div>
[CFP] Security of Individual, State and Society: Challenges and Perspectives
Honeypot Fun
At the Legal Informatics and Forensic Science Institute, we are preparing to do some research on IoT smart homes. Part of that is setting up a slightly-less-secure system. I run some honeypots on my home networks, but I was interested to see what is coming in to the known University IP range.
<div>
</div><div class="separator" style="clear: both; text-align: center;">
</div><div>I had an extra Raspberry Pi laying around, and decided to run cowrie (kippo) SSH honeypot. Mostly because it is very fast to set up, gives you an idea of where attacks are coming from, and also gives a list of usernames and passwords that people are trying. More on the setup of cowrie later.</div><div>
</div><div>After putting cowrie online, it took 28 minutes before the first connection. This is actually longer than I expected. Possibly because the IP was up before, but port 22 was not open.</div><div>
</div><div>After 12 hours, login attempts from the following addresses:</div><div>
</div><div><table> <thead><tr> <th class="tg-yw4l">Login Attempts</th> <th class="tg-yw4l">IP Address</th> <th class="tg-yw4l">Country</th> </tr></thead> <tbody><tr> <td class="tg-yw4l">1</td> <td class="tg-yw4l">146.66.163.107</td><td class="tg-yw4l">Russia</td> </tr><tr> <td class="tg-yw4l">3</td> <td class="tg-yw4l">185.103.252.14</td><td class="tg-yw4l">Russia</td> </tr><tr> <td class="tg-yw4l">9</td> <td class="tg-yw4l">195.154.58.76</td><td class="tg-yw4l">France</td> </tr><tr> <td class="tg-yw4l">18</td> <td class="tg-yw4l">159.122.123.183</td><td class="tg-yw4l">Germany</td> </tr><tr> <td class="tg-yw4l">40</td> <td class="tg-yw4l">117.102.109.18</td><td class="tg-yw4l">Indonesia</td> </tr><tr> <td class="tg-yw4l">41</td> <td class="tg-yw4l">193.201.227.200</td><td class="tg-yw4l">Ukraine</td> </tr><tr> <td class="tg-yw4l">91</td> <td class="tg-yw4l">94.79.5.102</td><td class="tg-yw4l">Russia</td> </tr><tr> <td class="tg-yw4l">126</td> <td class="tg-yw4l">193.201.227.86</td><td class="tg-yw4l">Ukraine</td> </tr><tr> <td class="tg-yw4l">336</td> <td class="tg-yw4l">202.83.25.95</td> <td class="tg-yw4l">India</td> </tr></tbody></table>
Remember that the country doesn’t actually mean anything. These could be proxies, tor, hacked servers, etc.
The top usernames and passwords are not very surprising.
<table class="tg"><tbody><tr> <th class="tg-yw4l">Tries</th> <th class="tg-yw4l">Username / Password</th> </tr><tr> <td class="tg-yw4l">21</td> <td class="tg-yw4l">[root/123456]</td> </tr><tr> <td class="tg-yw4l">19</td> <td class="tg-yw4l">[root/default]</td> </tr><tr> <td class="tg-yw4l">18</td> <td class="tg-yw4l">[admin/support]</td> </tr><tr> <td class="tg-yw4l">18</td> <td class="tg-yw4l">[admin/default]</td> </tr><tr> <td class="tg-yw4l">18</td> <td class="tg-yw4l">[admin/123123]</td> </tr><tr> <td class="tg-yw4l">8</td> <td class="tg-yw4l">[root/admin]</td> </tr><tr> <td class="tg-yw4l">6</td> <td class="tg-yw4l">[admin/admin]</td> </tr><tr> <td class="tg-yw4l">5</td> <td class="tg-yw4l">[test/test]</td> </tr><tr> <td class="tg-yw4l">5</td> <td class="tg-yw4l">[support/support]</td> </tr><tr> <td class="tg-yw4l">5</td> <td class="tg-yw4l">[root/qwerty]</td> </tr></tbody></table></div>
Probably the most interesting thing is that the first attack was that the first attack was trying some sort of buffer-overflow. Although they were connecting to SSH and sending (weird) user/pass combinations, after the connection was rejected they were sending really long strings. I suspect it is some sort of honeypot detection, or it exploits certain versions of SSH? Not sure.
Anyway, for a 1 hour project it is easy and interesting. Definitely something that students could do in an afternoon.