Category Archives: Forensics

A “DFUR-ent” Perspective on Threat Modeling and Application Log Forensic Analysis

Many organizations operating in e-commerce, hospitality, healthcare, managed services, and other service industries rely on web applications. And buried within the application logs may be the potential discovery of fraudulent use and/or compromise! But, let's face it, finding evil in application logs can be difficult and overwhelming for a few reasons, including:

  • The wide variety of web applications with unique functionality
  • The lack of a standard logging format
  • Logging formats that were designed for troubleshooting application issues and not security investigations
  • The need for a centralized log analysis solution or SIEM to process and investigate a large amount of application log data

So, in this blog post, we discuss threat modeling concepts that can help prioritize logging decisions and unleash the ability to identify and investigate attacks against an application. To help us demonstrate, we'll describe situations for a fictitious organization called Dog and Feline Urgent Response, or DFUR, that we presented at the 2020 SANS Digital Forensics & Incident Response (DFIR) Summit.

We selected Splunk Enterprise Security (ES) as DFUR’s SIEM and logging analysis platform, but this is just one option and there are multiple technologies that can facilitate application log analysis. We created a Splunk application called “Dog and Feline Urgent Response (DFUR)” available on the FireEye GitHub that contains pre-indexed data and dashboards that you can use to follow along with the following attack scenarios.

But, enough kitten around. Let’s introduce you to DFUR!

DFUR: Dog and Feline Urgent Response

DFUR is a long-standing organization in the pet wellness industry that provides care providers, pet owners, and insurance providers with application services.

  • Care providers, such as veterinarians, use DFUR to process patient records, submit prescriptions, and order additional care services
  • Pet owners use DFUR to make appointments, pay bills, and see diagnostic test results
  • Insurance providers use DFUR to receive and pay claims to pet care providers

Application users log into a web portal that forwards logon and user transaction logs to DFUR’s Splunk ES instance. Backend databases store metadata for users, such as street addresses and contact information.

DFUR Security Team Threat Modeling

After stumbling through several incidents, the DFUR security team realized that their application did not log the information needed to answer investigative question clearly and quickly. The team held workshops with technical stakeholders to develop a threat model and improve their application security strategy. They addressed questions, such as:

  • What types of threats does DFUR face based on industry trends?
  • What impact could those threats have?
  • How could the DFUR application be attacked or abused?
  • What log data would DFUR need to prove an attack or fraud happened?

The DFUR team compiled the stakeholder feedback and developed a threat profile to identify and prioritize high-risk threats facing the DFUR application platform, including:

  • Account takeover and abuse
    • Password attacks (e.g., credential stuffing)
    • Bank account modifications
    • PHI/PII access
    • Health service modifications or interruptions
  • Fraudulent reimbursement claim submission
  • Veterinarians over-prescribing catnip

The DFUR security team discussed how they could identify threats using their currently available logs, and, well, the findings were not purr-ty.

Logging Problems Identified

The DFUR team used their threat model to determine what log sources were relevant to their security mission, and then they dug into each one to confirm the log events were valid, normalized, and accessible. This effort produced a list of high-priority logging issues that needed to be addressed before the security team could move forward with developing methods for detection and analysis:

  • Local logs were not forwarded to their Splunk ES instance. Only a limited subset of logging was forwarded to their Splunk ES instance, so DFUR analysts couldn't search for the actions performed by users who were authenticated to the application portal.
  • Inaccurate field mapping. DFUR analysts identified extracted field values that were mapped to incorrect field names. One example was the user-agent in authentication log events had been extracted as the username field.
  • Application updates sometimes affected Splunk ingestion and parsing. DFUR analysts identified servers that didn't have a startup script to ensure log forwarding was enabled upon system reboot. Application updates changed the logging output format which broke field extractions. DFUR analysts didn't have a way to determine when log sources weren't operating as expected.
  • Time zone misconfigurations. DFUR analysts determined their log sources had multiple time zone configurations which made correlation difficult.
  • The log archival settings needed to be modified. DFUR analysts needed to configure their Splunk ES instance data retirement policy to maintain indexed data for a longer time period and archive historical data for quick restoration.
  • Source IP addresses of users logging into the portal were masked by a load balancer. The DFUR analysts realized that the source IP address for every user logon was a load balancer, which made attribution even more difficult. The X-Forwarded-For (XFF) field in their appliances needed to be enabled.

