Journey Into Incident Response

By failing to prepare, you are preparing to fail.

~ Benjamin Franklin

In many ways preparation is key to success. Look at any sporting event and the team who usually comes out on top are the ones who are better prepared. I'm not just referring to game day; I'm also talking about the coaching schemes and building a roster. Preparation is a significant factor to one's success in the Digital Forensic and Incident Response field. This applies to the entire field and not just malware forensics, which is the focus of this post. When you are confronted with a system potentially impacted with malware your ability to investigate the system successfully depends on your knowledge, experience, and toolset.  This is where there is a conundrum. There is a tendency for people not to do malware cases (either through being hired or within an organization) due to a lack of knowledge and experience but people are unable to gain knowledge and experience without working malware cases. The solution is through careful preparation one can acquire knowledge, experience, and toolset that can eventual lead to working malware cases. This post outlines the process I used and currently use to improve my malware forensics skills.

The process described in this post helped me to develop the skills I have today. I even use a similar process to create test systems to help develop malware forensic skills in others (if you read this blog then you have already seen the benefits of doing this). With that said, what I am describing is a very time consuming process. However, if you decide to replicate the path I took it will be worth it and along the way you'll improve your malware forensic skills. This post is specifically directed at those wanting to take this step using their own resources and time. Those wanting to lose themselves in the DFIR music.

Process, Process, Process

Malware forensics is the process of examining a system to: find malicious code, determine how it got there, and what changes it caused on system. The first place to start for improving one's skills is by exploring the process one should use. The purpose of starting with the process is twofold. First and foremost it is to understand the techniques, examination steps, and knowing what to look for. The second reason is to explore the various tools to use to carry out the process. There are only a few resources available specific to this craft such as: Malware Forensics Field Guide for Windows Systems and Windows Forensic Analysis Toolkit, Fourth Edition. In addition, this has been an area on my radar to add one more book to the discussion but in the meantime my jIIr methodology page outlines my process and links to various posts. My suggestion is to first review the methodology I put together which is further explained in the posts: Overall DF Investigation Process and End to End Digital Investigation. Afterwards, review one or two of the books I mentioned. As you work your way through this material pay attention to the malware forensic process the author uses or references.

When it is all said and done and you completed reviewing what you set out to then document a malware forensic process you want to use. If this sounds familiar then you either started reading jIIr from the beginning or you are one of my early followers. This is exactly what I described in my second and third posts Where to start? and Initial Examination Steps & First Challenge that I wrote almost four years ago. However, a lot of time has passed since I wrote those posts and I improved my process as outlined below:

     - Examine the master boot record
     - Obtain information about the operating system and its configuration
     - Examine the volatile data
     - Examine the files on the system that were identified in volatile data
     - Hash the files on the system
     - Examine the programs ran on the system
     - Examine the auto-start locations
     - Examine the host-based logs
     - Examine file system artifacts
     - Malware searches
     - Perform a timeline analysis
     - Examine web browsing history
     - Examine specific artifacts
     - Perform a keyword search
     - Examine suspected malicious files

Tools, Tools, Tools

After the process you want to use is documented then the next step is to identify the tools you will use in each examination step. There are numerous tools you can use; the tools mentioned by the authors in the reference material, tools talked about the bloggers in my blog roll, or tools you already have experience with. To be honest, what tools someone should use depends. It really depends on what you prefer and are comfortable with. The tools I started out with are not the same ones I use today; the important thing is each tool helped me learn and grow. Pick any tools you want as a starting point and over time you will start to see the pros and cons of various tools.

Testing Environment

With your process and tools selected, now it is finally time to stop the researching/documenting and to actually use the process you documented and tools you selected. To do this you first have to set up a testing environment. There is an inherit risk to using virtualization for the testing environment; the malware may be virtualization aware and behave differently than on real computer. However, despite this risk I highly recommend to use virtualization as your testing environment. It's a lot faster to create multiple test systems (by copying virtual machines) and the snapshot feature makes it easier to revert mistakes. There are various virtualization options available with great documentation such as VirtualBox and VMware. Pick a virtualization platform and install it using the provided instructions.

Creating your VMs

Another decision you'll need to make is what operating systems to perform your testing on. This not only includes the operating system versions (i.e. Windows 7 vs Windows 8) but what processor to use as well (32 bit vs 64 bit). I ended up selecting VMware for the virtualization software and Windows 7 32 bit as the testing platform. You will need to create your first VM by installing the operating system of your choice. After the installation try to make things easier for the system to be compromised.

