DFIR Archives - DETECTX | Cloud Security Expert

Digital Forensics – Evidence Handling guidelines – ACPO Digital Forensic

Association of Chief Police Officers ACPO Guidelines for Computer Based Evidence

Computer based electronic evidence is held to the same rules and expectations that apply to all other evidence before a court.

The onus is on the prosecution to prove to a court that the evidence produced by them is no more and no less than it was when it was first taken into the possession of the Police at the point of seizure.

As computer and mobile phone operating systems and other programs present often alter, including create and delete files from a device and this can happen without the user being aware of it, simply by being switched on.

To comply with the ACPO principles of computer based evidence where possible a full bit copy image of the memory present on the digital device should be taken. In some cases, for example when the amount of data present prevents a full copy being made, a partial or selected copy of certain files can be considered, however, the forensic examiner should take care to ensure that all required evidence is captured if that approach is taken.

The ACPO guidelines also require that any data is acquired using a suitable write blocking hardware unit, however, on some occasions this is not possible, for example, when the original digital device itself requires access. In these circumstances, the individual who carries out this process is sufficiently competent to provide evidence in court to explain the actions undertaken.

When providing evidence to court, the individual must display objectivity and fairness whilst being able to explain each process completed with the digital evidence, including the acquisition and examination of it, so that a third party digital examiner/expert can repeat the same process if required and arrive at the same result as that presented to the court.

ACPO Principle 1: That no action take is taken that should change data held on a digital device including a computer or mobile phone that may subsequently be relied upon as evidence in court.

ACPO Principle 2: Where a person finds it necessary to access original data held on a digital device that the person must be competent to do so and able to explain their actions and the implications of those actions on the digital evidence to a Court.

ACPO Principle 3: That an trail or record of all actions taken that have been applied to the digital evidence should be created and preserved. An independent third party forensic expert should be able to examine those processes and reach the same conclusion.

ACPO Principle 4: That the individual in charge of the investigation has overall responsibility to ensure that these principles are followed.

ACPO_Good_Practice_Guide_for_Digital_Evidence_v5

DFIR Tools

Write Blockers – https://www.forensicswiki.org/wiki/Write_Blockers
EnCase – Guidance Software
X Ways
Internet Examiner – http://www.siquest.com/
NetAnalysis – https://www.digital-detective.net/digital-forensic-software/netanalysis/
1. https://www.digital-detective.net/digital-forensic-software/free-tools/
Access Data FTK manager – https://accessdata.com/product-download/ftk-imager-version-4-2-0
Store Mailware – https://www.ghisler.com/
https://www.guidancesoftware.com/
https://accessdata.com/products-services/forensic-toolkit-ftk
http://www.x-ways.net/forensics/
https://www.digital-detective.net/digital-forensic-software/free-tools/

Samples

Tutorials

Available Artefacts – Evidence of Execution

https://blog.1234n6.com/2018/10/available-artifacts-evidence-of.html?m=1

This week I have been working a case where I was required to identify users on a Windows Server 2003 system who had knowledge of, or had run, a particular unauthorised executable. As such, I found myself wracking my brain for all the user attributable artifacts which evidence program execution (on an OS I hadn’t analysed for a short while).

Furthermore, David Cowen in his recent Sunday Funday Challenge over at HECFBlog had posed a similar question regarding evidence of execution. With that as my motivation, I set about to document different artifacts which can be used to evidence program execution (both user attributable and otherwise) as available in various different versions of Windows.

I should highlight up front that some really fantastic blog posts from Harlan Carvey, Andrea Fortuna, Corey Harrell and Mary Singh gave me a significant leg up. This isn’t my first time reading any of those posts and I’m sure it wont be my last. A myriad of other posts assisted in confirming details of specific artifacts and I have referenced those below. The main focus of this post, and particularly the associated table of artifacts, is to serve as a reference and reminder of what evidence sources may be available on a particular system during analysis.

On to the main event. The table below details some of the artifacts which evidence program execution and whether they are available for different versions of the Windows Operating System.

Too Small?… It’s a hyperlink!

Cells in Green are where the artifact is available by default, note some artifacts may not be available despite a Green cell (e.g. instances where prefetch is disabled due to an SSD)

Cells in yellow indicate that the artifact is associated with a feature that is disabled by default but that may be enabled by an administrator (e.g. Prefetch on a Windows Server OS) or added through the application of a patch or update (e.g. The introduction of BAM to Windows 10 in 1709+ or back-porting of Amcache to Windows 7 in the optional update KB2952664+)

Cells in Red indicate that the artifact is not available in that version of the OS.

Cells in Grey (containing “TBC”) indicate that I’m not 100% sure at the time of writing whether the artifact is present in a particular OS version, that I have more work to do, and that it would be great if you could let me know if you already know the answer!

It is my hope that this table will be helpful to others. It will be updated and certainly at this stage it may be subject to errors as I am reliant upon research and memory of artifacts without having the opportunity to double check each entry through testing. Feedback, both in the form of suggested additions and any required corrections is very much appreciated and encouraged.

Summary of Artifacts

What follows below is brief details on the availability of these artifacts, some useful resources for additional information and tools for parsing them. It is not my intention to go into detail as to the functioning of the artifacts as this is generally already well covered within the references.

Prefetch

Prefetch has historically been the go to indication of process execution. If enabled, it can provide a wealth of useful data in an investigation or incident response. However, since Windows 7, systems with an SSD installed as the OS volume have had prefetch disabled by default during installation. With that said, I have seen plenty of systems with SSDs which have still had prefetch enabled (particularaly in businesses which push a standard image) so it is always worth checking for. Windows Server installations also have Prefetch disabled by default, but the same applies.

The following registry key can be used to determine if it is enabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher
0 = Disabled
1 = Only Application launch prefetching enabled
2 = Only Boot prefetching enabled
3 = Both Application launch and Boot prefetching enabled

References/Tools:
https://www.forensicmag.com/article/2010/12/decoding-prefetch-files-forensic-purposes-part-1
https://github.com/EricZimmerman/Prefetch

ShimCache

It should be noted that the presence of an entry for an executable within the ShimCache doesn’t always mean it was executed as merely navigating to it can cause it to be listed. Additionally Windows XP ShimCache is limited to 96 entries all versions since then retain up to 1024 entries.

ShimCache has one further notable drawback. The information is retained in memory and is only written to the registry when the system is shutdown. Data can be retrieved from a memory image if available.

References/Tools:
https://www.fireeye.com/blog/threat-research/2015/06/caching_out_the_val.html
https://www.andreafortuna.org/cybersecurity/amcache-and-shimcache-in-forensic-analysis/
https://github.com/EricZimmerman/AppCompatCacheParser

MUICache

Programs executed via Explorer result in MUICache entries being created within the NTUSER.DAT of the user responsible.

References/Tools:
http://windowsir.blogspot.com/2005/12/mystery-of-muicachesolved.html
http://what-when-how.com/windows-forensic-analysis/registry-analysis-windows-forensic-analysis-part-8/

Amcache / RecentFileCache.bcf

Amcache.hve within Windows 8+ and RecentFileCache.bcf within Windows 7 are two distinct artifacts which are used by the same mechanism in Windows to track application compatibility issues with different executables. As such it can be used to determine when executables were first run.

References/Tools:
https://www.andreafortuna.org/cybersecurity/amcache-and-shimcache-in-forensic-analysis/
http://www.swiftforensics.com/2013/12/amcachehve-in-windows-8-goldmine-for.html
http://digitalforensicsurvivalpodcast.com/2016/07/05/dfsp-020-amcache-forensics-find-evidence-of-app-execution/
https://www.dfir.training/windows/amcache/207-lifars-amcache-and-shimcache-forensics/file

Microsoft-Windows-TaskScheduler (200/201)

The Microsoft-Windows-TaskScheduler log file (specifically events 200 and 201), can evidence the starting and stopping of and executable which is being run as a scheduled task.

References/Tools:
https://www.fireeye.com/blog/threat-research/2013/08/execute.html

LEGACY_* Registry Keys

Applicable to Windows XP/Server 2003 only, this artifact is located in the System Registry Hive, these keys can evidence the running of executables which are installed as a service.

References/Tools:
http://windowsir.blogspot.com/2013/07/howto-determine-program-execution.html
http://journeyintoir.blogspot.com/2014/01/it-is-all-about-program-execution.html

Microsoft-Windows-Application-Experience Program-Inventory / Telemetry

Both of these system logs are related to the Application Experience and Compatibility features implemented in modern versions of Windows.

At the time of testing I find none of my desktop systems have the Inventory log populated, while the Telemetry log seems to contain useful information. I have however seen various discussion online indicating that the Inventory log is populated in Windows 10. It is likely that my disabling of all tracking and reporting functions on my personal systems and VMs may be the cause… more testing required.

References/Tools:
http://journeyintoir.blogspot.com/2014/03/exploring-program-inventory-event-log.html

Background Activity Monitor (BAM)