Analysis Problems Identified

The DFUR infosec team reviewed how previous incidents involving the DFUR application were handled. They quickly learned that they needed to solve the following operational issues before they could effectively investigate application attacks:

  • Inconsistency during manual analysis. DFUR analysts took different approaches to searching their Splunk ES instance, and they would reach different conclusions. Playbooks were needed to define a standard investigative methodology for common incident scenarios.
  • No documentation of log fields or sources. Some DFUR analysts were not aware of all relevant data sources that were available when investigating security incidents. This led to findings that were based on a small part of the picture. A data dictionary was needed that defines the log sources and fields in the DFUR Splunk ES instance and the retention time for each log source.
  • Application logs were designed for troubleshooting, not investigating. The DFUR application was configured to log diagnostic information, application errors, and limited subsets of successful user activity. The DFUR team needed to reconfigure and develop the application to record more security related events.

DFUR: New and Improved Monitoring and Detection

The DFUR team addressed their application log and analysis problems and started building a detection and investigative capability in their Splunk ES instance. Using the analysis workflows developed during the threat modeling process, the DFUR team designed Splunk dashboards (Figure 1) to provide detection analytics and context around three primary datapoints: usernames, IP addresses, and care providers (“organizations”).


Figure 1: DFUR monitoring and detection dashboard

The DFUR team created the Splunk dashboards using Simple XML to quickly identify alerts and pivot among the primary datapoints, as seen in Figure 2. The DFUR team knew that their improved and streamlined methodology would save time compared to exporting, analyzing, and correlating raw logs manually.


Figure 2: Pivoting concepts used to develop DFUR dashboards

Newly armed (legged?) with a monitoring and detection capability, the DFUR team was ready to find evil!

Attack Scenario #1: Account Takeover

The next morning, the DFUR security team was notified by their customer service team of a veterinarian provider with the username ‘labradorable’ who hadn’t received their daily claims payment and noticed their banking information in the DFUR portal was changed overnight.

A DFUR analyst opened the User Activity Enrichment dashboard (Figure 3) and searched for the username to see recent actions performed by the account.


Figure 3: User Activity Enrichment dashboard

The analyst reviewed the Remote Access Analytics in the dashboard and identified the following anomalies (Figure 4):

  • The username reminder and password reset action was performed the day before from an Indonesia-based IP address
  • The user account was logged in from the same suspicious IP address shortly after
  • The legitimate user always logs in from California, so the Indonesia source IP login activity was highly suspicious


Figure 4: Remote access analytics based on user activity

The DFUR analyst clicked on the Application Activity tab in the User Activity Enrichment dashboard to see what actions were performed by the user while they were logged in from the suspicious IP address. The analyst identified the user account logged in from the suspicious IP address and performed an email address change and added two (2) new bank accounts, as seen in Figure 5.


Figure 5: Application activity timeline filtered based on IP address

The DFUR analyst confirmed that the two (2) bank accounts were added by the user to the care provider with organization ID 754354, as seen in Figure 6.


Figure 6: Bank accounts added and assigned to a provider

By clicking on the organization ID in the Splunk results table, the DFUR analyst triggered a drill-down action to automatically open the Organization Enrichment Dashboard and populate the organization ID value with the results from the previous panel (Figure 7). The DFUR analyst determined that the bank routing information for the new bank accounts was inconsistent with the organization’s mailing address.  


Figure 7: Organization Enrichment Dashboard

The activity indicated that the attacker had access to the user’s primary email and successfully reset the DFUR account password. The DFUR analyst confirmed that no other accounts were targeted by the suspicious IP address (Figure 8).