First disabled security features. This includes the built-in firewall and the user account control. Next make sure the account you are using has administrative privileges. Next you will want to make your test system a very juicy target. To do this you'll need to install vulnerable client-side applications including: Adobe flash, Adobe Reader, Java, Silverlight, Microsoft Office, Internet Explorer, and a non-patched operating system. One place to grab these applications is Old Apps and to determine what versions to install pick the ones targeted by exploit kits. At a minimum, make sure you don't patch the OS and install Java, Silverlight, Adobe reader, and Adobe flash. This will make your VM a very juicy target.

After the VM is created and configured then you'll want to make multiple copies of it. Using copies makes things easier during analysis without having to deal with snapshots.

Manually Infecting Systems

The first approach to improving your skills is a manual method to help show the basics. The purpose is to familiarize yourself with the artifacts associated with malware executing in the operating system you picked. These artifacts are key to be successful in performing malware forensics on a compromise system. The manual method involves you infecting your test VM and then analyzing it to identify the artifacts. The manual method consists of two parts: using known and unknown samples.

However, before proceeding there is very important configuration change. The virtual machine's network configuration needs to be isolated to prevent the malware from calling home or attacking other systems.

Using Known (to you) Samples

Starting out it is better to practice with a sample that is known. By known I mean documented so that you can reference the documentation in order to help determine what the malware did. Again, we are trying to improve our ability to investigate a system potentially impacted with malware and not trying to reverse the malware. The documentation is just to help you account for what the malware did to make it easier to spot the other artifacts associated with the malware running in the operating system.

The way to find known samples really depends. You could find them using information on antivirus websites since they list reports using their malware naming convention. For example, Symantec's Threat Listing, Symantec's Response blog, Microsoft's Threat Reports, or Microsoft's Malware Encyclopedia to name a few. These are only a few but there are a lot more out there; just look at antivirus websites. The key is to find malware with a specific name that you can search on such as Microsoft's Backdoor:Win32/Bergat.B. Once you find one you like then review the technical information to see the changes the malware makes.

I suggested finding known malware by names first because there are more options to do this. A better route if you can find it is to use a hash of a known malware sample. Some websites share the hash of the sample they are discussing but this doesn't occur frequently. A few examples are: Contagio Malware Dump, KernelMode.info, or MxLab blog. Another option is to look at the public sandboxes for samples that people submitted such as Joe Sandbox or one listed on Lenny Zelster's automated malware analysis services list.

After you pick a malware name or hash to use then the next step is to actually find the malware. Lenny Zelster has another great list outlining different malware sample sources for researchers. Anyone one of these could be used; it just needs the ability to search by detection name or hash. I had great success using: VirusShare, Open Malware, Contagio Malware Dump, and KernelMode.info.

Remember the purpose of going through all of this is to improve your malware forensic skills and not your malware analysis skills. We are trying to find malware and determine how the infection happened; not reversing malware to determine its functionality. Now that you have your sample just infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now that you have an infected image (i.e. the vmdk file) you can analyze it using the process you outlined and the tools you selected. At this point you are making sure the process and tools work for you. You are also looking to explore the artifacts created during the infection. You know the behavior of the known malware so don't focus on this. Malware is different and so will be their artifacts. Focus on the artifacts created by a program executing in the operating system you selected. Artifacts such as program execution, logs, and file system.

Using Unknown (to you) Samples

Using a known sample is helpful to get your feet wet but it gets old pretty quick. After you used a few different known samples it is not as challenging to find the artifacts. This is where you take the next step by using an unknown (to you) sample. Just download a random sample from one of the sources listed at malware sample sources for researchers.  Infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with a known malware sample. This method makes it a little more challenging because you don't know what the malware did to the operating system.

Automatically Infecting Systems

The manual method is an excellent way to explore the malware forensic process. It allows you to get familiar with an examination process, tools, and artifacts associated with an infection. One important aspect about performing malware forensics is to identify the initial infection vector which was used to compromise the system in the first place. The manual method infections always trace back to you executing malware samples so you need to use a different method. This method is automatically infecting systems to simulate how real infections appear.

Before proceeding there is a very important configuration change. The virtual machine's network configuration needs to be connected to the Internet. This can be done through the NAT or bridged configuration but you will want to be in a controlled environment (aka not your company's production network). There are some risks with doing this so you will need to take that into consideration. Personally, I accept this risk since improving my skills to help protect organizations is worth the trade off.

Using Known Websites Serving Malware

In the automatically infecting systems approach the first method is to use a known website serving malware. There are different ways to identify these websites. I typically start by referring to Scumware.org (FYI, site hates Internet Explorer), Malc0de database, and the Malware Domain List. In both instances I look for URLs that point to a malicious binary. Other sources you can use are the ones listed by Lenny Zelster on his Blocklists of Suspected Malicious IPs and URLs page. Again, you are trying to find a URL to a site hosting a malicious binary. Another, source you shouldn't overlook is your email SPAM/Junk folder. I have found some nice emails with either malicious attachments or malicious links. Lastly, if you pay attention to the current trends being used to spread malware then you can found malicious sites leveraging what you read and Google. This is a bit harder to pull off but it's worth it since you see a technique currently being used in attacks.

Inside your VM open a web browser, enter in the URL you identified, and if necessary click any required buttons to execute the binary. Wait a minute or two for the malware to run and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with the manual approach. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. Infecting a VM in this manner simulates a social engineering attack where a user is tricked into infecting themselves. If a SPAM email was used then it simulates a email based attack.

To see how beneficial this method is for creating test images to analyze you can check out my posts Examining IRS Notification Letter SPAM and Coming To A System Near You. The first post simulates a phishing email while the later simulates social engineering through Google image search.

Using Potentially Malicious Websites

The second method in the automatically infecting systems approach is to use potentially malicious websites. This method tries to infect the VM through software vulnerabilities present in either the operating system or installed client-side applications. This is the most time consuming out of all of the methods I described in this post. It's pretty hard to infect a VM on purpose so you will end up going through numerous URLs before hitting one that works. This is where you may need to use the VM snapshot feature.

To find potentially malicious URLs you can look at the Malware Domain List. Look for any URLs from the current or previous day that are described as exploit or exploit kit as shown below. You can ignore the older URLs since they are most likely no longer active.

Another option I recently discovered but haven't tried yet is using information posted at Malware-Traffic-Analysis.net. The site doesn't obfuscate websites used so you may be able to use it to find active websites serving up exploits. The last option I'm sharing is the one I use the most; the URLs others are submitting to URLQuery.net. Just keep in mind, there are certain things that can't be unseen and there are some really screwed up people submitting stuff to URLQuery. When reviewing the submitted URLs you want to pay attention to those that have detections as shown below:


After you see a URL with detections then you'll need to examine it closer by reviewing the URLQuery report. To save yourself time, focus on any URLs whose reports mention: malicious iframes, exploits, exploit kits, or names of exploit kits. These are the better candidates to infect your VM. The pictures below show what I am referring to.






Before proceeding make sure your VM is powered on and you created a snapshot. The snapshot comes in handy when you want to start with a clean slate after visiting numerous URLs with no infection. An easy way to determine if an infection occurred is to monitor the program execution artifacts. One way I do this is by opening the C:\Windows\Prefetch folder with the items sorted by last modification time. If an infection occurs then prefetch files are modified which lets me know. Now you can open a web browser inside your VM, enter in the URL you identified, and monitor the program execution artifacts (i.e. prefetch files). If nothing happens then move on to the next URL. Continue going through URLs until one successfully exploits your VM. Upon infection wait a minute or two for the malware to run and then power it down. Make sure you delete any snapshots to make it easier.

Now you can start your examination using the same process and tools you have been using. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. The initial infection vector will be a bit of a challenge since your VM has various vulnerable programs. Infecting a VM in this manner simulates a drive-by which is a common attack vector used to load malware onto a system. To see how beneficial this method is for creating test images you can check out my post Mr Silverlight Drive-by Meet Volatility Timelines (FYI, I suspended the VM to capture the vmem file in addition instead to powering it down to get the disk image).

Summary

Benjamin Franklin said "by failing to prepare, you are preparing to fail." To be successful when confronted with a system potentially impacted with malware we should be preparing for this moment now. Taking the time to improve our malware forensic skills including our process, tools, and knowledge of artifacts. Making the right preparations so when game day approaches we will come out on top. The process I use to improve my malware forensic skills and the one I described in this post is not for everyone. It takes time and a lot of work; I've spent countless days working through it. However, working your way through this process you will attain something that can't be bought with money. There is no book, training, college course, or workshop that can replicate or replace the skills, knowledge, and experience you gain through careful preparation by training yourself.

