AboutDFIR.com – The Definitive Compendium Project
Digital Forensics & Incident Response

IR A-Z

IR A-Z

By: Mary Ellen Kennel, Security Engineer
last updated: 6/30/2016
https://twitter.com/icanhaspii
https://ManhattanMennonite.blogspot.com
https://www.linkedin.com/in/MaryEllenKennel

Copyright © 2016 by Mary Ellen Kennel.  All Rights Reserved

ABOUT THE PAPER

Although I wrote this paper on my own, I can hardly take ownership of it.  The processes and procedures that are hereby illustrated are simply my regurgitation of the wealth of information I have been blessed to learn from my amazing co-workers, both past and present.  To name a few:  Jeremy Coons, Carlotta Del Hierro, Lawrence Judd, Michael Francess, Amanda Hadden, Paul Lewis, Jeffrey McGurk, Jesse Mayer, Erik Mercado, Daniel Rico, Daniel Rodriguez and Eric J. Schwartz.

I began the concept of this paper with one sentence, almost 5 years ago.  I have slowly expanded upon that sentence over the past 5 years, and I fully expect that trend will continue.  Over the course of chipping away at the paper, I have published portions of it on my blog.  A likely follow-up would be an example investigation, soup to nuts, along with a final report that one could hand to the client.  That may be my next endeavor.  I started that process recently, but with not a lot of free time in my schedule, I decided to go ahead and publish what I have so far, and if I can eke out enough time to do the rest and tack on other stuff, I certainly will.

The paper is dedicated to my daughters.  My 1 year old cannot yet grasp the concept of malware, however while traveling recently and Skyping with my 5 year old who is crazy about princesses and of course “Frozen,” we were sharing stories about our day and I mentioned that I had come across a very interesting piece of malware, to which she responded, “Mom, was it pink malware?!”  And thus, “pink malware” was born, because of course I had to come home with some for her.

Lastly, my thoughts and processes are just one of a thousand ways you can approach an incident.  I am making no claims that the paper is perfect, or exhaustive.  I do, however, hope that someone will find something meaningful that they can take away from it.  I recently received a private message from someone anonymously via my blog who encouraged me to keep putting things like this out there because it was incredibly helpful to the DFIR community.  I am releasing this paper in the spirit of that post.  It’s far from ready for publishing, or complete, but it is good enough for now.

INTRODUCTION

Several years ago, while I was working at a different company, at the beginning of each investigation, the firm would hold what they called a “Kick-Off Call” with the client.  Prior to the kick-off call, it was the job of the Project Manager to round up as much information about the case as possible, and then we’d all jump on a call with the client.  Inevitably, the initial information we’d be given was often a bit skewed.  For example, if the client initially stated the device list as 5 desktop computers each with 120GB hard drives, 3 laptops and 2 iPhones, we’d get on the call and realize there were 9 desktop computers and only 2 had 120GB HDD’s while the rest were 500GB, 3 iBooks and 2 Blackberries.  OK, I’m exaggerating just a little, but perhaps you can relate?

Probably the most enlightening thing about those kick-off calls was that we almost always came to realize that the in-house IT staff had invariably, whether out of curiosity (understandable) or just trying to be helpful, had already performed their own assessment of the situation and mucked things up.  Quite simply, it happened more than not, and on almost every case we handled.  I don’t have any other benchmark to gauge the commonality of this in respect to the overall DFIR community, but we saw quite a number of cases every year, so our sample was high enough that I thought I’d mention it.

Again, it’s logical that the first one to the scene of the event is going to try to be helpful, and also perhaps curious about what’s going on.  I’d venture to say that the bulk of IT folks are hackers at heart, and thrive on peeking under the hood to see what’s really happening.  Also, part of the task of IT is to just plain troubleshoot, so I will try to break things down enough that any first responder will have a sound and sanitized approach.  Lastly, I do NOT mean to rail on the IT guys and gals of the world, I was one of them!  My purpose is to empower the first-responder, whoever they may be, with the right tools for the right job.

Whether or not you are familiar with the term Incident Response or the acronym IR, this article is geared toward the first responders who don’t really have either of those two words in their title, but find themselves in a situation that’s both interesting, and challenging.  It’s not unusual for an IT person to be called upon to assess things when someone thinks they might have clicked on a malicious link, or downloaded a piece of malware.  The layperson probably isn’t going to know what just happened, but they may notice enough strange activity to cause them to call upon IT.

Maybe you work in an IT Department and you have taken one of those types of calls, or followed orders from your Supervisor to act accordingly.  Maybe you’re the director of the department who actually receives the phone call.

Many years ago I received a laptop that had been seized by a company due to concerns not so much of theft, but of data destruction.  This particular company was a very large company from another country, and had only had a small office with a few hundred employees in the United States.  Because of the meager size of their US branch, the company had made an executive decision not to implement an automated back-up system (huge mistake, but how many of you have had friends approach you because they lost critical data and didn’t have a back-up copy anywhere).  Basically, nothing had been backed-up.

What the company believed had happened, was that a disgruntled employee had opened hundreds of documents stored only on their local PC, deleted their contents, and then re-saved them.  We were given the laptop to run an analysis on recent events to see if we found any evidence of malfeasance.  Before we began the investigation, the first thing we did was hold a call with our team and the client/attorneys to harvest as much information as we could about what it was we would be tasked with doing once we had the media in our possession, and what was the history of events that led to the call in the first place.  For this particular matter, we’d been told on the kick-off call with the client and attorneys that the IT department had “performed their own investigation.”  The IT Department wasn’t on the call, and no one in that meeting seemed to know exactly what type of investigation had been done.

Once we imaged the machine in question, we noticed the absence of data where there usually is data.    (That is one of many concepts that I picked-up over the years by reading Harlan Carvey’s blog and books.  If you haven’t purchased every single one of his books yet, do so now!  The approach I took can be found in his blog post http://windowsir.blogspot.com/2007/03/book-updates-nukeondelete.html and basically states: “One of the core concepts of my book is that by understanding how artifacts are created and modified, we see that the absence of an artifact where we expect to see one is, in itself, an artifact. Checking for this value and then correlating what you find to other findings on the system will provide clues not only to what happened on the system and when, but also to the technical sophistication of the user.”

We had acquired the username in question, but under that profile, the “My Documents” was empty except for an Excel file and one pdf; a little different than what we’d been told on the kick-off call.  We were expecting lots of files with very little data in them, instead we found the antithesis.  We then checked the Administrator account (occasionally we’d come across a machine where the custodian has been logging into the Administrator account for their day-to-day).  What was interesting was, in the Administrators’ “My Documents”, there was a folder with the custodian’s name appended by the word “Recovered”.  After digging a little deeper, we noticed the presence of recovery software named “Recovered”, and so we immediately contacted the IT department to ask if they had used that particular software as part of their investigation.  Turns out they had, and the way that software worked was that it moved every file and folder as it attempted to recover it, placing it in a folder entitled “Recovered”, which created some challenges during the investigation.  Hopefully this paper will help prevent the aforementioned scenario.

“Pulling the plug on pulling the plug” is a phrase I like to use whenever I get a chance.  It’s an interesting topic, in my opinion, and I enjoy talking about it…but it begs the question, if we aren’t pulling the plug anymore, just what are we doing?

I thought perhaps it might make sense to break down our investigation process into three parts or phases.  Since each investigation can vary from the last, and depending on the scope and depth of what is found in the first phase, it may or may not make sense to perform all three phases.  Let’s begin a sample case with phase one, and see where that leads us.  We’ll be looking at the Windows examples, but for a good breakdown of the Mac, there are many great resources.  You can start at the following link: http://www.macforensicslab.com/index.php?main_page=document_general_info&products_id=271

For our sample case, we’ll be tasked with analyzing both a hard drive image and a memory dump.  Now let’s get our “Go Kit” ready!

PHASE I

ACQUISITION/CHAIN OF CUSTODY

  • There are many ways to acquire digital media in a sound forensic manner onto forensically sanitized media.
  • Once acquired, verify your image.
  • Validation of the digital content can be attained through a mathematical checksum process which provides confirmation that the content of the hard drives has not been altered during the collection or shipping process. The mathematical value utilized is an MD5 checksum.
  • Next, to preserve your original, you can make a bit-to-bit image of the acquired forensic images onto forensically sanitized media using a forensic write block and industry standard best practices for digital analysis. The original images can then be held and preserved as pristine masters.

MEMORY ACQUISITION

To analyze the memory, we must first acquire it. I believe it’s safe to say that the DFIR community has successfully pulled-the-plug on pulling-the-plug, and that “live” memory acquisition has proven the best method of capture. That being said, we First Responders aren’t always the first to respond.  There are numerous tools for live memory (not just RAM), and more than one method; some are listed below.  I recommend using two different tools for collection (and doing a double capture) as acquiring memory is tricky and you might not know you have a corrupted sample until it’s too late.

INITIAL TRIAGE

  • If you’re using FTK, it probably makes sense to kick-off the indexing process right away and let that get going. Just as a side-note, make sure you’re aware of what you’re processing when you kick things off, and even take a screen-shot of your settings so that if you ever need to support or explain the processing choices you made, you have that screen-shot as a back-up. For example, if you don’t think you’ll need to carve images right away, your case can load quicker by not checking that off initially.  There are pros and cons to choices like that.  You may not think your case will involve many images and then find out mid-way through that you wished you’d have carved for images initially.  You’ll have to use discernment and your best judgment, and you can always modify the processing options later.
  • Likewise, if you are using EnCase and were given search terms by the attorneys or authorities on what to look for, make sure you kick-off the search process right away, as those searches can take quite a long time.
  • Additionally, although it may add some time to the acquisition process, I believe it’s worthwhile to check-off creating a Directory Listing by Created Date, to aid in the purpose of timeline analysis.

$ python vol.py -f ~/Desktop/win7_trial_64bit.raw imageinfo
VolatileSystemsVolatilityFramework2.1_alpha
Determining profile based on KDBG search…

SuggestedProfile(s):Win7SP0x64,Win7SP1x64,Win2008R2SP0x64,Win2008R2SP1x64
                     AS Layer1: AMD64PagedMemory (Kernel AS)
                     AS Layer2:FileAddressSpace(/Users/Michael/Desktop/win7_trial_64bit.raw)
                     PAE type :PAE
                          DTB :0x187000L
                          KDBG :0xf80002803070
     Number of Processors:1
     ImageType(ServicePack):0
             KPCR for CPU 0:0xfffff80002804d00L
             KUSER_SHARED_DATA :0xfffff78000000000L
             Image date and time :2012-02-2211:29:02 UTC+0000
     Imagelocal date and time :2012-02-2203:29:02-0800

  • Next run pslist to find out what processes were running at the time the memory was acquired, and to look for oddities such as processes which have no ParentID (hidden):
  • vol -f [Drag memory image onto command line here] pslist
  • Now, carve w/ Volatility:
  • Type: vol -f [Drag memory image onto command line here] malfind -D [create a destination folder and drag it here]
  • Type: vol -f [Drag memory image onto command line here] procexedump -D [create a destination folder and drag it here]
  • Type: vol -f [Drag memory image onto command line here] dlldump -D [create a destination folder and drag it here]
  • Type: vol -f [Drag memory image onto command line here] procmemdump -D [create a destination folder and drag it here]
    • Once you’ve carved all you’re going to carve, you can scan all your carved files with your a/v and malware scanners. If any of the carved files hit, hash them and put into http://VirusTotal.com, http://Hybrid-Analysis.com, http://Malwr.com, (or many others) or straight into Google. Remember that VirusTotal and some others are crowd-sourced and not always 100% accurate.  Some people use the benchmark that if VirusTotal has 5 or fewer hits, most likely the file is benign, but that also is not an exact science.  Some of the carved artifacts won’t flag the scanners, but if you compute their MD5 Hash, and then plug that into VirusTotal or even just plain Google, you may find some interesting results.  There are lots of tools to compute hash, you can try:
  • HashCheck: http://code.kliu.org/hashcheck
  • HashDeep/MD5Deep: http://md5deep.sourceforge.net
  • Note: If you aren’t sure if you’re dealing with a targeted attack and you want to keep your submissions on the down-low, submitting just the hash will do so.
  • Additionally in Volatility, run the following processes against the RAM capture:
  • Apihooks
  • Callbacks
  • Driverirp
  • Devicetree
  • Psvview
  • Timers
  • Run ConnScan to find all connections from the host at the time the image was collected. After you run ConnScan, check all the ip’s it lists for suspicious backgrounds.
  • Run the MFTparser command to check for malware in the MFT (that command may take a bit longer than some of the others).
    • Additionally in Volatility, run the following processes against the RAM capture.
  • Malicious files can be packed and thereby possibly unidentifiable by any of the scanning tools and/or hex editors. You can scan the carved files with ExeInfoPE: http://exeinfo.pe.hu or PEiD: https://www.aldeid.com/wiki/PEiD to determine which ones are packed, and then you can download the correct software to unpack the binary.
  • You can run DensityScout: https://www.cert.at/downloads/software/densityscout_en.html against the C:\Windows\System32 directory to check the “weight” or entropy of the binaries. Not everything that’s packed or has high entropy is malicious, but tools like that can help you take a closer look. You can expand your search to the whole drive as time permits.
  • You can use SigCheck: http://technet.microsoft.com/en-us/sysinternals/bb897441, a Windows SysInternals tool to check signatures on the exe files which become of interest after running the aforementioned tools.
  • Next, you can run your memory files through the following tools:

REGISTRY ANALYSIS

  • I like to first pull out all of the Registry files. There are tools like EnCase or FTK that you can use to do that, or you can just manually export them from the mounted image at the following locations:

WindowsXP:

  • SAM file – Windows/System32/Config
  • SECURITY file – Windows/System32/Config
  • SOFTWARE file – Windows/System32/Config
  • SYSTEM file – Windows/System32/Config
  • NTUSER file – C:\Documents and Settings\ CustodianProfileName\NTUSER.DAT

Windows7/10:

  • SAM file – Windows/System32/Config
  • SECURITY file – Windows/System32/Config
  • SOFTWARE file – Windows/System32/Config
  • SYSTEM file – Windows/System32/Config
  • NTUSER file – C:\Users\CustodianProfileName\NTUSER.DAT
  • There are numerous programs that allow you to parse and/or view the Registry files:

PREFETCH PARSING

  • Peruse the Windows Prefetch directory (C:\Windows\Prefetch) for suspicious program names/paths and last run date (modified time).  You can begin your Prefetch dissection by trying a few examples (below) of the many Prefetch tools available, and add any eyebrow raisers to your master timeline.
  • PrefetchForensics
  • PrefetchParser
  • WindowsFileAnalyzerPrefetchTool
  • WindowsPrefetchParser
  • WinPrefetchView

OUTLIERS AND MFT

  • Parse Master File Table for timeline activity surrounding compromise with Bulk Extractor: http://digitalcorpora.org/downloads/bulk_extractor. Again, if we have a timeframe for our event, then a good rule of thumb I like to use is+/- 48 hours of that occurrence. If we have no timeframe for our event, then I suggest creating a Directory Listing of just zips, dlls, rars, exe’s, zero length files and one character named files, all common points for badness.
  • Perform hash comparison against Known Indicators of Compromise, including but not limited to:

PHASE II

LOG ANALYSIS

  • Logs of interest (+/- 48 hours on each IOC or established event timeframe) and their corresponding ip addresses with analysis where applicable.
  • Windows Event Logs
  • Wired Connection Logs
  • Wireless Connection Logs
  • Recent Items (where applicable)
  • Drive Connections (USBSTOR + Mounted Devices = Device and date/time)
  • File-Sharing (where applicable) (Win=Libraries for Home Group and Mac=File-Sharing)
  • Artifacts such as DropBox, P2P, torrent, etc.

KEYWORD SEARCH TERMS

  • Compile and run search terms you may have been given by counsel. And I always use personal discernment and add any relative terms that I believe may be of interest to the case based on what has been presented, e.g., you can always search for terms such as “pwdump” or “password”, to name a couple.

DELETED FILES

  • Perform deleted File Analysis and recovery if pertinent. You can do that easily with EnCase or carve them out with your favorite Hex editor. See Appendix A for more choices.

PHASE III

REVERSE ENGINEER

Phase III would involve reverse engineering any malware that we may have found.  The steps below show some precursors to reverse engineering if the exploit were to come through via a malicious link or attachment, but RE itself is a complicated art form, so we will not get deep into that in this paper.  Let’s look at any suspicious email first.

IS THE EMAIL LEGITIMATE OR PHISHING?

  • So the emails come in. Analysts first need to determine whether or not any suspicious or flagged emails are legitimate. Steps should include:
    • Acquire a copy of the email in .msg format and view original headers:

http://mxtoolbox.com/Public/Tools/EmailHeaders.aspx (for the uber paranoid, try to learn to read them on your own without having to force them into “the cloud”.)

  • Who was the sender, and was there spoofing involved?
  • What was the Subject?
  • Did the message contain a URL? (Y/N) If so, analyze all URL’s via tools like:
  • Malicious indicators can have a range and a severity, so it’s prudent the examiner is keenly able to decipher a true finding from a false positive, and take necessary action. Indicators include (but are not limited to):
  • MX Header black-listing
  • URLquery dropper findings
  • Z-scaler malicious ranking
  • URLvoid – any number of hits
  • IPvoid – any number of hits
  • Domain Registrations that are same-day or 1-2 days old
  • ip addresses from known malicious entities

MALICIOUS SOFTWARE ANALYSIS

  • If the analyst determines that the email is suspicious and not legitimate, they need to perform a root cause investigation, in order to ensure proper containment. Steps may include:
    • Check your mail filters to verify if the mail was actually delivered, and if so, how many users clicked on it.
    • Check to verify that the URL was blocked in your environment.
    • Query the enterprise to verify that no one clicked the malicious link and got through (even if a block was in place, the click could have predated the block).
    • Did the message contain an attachment? (Y/N) If so, did the user open the attachment? (Y/N)
    • Analyze any attachment that was not cleaned by a/v.
      • Create a hash of the attachment.
      • If previously undetected, submit the sample to your a/v solution.
      • Search for the hash in malware databases such as:
    • Malwr: https://malwr.com/submission
    • VirScan: http://virscan.org
    • VirusTotal: https://www.virustotal.com
    • Hybrid Analysis: http://hybrid-analysis.com
    • Note: If you aren’t sure if you’re dealing with a targeted attack and you want to keep your submissions on the down-low, submitting just the hash will do so.

SANDBOXING

  • Load the sample into a sandbox appliance (If you have one), and I recommend submitting twice (both “Live” and “Sandbox” mode).
  • Load the sample into the following malware databases:
  • Make sure to move all samples to an isolated physical or virtual lab. The lab should be bifurcated from your production network.
    • One suggested lab config could be a dedicated laptop on a separate ISP, and its own completely isolated LAN. Ensure that Internet connectivity is disabled on your lab VM’s.
    • Another config suggestion could be to have the netflow of one VM set to pipe over to a second VM running FakeDNS so that when you begin your dynamic analysis, you can easily capture any C2’s with WireShark for example.
    • If using VMWare, be certain to check the following:
  • Make sure that you are running as Host-Only.
  • Ensure that your memory is set to: File ->Preferences->Memory->Fit all virtual machine.
    • Also for your lab, it’s suggested you install Adobe Reader (free), MS Word and PowerShell as some malware requires those programs in order to fully execute. For Acrobat, some recommend an older version that may have fewer patches. You can grab that at http://www.oldapps.com.
    • Take a snapshot of your lab before kicking-off any malware in order to easily revert your VM to its previous state.
    • NOT for the faint of heart:
      • If you find that your malicious specimen won’t fully engage without Internet connectivity, you can turn on Internet to your VM temporarily and follow all the processes listed below under “Dynamic Analysis”.
      • If you find that your malicious specimen is environment-aware and won’t fully execute in a VM, you can launch it “live” right on your bifurcated laptop using all the processes listed below under “Dynamic Analysis”. Just be sure to create an image beforehand so that you can restore.

STATIC CODE ANALYSIS

  • If sample is an executable (.exe, .scr, etc.), drag the specimen into PEstudio (You’ll need to have Internet “on” for that, not necessarily on your VM’s but on your isolated/dedicated laptop).
  • Note: If you aren’t sure if you’re dealing with a targeted attack, you don’t want to submit “publically” to any online analysis tools so as to keep your submissions on the down-low. Submitting just the hash will do so.
    • Review the “Indicators” section of PEstudio for signature hits – any hit in this section is a very strong sign of malicious code.
    • Review the “Imported Symbols” section of PEstudio, these are API calls that the code is instructed to use. There are certain API calls, that while not malicious on their own, are not used by legitimate applications and thus are ‘blacklisted’. This program will review those imports.
  • Review the “Strings” section of PEstudio, you may see the same API calls in “Imported Symbols” but you will also find interesting code (if not obfuscated or packed) that could lead you to IOCs (IP addresses, domain names, user names, commands, configuration files, install locations etc).
  • Review the “VirusTotal” results, if no sample has yet been submitted to VirusTotal and you don’t think the attack is targeted, submit. If targeted, do not submit to any crowd-sourced sites.
  • Save an XML report/export of the PEstudio analysis (optional).
  • Check for “packing” using tools such as:

DYNAMIC ANALYSIS

  • First things first: Take your initial snapshot before infection (so you can revert back).
  • Make a copy of your malware and save the original as your pristine master because once launched, the specimen will often delete itself and create another instance (with the same hash) at a different (dropped) location.
  • Windows7: C:\Users\<USER>\AppData\Local\Temp
  • WindowsXP: C:\Documents and Settings\<USER>\Application Data\Identities
  • C:\Documents and Settings\<USER>\Application Data
    • Detonate the malicious specimen by double-clicking, and let it run for about 2.5 minutes.
    • Pause ProcessExplorer.
    • Pause CaptureBAT by pressing ENTER and review what’s new.
    • Take your second RegShot SnapShot.
    • Hit “compare” and note differences.
    • Playback your Pcaps in Wireshark and you can also dump them into NetworkMiner:

http://www.netresec.com/?page=NetworkMiner

  • Suspend the VM and grab the vmem RAM for analysis.
  • After running the malware, you may be able to find an unpacked version at the root of “C”, for example.

PREPARE FINAL REPORT

  • Gather all of your infection attributes
  • Infection attributes are what they can have their IR team put into signatures to keep from happening again.
  • Determine the infection vector
  • Infection vector tells how it (or ultimately he/she) got onto the box e.g., email with malicious link or attachment.
  • Prepare your remediation recommendations.

GLOSSARY

Access:  The ability and means to communicate with or otherwise interact with a system, to use system resources to handle information, to gain knowledge of the information the system contains, or to control system components and functions.
Active Attack:  An actual assault perpetrated by an intentional threat source that attempts to alter a system, its resources, its data, or its operations.
Active Content:  Software that is able to automatically carry out or trigger actions without the explicit intervention of a user.
Advanced Persistent Threat (APT): An adversary that possesses sophisticated levels of expertise, and significant resources, which allow it to create opportunities to achieve its objectives by using multiple attack vectors.
Adversary:  An individual, group, organization, or government that conducts or has the intent to conduct detrimental activities.
Binary File – Binary files are usually thought of as being a sequence of bytes, which means the binary digits (bits) are grouped in eights.  Binary files typically contain bytes that are intended to be interpreted as something other than text characters. Compiled computer programs are typical examples; indeed, compiled applications (object files) are sometimes referred to, particularly by programmers, as binaries. But binary files can also mean that they contain images, sounds, compressed versions of other files, etc. — in short, any type of file content whatsoever.
“Bit-To-Bit” forensic image – An exact copy of digital media, in which every single bit is copied to the target media.  After the copy, the source and target are verified using a hash algorithm.
Command & Control (C2):  While botnets are often named after the malware that created them, multiple botnets typically use the same malware, but are operated by different entities.  A botnet’s originator (known as a “bot herder” or “bot master”) can control the group remotely, usually through IRC, and often for criminal purpose. That server is known as the Command-and-Control (C&C) server.
File Created – The date the file was “created” on the volume.  This does not change when working normally with a file, e.g. opening, closing, saving, or modifying the file.
File Last Accessed – The date the file was last accessed.  An access can be a move, an open, or any other simple access.  It can also be tripped by Anti-virus scanners, or Windows system processes.  Therefore caution has to be used when stating a “file was last accessed by user XXX” if there is only the “File Access” date in NTFS to work from.
File Modified – The date as shown by Windows there has been a change to the file itself, e.g. a notepad document has more data added to it, would trip the date it was modified.
File Signature – A file signature is a unique string of characters, often at the start of a file, which can be used to identify the file type. The file signature is not viewable through normal methods, but can be accessed and viewed using forensic software or other software designed to examine files a byte level
Forensically Sanitized – A forensically sanitized hard disk drive is a drive which has been completely written with 0 (zero) bytes to ensure that no residual data is present on the drive.
Forensic Write Block – A Write Block allows a forensic technician to acquire an image of a digital device without writing to the device that’s being acquired.  A Write Block does this by allowing read commands to pass, but by blocking write commands.
Hash/Checksum – A mathematical computation performed on a particular file or hard disk drive. This computation generates a unique string of alpha-numeric characters which can be used to identify files in computer forensics and computer programming.
Indicator of Compromise (IOC):  A breadcrumb, artifact or combination of expressions (simple, complex, or both), usually grouped together for the purposes of attribution.
Infection Attributes:  Elements which determine IOC’s and signatures.
Infection Vector:  Point of entry.
TTP (Tactics – or Tools, Techniques and Procedures):  Advanced detailed behavior surrounding an adversary.
Unallocated Space – Clusters of a media partition not in use for storing any active files.  They may contain pieces of files that were deleted from the file partition, but not removed from the physical disk.

 

Copyright © 2017 by Mary Ellen Kennel.  All Rights Reserved