Finding Evidence of Data Exfil – USBStor artefacts

Readers!

Last year one of the member on SANS DFIR posted a question with regards to identifying whether there was any data leakage occurred in the environment via a USB thumb drive. As for the evidence investigator had USBStor artefacts. Shell bag analysis(TZ Works sbag) showed a large number of files touched (reg-UTC) within a very short time period and a few with the MRU (Most recently used list) flag set with different times.

This blog is a concise article of the tips provided by myself and other members. Provided tips assisted the investigator to support the theory of data leakage.

  1. Evaluating USB dates as a group.  If any number of artefacts is detected with the same exact time stamp, investigate it further. Having such artefacts indicates that they were somehow modified. It is also, worth the effort to carve the data for deleted registry files and look for relevant keys there.
  2. Normal users will/may access the files again after copying to any removable media to make sure the files were copied correctly and are not corrupted. This operation leaves shell items in the form of shell bags and link (.lnk) files. One can use Windows Time Rule to for evidence of file copy. Using the time rule examine the link files with target data pointing to files on removable media (tz works ‘lp’ is excellent for this). If the modified date of the target file data in the link file precedes the created date of the target file data in the link file, then this is an indication that the file was opened from the removable media, after the file was copied to the removable media. This means that even without access to the removable media, you can state that files were copied to the removable media and then they were opened from the removable media. The created date of the target data in the link file is when the file was copied to the removable media. One can state that the files were copied, but cannot state where the file was copied from, as that is not tracked.
  3. Now to determine when the file was opened from the removable media, look at the times of the link file itself. The created date of the link files will be the first time the file was opened and the modified date of the link file will be last time the file was opened. To discover the removable media, locate the volume serial number of the removable media’s file system which will be stored in the link file’s data. Correlate the volume serial number to the data from your USB drive analysis and you will get the manufacturers unique serial number for that removable media. Find that unique serial number across your enterprise and you will discover other machines where that drive was connected to. Correlate the link file target data to the shell bag data and you should be able to get a neat timeline of what happened on the system.
  4. Memory analysis of the system can assist. If the files were copied it should have data on the clipboard. Drag and drop will not likely have any artefacts.
  5. Registry hives –  one can use FTK registry viewer for ease. Usbstor have last written values – dates when the last device was accessed or connected.
  6. Look at the recent files in Windows section. Although if one is not able to open the file it may show which file from which volume – it may not prove that file was copied however if the document name is ‘organisationconfidential‘ than you can argue what was the file doing on USB? The link files should also contain volume serial that one can match/compare with removable media serials.
  7. Registry restore points can also be used to check last written dates.
  8. Look at the MFT records – they have sourceMFT and destinationMFT.

Tools mentioned : SBE – Shellbag Explorer and MFTparser

Links mentioned :

Click to access PlumbingtheDepthsShellBagsEricZimmerman.pdf

 

Hash Values – A Trivial Artefact

Readers!

Merry Christmas and Happy new year to all. The days of holiday spam and vendor predictions are here.

Here I am spending summer afternoon watching TV and writing on my blog. As I am bit lazy during holidays I am posting something simple. The post is about HASH values and how trivial they are in identifying malicious files/programs.

You can read about Hash here.

Hash values are important to first verify the files. Think of it as a signature or footprint. As living beings has a signature or footprint that we can recognise them from, similarly files  have something called digital footprint that we can identify them from.

Take example of HashCalculator. Following screenshot shows different hash values of HashCalc.exe.

hashcalc

As you can see HashCalc provides lot of information (digital footprint) of its own. With regards to security the hashes are normally used to verify the file as mentioned earlier. Let’s look at the output in brief for commonly used hash values :

  • MD5 – Based on Message Digest algorithm. Normally represent as 32 hexadecimal digits. Vulnerable to collision attacks. Read further here.
  • SHA-1 – Secure Hash Algorithm 1. Represented as 40 digit hexadecimal digits. Generates 160 bits message digest. Vulnerable to collision attacks. No longer in use and has been replaced by SHA-2 and SHA-3. Read further here.
  • SHA-256 – Secure Hash Algorithm 2. Represented as 64 digit hexadecimal digits. Generates six digests – SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Read further here.

Now, why the blog entry. The information is available on google and Wikipedia. Reason for the blog is Hash values are considered trivial/important in Threat Intelligence and/or cyber security world. Lots of OSINT, vendor intelligence systems share hash values of known malware dropper. This could be an executable, MS office document, Adobe document, image files etc.

Following are few scenarios where Hash values can assist :

  • Hash values can assist in identifying whether the file/program that we have is legitimate or not.
  • Lot of malware analysis blogs will always provide Hash value of identified file/program.
  • The Hash value is also used by Endpoint solutions to detect known malicious files/programs.
  • During Incident Response, one can also use Hash values in YARA rules to detect any malicious files/programs.
  • Organisations can have a list of program with the Hash values of known good  and authorised programs in their organisation, which than can be used to identify any unwanted programs on the system, either via endpoint for real time detection and/or during incident resposne. Benchmarking/Baselining is a complicated process and sometimes not feasible in large organisations.

NIST provides list of known good hash values of legitimate programs, that one can use to compare good vs bad. Read here.

Hash values are just another indicator that gives more targeted detection of malicious files/programs. IP address and URLs are dynamic, not 100% reliable and have low confidence level as a Threat Indicator and therefore Hash values is considered important artefact in Security world.

Happy Holidays!

 

Forensics – Where to start and What to know

Readers

I would like to share my experience and understanding with regards to forensics and where I started to get a foothold in forensics.

Questions that I normally get : I want to get into forensics. What should I study? What kind of certificates are good? What background should I have? 

By this blog I will answer those question based on my experience. I will not dwell into explaining what forensics is and why do we perform that. For that you can just google it and/or read my blog entry – Incident Response and Forensics : The Two Towers. Understand Forensics is considered a specialised field, meaning one must have prior knowledge of fundamentals in operating systems, networking, packet analysis, incident handling etc.

For me I started in Technical Support – this is first due to I was a student and second technical support guys will go through numerous issues and fix through out the day which can be extended into Forensics investigation. For example, a user calls into saying my system is working slow – a tech support guy will first investigate why and provide solution/workaround based on the findings. This helped in understanding system internals especially Windows. One must understand how an operating system works – their processes, services, kernel level attributes etc. A very good link to start is here for windows, here for MacOSX and here for linux. I will be creating mind map for this and will provide them on my github account.

Certificates such as SANS GCFE will give you insights on windows operating system forensics. Individuals thinking of this course should read on here.

Other courses and comparison can be viewed here.

We obviously need tools to perform forensics. There are numerous tools available to perform forensics based on what is required. SANS has their own linux distribution SIFT and further information can be found here.

There is also a debate, that System Admins are the best Forensic examiners or investigators and I don’t agree with that statement. Yes system admins have knowledge of system, however that’s mostly into hardening and fixing an issue. Rarely security aspect is covered in System Admin side. System Admin will still need to learn and/or go through training (self or class based) and understand how their experience overlaps in forensics.

To gain a bit more knowledge about networking, incident handling, packet analysis I dwelled into SOC (security operations centre). This allowed me to understand how operating system communicates to other operating systems, network and/or external systems. In SOC, I was responsible to identify anomalies, develop SIEM content to identify incidents within network and/or operating system from a known bad behaviour. This allowed me understand what is a good behaviour. All operating system logs events and one must understand what is the meaning of those and in what situations they are triggered, and how one can use these events in identifying an unauthorised activity and/or unusual behaviour for example. This knowledge, during forensics, allowed me to investigate the operating system and/or infected host in different manner. Yes, Forensics and Incident Response overlaps and are two sides of the same coin. I always took initiatives and that helped me in the field.

To understand how Forensics should be performed one must also understands standards and RFC. Understanding these standards allowed me to grasp how corporate world and/or any forensics practice should perform forensics and how that can be integrated in Incident Response. Have a read here for NIST publication, here for RFC and here for NIST Mobile forensics publication.

This will be a good start to for individuals interested in Forensics. One should also dive into the operating system they normally use at work/home on their laptop/desktop and go through system. For Windows, work on PowerShell, look at the event viewer, services, use Sysinternal Tools. Fire up wireshark and/or Chrome net internals to see what happens when you access a website. Note down whatever is considered a normal behaviour. For linux/Mac look at the logs under directory /var/logs.

Lastly, read the blogs that are forensics and incident response related which will give a good insight in using tools, how forensics is performed and current methodologies and type of investigations.

Few Forensics Blogs :

Another point, I will raise is certifications are not the only way you will understand or gain more knowledge in Forensics. Your practice and dedication in self-learning and implementing on a regular basis will help a lot. But, also in corporate world these certifications are considered an entry point and it is advisable to get them. I have done SANS certifications (I am not advocating them and/or advertising SANS for personal gain, just sharing my personal experience), and I believe they concentrate on fundamentals and have better content with related to topics that are covered in any certifications.

I will be providing more links on the up coming mind map. I will also be providing any Forensic and/or IR investigations that I perform, at my home lab including tools usage.

Happy Forensicating!!!!!

Incident Response and Forensics – The two towers

Readers

Been meaning write something about my experience with Incident response and forensics and how knowledge of both field helped me.

Most of the organisations have Incident Response and Forensics as 2 different department and no overlap of services or transparency is seen between them. Personally, I believe it is not a good approach as Incident Response and Forensics team should work hand in hand to get the most out of the investigation. There are organisation who thinks Forensics are only to collect evidence. Yes indeed I was shocked!!!

Both stream requires well organised plans and procedures and individuals with strong technical expertise. Both streams have standards – NIST 800-61 of IR and 800-86 for Forensics. One must understand these standards.

When an organisation is performing IR, imagine the responder has no forensic knowledge.

  1. The reason we perform incident response is to understand what happened, how it happened, how we can stop it to further affect/infect our systems and how we can stop in future – Preparation, Identification, Containment, Remediation, Recovery and Lesson Learned. As mentioned in my earlier blog most organisation perform Preparation, Identification and Recovery. Is this due to improper process ? Is it because the responder doesn’t know the IR Phases? Is it due to time constraints or can’t be bothered?
  2. Now to understand what happened (e.g., malware infection), one must understand malware, and how it interacts with the system and what artefacts are involved. This is where Forensic knowledge will come in place. Handling a malware incident, one must know malware analysis and in certain scenarios reverse engineering. Let’s say you are not sure its a malware infection, however system are showing signs of unusual behaviour. As an incident responder one may think to just run certain tool to identify or understand behaviour – nothing wrong however, this may alter certain files by treating them malicious – like what a endpoint protection does by performing quarantine.
  3. A forensic investigator will first manually investigate the system and learn why a system is behaving in such manner – look through process (parent/child), file paths, services etc to determine what is not part of the system. I am not saying tool will not be used but this is about a process. Forensic investigator may choose to run Redline for example.
  4. The approach taken by 2 individuals are always different but the end goal should remain the same – reduce impact and determine indicators of compromise and TTPs (Tools, techniques and procedure) that can be used in earlier detection in future. When this is not performed our adversaries will always have tactical advantage over us.

An ideal approach I prefer is that an Incident Responder must have certain knowledge of forensics that can assist him/her in making sure our investigation is not only to clean the system (an anti-virus/anti-malware can do that), but identify the artefacts and preserve them for further investigation if time permits. Forensics should be performed in parallel to incident response.

IR is more process driven and forensics allows to deep dive into systems to identify bad actors. Forensics is time consuming and most of the time organisations prefer not to include them as they want business or system to return to its normal state. IR and Forensics should also communicate to other security network team and share the outcome of investigations.

I will be writing more about IR and Forensics methodologies (technical and non-technical) and answer most common question – how do i go by starting in IR or Forensics (DFIR). This will supplement the Threat Hunting article that I am working on.

Mandatory Reads

Happy Investigation!!!!!!