Virtual Machines, like anything else in technology, can be used for bad

Virtual machines have always been one of the neatest aspects in computer technology.  My first exposure to a virtual machine was in a digital forensics courses I took at FLETC and I knew that this would be the coolest thing ever.  The coolness factor of being able to run one operating system (the virtual machine or VM) inside another operating system (the host) has not grown old for me especially because of the forensic and security implications that exist more so today than that day of first exposure.

It has been 10 years since I wrote the first of two papers on virtualization and forensics.  The first, “vmware as a forensic tool” and subsequentlyVirtual Forensics: A Discussion of Virtual Machines Related to Forensic Analysis”.  Some of the information has been outdated, but most of the information and certainly the concepts are still in play today.  I recommend looking at these two papers to get started on thinking about VMs as it relates to your cases.

Skip forward some years after those first papers; I began to find VM use occur more often on forensic cases in civil litigation matters.  In the majority of the cases, the VMs I found were not used to facilitate any malicious activity, but did result in longer examination time of each hard drive with VMs.  In one case of my cases, a single hard drive contained over 50 (yes, FIFTY) virtual machines and each one VM had multiple snapshots and practically all were being used with malicious intent.  After that case, I made sure to include virtual machine investigative information in two books I wrote (Placing the Suspect Behind the Keyboard and Hiding Behind the Keyboard) to make sure investigators consider VMs as a source of evidence.

There was a time when computer users, including criminal using computers, were oblivious to the amount of evidence a forensic analysis can recover.  Those days are virtually gone since most anyone with a computer knows for the most part, that a ‘deleted’ file can be recovered.  In addition, with Hollywood producing movies and TV shows showing forensic analysis of computers, common criminal knowledge now includes knowing about electronic evidence that is created on computers and forensics recovers it.  Every push of a button, click of a mouse, and click of a link litters the system with evidence.  The litter (creation/modification/access/deletion of files) is everywhere in the system, spread out among various locations from the registry to free space to system files, and most can be attributed to a user’s activity.  Getting rid of every bit of the electronic litter is practically impossible, even as certain amounts can be wiped securely.

However, with a VM, all of that electronic litter, aka evidence, is kept within one file that stores the virtual machine.  The user need only wipe that one file to destroy all the electronic litter and evidence that was created during the malicious activity.   The only evidence able to be found will be on the host, and usually that will just show a VM had been started.  The malicious activity/user activity…gone.    Going a step further, a VM booted to a Linux bootable OS (even to an .iso file), will have no evidence saved in the VM to begin with.

I am not discounting other important evidence, such as network logs, captured traffic, or the evidence that can be recovered on the host machine.  That is all good evidence too, but when the actual user activity is contained in a single file that can be wiped securely, digital forensics gets harder if not downright impossible.