I have always maintained a strong separation between jIIr -which is my personal blog - and the work I do for my employers. For one time, for one post I'm blurring the lines between my personal publishing platform and work I did for an employer. I previously posted about My Journey into Academia where I discussed why I went from DFIR practitioner to DFIR educator. I'm continuing the journey by discussing the course I designed for Champlain College's Master of Science in Digital Forensic Science (MSDFS) program. My hope is by sharing this information it will be beneficial to those developing DFIR academia curriculum and those going from DFIR practitioner to DFIR educator.

Why Academia Recap

My Journey into Academia post goes into detail about the issue where some academic programs are not preparing their students for a career in the digital forensic and incident response fields. How students coming out of these programs are unable "to analyze and evaluate DFIR problems to come up with solutions." In the words of Eric Huber in his post Ever Get The Feeling You’ve Been Cheated?:

"It’s not just undergraduate programs that are failing to produce good candidates. I have encountered legions of people with Masters Degrees in digital forensics who are “unfit for purpose” for entry level positions much less for positions that require a senior skill level."

As I said before, my choice was simple: to use my expertise and share my insight to improve curriculum; to put together a course to help students in their careers in the DFIR field.

Why Champlain College

Years ago I went to my first DFIR conference where I met Champlain's MSDFS program director at the time. One of the discussions we had was about the program being put together. A program that was supposed to not only help those looking to break into the field but to benefit those already in the field by covering advanced forensic topics.

Years later when an opportunity presented itself for me to develop the Malware Analysis course for Champlain's MSDFS program I remembered this discussion. I always heard great things about Champlain's programs and it was humbling to be offered this chance. It was even better when I took a look at the MSDFS curriculum. Seeing courses like: Operating System Analysis, Scripting for Digital Forensics, Incident Response and Network Forensics, Mobile Device Analysis, and then adding Malware Analysis to the mix. The curriculum looks solid covering a range of digital forensic topics; a program I could see myself associated with.

For those who don't want to pursue a Master's degree can have access to the same curriculum through their Certificates in Digital Forensic Science option. An option I learned about recently.

DFS540 - Malware Analysis Course

How can you reverse malware if you are unable to find it? How can you find malware without identifying what the initial infection vector is? How can you identify the initial infection vector without knowing what artifacts to look for? How can you consistently explore artifacts without a repeatable process to follow? How can you carry out a repeatable process with having the tools to do so? I could go on but this adequately reflects the thought process I went through when developing the curriculum. Basically, the course had to explore malware in the context that a DFIR practitioner will encounter it. To me, the best way to approach building the course was by starting with the course objectives and the following were the ones created (posted with permission):

     -  Evaluate the malware threat facing organizations and individuals
     -  Identify different types of malware and describe their capabilities including propagation and persistence mechanisms, payloads and defense strategies
     -  Categorize the different infection vectors used by malware to propagate
     -  Examine an operating system to determine if it has been compromised and evaluate the method of compromise
     -  Use static and dynamic techniques to analyze malware and determine its purpose and method of operation
     -  Write reports evaluating malware behavior, methods of compromise, purpose and method of operation

Course Textbooks

After the course objectives were created the next item I took into consideration was the reading materials. One common question people ask when discussing academic courses is what the courses’ textbooks are. I usually have mixed feelings about this question since the required readings always extend beyond textbooks. The Malware Analysis course is no different; the readings include white papers, articles, blogs, reports, and research papers. However, knowing the textbooks does provide a glimpse about a course so the ones I selected (as of the date this post was published) were:

Szor, P. (2005). The Art of Computer Virus Research and Defense. Upper Saddle River: Symantec Press.

Russinovich, M., Soloman, D., & Ionescu, A. (2012). Windows Internals, Part 1 (6th ed.). Redmond: Microsoft Press.

Honig, A, & Sikorski, M. (2012). Practical Malware Analysis: The Hands on Guide to Dissecting Malicious Software. San Francisco: No Starch Press.

Ligh, M., Adair, S., Hartstein, B., & Richard, M. (2011). Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code. Indianapolis: Wiley Publishing.

Course Curriculum

I started creating the curriculum after the objectives were all set, the readings were identified, and most of my research was completed (trust me, I did plenty of research). When building out the curriculum its helpful to know what format you want to use. Similar to my collegiate experience (both undergraduate and graduate), I selected the traditional teaching methods for the course such: lectures, readings, discussions, laboratories, and assignments. I made every effort to make sure the weekly material covered by each teaching method tied together as well as the material from each week.

Developing Weekly Content

To illustrate how the weekly material ties together I thought it would be useful to discuss one week in the course; the course's second week material which explores anti-forensics and Windows internals. Each week (eight in total) begins with a recorded lecture. The lectures either convey information that is not discussed in the readings - such as a process -  or re-enforces the information found in the readings and lab. The week two lecture explores anti-forensics to include: what it is, its strategies, and its techniques to defeat post mortem analysis, live analysis, and executable analysis. When dealing with malware whether on a live system (including memory images), powered down system, or the malware itself it's critical to know and understand the various anti-forensics techniques it may leverage. Without doing so may result in an analyst missing something or reaching false conclusions. Plus, anti-forensics techniques provide details about malware functionality and can be used as indicators to find malware.

The week two readings continue exploring anti-forensics as well as self protecting strategies used by malware. The readings also go in-depth on Windows internals to explore covering items such as system architecture, registry, processes, and threads. All of the readings explore topics crucial for malware forensics and analysis.

Even though this is an online course I made a strong emphasis on the weekly labs so students explore processes, techniques, and tools. The week two lab ties together the week's other material by exploring how two malware samples use the Windows application programming interface to conceal data with different anti-forensic techniques.

The remaining weeks in the course ties together the material in a similar way I described for the second week. (There is more to the second week's material but I didn't think it was necessary to disclose every detail). The topics explored in the other weeks include but isn't limited to:

     -  Malware trends
     -  Malware characteristics
     -  Memory forensics
     -  Malware forensics
     -  Timeline analysis
     -  Static and dynamic malware analysis

Assignments

The curriculum wouldn't be complete without requiring the students to complete work. In addition to weekly discussions about engaging topics there needs to be assignments to engage and challenge students. The assignments need to tie back to the course objectives and this was another area I made sure of. I'd rather not disclose the assignments I put together for the course or my thought process behind creating them. However, I will discuss one assignment that I think truly reflects the course; the final assignment. Students are provided with a memory image and a system forensic image and then are tasked with meeting certain objectives. Some of these objectives are: finding the malware, identifying the initial infection vector, analyzing any exploits, analyzing the malware, and conveying everything they did along with their findings in a digital forensic report.

Summary

In the end, the Malware Analysis course is just one of the courses in Champlain's MSDFS and certificate in digital forensic science programs; a course I would have killed to take in my collegiate career. A course with material that cannot be found in any training.

Developing the course has been one of the most challenging and rewarding experiences in my DFIR career. Not only did I develop this course but I'm also the instructor. One of the best experiences so far about my journey into academia has been watching the growth of students. Seeing students who never worked a malware case successfully find malware, identify the initial infection vector, analyze the malware, and then communicate their findings. Seeing students who already had DFIR experience become better at working a malware case and explaining everything in a well written report. My posts about academia may come to a close but the journey is only just beginning.

 

The frequency of my blog posts was slowly decreasing until I finally reached the point when I decided to take a hiatus from jIIr. My decision to stop blogging wasn’t because my heart is no longer in it, I ran out of ideas, or I lost interest in sharing with others. My decision was the result of a time management issue. I’ve been focused on another endeavor that has left me with very little time for blogging. This endeavor has been my journey into academia. As I recently reached a milestone on this journey (developed my first course) I wanted to take the time to talk about why I went from DFIR practitioner to DFIR educator.

Why Even Bother with Academia

To be honest academia wasn’t even on my radar. An opportunity presented itself and after careful consideration I decided to pursue it. However, before saying what my final deciding factor was for starting this journey it’s necessary to reflect on our DFIR field and how academia supports it.

There has been an issue within our field that seems to be growing with each passing year. The issue is obvious for those who are active on DFIR forums, mailing lists, and conducting interviews to fill positions. Eric Huber (A Fistful of Dongles) addressed this issue in his post Ever Get The Feeling You’ve Been Cheated? Eric made a lot of great points in the post so it’s well worth the read. I wanted to pull out two quotes to highlight the issue I referenced.

“During the early years, it was rare to see applicants who had degrees in digital forensics, but I’m finding it increasingly common in recent years. One of the things that I have been struck by is how poorly most of these programs are doing in preparing students to enter the digital forensics fields.”

“One of the core issues that I see with the programs that aren’t turning out prepared students are the people who are teaching them.”

The issue is some academic programs are not preparing their students for a career in the digital forensic and incident response fields. I’m not talking about skills such as students not being able to run tool XYZ since this can be easily addressed through training. The deeper issue is students not being able to analyze and evaluate DFIR problems to come up with solutions. Like Eric, I don’t fault the students to a certain degree. The blame goes to the academic programs that are hastily putting together information security and digital forensics programs to jump on the bandwagon.

As practitioners in this field we have a choice to make. We can either continue on with not hiring students coming out of these programs, ignoring their requests for homework answers in forums, or be irritated about those doing a disservice to our field by being unqualified and doing casework. Or we can do something different; we can try to change it by being involved with academia and sharing our insight/expertise to improve the curriculum. When I was presented with the opportunity this is what my decision came down to. My choice was simple; to use my ability to put together a course that helps students in their careers in the digital forensic and incident response fields. In the words of Jon Rajewski about why this should matter to all of us; “they are the future generation of digital forensic / incident responders”.

Why Academia and Not Training

My decision to start my journey into academia wasn’t solely to help those entering the DFIR field. I also wanted to help provide curriculum to benefit those already in the field. At the time I had an idea about why training wasn’t an option but I couldn’t quite put my finger on it. That was until I started looking into the differences between education and training. The difference is illustrated in Peter Fabri’s story when he went back to graduate school. He contrasted the two by saying “training is concerned with acquiring a skill” while “the aim of education is broader than training”. He went on to say education “strives to prepare learners to be analytical thinkers and problem solvers by facilitating the learning of principles, concepts, rules, facts, and associated skills and values/attitudes”.

It might be more helpful to put the difference between education and training in the context of DFIR. The paper Computer Forensics: Training and Education compared the difference as saying training "has the goal of training students for an occupation within the computer forensics field". The paper further states “training is also limited in that it focuses students’ attention on current techniques and methods rather than processes”. On the other hand, the paper explained education “destines to educate students on the needed capabilities but goes a step further in attempting to teach the students a greater level of detail on the goings on behind the scene”.

Continuing on exploring this difference is the article Education versus Training: Selecting the Right Lifelong Learning Experience (I highly recommend reading this article). As it relates to training the article explains:

“The bottom line is to seek training to acquire skills and knowledge for short-term advantage. Training brings the learner up to the level of others in the industry and will tend to make them the same as the experts they seek to emulate”

As it relates to education the article says:

“Education is different. It should be used to acquire a mindset not currently owned or to deepen a mindset already possessed”

“Education broadens the learner, makes him different from everyone else and helps him think in his own way to solve problems that have not been solved before. Of course educational programs include training in the skills and knowledge of the discipline, but they go further to develop thinking abilities, attitudes and behavior patterns that might be classified as a mindset. In this sense, training programs do not include education but education programs often include training.”

The key difference between education and training as it relates to digital forensics and incident response is one’s goal is to equip the learner with the skills, techniques, and methods to tackle a known problem while the other’s goal is to develop the learner into an analytical problem solver to tackle any problems they may face. To illustrate this point it might be helpful to share two experiences I’ve seen in my career. Numerous people in DFIR have attained most of their skills and knowledge through trainings and they weren't developed into an analytical thinker through a formal education. At times this puts them at a disadvantage.

One day I was leading a local forensic group meeting on walking them through an analysis  on a test image. I wanted everyone to participate so I provided an option to use free or open source digital forensic tools. As I was going through the analysis someone in attendance said “I could do this if I had “insert commercial forensic tool here”. This person wasn’t approaching the analysis as a problem solver and saying what tools can help me carry out my process. Instead they fell back on their training and without the tool they were trained on they were helpless.

Another example is one I see online. In these instances it’s people who are new to finding malware on systems but they have recently completed some training on the topic. They have a system where they must find malware. In an effort to use their newfound memory forensic skills they try to virtualize the system, dump the memory, and then try to analyze the memory to find the malware. This is a good technique but they never take a step back to look at the problem they must solve and the process to use to solve the problem. Again, they fall back on their training to try to solve what they are faced with.

This key difference is why I felt more aligned with academia with trying to educate others into the DFIR mindset as opposed to instructing others on a specific skill. As the Education versus Training: Selecting the Right Lifelong Learning Experience article states I wanted the learners to be “acting after deep thought and analysis; broad” instead of “acting out of new habits and skills; narrow”. I wanted the end result to be “makes you different from others, thoughtful and mindful, educated” and not “make you the same as others with the same training, measure up”.

These were the two primary reasons why I started my journey into academia; why I’m using my DFIR practitioner mindset and skill set to be a DFIR educator. The other perks such as research resources and extra income were just icing on the cake.