Figure 8: IP Address Enrichment dashboard

Attack Scenario #2: Credential Stuffing

Later that afternoon, the DFUR team began receiving reports of account lockouts in the patient and provider portals when users tried to login. The security team was asked to investigate potential password attack activity on their DFUR platform.

The DFUR analyst pulled up the main monitoring and detection dashboard and scrolled down to the panel focused on identifying potential password attack activity (Figure 9). They identified five (5) IP addresses associated with an elevated number of failed login attempts, suggesting a password spray or credential stuffing attack with varying success.


Figure 9: Dashboard panel showing potential password attack events

The DFUR analyst clicked on one of the IP addresses which triggered a drill-down action to open the IP Address Enrichment dashboard and prepopulate the IP address token value (Figure 10).


Figure 10: IP Address Enrichment dashboard

The DFUR analyst identified more than 3,000 failed login attempts associated with the IP address with three (3) successful logins that morning. The Remote Access Analytics panels for the IP address further showed successful logins for accounts that may have been successfully compromised and need to be reset (Figure 11).


Figure 11: Remote access analytics for IP address

Conclusion

After implementing the newly developed logs and analysis capabilities and by leveraging Splunk’s security solutions, the DFUR security team drastically improved key metrics aligned with their application security missions:

  1. Identify compromise and fraud before customers report it
  2. Analyze 90% of application security events within 30 minutes
  3. Answer all investigation questions from users, compliance, and legal teams

Mandiant and the whole DFUR security team hope you can use the scenarios and references in this post to improve your log analysis and how you leverage a SIEM solution in the following ways:

  • Reflect on your current logging gaps and capabilities to improve
  • Enhance logs from “whatever the developers implemented” to “designed to be investigated”
  • Develop investigative workflows that are reliable and repeatable
  • Correlate pivot points between your data sources and streamline correlation capabilities
  • Create monitoring and alerting capabilities based on threat modeling
  • Lower the technical barrier for comprehensive analysis
  • Implement similar analysis capabilities to those in the “DFUR” Splunk application, linked in the References section
  • Understand that logs can lead into better security analytics and strengthening of your security operations

References

For organizations that utilize Splunk security solutions as their SIEM solution, for automation, analytics or log aggregation, or want to try out for free with Splunk’s free trial download, we developed an application called “Dog and Feline Urgent Response (DFUR)” to demonstrate application log forensic analysis and dashboard pivoting concepts. The code contains pre-indexed data and CSV files referenced by searches contained in four Splunk XML dashboards. All data, such as IP addresses and usernames, was fabricated for the purposes of the demo and any association with organizations, users, or pets is coincidental.

Did It Execute?

You found a malicious executable! Now you've got a crucial question to answer: did the file execute? We'll discuss a few sources of evidence you can use to answer this question. In this post, we will focus on static or "dead drive" forensics on Windows systems. We will cover four main sources of evidence: Windows Prefetch, Registry, Log Files, and File Information.

Prefetch

Windows Prefetch is a good place to begin looking for evidence of file execution. Microsoft designed Windows Prefetch to allow commonly used programs to open faster. By default, it stores information for the last 128 executed files in prefetch files found in "C:WindowsPrefetch". A prefetch file is named as "executable file name" + hash of file path + .pf. The prefetch file stores the first and last run dates, file path, number of times executed, and files loaded within the first ten seconds of process execution. So, if your malware filename / path hash shows up as a prefetch file named "DABEARS.EXE-12F3B52A.pf", then you know the file executed. Note: on Windows servers, Prefetch is disabled by default.

Registry

As one would expect, the Windows Registry contains vast amounts of information on what goes on behind the scenes in Windows. Since the Registry is so large, the list below is not comprehensive, but it shows the main Registry keys we examine to determine file execution:

1. ShimCache

Microsoft created the ShimCache, or "AppCompatCache" to identify application compatibility issues. The cache data tracks file path, size, last modified time, and last "execution" time (depending on OS). If a file is executed with Windows "createprocess," it is logged in the ShimCache. While a file's presence in the ShimCache does not 100% prove file execution, it does show Windows interacted with the file. The following keys contain ShimCache data: "HKLMSYSTEMCurrentControlSetControlSession ManagerAppCompatibilityAppCompatCache (XP) and "HKLMSYSTEMCurrentControlSetControlSession ManagerAppCompatCacheAppCompatCache" (Non-XP). For more information on the ShimCache, see Andrew Davis' blog entry here - or Mandiant's SANS DFIR conference presentation here.

2. MUICache

When a file is executed via Windows Explorer, the program shell creates an entry in the MUICache. There's a good write up of the process on the Windows Incident Response blog. Windows uses the MUICache to store application names as retrieved from the PE Version Information in its Resource Section. The information is stored in the following keys:

  • "HKCUSoftwareMicrosoftWindowsShellNoRoamMUICache" (XP, 2000, 2003) and
  • "HKCUSoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache" (Vista, 7, 2008).

3. UserAssist

The UserAssist tracks executables and links opened in Explorer. The UserAssist key tracks last execution time and number of times a file was run in the registry key: "HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist". Values under the UserAssist key, corresponding to the executable names and file paths, are encrypted with ROT13; as a result, you may miss evidence within this key if you conduct keyword searches prior to decoding. There are a number of tools to decrypt the key, including the RegRipper userassist.pl plugin, found here.

Log Files

There are a few logs you can analyze to determine file execution. Start with the Windows System Event Log, since this log records service starts. The event in Figure 1 shows an Administrator (SID="-500") executed the PSEXECSVC remote execution service:

Figure 1: Event ID 7035 - Service start

When a service starts, it usually executes the file specified in the ImagePath or a loaded service DLL. For example, the "Netman" service uses the legitimate file "netman.dll" when it executes. However, if the ServiceDll in the registry contains a path to a backdoor named "tabcteng.dll", the "Netman" service would execute "tabcteng.dll" instead. Be sure to validate the files in the ImagePath and ServiceDlls for any suspicious service starts.

If Audit Process Tracking is enabled in the Windows Event Log audit settings, the Windows Security Event Log is a wealth of information about processes and can definitively prove file execution. Figure 2 and Figure 3 show the malicious file and associated process ID, as well as the parent process ID and username to aid in further investigation.

Figure 2: XP EventID 592 - Process creation

Windows Vista+ records a similar process creation event, but the EventID is 4688.

Figure 3: Vista+ EventID 4688 - Process creation

Auditing capabilities are more granular with newer versions of Windows and are integrated with Group Policy starting in Windows Server 2008 R2 and Windows 7. Advanced audit policy settings can be found here.

There are too many vendors to cover in this post, but host-based IPS or AV product logs may show when a file is running and/or attempting an action on another file. Figure 4 contains an example event from a McAfee Access Protection log.

Figure 4: McAfee Access Protection log event

The Windows Scheduled Task Log may confirm if the attacker used a scheduled task to execute malware. Scheduled Tasks are recorded in a log file named "SchedLgU.txt" as follows:

Figure 5: Event in Scheduled Task log

In Windows Vista+, the scheduled task executions are also recorded in the log "Microsoft-Windows-TaskScheduler/Operational" event log under Event ID 200 and 201.

Figure 6: Event ID 200 & 201 - Scheduled Task execution

Finally, if an application crashes, the Dr. Watson log may record a malicious task running.

Figure 7: Running tasks captured in Dr. Watson Log

File Functionality

Another way to determine if a file was executed is to look for any output files. When you analyzed the malicious file, was it configured to create data? For example, if the malicious file you found is a keylogger and an associated keylog file is present on the system, the attacker likely executed the file. If the malware was configured to connect to a particular domain name, the browser history may have recorded the associated domain. Table 1 contains an example of two communication mechanisms captured in browser history from the same backdoor.

