Open Memory Forensics Workshop
This is the first time this workshop has been put on, but I have to say that it was a rousing success right off the starting blocks! An excellent format, excellent schedule, and excellent speakers. More importantly for me, there was a great deal of information and discussion that was either immediately practical, or would lead to something practical and useful in a hands-on manner within a relative short period.
A couple of the big-brain take-away thoughts that came out of this 1/2 day workshop were:
There seemed to be agreement amongst the assembled panel (as well as the attendees) that open-source is the way to go with tools like memory parsing tools. Open-source allows for verification of your findings and how various items were found, transparency, as well as extensibility.
When performing memory acquisition and analysis (parsing, really), what are the essential or pertinent objects/items/elements? What parts of, say, an EPROCESS structure are absolutely essential for determining if you're looking at an actual EPROCESS structure?
The subject of anti-forensics came up as well, and a thought was that if the bad guys know about what the good guys are doing, and know what important elements have been identified simply by looking at the open-source code, then they can easily come up with ways to combat those tools and techniques, and obfuscate what they're doing. This has in part to do with the discussion of essential/critical structure elements. For example, many of the tools that do a brute-force linear scan through a memory dump looking for EPROCESS structures look for specific elements of the structure itself in order to identify, as close as possible, a legitimate structure. Someone could obfuscate what they're doing by discovering which of those elements they can modify in order to avoid detection. Without identifying these critical elements...elements that cannot change without crashing the system...then this relatively new area of memory analysis is more open to anti-forensic and obfuscation techniques. However, Jesse pointed out something very important...a preponderance of anti-forensics and obfuscation (i.e., the over-abundance or relative lack of artifacts that an examiner would expect to see) activity should be a clear indicator to the examiner that something is amiss.
Also, Jesse used the term "tool marks" in his presentation...from what I saw, it sounded like "artifacts" to me, albeit specific to a particular "tool". This can be an important tool (I need to discuss this interesting topic w/ Jesse some more...) in that it can be a very useful data reduction tool to assist the examiner in identifying unusual things. For instance, something that came out of the DFRWS2008 Forensic Rodeo was that an unusual string in memory may indicate the use of TrueCrypt.
Overall, the quality of the presentations and speakers, as well as the panels, made for an excellent workshop! My hat's off to AAron and everyone else who put their time and effort into this event! It was great to finally meet folks like Moyix, Andreas, and have a chance to listen to their thoughts, and thank them. I hope to see this workshop again next year!
A couple of the big-brain take-away thoughts that came out of this 1/2 day workshop were:
There seemed to be agreement amongst the assembled panel (as well as the attendees) that open-source is the way to go with tools like memory parsing tools. Open-source allows for verification of your findings and how various items were found, transparency, as well as extensibility.
When performing memory acquisition and analysis (parsing, really), what are the essential or pertinent objects/items/elements? What parts of, say, an EPROCESS structure are absolutely essential for determining if you're looking at an actual EPROCESS structure?
The subject of anti-forensics came up as well, and a thought was that if the bad guys know about what the good guys are doing, and know what important elements have been identified simply by looking at the open-source code, then they can easily come up with ways to combat those tools and techniques, and obfuscate what they're doing. This has in part to do with the discussion of essential/critical structure elements. For example, many of the tools that do a brute-force linear scan through a memory dump looking for EPROCESS structures look for specific elements of the structure itself in order to identify, as close as possible, a legitimate structure. Someone could obfuscate what they're doing by discovering which of those elements they can modify in order to avoid detection. Without identifying these critical elements...elements that cannot change without crashing the system...then this relatively new area of memory analysis is more open to anti-forensic and obfuscation techniques. However, Jesse pointed out something very important...a preponderance of anti-forensics and obfuscation (i.e., the over-abundance or relative lack of artifacts that an examiner would expect to see) activity should be a clear indicator to the examiner that something is amiss.
Also, Jesse used the term "tool marks" in his presentation...from what I saw, it sounded like "artifacts" to me, albeit specific to a particular "tool". This can be an important tool (I need to discuss this interesting topic w/ Jesse some more...) in that it can be a very useful data reduction tool to assist the examiner in identifying unusual things. For instance, something that came out of the DFRWS2008 Forensic Rodeo was that an unusual string in memory may indicate the use of TrueCrypt.
Overall, the quality of the presentations and speakers, as well as the panels, made for an excellent workshop! My hat's off to AAron and everyone else who put their time and effort into this event! It was great to finally meet folks like Moyix, Andreas, and have a chance to listen to their thoughts, and thank them. I hope to see this workshop again next year!