A recent article I read on malicious use of VMs goes one-step further.  In the article (https://www.secureworks.com/blog/virtual-machines-used-to-hide-activity), an attempt to remotely start a VM inside a compromised system failed only because the compromised system was also a VM.  Considering that scenario, a hacker starting a VM on a compromised machine can effectively hide nearly all activity within that VM by subsequently wiping it after the hacker is finished.  Incident response just got harder.

Not only are virtual machines used to facilitate criminal activity, but can also be used as a tool to compromise systems.  One creative example of malicious VM use can be read here: https://www.helpnetsecurity.com/2016/08/18/compromising-linux-virtual-machines/  where virtual machines in the cloud can be used to attack another virtual machine if hosted on the same server.  Now that is clever.

Virtual machines are here to stay for all the good uses they provide, which also means they are here for all the bad uses too.  In the world of cyber-cop vs cyber-criminal, every day is another day where each side tries to out-MacGyver the other side with something new, unique, and sometimes pretty cool.

 

 

 

 

967 Hits

Mini-WinFE and XWF

Due to a dozen tragedies, a half dozen fires popping up, and twice as many projects due at the same time, I’ve been way late in updating an X-Ways Forensics course along with updating the WinFE.  But now, the X-Ways course is about done to be uploaded as soon as the finishing touches are finished.  The new course includes a whole lot more than originally made and updated to the current version of X-Ways (everyone currently registered will receive an email when  the course has been published (no cost to current registrants). 

The WinFE online course will be depreciated and replaced with a longer ‘Forensic Boot CD Course” that includes Linux forensic CDs along with some updated WinFE  information.  The goal of this course is to complete cover just about every aspect of using a forensic boot OS (CD/DVD/USB), with examples of the most currently updated Linux forensic CDs.  There are plenty of outdated distros to avoid and those are not described in the course.

Until the Forensic Boot CD Course is uploaded, you can download the Mini-WinFE builder from this link: http://brettshavers.cc/files/Mini-WinFE.2014.07.03.zip  as currently, the reboot.pro download link for Mini-WinFE is broken.  I have sent the developer a message to repair it.

1437 Hits

Compiling Identity in Cyber Investigations

Digital forensics analysis is the easy part of an investigation. That is not to say that the work of digital forensics is simple, but rather recovering electronic data is a rote routine of data carving and visual inspection of data. Interpreting the data requires a different type of effort to put together a story of what happened ‘on the computer’.  As important an analysis is to determine computer use, it is just as important to identify the user or users and attribute computer activity to each user.  An investigation without an identified suspect is a case that remains open and unsolved..sometimes for years or forever.

In many investigations (civil and criminal), identifying the computer user is obvious through confessions or by process of elimination.  Proving a specific person was at the keyboard is barely a consideration since the person either admitted control of the device or was caught red-handed and the examiner can focus more on the user activity on the computer devices rather than spending time identifying the user.

However, simply accepting the suspect’s identity without further investigation into other aspects of the suspect’s identity may sell the investigation short.  Whether the suspect is known or unknown, compiling a complete identity of the suspect adds important information that is beneficial to a case, such as motives, intentions, and identification of more crimes.  The most important point is that a physical person that has been identified, or even arrested, does not give a complete identity of that person.  It is only the physical identity.  Investigators should strive to compile a complete identity that includes digital identities.

So what’s in it for you?

Building a case against a suspect requires more than just finding evidence.  A case needs evidence to point to a suspect as well as showing motive and opportunity.  Providing evidence of every identified persona of a suspect paints a picture of the suspect, to include intent, desires, motive, behaviors, and overall character to add to the supporting evidence.  In short, you get a better case.

The Complete Identity

A physical identity (aka biometric identity) and digital identity comprises the complete identity of a person.  Biometrical features of a person, such as fingerprints and eye color, are bound to the physical identity and typically permanent to the person depending on the feature.  Although eye color can be temporarily changed with color contacts and hair can be temporarily dyed to a different color, the majority of physical features cannot be changed without drastic injury or surgery. 

Internet users create digital trails of use and subsequently (and without intention) create digital personas based on their unique computer use.  The normal, everyday use of the Internet creates a digital identity that is based on Internet surfing habits (the Websites visited), communications made online through forums, chats, e-mails, blog posts and comments, and through the accounts created for online services to include online shopping.

Compiling the digital identity and physical identity may seem like an obvious and easy task, but assembling the identities is not so simple.  In an ideal case, a suspect has a single physical identity and a single digital identity, but in reality, a person may have multiple physical personas tied to a single physical identity and multiple digital personas.  Some personas may be intentional while others unintentional.  For example, a criminal wanting to travel in a name other than his true name may create or purchase a fake driver’s license. As he goes about using the fake or stolen driver’s license, he creates a persona under the false name.  Although this persona is not truly a ‘physical’ identity, as it is not biometrically tied to a physical body, it is part of his physical identity as he uses the false name as if it were his true name. 

One example of a digital identity is the accumulation of normal Internet and computer use.  A person’s computer use is generally a reflection of that person’s personality, desires, and intentions.  The unique activity of one device is typically replicated across devices under that person’s control.  For instance, given a new computer, a user will configure it by personal preference by arranging icons, colors, sounds, and folder structure to save.  When the user has an additional computer, both computers will have a very similar order of computer activity when used over time and will even look the same, such as the placement of desktop icons and wallpaper choice.  Configurations of the computers will likely be similar, if not exact for some items, and Internet use will most certainly mirror each other by bookmarks and frequently visited Websites.  Merely comparing the type of computer use and configuration between two or more devices can give an indication that the same person used all of the devices. 

Adding to the complexity of finding both digital and physical identity of a suspect is that of multiple aspects of both types of identity.  A person leading a double life may have two spouses and two jobs with one being a false identity.  This person is physically tied to both identities, even if the false identity contains no true information.   Leading a double life is an extreme example of a fake physical identity, and examples that are more common include using a fake ID to make consumer purchases, or using fake names to register at hotels.  The depth of a fake physical identity depends upon the person’s intention and resources. Types of physical identifiers are seen in the following figure.

Digital identities, being far easier to create, generally mean that any one person can have multiple, or even hundreds, of fake digital identities.  A harassment suspect may have dozens of online identities that he uses to harass a single victim or victims through repeated e-mails from different e-mail accounts created to appear as different people.  In any investigation, treat each digital identity as its own identity that will be tied to a physical person at some point in the investigation.  Each identity gives information about a person based on the fake identity, whether the only information is the username of an e-mail or a completely falsified social networking account.

An example of having multiple digital identities is that of one fake identity used to create specific online accounts and a different fake identity used to create other specific online accounts.  In this manner, a person is simply trying to distance himself from something (such as registering for a pornographic Website) by using a fake digital identity while using a different fake identity to distance himself from other aspects of his online life.  An investigator who can identify the fake accounts adds to the case by showing the intentionally hidden aspects of a personality, motive, or intention of the real person based on the real person’s actions under the fake digital identities.  A pedophile whose physical identity has no ties to pedophilia may appear innocent until fake digital personas are found and tied to his physical identity.

Of note is that each person has a true physical identity and a true digital identity.  Typically, the true digital identity shows the real information, such as a real name, and is easily tied to the physical person.  However, every identity and persona (real and fake, digital and physical) should be compiled together to show the complete identity of a person.  False information is just as important as the true information to build a complete picture of a suspect.

A great example of tying a physical identity to a false persona is in the Silk Road case where the creator of Silk Road (Ross Ulbricht) used his public e-mail/forum (rThis email address is being protected from spambots. You need JavaScript enabled to view it.) account on the open Internet to market the Silk Road.  One simple post eventually tied his legitimate physical identity to a secret, false, and criminal persona on the Dark Web site, the Silk Road.

Identifying the digital identity becomes easier as Big Data continues to grow exponentially through massive data collection by government and corporations.  Social media sites contribute to identifying digital identities as the connectivity between sites exists through single usernames, using the same e-mail address across online accounts, and algorithms created to ‘find’ friends based on relationships and Internet use.  The digital identity is the sum of all electronic information of a person.  Corporations have been compiling digital identities of consumers in order to focus on advertising efforts.  Investigators should focus on compiling digital identities of suspects to determine motive and opportunity.

Any investigation benefits by compiling the complete identity of suspects.  Whether the identities contain true information about a suspect is not as relevant as tying the identities and personas to a person. Motives and intentions are clearer with a complete picture of a person in both the physical and digital worlds. 

Now that you know the ‘why’, become competent in the ‘how’ in each investigation with thorough research to find the connection between each identity in order to place your suspect at the keyboard.  Digital forensic skills are necessary and important, but solid cases usually need some old fashioned, gumshoe detective work too.

1266 Hits

The Secret to Becoming More-Than-Competent in Your Job

The Secret to Becoming More-Than-Competent in Your Job

I was part of an interesting and product online podcast today.   You can check it out at: http://nopskids.com/live/

The topics ranged from hacking, forensics, how to catch hackers, and a little on how criminals sometimes get away with it. Although I didn’t give any tips on how to get away with a crime, other than DON’T DO IT, I did speak a little on some of the things that can be found forensically on a hard drive.  Actually, I think I only had time to talk about one thing (the Windows registry) for a few minutes and nothing of which that has any impact on a criminal using the information to get away with a crime.

The one thing I wanted to stress that even if every top secret, secret squirrel, spy and investigative method was exposed, criminals would still get caught using the very techniques they know.  Proof in the pudding is seeing cops being arrested for committing crimes.  You’d figure they would be the most knowledgeable of not getting caught, but they get caught. Same with accountants being arrested for fraud, and so forth.  I’ve even arrested criminals when they had in their possession, books on how not to get caught.   The most diligent criminal can be identified and arrested by simple mistakes made and sometimes by sheer massive law enforcement resources put on a single case to find a criminal or take down an organization.

With that, I learned a few things from the podcast too.  One of the moderators was actually a case study in my latest book (Hiding Behind the Keyboard).  To be an expert, to be knowledgeable, and to be more than just competent requires talking, listening, and sharing.  That doesn’t mean sharing trade secrets or confidential information, but it does mean having conversations to learn your job better.

When I worked as a jailer, I talked to every person I booked (at least the sober arrestees and those cooperating with the booking process).  I asked personal questions like, “how did you get started with drug use?” and “how did you start doing X crime”?  I learned a lot after hundreds of bookings.  I learned so much that when I make it to patrol and hit the streets, I had a big leg up on the criminal world, in how it worked with people.  That directly helped me in undercover work.  I spoke to so many criminals, both as a police officer and as an undercover (where they didn’t know I was a police officer), that I learned how to investigate people who committed crimes.  I was darn effective.

The point of all this is that talking to “the other side” is not a terrible idea.  Working on the law enforcement side, I promise that if you have a conversation with a criminal defense expert, you will learn something to help win YOUR case.  If you talk to a hacker, you will learn something to help figure out YOUR cases.  The best part, like I said, nothing you give will make a criminal’s job easier.  In fact, anything you say will only make them worry and make more mistakes.

If you are more-than-competent, you can do your job like a magician.   My first undercover case was buying a gram of meth from a cold phone call of a guy I didn’t even have a name for.  As soon as we met, I recognized the meth dealer as someone I arrested a half dozen times when I was in patrol.   Luckily for me, he didn’t recognize me and believed my UC role.  Arrested, booked, and convicted.  This was a career criminal with dozens of arrests who probably met more cops that I ever did at that time.  Still, he was arrested, by me, because I was more-than-competent in my job.  Digital forensics work is no different.

Talk to everyone and share.  I promise you will get more than you give.  And there is no shame in learning that you don't know it all, because none of us do.

1106 Hits

Behind the Keyboard - Enfuse 2016 Presentation download

I had the amazing honor of speaking before a full room at Enfuse this week.  This was not only my first time speaking at Enfuse, it was my first time at Enfuse. The conference was put together well.  Kudos to poolside event coordinator.  Those who know my forensic tool choices also know that I do not use Encase as my primary forensic tool.  However, I have a license for v7 and have used Encase since v4 (with sporadic breaks of use and licensing).

This year at Enfuse, I did not speak on any forensic software (or hardware) at the conference. I gave a snippet of two recent books I published (Placing the Suspect Behind the Keyboard and Hiding Behind the Keyboard).  I say “snippet” because one hour is not even near enough time to talk about the investigative tips in the books.  I was able to give a few good tips that I hope someone will be able to take the bank and boost case work.   I could spend weeks talking about investigative methods of not only finding suspects that are using computers to facilitate crimes, but also to place them at a specific device with both forensic analysis and traditional investigative techniques.   

After my talk, I received emails from some who did not or could not attend my Enfuse talk; I am providing my slidedeck for them and others who may want to see high-level notes from the Powerpoint slides.  However, I removed a number of slides that had personally identifiable information to avoid any embarrassment from Google searches and cases.  I did not get to a few slides in the presentation due to time (only one hour!), and I removed them as well.   Nonetheless, the meat and potatoes of the presentation is in the below PDF.

  

 

A few toughts on digital forensic skill development and giving away investigative secrets

Forensic examiners/analysts generally follow the same path in skill development, with some exceptions of course.  For most of us, the tools are just plain neat and we initially focus on the tools.  High tech software and using the type of hardware that you cannot find at Frys turns work into play.  We dive into the box, swim around in it for days, weeks, or even months, and then we pull out every artifact we can to write a report of what happened ‘in the box’.  Writing a report usually means pushing the "Create Report" button. I suggest that every examiner go through this stage quickly and move forward.  Get it out of your system as soon as you can. There is more to digital forensics than the toys, I mean, tools.

Digital forensics investigators must investigate, unless your job is solely looking at data because someone else is investigating the case.  This is where leaving the stage of ‘playing with high-tech toys’ turns the new forensic examiner into a real digital forensics crime fighter.  When an examiner can integrate data recovered from ‘the box’ with information collected from ‘outside the box’, using any tool and investigative method available, we have a competent and effective digital forensics investigator, not just a tool user.

I have always believed that a good digital forensics investigator can practically use any software, as long as the software can do the job, without relying on the software to do the complete job.  Pushing a button to find evidence, then pushing another to print a report does not a forensic analysis make.  Just as Picasso could paint a masterpiece only using an old paintbrush and watercolors, a good forensic examiner can make a great case with only using a hex editor and gumshoe detective mindset.  The high-tech tools should be used to make the work easier and faster without becoming a crutch.

And that was the inspiration of why I wrote Placing the Suspect Behind the Keyboard and Hiding Behind the Keyboard, boiled down in two simple intentions:

1) To push forensic examiners out of the high-tech toy reliance into becoming a well-rounded, effective, efficient, and competent investigator.

2) As a reminder to the former investigator-turned-forensic-analyst to get back into the investigative mindset.

If you are currently in the ‘gotta-have-the-most-expensive-tools-on-the-planet’ stage while at the same time not working outside the CPU, don’t fret. It happens to most everyone, and not just in the digital forensics field.  When I was a young Marine, I went to the local army surplus store and base PX to buy every cool tool I could think that would help me in the field.  I had so many ‘tools’ that my ALICE pack looked like a Christmas tree dangling a five years' worth of trinkets from New Orleans’ Mardi Gras parades.  After one trip to the field, I realized how much money I wasted on unnecessary gear (if you could actually call some of those things I bought "gear"..) and focused on using only the things that work and making things work for me.  Digital forensics work is no different.  Consider yourself DFIR SEALTeam 6 once you can work a case using ANY computer and ANY tool.

Giving away trade secrets?

There is a long-standing problem in the digital forensics world: Sharing, or rather, lack of sharing.  Yes, experts and practitioners share their work, but many do not.  I completely understand why.  When you share your ideas and research to the public, there is a fear that the bad guys will see it and use it for their benefit.  The fear is that once the methods are known to the criminal world, the methods become ineffective.

In short, that thinking is incorrect.

First off, cybercriminals and criminals, in general, share information with each other.  They share the methods when they work together to commit crimes, they share it online,  and they share it during their stays in the big house.  Still, they get caught.  Still, they make mistakes. Still, the methods work against them.  I have even arrested drug dealers when they had in their possession, books on 'how not to get caught dealing drugs'.  Cybercrime is no different.  An entire website can be written on how to get away with crime on the Internet and read by every cybercriminal, and yet, they can still be identified, found, and arrested.  

Second, lack of sharing only hurts us all. If you were to find a better way to find evidence, but keep it to yourself, the entire community stagnates.  But when shared, we push ourselves ahead in skills.  Do not be afraid that the bad guys will get away with crimes if they know how you catch them.  Just as watching a Youtube video on Marine Corps boot camp does not make boot camp any easier, criminals that know how we place them behind a keyboard does not negate the process that can place a suspect behind a keyboard.  In fact, the more they know, the more chance they will slip up more than once out of sheer fear of how easy it is to put enough investigative resources to find a criminal that cannot be countered with any amount of preparation.  

1302 Hits

Reviewing a tech book technically makes you a peer reviewer…

    If you have been in the digital forensics world for more than a day, then you know about peer reviews of analysis reports.  If you have ‘only’ been doing IR work where forensics isn't the main point (as in taking evidence collection all the way to court), then you may not be reading reports of opposing experts.  Anyway, the opposing expert peer review is one of the scariest reviews of all since the reader, which is again, the opposing expert, tries to find holes in your work.  The peer review is so effective to push toward doing a good job that I think it prevents errors by the examiner more than it does help opposing experts find errors of the examiner.  Peer reviews take different shapes depending on where it is being done (review of a book draft, review of a report, etc...) but in general, a peer review is checking the accuracy of the written words.

    Academia has always been under the constant worry of peer reviews.  One professor's journal may be peer reviewed by dozens of other professors in the same field, with the end result being seen by the public, whether good or bad. Peer reviews are scary, not for the sake that you made a mistake, but that maybe you could have missed something important that someone else points out to you.

    If you read a tech book and write a review of it (formally in an essay/journal, or informally on social media), consider yourself a peer reviewer of tech writings.  That which you say, based on what you read, is a peer review of that material.  Think about that for a second.  If you are in the field of the book you are reviewing, you practically are tech reviewing that book for accuracy (so make sure you are correct!).  That is a good thing for you as it boosts your experience in the field.  Always be the expert on the stand who can say, “I’ve read x number of forensic books and have given x number peer reviews on social media, Amazon, essays, etc….”.  If for nothing else, this shows more than that you just read books.  You read for accuracy and give public review of your findings. Nice.

    There is some stress in writing a peer review because you have to be correct in your claims.  Sure, maybe some things in the book could have been done a different way, but was it the wrong way?  The manner in which you come across in a peer review is important too.  Crass and rude really doesn't make you look great on the stand if you slam a book or paper.  You can get the point across just as well by being professional.

    Writing books takes no back seat to peer review stress, especially when it comes to technical books.  Not only does the grammar get combed by reviewers, but the actual technical details get sliced and diced.  Was the information correct? Was it current and up-to-date?  Is there any other information that negates what was written in the book?

    So, to get any positive reviews makes for a good day.  Not for the sake of ego, but for the sake of having done it right so others can benefit from the information.  Writing is certainly not about making money as  much as it is putting yourself out there to share what you have learned at the risk of having your work examined under a microscope by an unhappy camper.

    b2ap3_thumbnail_HBTK.JPGWhich brings me to my latest reviews for Hiding Behind the Keyboard.  This is my third tech book (more to come in both nonfiction and fiction) and with each book, I have always cautiously looked at Amazon book reviews each time.  Not that I have written anything inaccurate, inappropriate, or misleading, but that I just want to have written something useful in a topic that I wish existed when I started out in the digital forensics field.  My best analogy of what it is like to write a book is to walk outside to your mailbox nude and then check Facebook to see what people say about you…then do it again.  At least I don't have a Facebook account...

    So far, the reviews for my latest book show that I did a good job (my gratitude to the reviewers).

And that brings me to another point of this post. 

    One of the social media reviewers is actually in a case study in the book.  Higinio Ochoa read and reviewed my book in a Tweet (as seen below).   

 

    You will have to check the Internet to get Hig’s story, or read it my book…  Suffice to say he was a hacker who was caught, and then ended up as one of the case studies in my book.  Positive reviews from forensic experts are great, but so are reviews from former hackers that can double-validate the work.  Like I said, it takes a lot of guts to write a book and almost as much guts to peer review it in public.  That’s what we are doing when we write a review of a tech book.  We are all peer reviewers.

 

677 Hits

Bio-hacked humans and digital forensic issues...

Bio-hacked humans and digital forensic issues...

If you thought The Grudge was the scariest thing you’ve seen on screen, you must have not yet watched Showtime’s ‘The Dark Net’.  In short, the series show how humans are procreating less and merging digitally into technology with bio-hacks. That makes for a bad combination on a few different levels.

Without getting into non-techical issues (such as moral, ethical, or legal), I have a technical question: How the heck are we going to going to do a forensic analysis of a bio-hacked…human?

Before the human race ends up looking like robots, we are already in the era of implanting electronic data devices in our bodies.  Check out http://dangerousthings.com to find how you too can jab an injection device into your hand and shoot a RFID under your skin…all by doing it yourself. As for me, I don't think I'll be joining in that movement anytime soon.

RFID (http://en.wikipedia.org/wiki/Radio-frequency_identification) tags store data. Data such as medical, financial, personal, or any type of information can be stored on a RFID tag, although the amount is quite limited currently (2-10 kilobytes?).  That's not much data, but depending on the content, it may be more than enough to cause a war or bankrupt a company.

But even at that low amount of storage, it can raise suspicions in theft of intellectual property, trade secrets, or national security information.  Imagine the use of implanted RFID chips by criminals, terrorists, and corporate spies to exfiltrate and transport sensitive data.  Just when you thought the MicroSD cards presented a threat because of their small sizes, the RFID is even an even bigger problem.  We can find a USB since we can see it. RFID chips implanted under the skin…not so easy.

b2ap3_thumbnail_implant.JPG

Now back to my first question of how we will be doing forensic analysis on a bio-hacked human. When the time arrives where humans are embedded with multiple types of technology and devices, where and how do we start the data acquisition process?   Depending on how much technology is embedded, where it is embedded, and what it is connected to, forensic imaging takes on a whole new world.  

And what if the person (or man-machine cyborg…) doesn’t want to be forensically analyzed? 

b2ap3_thumbnail_robocop.JPG

Maybe for imaging software, we can try Robocopy (looks like the software is already here….).

b2ap3_thumbnail_header.JPGb2ap3_thumbnail_robocopy.JPGhttp://sourceforge.net/projects/robocoprobocopy/

 

 

 

 

 

 

 

 

1375 Hits

Tech Talk Can Get You Lost in Lingo

Tech Talk Can Get You Lost in Lingo

    Every career and academic field has its own “lingo” to the extent that a conversation buried deep in lingo sounds like a foreign language. I have experienced military lingo, law enforcement lingo, and technical lingo in my life to the point that I practically dream in acronyms, speak with words not recognized by Webster’s Dictionary, and instantly recognize the glazed-over look when speaking to an non-native lingo listener.

                The reasons for individualized lingo range from the coolness factor such “oh dark thirty”  in order to express time as ‘really damn early’ to efficiency such as using “HMMWV” instead of saying “High Mobility Multi-purpose Wheeled Vehicle”.  Many acronyms are spoken as works when gives an added effect of the listener not having a clue of what you are talking about.  For example, “I’m going to pick up a hum-v” means “I’m going to pick up a high mobility multipurpose wheeled vehicle”. Even in law enforcement, the acronyms can irritate the most patient listener if they are not in the club.

b2ap3_thumbnail_hmmwv.JPG

                There are two situations where lingo can get you killed, or at least make you feel like you are getting killed. One is in court. The other in your writing.

                Getting killed in court by lingo as a witness is painful. In fact, I’ve seen witnesses get physically ill as if the roach coach burrito eaten at lunch has suddenly reached its final destination in all its glory. Getting beat up on the stand by an attorney or judge is so unpleasant, that time actually slows to a stop and you wonder why you even got up that morning. Using lingo on the stand can give you a bad case of ‘why did I say that?” when being cross examined.

                I talk about lingo today, because I recently experienced one of the best cases of using lingo in all the wrong ways in a federal district court.  I gave my testimony first as the defense expert in a class action lawsuit, and spoke as simply as I could to make sure the judge understood what I intended to say. Then the opposing expert was called. One of the attorneys asked her a question, she answered, but her answer was not only complicated, it was complex, full of lingo, and I even felt a sway of arrogance. I barely understood what she said and took notes to make sure I got correct what she said.

b2ap3_thumbnail_courtrooom.JPG

                Then the beating started. The judge asked her to repeat her answer. She did. Then the judge asked her the same question by rephrasing it and asked for a better explaination. The expert answered again but it sounded even more complex. After three more tries with increasing tension and the judge telling the witness that she does not understand the answer, the judge turned to me at the back of the courtroom and said, “Can you tell me what she is trying to say?”

                That is when I knew this cross country trip for court was worth the trip. I translated the opposing expert’s answer, the judge understood it, and the opposing expert said I was correct.  Boom. Lingo killed that day, but luckily it didn’t kill me.

                The other place where lingo can kill is in writing. I’ve written more police reports and affidavits for search warrants than I could ever count and the one thing I learned is to keep lingo out unless it is pertinent, relevant, and understandable. Jurors don’t get lingo and much of what they hear in the movies is incorrect or misused. Judges don’t like it either.  Don’t be the only person in the room that understands what you are saying…

In fiction books where computer technology is a key element or theme, using lingo without explanation is like using a foreign language to frustrate a reader. I say this because I just read an unnamed book that when I read it, I had to really slow down my reading in order to understand what was being described. I don’t like reading slow...which means I won’t finish reading it if I don’t have to.

It is one thing to use a technical term in a sentence, but there comes a point that when the majority of words in a sentence are acronyms and “words” not found in a dictionary, the reader becomes lost and frustrated. That’s not good. It’s not good for reports, testimony, or fiction writing. Nonfiction technical writing is a little different since generally, the reader of a technical writing is a technical person.  For those types of writing, give the definition once and move on since the audience is a technical reader audience. In the other types, even though you give the definition once, the reader/listener is going to forget by the time the uncommon word or acronym is used again. So be sparse in the lingo unless it really matters or that it is used so often, your reader won’t be frustrated trying to figure out what it means.

I’ve given a few talks of putting ‘cybercrime’ into writing for fiction authors who are not computer experts.  Some of the talk is showing what forensics look like (hint: it’s not like what you see in James Bond…) as well as how to use technical terms without turning off the reader or sounding like you don’t know what you are talking about. For me, when I read, I just want to read without having to say to myself, “Excuse me, that’s not how Tor works…”.

Remember, lingo kills.

1920 Hits

The best part of writing a book is finishing the book.

The best part of writing a book is finishing the book.

I choose the title of my latest book (Hiding Behind the Keyboard) to be provocative, although the book may not completely be what you would expect if you think that it is a manual to hide yourself on the Internet. Being from Syngress, this is technically a technical book in that it discusses how to uncover covert communications using forensic analysis and traditional investigative methods.

The targeted audience is those charged with finding the secret (and sometimes encrypted) communications of criminals and terrorists.  Whether the communications are conducted through e-mail, chat, forums, or electronic dead drops, there are methods to find the communications to identify and prevent crimes.

For the investigators, before you get uptight that the book gives away secrets, keep in mind that no matter how many “secrets” are known by criminals or terrorists, you can still catch them using the same methods regardless of how much effort criminals put into not getting caught.

As one example, one of the cases I had years ago as a narcotic detective was an anonymous complaint of a large, indoor marijuana grow operation.  Two plainclothes detectives and I knocked on the door and politely asked for consent to search the home for a marijuana grow.  I told the owner that he didn’t have to give consent, or let us in, and could refuse consent at any time.  He gave consent and we found hundreds of marijuana plants growing in the house.  The point of this story was that on a table near the front door, was a book on how to grow marijuana that was opened to the page that said “when the cops come to your door for consent, say NO!”.  He had the book that advised not to do what he did anyway.

The point being, even when knowing how to commit crimes, criminals are still caught and terrorist plots are still stopped. The more important aspect is that investigators need to know as much as they can and this requires training, education, and books like Placing the Suspect Behind the Keyboard and Hiding Behind the Keyboard.

I had help with this book with early reviews, suggestions, recommendations, and co-authoring.  Most of what is in the book, I’ve done or helped others do. Some things work sometimes, other things work other times, and nothing works all the time. But having a toolbox to choose from gives you choices of methods that can fit individual cases.

As a side note, many of the methods can work in civil litigation depending upon cooperation and legal authority. For example, use of the Tor browser in a corporate espionage or employee IP theft case can make a huge difference in the direction a forensic analysis takes.

For anyone going to Las Vegas for the Enfuse conference, I’ll be presenting on this book and look forward to meeting you there (please say hi).

You can order Hiding Behind the Keyboard here:

1249 Hits

RegRipper

RegRipper

The short story-if you want RegRipper, get it from GitHub (don't download it from anywhere else)

http://github.com/keydet89

 

What is RegRipper?

RegRipper was created and maintained by Harlan Carvey.  RegRipper, written in Perl, is the fastest, easiest, and best tool for registry analysis in forensics examinations.  RegRipper has been downloaded over 5000 times and used by examiners everywhere.

How can you make it better?

If you want RegRipper to be better, you can help by first sending in registry hives with specific information of what you need RegRipper to do with that hive to Harlan Carvey.  Is it a P2P application of interest?  Or USB devices? Or…?

What is the RegRipper?
RegRipper is *not*…it’s not a Registry Viewer.  An examiner would not open a Registry hive file in RegRipper to “look around”.

Further, RegRipper is NOT intended for use with live hive files.  Hive files need to be extracted from a case (or from a live system using FTK Imager…), or accessible via a tool such as Mount Image Pro or F-Response.

RegRipper is a Windows Registry data extraction and correlation tool. RegRipper uses plugins (similar to Nessus) to access specific Registry hive files in order to access and extract specific keys, values, and data, and does so by bypassing the Win32API.

How does RegRipper work?
RegRipper uses James McFarlane’s Parse::Win32Registry module to access a Windows Registry hive file in an object-oriented manner, bypassing the Win32API.  This module is used to locate and access Registry key nodes within the hive file, as well as value nodes and their data.  When accessing a key node, the LastWrite time is retrieved, parsed and translated into something the examiner can understand.  Data is retrieved in much the same manner…if necessary, the plugin that retrieves the data will also perform translation of that data into something readable.

Who should/can use RegRipper?
Anyone who wants to perform Windows Registry hive file analysis.  This tool is specifically intended for Windows 2000, XP, and 2003 hive files (there has been limited testing on Vista/Win2K8 hive files…everything has worked fine so far…).

How do I use RegRipper?
Simply launch rr.exe.  Also, please be sure to read the RegRipper documentation.

Do I have to install anything to use the RegRipper?
Nope, not a thing.  RegRipper ships as an EXE file, able to run on Windows systems.  All you need to do is extract the EXE and DLL in the same directory. The source file (rr.pl) is also included, as are the plugins.

Further, RegRipper doesn’t make any changes to your analysis system…no Registry entries are made, nor are any files installed in odd, out-of-the-way locations.

HC

—————————————————————

RipXP

Installing
RipXP uses all of the same plugins available with RegRipper, so simply extract the files in this archive into the same directory with RegRipper (rr.exe) and rip (rip.exe).

Running
1. Using your tool-of-choice (I use FTK Imager), open the image and extract the hive files you’re interested in from the system32\config directory, as well as from user profile(s), into a directory (ie, D:\cases\case001\xp\config).

2. Using that same tool, within the image navigate to the directory where the Restore Point directories are located (usually C:\System Volume Information\{GUID}\). Extract all of the RP* directories into a directory on your analysis system (ie, D:\cases\case001\xp\restore).

3. To see the options used by RipXP, simply type:
C:\ripXP>ripxp

RipXP allows you to run one plugin across a designated hive file, and all corresponding hive files in the Restore Point directories.

C:\ripXP>ripxp -r d:\case\config\ntuser.dat -d d:\case\restore -p userassist

——————————————————————————

RegRipper is an open source tool, written in Perl, for extracting/parsing information (keys, values, data) from the Registry and presenting it for analysis.

RegRipper consists of two basic tools, both of which provide similar capability. TheRegRipper GUI allows the analyst to select a hive to parse, an output file for the results, and a profile (list of plugins) to run against the hive. When the analyst launches the tool against the hive, the results go to the file that the analyst designated. If the analyst chooses to parse the System hive, they might also choose to send the results to system.txt. The GUI tool will also create a log of it’s activity in the same directory as the output file, using the same file name but using the .log extension (i.e., if the output is written to system.txt, the log will be written to system.log).

RegRipper also includes a command line (CLI) tool called rip. Rip can be pointed against to a hive and can run either a profile (a list of plugins) or an individual plugin against that hive, with the results being sent to STDOUT. Rip can be included in batch files, using the redirection operators to send the output to a file. Rip does not write a log of it’s activity.

RegRipper is similar to tools such as Nessus, in that the application itself is simply an engine that runs plugins. The plugins are individual Perl scripts that each perform a specific function. Plugins can locate specific keys, and list all subkeys, as well as values and data, or they can locate specific values. Plugins are extremely valuable in the sense that they can be written to parse data in a manner that is useful to individual analysts.

Note: Plugins also serve as a means of retaining corporate knowledge, in that an analyst finds something, creates a plugin, and adds that plugin to a repository that other analysts can access. When the plugin is shared, this has the effect of being a force multiplier, in that all analysts know have access to the knowledge and experience of one analyst. In addition, plugins remain long after analysts leave an organization, allowing for retention of knowledge.

The use and function of RegRipper is discussed in great detail in the book, Windows Registry Forensics.

How do I..

…install RegRipper?

Go to the download site for RegRipper and get the archive that contains the most recent version of RegRipper (in this case, rrv2.5.zip). Extract the archive into a directory on your system, such as “C:\rr”.

Next get the latest plugin archive, based on the date of the archive, and extract everything in the archive into “C:\rr\plugins”.

That’s it…you’re done. Either launch rr.exe (the GUI) or run rip.exe (CLI) from the command prompt.

…get a list of all plugins?

This is actually pretty straight-forward. To list all of the plugins in the \plugins folder, simply open a command prompt, navigate to the folder where you installed RegRipper, and type:

rip -l

Another way to see what plugins are available is to launch the Plugin Browser (pb.exe), and navigate through the list of plugins, one at a time. In order to get a .csv listing of the available plugins, use this command:

rip -l -c > plugins.csv

You can then open the resulting file in Excel.

In order to get just a listing of plugins available for a particular hive file (in this case, the Software hive), type:

rip -l -c | find ",Software" /i

Does RegRipper do…?

Perhaps one of the biggest misconceptions regarding the RegRipper plugins is whether or not it does specific things; that is, does it check for specific values, parse specific data, or enumerate the contents of specific keys? This isn’t the right question to ask.

From the beginning, RegRipper plugins have been created and updated based on needs. Some needs are relatively easy to meet, due to the availability of data; most Windows systems have a ‘Run’ key. Other plugins have been created/modified due to unique circumstances based on analysis; finding something new or unusual during an examination will very often result in a new plugin, or an update to an existing plugin.

Of those currently writing plugins, it appears that few have encountered systems on which the P2P application Ares has been installed and used. As such, the ares.pl plugin may be somewhat limited and not meet the complete needs of a specific examiner working on a specific case.

In short, the power of RegRipper is in the plugins, and for this to be a truly powerful tool, it depends on examiners sharing their needs and data before hand, rather than asking, “Does it do…?” after the fact.

If you have any suggestions, recommendations, or questions about RegRipper, just ask Harlan.  Don't be afraid. Don't post all over the Internet that RegRipper doesn't do what you thought it would or is defective.  Ask Harlan. http://windowsir.blogspot.com

This email address is being protected from spambots. You need JavaScript enabled to view it.

 

ASEPs

Auto-Start Extensibility Points (ASEPs) checked by RegRipper's plug-ins

Details

Run Keys

Software Hive Run keys

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

• HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices

• HKLM\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

• soft_run plugin

NTUSER.DAT Hive Run keys

• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run

• HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run

• HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

• HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce

• HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce

• HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

• HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

o Run and Load values

• user_run plugin

System Services

• HKLM\System\CurrentControlSet\Services

o services plugin (list services by last write times)

o svcdll plugin (list services with ServiceDLL values)

o svc plugin to (list services and drivers by last write times)

o svc_plus plugin (short format with warnings for type mismatches)

o svc2 plugin (csv output)

• Legacy registry keys located at HKLM\System\CurrentControlSet\Enum Root

o legacy plugin

Software Registry Hive ASEPs

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

o winlogon plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

o winlogon plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman

o winlogon plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\System

o winlogon plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify

o winlogon plugin

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

o winlogon plugin

• HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components

o installedcomp plugin

• HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components

o installedcomp plugin

• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks

o shellexec plugin

• HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks

o shellexec plugin

• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects

o bho plugin

• HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects

o bho plugin

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32

o drivers32 plugin

• HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32

o drivers32 plugin

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

o imagefile plugin

• HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

o imagefile plugin

• HKLM\SOFTWARE\Classes\Exefile\Shell\Open\Command\(Default)

o cmd_shell plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls

o appinitdlls and init_dlls plugins

• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls

o appinitdlls plugins

• HKLM\SOFTWARE\Microsoft\SchedulingAgent

o schedagent plugin

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved

o shellext plugin

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost

o svchost plugin

System Registry Hive ASEPs

• HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls

o appcertdlls plugin

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SecurityProviders

o securityproviders plugin

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages

o lsa_packages plugin

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages

o lsa_packages plugin

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages

o lsa_packages plugin

• HKLM\SYSTEM\ControlSet00.$current.\Control\Session Manager\CWDIllegalInDllSearch

o dllsearch plugin

• HKLM\SYSTEM\ControlSet00.$current.\Control\SafeBoot

o safeboot plugin

NTUSER.DAT Registry Hive ASEPs

• HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

o winlogon_u plugin

• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load

o load plugin

• HKCU\Software\Microsoft\Command Processor\Autorun

o cmdproc plugin

UsrClass.dat Registry Hive ASEPs

• HKCU\Classes\Exefile\Shell\Open\Command\(Default)

o cmd_shell_u plugin

This section presents and discusses a list of artifact categories, as they relate to the RegRipper tools and plugins. As they are defined or described (see below), each of these categories applies specifically to artifacts found within the Windows Registry.

Many of the available Registry artifacts persist beyond file and program deletion, providing indications of system or user activity that occurred in the past.

Many artifacts can and may fall within multiple categories. For example, the File Access category by extension indicates Program Execution.

Multiple categories of artifacts can be used in analysis though the use of an analysis matrix.

Categories are identified within plugins as part of the configuration hash (%config) provided as part of the plugin. The use of categories in this manner does not obviate the use of profiles within RegRipper; instead, it enhances that capability.

Note: This should be considered to be a living document, subject to update and modification.

Category Definitions

What follows are some of the categories that have been identified, along with descriptions of each of the categories.

Where applicable, examples of available RegRipper plugins are provided.

OS Info

Basic OS information, such as version, installation date, install source path, time zone information, etc.

Example plugins: winver.pl, compname.pl

User Account Info

Basic user account information.

Example plugins: samparse.pl, profilelist.pl

Network Configuration

Artifacts associated with the network configuration of the system.

Example plugins: compname.pl, networklist.pl

AutoStart

Registry artifacts associated with the autostart of applications and programs (those programs/applications that are launched with no interaction from the user or system).

This category can overlap with and include some of the same artifacts as those from the Program Execution category.

Example plugins: services.pl, legacy.pl

Program Execution

Artifacts that relate to or indicate that programs were executed.

Example plugins: appcompatcache.pl, direct.pl, sysinternals.pl, muicache.pl, userassist.pl

Installed Programs

Installed Programs artifacts differ from Program Execution artifacts, in that many applications/programs are installed on a Windows system via a setup.exe file, or via an MSI file. As such, the program itself has artifacts in the Software hive, and then user-specific artifacts "live" in the user's NTUSER.DAT hive.

An example of this includes Adobe Reader; the Software hive will contain information about the system-wide application configuration, while the NTUSER.DAT hives will indicate not only which user(s) launched the application, but also maintain an MRU list of files that the user accessed.

Note: A program or application can be installed, but may not have been executed.

Example plugins: apppaths.pl

Storage Information

This category pertains to the usage of or access to storage media, including (but not limited to) USB devices, network shares, "cloud" storage, etc.

Example plugins:

Log Info

This category pertains to artifacts related to the configuration of log files on the system, which can include Windows Event Logs, as well as application specific logs.

Example plugins:

Malware

This category pertains to artifacts that specifically provide indications of malware infection or activity. This category differs from the AutoStart category, in that legitimate applications can make use of AutoStart artifacts. In many instances, the AutoStarts or Program Execution categories can be used to extract general information (i.e., contents of the Run key, etc.) that the analyst can review, plugins in the Malware category can be used to look for specific artifacts related to a variety of specific malware samples, or related to malware families.

Examples of a malware specific artifacts include:

  • Variants of Zeus have been known to add "sdra64.exe" to the UserInit Registry value
  • OSVerion

Example plugins: osversion.pl, zeus.pl

File Access

This category pertains to files that a user has accessed, which is most often through the use of a specific application. As such, artifacts within this category will indicate Program Execution (or usage), but the purpose of this category is to provide indications of files that a user specifically had access to, via downloading, or through creation or modification.

Example plugins: recentdocs.pl, trustrecords.pl

Communications

This category can be a subset of the Installed Programs and Program Execution categories, and is specific to programs/applications intended for off-system communications. While the Program Execution category may be used to look for indications of the use of ftp.exe or chat programs, this category is intended for communication application-specific artifacts.

Example plugins:

Analysis Matrix

The above listed categories can be used in an analysis matrix; several categories of artifacts may be used in specific types of analysis activities.

The following table is a notional analysis matrix, and is intended to serve as a starting point for both discussion and analysis:

  Malware Detection Data Exfil Unauth Use Illicit Images
Program Execution X     X
Malware X     X
File Access   X   X
Storage Info   X   X
Comms X X    

 

Tool Architecture  

RegRipper is actually a suite of tools that all rely on a core set of functionality.

Helper Functions

The main user interface (UI) tools for RegRipper (ie, the RegRipper GUI and the rip CLI tools) provide a number of functions to the plugins. These functions are included in a separate .pl file, and are accessed by the UI code via the require pragma (allows the code to be loaded at run-time). This allows for the following:

  • The one set of code is available to the UI tools in a uniform manner.
  • The helper function code can updated and made available without requiring the tools themselves to be completely recompiled.
  • The code is completely transparent; anyone can open the helper files and see what the code is doing.

Note: In order to make the code portable and usable by the widest range of users, any modules required to use the helper functions (ie, Time::Local) will be compiled into the UI.

Time

This secton is about how time is treated on Windows systems, as well as the various time formats found on Windows systems.

Formats

Time in recorded in a number of formats on Windows systems. Even though MS maintains a page that discusses time formats, there are other formats available, as well.

Unix Time

Unix epoch time - yes, there are time values recorded on Windows systems in the 32-bit Unix epoch time format, which is the number of seconds since midnight UTC, 1 Jan 1970.

This time format has a granularity of 1 second.

This time format is found in Windows XP/2003 Event Log records, as well as some Registry value data.

To convert this time format to something readable, use the built-in gmtime() function.

DOSDateTime

DOSDateTime - Date and time format encoded in two 16-bit values. Used as part of the shell item format specification, described by Joachim Metz. Shell item ID lists appear in the Shell\BagsMRU Registry values, as well as part of the MS-SHLLINK binary format for Windows shortcut files.

This time format has a granularity of 2 seconds.

Python code for translating the DOSDateTime values into something readable can be found as part of the libforensics package.

Perl code (note: requires the Time::Local module to translate to a Unix epoch time):

sub convertDOSDate {
  my $date = shift;
  my $time = shift;
  if ($date == 0x00 || $time == 0x00){
    return 0;
  }
  else {
    my $sec = ($time & 0x1f) * 2;
    $sec = "0".$sec if (length($sec) == 1);
    my $min = ($time & 0x7e0) >> 5;
    $min = "0".$min if (length($min) == 1);
    my $hr  = ($time & 0xF800) >> 11;
    $hr = "0".$hr if (length($hr) == 1);
    my $day = ($date & 0x1f);
    $day = "0".$day if (length($day) == 1);
    my $mon = ($date & 0x1e0) >> 5;
    $mon = "0".$mon if (length($mon) == 1);
    my $yr  = (($date & 0xfe00) >> 9) + 1980;
    return "$yr-$mon-$day $hr:$min:$sec";
#   return gmtime(timegm($sec,$min,$hr,$day,($mon - 1),$yr));
  }
}

UUID

UUID - Windows systems maintain volume GUIDs, particularly those associated with volumes beneath the MountedDevices and MountPoints2 keys, in UUIDv1 format. Part of this format specification includes a 60-bit time value, which indicates the number of 100-nanosecond intervals since 15 Oct 1582 (this date is described in the RFC as the date of Gregorian reform to the Christian calendar).

This time format has a granularity of 100 nanoseconds.

Note: This format also includes a "node" value, which for several of the volume GUIDs is a MAC address that was available on the Windows system at the time that the GUID was generated.

FILETIME

FILETIME - A 64-bit time value representing the number of 100-nanosecond intervals since midnight UTC, 1 Jan 1601. Used pervasively throughout Windows systems, and can be found:

  • $STANDARD_INFORMATION and $FILE_NAME attributes within MFT records
  • Registry key properties
  • Registry value data

This time format has a granularity of 100 nanoseconds.

Perl code for translating a FILETIME object into a Unix epoch time (borrowed from Andreas Schuster):

#-------------------------------------------------------------
# getTime()
# Translate FILETIME object (2 DWORDS) to Unix time, to be passed
# to gmtime() or localtime()
#-------------------------------------------------------------
sub getTime($$) {
  my $lo = shift;
  my $hi = shift;
  my $t;

  if ($lo == 0 && $hi == 0) {
    $t = 0;
  } else {
    $lo -= 0xd53e8000;
    $hi -= 0x019db1de;
    $t = int($hi*429.4967296 + $lo/1e7);
  };
  $t = 0 if ($t < 0);
  return $t;
}

SYSTEMTIME

SYSTEMTIME - 128-bit format, and according to MS, "The time is either in coordinated universal time (UTC) or local time, depending on the function that is being called." This time format is used in a number of artifacts on Windows systems, including (but not limited to) in XP Scheduled Task/.job files, as well as in value data beneath the Vista/Win7 NetworkList key (within the Software hive).

It is important to note that this value can be stored in the Registry in either UTC or localtime format. Beneath the NetworkList key, for example, the value is stored in localtime format.

This time format has a granularity of 1 millisecond.

Example Perl code to parse this date format appears as follows:

sub parseDate128 {
  my $date = $_[0];
  my @months = ("Jan","Feb","Mar","Apr","May","Jun","Jul",
                      "Aug","Sep","Oct","Nov","Dec");
  my @days = ("Sun","Mon","Tue","Wed","Thu","Fri","Sat");
  my ($yr,$mon,$dow,$dom,$hr,$min,$sec,$ms) = unpack("v*",$date);
  $hr = "0".$hr if ($hr < 10);
  $min = "0".$min if ($min < 10);
  $sec = "0".$sec if ($sec < 10);
  my $str = $days[$dow]." ".$months[$mon - 1]." ".$dom."
     ".$hr.":".$min.":".$sec." ".$yr;
  return $str;
}

Strings

Strings - Date and time values may be stored in Registry value data in string format; ie, "2011-06-07" or "1/2/2011". This is often found in Registry values in specific applications.

To convert data stored in this format to a Unix epoch time, parse the strings and use the Time::Local module to convert the information.

File System Tunneling

MS KB172190 describes file system tunneling, which can have a significant impact on your analysis.

Links

MS KB299648: Description of NTFS date and time stamps

MS: File Times

MS KB188768: Working with the FILETIME structure

MS: SYSTEMTIME structure

MS: DosDateTimetoFileTime function

Software Sleuthing: DateTime formats and conversions

Old New Thing Blog: DateTime formats and conversions

Shellbags

MS KB 813711 describes what actions cause data to be added to the Shell Bags values.

The structure of shell items is very important to understand, as these structures are used in multiple locations on Windows systems, not just in the Shell BagMRU subkeys within the Registry. For example, the structures are used in the shell item ID list section in Windows shortcut LNK files, as well as within the LNK streams in .automaticDestinations-ms Jump List files on Windows 7. These structures are also used within the data of values beneath the OpenSavePidlMRU keys within the Windows 7 NTUSER.DAT hives (full path is "HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU").

As such, being able to recognize and parse these structures is essential to being able to fully understand the data that you're looking at, and what it's telling you.

GUIDs

The Variable type (type == 0x00) data structures can contain a variety of information, in various formats. One of the data structures, in particular, can be seen (when viewed in hex) to contain "1SPS" in several places. If the data is broken up, using "1SPS" as a separator (ie, via Perl's split() function), the first 16 bytes of each section appears to be a GUID.

One GUID in particular appears as follows:

{B725F130-47EF-101A-A5F1-02608C9EEBAC} - Ref: Schema (Windows)

Apparently, this GUID applies to both desktop and Metro-style (Win8) apps, and is referred to as both a SHCOLUMNID and a PROPERTYKEY structure. The contents of the subsection of data that begins with this GUID can be further parsed using a distinct set of rules.

References

MS: Canonical Names of Control Panel Items

MS: Known Folder GUIDs

MS: KnownFolderID

Links

Joachim Metz's Windows Shell Item format specification paper (PDF)

ShellBagMRU.py, part of Registry Decoder (written by Kevin Moore)

Willi Ballenthin's Windows Shellbag Forensics

Alerts

The purpose of adding alerts (or an alerting function, via alertMsg()) is to provide a facility for identifying items of interest (from previous analyses) within the vast wealth of data available within a Windows system, and in particular the Registry. This allows an analyst to identify "low-hanging fruit" that may be of value to an examination.

This page will serve as a facility for collaboration amongst the admins of this site, to add, revise, and hone the information alerted on within various plugins.

Plugins

Many plugins provide path information that can be searched via grep() for specific indicators of suspicious or malicious activity:

  • appcompatcache.pl
  • userassist.pl
  • service.pl - also, added Beth S.'s checks from svc_plus.pl to the services.pl plugin

Note: To avoid issues with case sensitivity, process the path through the lc() function first, and then grep for the lower-case string of interest.

Paths

Below are some paths to check for:

  • Recycle
  • GlobalRoot
  • System Volume Information
  • App + Data (gets "Application Data", and "AppData")
  • Temp
  • ADSs - split() the path, check the final element for a colon

Example Code:

my @vals = ("Recycle","GLOBALROOT","System Volume Information", "Temp",
  "Application Data","AppData");

foreach my $v (@vals) {
  ::alertMsg("ALERT: ".$v." found in path: ".$_) if (grep(/lc($v)/,lc($_));
}

Example ADS Check:

my @vals = split(/\\/,$_);

my $int = scalar(@vals) - 1;

::alertMsg("ALERT: Possible ADS found: ".$_) if (grep(/:/,$vals[$int]));

Other Checks

 

  • appinitdlls.pl - generate an alert if the value is NOT blank
  • imagefile.pl - generate an alert if a Debugger value is found
  • attachmgr.pl - generate an alert based on MS KB 883260
  • winlogon.pl - generate several alerts; UserInit value with multiple entries, 'TaskMan', 'System, 'load' or 'run' values found, etc.

Checking for Encryption

 

  • MountedDevices key - check value data for "TrueCryptVolume"; access to a TrueCrypt volume often results in a volume GUID within the MountedDevices key that includes "TrueCryptVolumeN" in the data (with N being a volume letter)
11702 Hits