The Background Activity Monitor (BAM) and (DAM) registry keys within the SYSTEM registry hive, however as it records them under the SID of the associated user it is user attributable. The key details the path of executable files that have been executed and last execution date/time

It was introduced to Windows 10 in 1709 (Fall Creators update).

References/Tools:
https://www.andreafortuna.org/dfir/forensic-artifacts-evidences-of-program-execution-on-windows-systems/
https://www.linkedin.com/pulse/alternative-prefetch-bam-costas-katsavounidis/

System Resource Usage Monitor (SRUM)

Introduced in Windows 8, this Windows features maintains a record of all sorts of interesting information concerning applications and can be used to determine when applications were running.

References/Tools:
https://www.sans.org/summit-archives/file/summit-archive-1492184583.pdf
http://cyberforensicator.com/2017/08/06/windows-srum-forensics/
https://github.com/MarkBaggett/srum-dump

ActivitiesCache.db

In Windows 10 1803 (April 2018) Update, Microsoft introduced the Timeline feature, and all forensicators did rejoice. This artifact is a goldmine for user activity analysis and the associated data is stored within an ActivitiesCache.db located within each users profile.

References/Tools:
https://cclgroupltd.com/windows-10-timeline-forensic-artefacts/
https://binaryforay.blogspot.com/2018/05/introducing-wxtcmd.html

Security Log (592/4688)

Event IDs 592 (Windows XP/2003) and 4688 (everything since) are recorded within the Security log on process creation, but only if Audit Process Creation is enabled.

References/Tools:
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=592
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4688

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-process-creation

System Log (7035)

Event ID 7035 within the System event log is recorded by the Service Control Manager when a Service starts or stops. As such it can be an indication of execution if the associated process is registered as a service.

References/Tools:
http://www.eventid.net/display-eventid-7035-source-Service%20Control%20Manager-eventno-1530-phase-1.htm

UserAssist

Within each users NTUSER.DAT the UserAssist key tracks execution of GUI applications.

References/Tools:
https://www.4n6k.com/2013/05/userassist-forensics-timelines.html
https://blog.didierstevens.com/programs/userassist/
https://www.nirsoft.net/utils/userassist_view.html

RecentApps

The RecentApps key is located in the NTUSER.DAT associated with each user and contains a record of their… Recent Applications. The presence of keys associated with a particular executable evidence the fact that this user ran the executable.

References/Tools:
https://df-stream.com/2017/10/recentapps/

JumpLists

Implemented in Windows 7, Jumplists are a mechanism by which Windows records and presents recent documents and applications to users. Located within individual users profiles the presence of references to executable(s) within the ‘Recent\AutomaticDestinations’ can be used to evidence the fact that they were run by the user.

References/Tools:
https://articles.forensicfocus.com/2012/10/30/forensic-analysis-of-windows-7-jump-lists/
https://www.blackbagtech.com/blog/2017/01/12/windows-10-jump-list-forensics/
https://ericzimmerman.github.io/#!index.md

RunMRU

The RunMRU is a list of all commands typed into the Run box on the Start menu and is recorded within the NTUSER.DAT associated with each user. Commands referencing executables can be used to determine if, how and when the executable was run and which user account was associated with running it.

References/Tools:
http://www.forensicfocus.com/a-forensic-analysis-of-the-windows-registry
http://what-when-how.com/windows-forensic-analysis/registry-analysis-windows-forensic-analysis-part-8/

AppCompatFlags Registry Keys

References/Tools:
https://journeyintoir.blogspot.com/2013/12/revealing-program-compatibility.html

AV/IDS/EDR

Various Anti-Virus, Intrusion Detection and Endpoint Detection and Response (EDR) solutions may provide evidence of program execution. It is recommended to identify and analyse any associated logs and note that some logging may be centralised.

Repeating the appeal earlier in this post, feedback, suggested additions and corrections are very welcome!

Incident Response

Incident Identification

Step 1: Prepare your documentation

You will need to document all your activities, from meeting minutes and decisions down to commands typed into your systems by your incident response team.

For each step, you will need to record, at minimum:

Identifying information (location, serial no, model no, hostname, MAC address, IP Address)
Name, title, and phone number of each person who collected or handled evidence during the investigation
Time and date (including time zone) of each occurrence of evidence handling
Locations where the evidence was stored

Step 2: Assemble your Team

Get your incident response team together! Where possible use phone communication – your email and chat systems may be compromised and you might tip off an attacker that you are aware of them.

You’ll need a broad set of people:

Security personnel, including incident responders
System and network administrators
Business stakeholders, such as PR

Remember! Apply a need-to-know policy for now – no need to blow it out of proportion just yet.

Hint: If you have Cyber Insurance, notify them of a potential claim.

Step 3: Determine Scope

Working with your team, determine as best you can what devices have been compromised.

Assume the worst – that more of your environment is compromised. Yes, it will increase the scope of the response, but will reduce the chance of an incident recurring.

‘Indicators of compromise’ are unexpected or suspicious behaviour which may mean an incident has occurred. This may include behaviours such as:

Strange or unexpected system activity
Alerts from a Network IDS or Antivirus system
Unscheduled system crashes or server reboots
Unexplained configuration changes, unusual files, unknown processes, unexpected web-site changes, etc.
Influx of phishing e-mails, spoofed e-mails, etc.
Unusual activity in log files, or gaps in or missing logs
E-mail system showing a large number of bounced/invalid emails
Large volumes of network traffic to unknown countries and networks

Containment

Step 1: Contain to Affected Systems.

A hacker will try to traverse to other systems, so isolate affected systems as soon as possible. The goal here is to prevent the problem from getting worse.

There are some key actions – these may affect incident response, forensic, and legal activities, so make sure you do it right:

Do unplug the network cable of affected systems
Do suspend affected VMs (a copy of the RAM is taken, which is important for forensic analysis)
Do disable wireless connections (in order of preference: at the router, hibernating the laptop, then disconnecting via the computer operating system)
Do declare an incident, if it appears to be one
Don’t run an anti-virus scan (this changes timestamps)
Don’t shut down operating systems

Step 2: Backup affected systems

You want to keep copies of the affected system for forensic purposes.

The best approach is to remove the affected system from the environment, and provide a new system for the user, or build a new server from a clean SOE.

Of course, sometimes this isn’t possible, in which case you should:

Obtain a brand new disk drive and create a complete bit-for-bit backup; and
Get another copy on write-once media (CD-R or DVD-R) in the event that you need pursue legal recourse.

Hint: Use the ‘dcfldd’ tool, which is available for Unix and Windows.

3rd party forensic investigators will have disk cloning hardware to perform this task if you don’t have the relevant expertise.

Eradicate the Problem

Step 1: Remove the malicious code

Eradication means removing the problem from affected systems determined through your scoping efforts.

The actual technical actions for eradication may vary considerably.

Hacking

For attacks on vulnerable systems, cleaning the system and patching the system may be sufficient.

Malware outbreaks

It can be very difficult and time-consuming to verify that systems are in fact secure, and malware has been completely removed. Rootkits in particular need specialist skills to detect.

We recommend rebuilding systems affected by malware, by either:

Reinstall the operating system from original media or image, and restore data from the last known good backup onto new media;
Wipe the existing media, reinstall the operating system from original media, and restore data from the last known good backup;

See the eradication tools in the Links below.

Step 2: Apply compensating controls

If you have indeed been breached, it will be best to apply further controls to ensure you are better able to prevent and detect malicious activity next time.

These controls may include:

Additional logging and monitoring of systems, applications, and databases
Increased monitoring of infrastructure logs, such as SIEM, firewalls, and IDS/IPS
Restriction of logical access to databases
Additional network segmentation
Restrict access to databases

Recovery

Step 1: Recover your systems

Once you’ve eradicated the problem, you can recover the affected systems and return them to production.

Remember to check the integrity of your backups before restoring from them. Malware may have been backed up with your system and data files.

There are key actions when you recover your systems:

Do patch all affected systems
Do check and remediate the original attack vector
Don’t re-introduce the vulnerability from your backups

Step 2: Monitor your environment

You need to conduct logging and monitoring of systems and network traffic to verify that the system or environment has been remediated.

Setup a sniffer on a switches span port to capture all network traffic
Log all traffic and send to your logging and monitoring solution
Check for further activity on the network

If you’re satisfied that the attack has been completely eradicated, then you can formally terminate the incident and conduct post-incident activities.

Have a look at our Incident Response Guide (available to subscribers) for supporting information on conducting post-incident activities, and preparing for the next security incident.

Incident Response Flow Chart

What to capture

Network Diagram
Internal LAN IP Address(s)
External WAN IP Address(s)
Log Files
Firewall
IDS / IPS
Web / Proxy Server
Other Application Logs as Needed
PowerShell ▪ SQL
RDP
DNS
Active Directory
Disk Images for Affected Systems
Forensic Image of Disk
Volatile Memory Capture o Event Logs
Specific Application Logs
Detailed Timeline Prior to Engagement