Table 1: Malicious communication in browser history

To determine if a malicious file executed, analyze the file's functionality, and look for evidence of the resulting activity on disk. Malware functionality can also help you assess an attacker's motivation, end goals, and perhaps reveal additional malicious files.

While this post covered the primary sources of evidence we use to detect file execution, there are many more Registry keys and other Windows files which provide evidence of malware execution, especially in Windows Vista and above. Similarly, information found in system memory can be even more valuable for proving file execution and may provide specific attacker commands and accessed resources. So please, if you find a malicious executable on a running system, be sure to capture the memory before doing anything else. You can capture and analyze memory with Mandiant Redline™.

We will discuss more forensic artifacts in future posts, but feel free to direct message me on Twitter @marycheese.

Highlighter Super Users Series: Post 2

Back in November I published the first interview from the Highlighter™ Super Users blog series. My goal with this series is to shed some light on all the great things that can be achieved using this freeware tool. In part 2, I interviewed toolsmith author and HolisticInfoSec.org webmaster, Russ McRee.

Super User Interview #2: Russ McRee

Russ McRee is the author of ISSA Journal's toolsmith series and runs HolisticInfoSec.org. In October 2011 Russ contacted me to discuss Highlighter in that month's issue of the ISSA Journal, and later for the nomination of Highlighter for the 2011 Toolsmith Tool of the Year. As someone who has analyzed Highlighter's effectiveness as a forensics tool for his own articles, I asked him to answer a few questions based on his experience with the freeware tool.

  1. Name
    Russ McRee
  2. Realm of work
    Security Analytics (security incident management, security monitoring, attack and penetration testing).
  3. How did you hear of Highlighter?
    I watch the websites and check for tool updates.
  4. Do you know of any other tools that do what Highlighter does?
    Log Parser, Log Parser Lizard, Log Parser Studio, Splunk
  5. How do you normally use Highlighter?
    I mainly use Highlighter for Log analysis, forensic investigations, demonstrations and research (see http://www.youtube.com/watch?v=w0uOCOINrWY and https://www.sans.org/reading_room/whitepapers/logging/evil-lens-web-logs_33950)
  6. Can you describe one scenario in which Highlighter helped you find evil and/or solve crime?
    I had a recent mysterious case of core utility files and binaries gone missing from very important infrastructure management servers that initially looked malicious and intentional. Using Highlighter for analysis of Windows event logs led to the discovery of a sync job gone awry (misconfiguration) in the Application log via time stamp matching and keyword highlights.
  7. On a scale from 1 (worst) to 5 (best), how well does Highlighter address your use case(s)?
    4
  8. What is missing from Highlighter for your use case(s)?
    Word wrap option
  9. What is one Highlighter feature addition that would serve the Information Security community best?
    Potential DB support
  10. Are you aware of, or have you used, any of the following features:
    • Activity Over Time feature that lets you view log data as a function of Entries Per Day
      No, I was not aware.
    • Hotkeys feature
      Yes, I was aware of this feature.
    • Ability to change basic font settings for your output
      Yes, I was aware of this feature.
  11. Have you ever seen Highlighter used in such a way that your eyeballs melted from all the Awesome?
    My eyeballs melted from the awesome when I stuffed Highlighter with a 2.44GB Swatch log file during large file testing while writing October 2011's toolsmith. It took a little time to load and format (to be expected), but it handled 24,502,412 log entries admirably (no choking). I threw a query for a specific inode at it and Highlighter tagged 1930 hits across 25 million+ lines in ten minutes.

Keep an eye out for the final post in the Highlighter Super Users Series. If you're interested in sharing your own experiences with this tool, please let me know by commenting below.

Highlighter Super Users Series: Post 1

The Highlighter™ Super Users series is a little something I've put together to reach out to the Highlighter community. As a user of this freeware tool from Mandiant, I want you to know there are many users out there who can help you get through your log analysis paralysis. This series is meant to highlight (see what I did there?) how some users have solved a various range of problems using Highlighter. These interviews will provide insight into the benefits and pitfalls of using Highlighter, some features you may not be aware of, and a few use cases you may not have considered.

Super User Interview #1: Ken Johnson

Ken Johnson is one of Highlighter's Twitter-friendly users. He is a malware analyst and incident responder extraordinaire; fighting evil one keyword search at a time. Known as @patories on Twitter, I reached out to him and asked some questions about his experience using Highlighter.

  1. Name
    Ken Johnson
  2. Realm of work
    My primary work is focused on malware analysis and incident response. Occasionally I also do some forensics work.
  3. How did you hear about Highlighter?
    I first saw Highlighter when I was familiarizing myself with free tools. I have used Memoryze™ previously.
  4. Do you know of any other tools that do what Highlighter does?
    Highlighter is the only tool I know of, and it does what I need so I haven't looked for others.
  5. How do you normally use Highlighter?
    I use Highlighter to trim out known good traffic from proxy logs. This helps get to the unknown stuff quicker. When logs can be multiple gigabytes this is a time saver.
  6. Can you describe one scenario in which Highlighter helped you find evil and/or solve crime?
    On more than one occasion I have used Highlighter to narrow down proxy log traffic to find connections that are malicious. There was an instance about 2 months ago where users fell for a Phish. We used Highlighter to find the C&C IP's that machines kept calling home to, by filtering out what was normal and analyzing what was left. Highlighter helped find almost 50 IP/URLS that were malicious.
  7. On a scale from 1 (worst) to 5 (best), how well does Highlighter address your use case(s)?
    I would have to give Highlighter a 4.
  8. What is missing from Highlighter for your use case(s)?
    I would like to have the ability to whitelist traffic so I do not have to manually keep removing internal hosts that we see. This may be in the program and I have not found it.
  9. What is one Highlighter feature addition that would serve the Information Security community best?
    I think the ability to whitelist hostnames would be a nice addition.
  10. Are you aware of, or have you used, any of the following features:
    • Activity Over Time feature that lets you view log data as a function of Entries Per Day
      No, I was not aware of this one.
    • Ability to change basic font settings for your output
      I know it is there, but for my use this is never used.
  11. Have you ever seen Highlighter used in such a way that your eyeballs melted from all the Awesome?
    I have only seen myself use it, but I have seen my co-workers eyeballs melt when I show them the awesomeness that they can do. Some are still stuck in the grep world...

Keep an eye out for the second post in the Highlighter Super Users Series featuring Russ McRee, author of ISSA Journal's toolsmith series and mastermind behind www.holisticinfosec.org. If you're interested in sharing your own experiences with this tool, please let me know by commenting below.

Incident Response with NTFS INDX Buffers – Part 1: Extracting an INDX Attribute

By William Ballenthin & Jeff Hamm

On August 30, 2012, we presented a webinar on how to use INDX buffers to assist in an incident response investigation. During the Q&A portion of the webinar we received many questions; however, we were not able to answer all of them. We're going to attempt to answer the remaining questions by posting a four part series on this blog. This series will address:

Part 1: Extracting an INDX Record

An INDX buffer in the NTFS file system tracks the contents of a folder. INDX buffers can be resident in the $MFT (Master File Table) as an index root attribute (attribute type 0x90) or non-resident as an index allocation attribute (attribute 0xA0) (non-resident meaning that the content of the attribute is in the data area on the volume.)

INDX root attributes have a dynamic size in the MFT, so as the contents change, the size of the attributes change. When an INDX root attribute shrinks, the surrounding attributes shift and overwrite any old data. Therefore, it is not possible to recover slack entries from INDX root attributes. On the other hand, the file system driver allocates INDX allocation attributes in multiples of 4096, even though the records may only be 40 bytes. As file system activity adds and removes INDX records from an allocation attribute, old records may still be recoverable in the slack space found between the last valid entry and the end of the 4096 chunk. This is very interesting to a forensic investigator. Fortunately, many forensic tools support extracting the INDX allocation attributes from images of an NTFS file system.

Scenario

Let's say that during your investigation you identified a directory of interest that you want to examine further. In the scenario we used during the webinar, we identified a directory as being of interest because we did a keyword search for "1.rar". The results of the search indicated that the slack space of an INDX attribute contained the suspicious filename "1.rar". The INDX attribute had the $MFT record number 49.

Before we can parse the data, we need to extract the valid index attribute's content. Using various forensic tools, we are capable of this as demonstrated below.

The SleuthKit

We can use the SleuthKit tools to extract both the INDX root and allocation data. To extract the INDX attribute using the SleuthKit, the first step is to identify the $MFT record IDs for the attributes of the inode. We want the content of the index root attribute (attribute type 0x90 or 144d) and the index allocation attribute (attribute type 0xA0 or 160d).

To identify the attribute IDs, run the command:

istat -f ntfs ntfs.dd 49

The istat command returns inode information from the $MFT. In the command we are specifying the NTFS file system with the "-f" switch. The tool reads a raw image named "ntfs.dd" and locates record number 49. The result of our output (truncated) was as follows:

....
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: Resident size: 72

...

Type: $I30 (144-6) Name: $I30 Resident size: 26

Type: $I30 (160-7) Name: $I30 Non-Resident size: 4096

The information returned for the attribute list includes the index root - $I30 (144-6) - and an index allocation - $I30 (160-7). The attribute identifier is the integer listed after the dash. Therefore, the index root attribute 144 has an identifier of 6, and the index allocation attribute 160 has an identifier of 7.

With this information, we can gather the content of the attributes with the SleuthKit commands:

icat -f ntfs ntfs.dd 49-144-6 > INDX_ROOT.bin

icat -f ntfs ntfs.dd 49-160-7 > INDX_ALLOCATION.bin

The icat command uses the NTFS module to identify the record (49) attribute (144-6 and 144-7), and outputs the attribute data into the respective files INDX_ROOT.bin and INDX_ALLOCATION.bin.

EnCase

We can use EnCase to extract the INDX allocation data. To use EnCase version 6.x to gather the content of the INDX buffers, in the explorer tree, right click the folder icon. The "Copy/UnErase..." option applied to a directory will copy the content of the INDX buffer as a binary file. Specify a location to save the file. Note that the "Copy Folders..." option will copy the directory and its contents and will NOT extract the INDX structure.

FTK

We can use the Forensic Toolkit (FTK) to extract the INDX allocation data. Using FTK or FTK Imager, the INDX allocation attributes appear in the file list pane. These have the name "$I30" because the stream name is identified as $I30 in the index root and index allocation attributes. To extract the content of an index attribute, in the explorer pane, highlight the folder. In the file list pane, right click the relevant $I30 file and choose the option to "export". This will prompt you for a location to save the binary content.

Mandiant Intelligent Response®

The Mandiant Intelligent Response® (MIR) agent v.2.2 has the ability to extract INDX records natively. To generate a list of INDX buffers in MIR, run a RAW file audit. One of the options in the audit is to "Parse NTFS INDX Buffers". You can run this recursively, or you can target specific directories. We recommend the latter because this option will generate numerous entries when done recursively.

To display a list of parsed INDX buffers, you can filter a file listing in MIR by choosing the "FileAttributes" are "like" "*INDX*". The MIR agent recognizes "INDX" as an attribute because the files listed in the indices may or may not be deleted.

Results

Regardless of which method is used, your binary file should begin with the string "INDX" if you grabbed the correct data stream. You can verify the results quickly in a hex editor. Ensure that the first four bytes of the binary data is the string "INDX".

Conclusion

This example demonstrates three ways to use various tools to extract INDX attribute content. Our next post will detail the internal structures of a file name attribute. A file name attribute will exist for each file tracked in a directory. These structures include the MACb (Modified, Accessed, Changed, and birth) times of a file and can be a valuable timeline source in an investigation.