Initially identified fifteen years ago, and clearly articulated by a Microsoft Security Advisory, DLL hijacking is the practice of having a vulnerable application load a malicious library (allowing for the execution of arbitrary code), rather than the legitimate library by placing it at a preferential location as dictated by the Dynamic-Link Library Search Order which is a pre-defined standard on how Microsoft Windows searches for a DLL when the path has not been specified by the developer.
Despite published advice on secure development practices to mitigate this threat, being available for several years, this still remains a problem
Scammers, intruders and other miscreants often aim to conceal their actions from forensic investigators. When analyzing an IT support scam, I interacted with the person posing as the help desk technician. He brought up a web page on the victim's system to present payment form, so the person would supply contact and credit card details. He did this in a surprising manner, designed to conceal the destination URL.
Hardly a day goes by without me hearing the phrase 'Threat Intelligence' being used in the context of big budget enterprise protection, but recently I have been giving some thought to what this means to the home user and small business.
Most computers have (or at least, should have!) up-to-date antivirus software installed which provides a certain degree of protection and gives insight on whether a particular file, or set or circumstances, are suspicious according to vendor X (using signatures, reputation lookup and several other methods), but I'm sure there is more that the open source cyber security community can do to protect itself by leveraging fantastic free resources, such as the VirusTotal Public API.
check_first.exe, a proof of concept
To this end, I've just finished writing a proof-of-concept tool to demonstrate how public threat intelligence APIs can be leveraged to ...
I can honestly say that the most common question I am asked by examiners, investigators, students and even my neighbors is, "which phone is the most secure?" Obviously, the concern behind the question varies. Some want to secure their own device, and others, like myself, want to prove everyone in DFIR wrong by cracking into the toughest and most secure devices.
Smartphone security has gotten drastically stronger in 2014. This year, we are expecting even more challenges when examining smartphones. When thinking about the forensic aspects of smartphone security and encryption, we have to consider two things:
- How are we going to get access to the data?
- Even if we get a dump of the device, can we decrypt and examine the data?
- What happens if I can access the data, but the application data is encrypted?
Let's look at a few devices to consider our options. First, Windows Phone 8 (WP8) brought us new issues that ...
2015-03-04 UPDATE: I've added some thought process/methodology to the answers inline below.
Thanks to everyone that submitted or just played along with the SANS DFIR Network Forensic Challenge! We had over 3,000 evidencedownloads, and more than 500 submissions! Per the rules, the winner must have answered four of the six questions correctly. Then, by random selectionamong those submissions, the winner was selected.
We're excited to announce thatHenry van Jaarsveld is the winner for this challenge! Congratulations, and we hope you enjoy your SANS OnDemand Course. Great work, Henry!
Thanks for all the submissions and interest in this challenge. If you enjoyed the questions- no matter how many questions you answered - you should check out FOR572: Advanced Network Forensics and Analysis. The class is available via OnDemand, as well as the following live and virtual SANS events: