Normal view

There are new articles available, click to refresh the page.
Before yesterdayHaboob

Introduction to: Sharing Cyber Threat Intelligence using STIX and TAXII (Part 1)

18 July 2021 at 09:57

Abstract:

Due to the complexity of nowadays attack scenarios and the growth of adversary technologies and tools, it is a must for organizations to possess a cyber threat intelligence capability. A key component of success for such capability is sharing threat information with organizations they trust, especially if they are in the same sector or have a similar business type, which is likely to be targeted by the same adversary. While cyber threat intelligence and information sharing can help to make better security decisions, there are multiple issues organizations face on how to represent and share threat information across multiple organization that uses different security solutions. Hence, the need arises for a standard that provides a structured representations of threat information and a way to share them so that multiple security solutions can understand and deal with. The Structured Threat Information eXpression (STIX™) is a collaborative community developed language to represent structured threat information, and the Trusted Automated exchange of Intelligence Information (TAXII™) is the protocol that will be used to share/communicate these information. These standards were governed by OASIS: an international standards development organization.

In this blog we will try to answer these questions:

•        What is Cyber Threat Intelligence (CTI)?

•        Why do we need to share cyber threat intelligence

•        The Cyber threat intelligence cycle

•        Issues organizations face on how to share cyber threat intelligence

•        What is STIX?

•        What is TAXII?

•        How they are used to share Cyber threat intelligence

What is Cyber Threat Intelligence (CTI)?
To answer this question, we will have to know the meaning of intelligence and threat in cybersecurity context.

What is intelligence?
There are lots of different definitions, but the key concepts to highlight on is that Intelligence consists of two parts: the first part is the collection and processing of information about an entity or adversary. The second part is to provide these processed information to concerned people in the organization to make decisions about security.

What is a threat?
A threat consists of three components: hostile intent, capability, and opportunity. The threat actor will perform an action on a target to cause damage.

Now back to the main question: What is Cyber Threat Intelligence?
Analyzed information about the threat of an adversary to an asset. These analyzed information enable defenders and their organizations to reduce harm through better security decision making.

The cyber threat information will provide answers of these questions:
1- Who are the adversaries?
2- What are the technologies, tools and infrastructures used by the adversary?
3- Where did the attack happen?
4- When did the attack occur? Establish a timeline.
5- Why it is targeted? what are the motives and intent?
6- How the adversary conducted the attack
7- What is the impact?
8- What course of action can we do about it?

The Intelligence Cycle:

To produce cyber threat intelligence, where to start? and what to do?
The cyber threat intelligence production cycle consists of five steps, there are lots of details on each step, but we will talk about it briefly:
1- Planning and Direction:
Every organization has different intelligence requirements or needs, which are request and knowledge gaps of what the people in the organization need from CTI.
Based on the intelligence needs of your organization, from where should the CTI team start collecting information? and what information to collect?
2- Collection:
Collecting information from the place planned in the previous step, to be processes and analyzed.
3-Processing:
Processing the information to be represented in a structured way that it is easy for the analyst to analyze.
4-Analysis and Production:
Analyzing the processed information.
5-Dissemination:
Sharing the analyzed information.

Figure 1 Cyber intelligence Cycle

Why do we need to share cyber threat intelligence?

Producing cyber threat intelligence based on the organization’s needs is a great way to start making decisions about the organization security well-being, but is it enough to cover the threat range? Suppose that there are two companies, company A and B that are in the same sector, providing a similar service. Companies in the same sector are highly likely to be targeted by the same adversary campaign. If an attack occurs on company A, and CTI team have produced the cyber threat intelligence on that attack, identifying the attacker tools and pattern, but this information is not shared with company B, if company B got attacked by the same adversary, the attack could succeed, but it could be prevented if the CTI was shared by company A. This is a problem that can be solved by sharing CTI between the two companies. Now you see the benefit of sharing CTI between two companies, imagine if a whole industry or business sector collaborated to share CTI between them, that will help to cover a wide range of the threats faced by these organizations.

Issues organizations face on how to share CTI:

Let us assume that there are two different companies, and each company has produced cyber threat intelligence that are ready to be shared. These two companies have an agreement to share these CTI with each other. The question here is how they will share this information? What are the problems they could encounter?

Figure 2 Scenario of sharing CTI between two companies

There are five main problems these two companies will face:


1- Reading CTI by Different Solutions:
CTI could be written on each solution with different formats. For example, one solution accepts CSV format, another accepts XML. How will the CTI be read by the different security solutions if the formats are different? To be able to share CTI with different security solutions, they must be in a standard format that is supported and understood by most security solutions.

Figure 3 Examples of security solutions used by different organization

2- Type of shared CTI information:
For example, does it mention information about behaviors, like Tactics, Techniques and Procedures (TTPs)? The shared CTI should provide the required depth and context of information for better detection.

These two problems led to the creation of “STIX standard”. STIX is the standard format that CTI will be written in, and it can be read by different security solutions that comply with the standard. We will talk about it in details later.

3- Sharing STIX CTI with Different Solutions
How can we share STIX CTI? STIX allows us to import CTI in one format to different security solutions that can understand it. However, to share STIX CTI through a Threat Feed, the exchange protocol must also be a standard that is understood by most security solutions.

This led to the creation of the “TAXI” protocol for sharing STIX CTI Feeds. We will talk about it in details later.

4- Automatic sharing of CTI:
Can we make sharing of CTI automatic?
Yes, using these standards once there is a sync between the two entities, they can make sharing CTI automatic.

5- Real time Monitoring:
Is it real time monitoring or user initiated? one of these standards features, is that it supports real time monitoring instead of user initiation monitoring. Once these feeds are imported in the security solution, it will be utilized by the security solution to empower its defense capability, without the need for user initiation.

After facing these problems, we see the need for a CTI Exchange standard.

Advantages of CTI exchange standard:

•        Collaborative analysis, inside and outside the organization

•        Expressive information

•        Better detection rate

•        Respond faster to attacks

•        Automatic import of feeds

•        Realtime CTI Monitoring

 

Conclusion

In this blog post, we shed the light on threat intelligence and the importance of collecting and sharing it in standardized formats (STIX and TAXII), and the benefits that brings to the overall cyber defense capability.

 

In part 2 of this blog post we will dive deeper into STIX and TAXII in further details to answer questions that might be hanging, stay tuned ;)

References:

1. The Cycle of Cyber Threat Intelligence
https://www.youtube.com/watch?v=J7e74QLVxCk&ab_channel=SANSDigitalForensicsandIncidentResponse

Introduction to: Sharing Cyber Threat Intelligence using STIX and TAXII (Part 2)

3 August 2021 at 10:06

In PART 1 (Link to Part 1) of this blog post, we went over threat intelligence, from concepts and benefits to challenges and solutions. Two great solutions present themselves which are STIX and TAXII and this is what this blog post is all about.

 

So ..

What are STIX and TAXII?

•      What is STIX?
Structured Threat Information Expression (STIX™) is a language for expressing cyber threat and observable information.

•      Usage:
It is used to describe cyber threat intelligence (CTI), such as TTP, Adversary information and indicators.

•      Versions:
Latest Version is STIX 2.1, It uses JSON format to describe Cyber Threat Intelligence.
Older versions STIX 1.X, used XML format.

•      STIX Features:

  1. Provides a structure that puts together a diverse set of cyber threat information, including:
    a) Cyber Observables
    b) Indicators
    c) Incidents
    d) Adversary Tactics, Techniques, and Procedures
    e) Courses of Action
    f) Threat Actors

  2. Graph based: a tool is provided to convert STIX format to graph, to help in the analysis process.

  3. Improve capabilities such as:
    a) Collaborative threat analysis
    b) Automated threat exchange
    c) Automated detection and response

Example for a CTI in STIX Format:

As you can see, it is written in JSON format. There are variables names which have values, we will explain it in details later, this sample is just to get familiar with the STIX format.

•      What is TAXII?

Trusted Automated Exchange of Intelligence Information, an application layer protocol that runs over HTTPS, used for sharing cyber threat intelligence between trusted partners. TAXII defines API’s (a set of services and message exchanges) and a set of requirements for TAXII Clients and Servers. There are open-source implementations in multiple programming languages.

History of STIX and TAXII:

A brief history of STIX / TAXII standards is displayed on the timeline figure below.

History of STIX / TAXII

STIX data model:

We will see how this language models the threat information, meaning: how it represents the threat data. It models the data in three main objects:

1. STIX Domain Objects (SDO):

Higher Level Intelligence Objects. Each of these objects corresponds to a concept commonly used in CTI.

STIX Domain Objects:

•      Attack pattern •      Indicator •      Tool

•      Campaign •      Infrastructure •      Vulnerability

•      Course of Action •      Intrusion set •      Malware

•      Grouping •      Location •      Malware Analysis

•      Identity •      Report •      Note

•      Incident •      Threat Actor •      Observed Data

•      Opinion

2. STIX Cyber-observable Objects (SCO):

For characterizing host-based and network-based observed information, such as IP address and domain name.

STIX Cyber observable Objects:

•      Artifact •      File •      Process

•      Autonomous System •      IPv4 Address •      Software

•      Directory •      IPv6 Address •      User Account

•      Domain Name •      MAC Address •      Windows Registry Key

•      Email Address •      Mutex •      X.509 Certificate

•      Email Message •      Network Traffic

 

3. STIX Relationship Objects (SRO):

There are two types of relationship objects:
a) Standard relationship:

is a link between STIX Domain Objects (SDOs), STIX Cyber-observable Objects (SCOs), or between an SDO and a SCO that describes the way in which the objects are related.

Standard relationships:

•      Target •      Investigates •      Exfiltrate to

•      Uses •      Remediates •      Owns

•      Indicates •      Located at •      Authored by

•      Mitigates •      Based on •      Downloads

•      Attributed to •      Communicate with •      Drops

•      Variant of •      Consist of •      Exploits

•      Impersonate •      Controls •      Characterizes

•      Delivers •      Has •      AV-analysis of

•      Compromises •      Hosts •      Static analysis of

•      Originate from •      Duplicate of •      Beacons to

•      Derived from •      Dynamic analysis of •      Related to


b) Sighting relationship:

Denotes the belief that something in CTI (malware, threat actor, tool) was seen. Used to track who and what are being targeted, how attacks are carried out, and to track trends in attack behavior, and how many times it was seen. It is used to provide context and more descriptive information.

Example:
Indicator was seen by Haboob company in an organization on public sector in East of Saudi Arabia.

STIX to Graph

Since one of STIX features is that is can be converted to graph, we will see an example showing all STIX objects:

STIX converted to graph

How to write CTI in STIX format:

We will see an example of writing a CTI in STIX format.

  • Writing STIX domain Object: Attack Pattern:

Attack pattern Domain object: contains information about the TTP of an adversary to compromise targets.

We will convert CTI about the TTP of an adversary to a STIX Domain Object Attack Pattern.

Let us assume that the TTP of the adversary is: initial Access using Email Spear phishing.

Before writing the Attack pattern object, let us refer back to our previous example:

As we see from the STIX code example, when writing CTI in STIX format, we have to write in JSON format, and there are variables (black color) that have values (green color), these variables are the properties. Each STIX object has properties. Also, for each STIX object there are common properties that all objects share and specific properties to that object. Some of these properties are required, some are optional. Also, each of these properties accept a defined input type. All STIX properties and their required input are available in the official STIX Standard documentation provided by OASIS organization.

Seeing the properties for Attack Pattern Object from STIX documentation:

We will see now how to write these properties and what input they accept:

  • Common Properties:

Notice how id property is written. UUID here is version 4.

Also notice how the timestamp is written, where "s+" represents 1 or more sub-second values. The brackets denote that sub-second precision is optional, and that if no digits are provided, the decimal place must not be present.

  • Specific Properties:

Notice that some specific properties are required, and some are optional.

  • Relationship objects:

These are the relationships explicitly defined between the Attack Pattern object and other STIX Objects.

Notice that there are relationships from this object to other objects which is forward relationships, and from other objects to this object which are Reverse relationships.

Also, STIX also allows relationships from any SDO or SCO to any SDO or SCO that have not been defined in this specification, by using common relationships. Meaning, if you couldn’t use the mentioned forward and reverse relationship to relate an attack pattern to another object, you can use common relationships to relate them to each other.

After seeing the properties, back to our example. We will write a spear phishing attack pattern with a relationship to Threat actor X in STIX:

As we see the code is written for two domain objects which are “Attack Pattern” and “Threat Actor”, and a relationship object standard type which is “uses”. As we saw the specification and properties for Attack Pattern domain object so that we were able to write it in the correct format, we also had to go to STIX documentation to see the specification and properties of Threat Actor domain object, to write it in the correct format.

If we use the provided resource that converts STIX to graph, we will see this graph:

result after converting STIX to graph

The tool to convert STIX to graph can be found here:
https://oasis-open.github.io/cti-stix-visualization/

This was an example of how to write STIX CTI with two domain objects and one relationship object. To write about more objects and provide more details, we must refer back to the STIX standard documentation, to know the properties for each object, so that we write it adhering to the required specification and format.

Resources:

More resources to be used with STIX standard can be found here:
https://oasis-open.github.io/cti-documentation/resources.html

STIX transportation through TAXII:

If the CTI is transferred to STIX, now it is ready to be shared. To share it, we will use TAXII.

TAXII is the protocol that runs over HTTPS which is used to exchange cyber threat intelligence. It has specifications that govern this exchange. Also, it has two sharing models. We will mention those specifications and models.

TAXII Sharing Models:

It has two sharing models:
1- Collections:
It is a relationship between a producer and a consumer. Consists of a TAXII server and a TAXII client. The TAXII server hosts a repository of CTI in STIX format, that can be requested from a TAXII client. The TAXII client will be only able to request CTI, and not able to add CTI to the server.
2- Channels:
It is a relationship between a publisher and a subscriber. Consists of a TAXII server and TAXII clients. The TAXII server will host a repository of CTI, that can be requested from AND added to by a TAXII client. The TAXII client can request and add CTI to the TAXII server. The published CTI from one TAXII client to the TAXII server, will be pushed and shared through the TAXII server, to other TAXII clients, that are subscribed to this TAXII server.

TAXII sharing models: Collections and Channels

The Specification of Channels sharing model is yet to be defined by OASIS in TAXII standard documentation. Due to this reason, we will mention the specification of Collection sharing model only.

Collections sharing model specifications:

We have a TAXII server and a TAXII client in this sharing model, that need to communicate through HTTPS (HTTP over TLS). There are some specifications defined that must be met in this communication. These specifications are:
1- Media type:
it is shown in the following table:

There is a version parameter that can be used with media type, it is shown in the following table:

The media type specification must be met for the HTTP request and response.

2- Discovery:

There are two discovery methods for the TAXII server, either by network using DNS SRV record, or by a Discovery endpoint. The first method is using a DNS SRV record that identifies the TAXII Server hosting this service in the network. The second method is to make an HTTP request to a defined URL that will enable a client to be authenticated and authorized. Endpoint term is used here to refer to a specific URL for discovery of the TAXII server.

The discovery URL must be named “taxii2”.

3- Authentication and Authorization:

To access any of the API’s on the TAXII servers, it requires authentication. The Authentication and authorization are done using HTTP basic authentication.

4- API Roots:

It is a group of collections. Each API root has a specific URL to be requested from. Organizing the collections into API Roots allows for a division of content and access control.

5- Collections:

A repository of CTI objects. Each collection has a specific URL to be requested from.

6- Objects:

The available CTI to be retrieved by the TAXII client. Each object has a specific URL to be requested from.

The following table shows example of URLs of the mentioned specifications.

An important note is that as you see from the tables, all requests end with a slash “/”. This is also a TAXII specification.

TAXII request and response examples:

  • Discovery:

GET Request

GET /taxii2/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

  • API Roots:

GET Request

GET /api1/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

  • Collections:

GET Request
GET /api1/collections/ HTTP/1.1   

GET Response

  • Objects:

GET Request
GET /api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/ HTTP/1.1
Host: haboob.com
Accept: application/taxii+json;version=2.1

GET Response

Note: API roots, Collections and objects are all saved in an internal database on the TAXII server. The database type is different depending on the implementation of the TAXII server, and the type is left to be chosen by the developer.

Resources:

There is an implementation of a TAXII server and client provided by OASIS. It can be found here:
TAXII server:
https://github.com/oasis-open/cti-taxii-server

TAXII client:
https://github.com/oasis-open/cti-taxii-client

 

Conclusion:

In this blog we have defined what CTI is and why it needs to be shared with alike organizations. We also briefly went over the steps of a CTI cycle. After that we saw the issues faced by organizations to share CTI, which resulted in the creation of STIX and TAXII standards. Then, we have defined what is STIX and TAXII standards and how to use them to share CTI.

 

 

References:

1.STIX 2.1 Documentation
https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.pdf

2.TAXII 2.1 Documentation:
https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.pdf

3. Cti-traning : STIX2-TAXII2 Workshop
https://github.com/oasis-open/cti-training/blob/master/june-2018-FIRST-half-day-training/FIRST%20STIX2-TAXII2%20Workshop%20June%202018.pdf

4.CTI documentation:
https://oasis-open.github.io/cti-documentation/

5.OASIS:
https://www.oasis-open.org/

 

Advanced “USN Journal” Forensics

7 November 2022 at 11:16

NTFS is the default journaling file system for windows operating systems. Understanding NTFS features and how it works helps Digital Forensics investigators navigate and conduct their analysis for various objectives. The NTFS file system contains several files (called metafiles) to organize and structure the file system, one of those metafiles is the master file table ($MFT) which is used by forensics practitioners to gain insight into all files within an NTFS structured volume. Later, Microsoft added the USN Journal (Update Sequence Number) “$UsnJrnl” metafile which is also called the change journal, to maintain information of all changes occurred to files and folders on an NTFS volume, providing records for what and when changes are made and to which objects.

One USN Journal is stored within each NTFS volume and is stored in the NTFS metafile named “$Extend\$UsnJrnl”. The journal begins with an empty file, and whenever a change is made to the volume, a record is added to the file. Each record will contain a 64-bit Update Sequence Number (USN), the name of the file and a bit flag (e.g. USN_REASON_DATA_OVERWRITE) representing the change that was made.

“$UsnJrnl” has two main data streams which are, “$J”which records file and folder changes that occurred on the volume, and “$MAX”which is a small file that stores metadata about “$UsnJrnl”.

 

Forensics Value

Since “$J has records of all changes on files and folders in a volume including deleted files, this opens the doors for digital forensics investigators and threat hunters to empower their analysis with information such as the following:

  • Detection of malicious tools and bad files that were present at some point in time within the file system, which provides insight into suspicious/malicious user activity.

  • Detection of “Timestomping” activity, a technique used by attackers which is the alteration of timestamps of files to confuse investigators during their analysis.

  • Extending “Prefetch” artifacts value, which each contain the dates for the last 8 times an executable was run, which is a limitation of the artifact. This limitation can be overcome to gain the dates for more executions of an executable (Subject to the limitations of USN Journal below).

 

Limitations

  • The records indexed in the “$J” data stream has a maximum size and can be checked using the command “fsutil usn queryjournal C:” (C in this example is the target volume) and in busy volumes it can store approximately 20 days of changes on all files and folders.

  • The “$UsnJrnl” is a metafile, which makes its acquisition a little bit more complex than doing copy and paste.

 

Acquisition and Parsing of “$J” Data Stream

The “$J” USN Journal data stream is located in “VOLUME:$EXTEND/$UsnJrnl/$J” (note that each volume has its own journal). The acquisition can be conducted by any disk forensics or data preview and imaging software such as Encase, and FTK Imager.

Figure 1. Acquiring the “$J” data stream

The parsing of the “$J” data stream can be conducted using tools such as UsnJrnl2Csv64.exe, or MFTECmd.exe which will be used in this post.

Figure 2. Using “MFTECmd” to parse the “$J” data stream

We used the “--csv” switch to get the parsing results in CSV format so it can be further inspected and analyzed with software made for that purpose. Timeline Explorer.exe is a good choice for our purposes and is highly recommended for forensic investigators.

Figure 3. The parsed “$J” data stream viewed in “Timeline Explorer”

Note that Parent Path has no values, because the “$J” records don’t store such information, such information can be either correlated manually by going through the Master File Table ($MFT) and matching the entry numbers in both records, or “$MFT” can be passed to “MFTECmd” tool as an argument and automatic correlation will be conducted by the tool itself.

Figure 4. Parsing the “$J” data stream and enriching it with parsed “$MFT” information to show the full path

Figure 5. The parsed and merger of “USN Journal” and “Master File Table” records viewed in “Timeline Explorer”

 

Use Cases for The Utilization of USN Journal for Forensic Analysis

  1. Detection of Deleted Files:

    To demonstrate this use-case, we will create a malicious file, use the file, and then remove it permanently from the system, and try to detect its past presence using USN Journal, so we will download psexec.exe (Our model for the malicious tool) on the test machine and then delete it.

Figure 6. “PsExec.exe” is dropped in “C:/Users/User/Desktop/article” folder

Figure 7. Deleting “PsExec.exe” permanently from the machine

Now to hunt for this tool, we will acquire “$UsnJrnl:$J” and “$MFT” parse them and merge their results to enrich the output with the parent path for each record using “MFTECmd” as explained earlier.

Figure 8. Merged $UsnJrnl and $MFT parsed records show the full life-cycle of the file on the volume

As shown in the figure above, using information from the “Update Reasons” and “Update Timestamp” fields, we can draw a timeline of the file activity on the volume from its creation on “2022-10-24 16:12:04” and finally after the attacker used it, its deletion on “2022-10-24 16:15:16”.

 

2. Detection of “TimeStomping” Activity:

Timestomping is a technique used by attackers which is the change of file attributes that contain dates (MACB) such as the file creation and modification dates, to confuse investigators by diverging certain files from the timeline analysis of a certain incident or activity. Attackers mostly use this technique when planting a persistent malicious backdoor, so incident responders cannot detect it when looking at files planted by the attacker when searching within the incident time range.

We will do a small experiment to demonstrate how this can be done, and how USN Journal analysis can help uncover such activities.

Figure 9. Shows the current modification date for “calcx.exe” as it appears in the system

 “nTimeStomp.exe“ is a tool that allows changing timestamps of a file, and in this experiment we used it to alter the date and time information back to “1996-01-07 12:34:56.7890123” for all MACB attributes.

Figure 10. Using “nTimestomp.exe” to alter date and time attributes for “calcx.exe”

Now if we check the file metadata we can see the change reflected on the target file and a new fake date/time appears on its MACB attributes.

Figure 11. Timestomped “calcx.exe”

Now we will acquire the actual MACB dates for the file utilizing the Change Journal (USN Journal) and enriching its output by parsing and mergin the “$J” and “$MFT” metafiles. Looking for entries related to “calcx.exe” we can see the actual dates for the file activities on the volume.

Figure 12. Parsed “$J” output showing the real time and date of the file

As shown the file creation date is a fresh date and not actually back in “1996”, and in “Update Reasons” show “BasicInfoChange” which indicate a metadata change was occurred on the file, hence the the identification of the timestomping technique. This can be further enhanced to hunt for files that are timestomped without having a specific file in question, by collecting MACB attributes from “$MFT” or directly from recursively going over the volume, than joining both results by “File Name” and running an equation to calculate the difference in times for both entries, if they do not match, alert on that for “Timestomping Activity Detected”.

 

3. Prefetch Output Enrichment:

Any executable that is run on a Windows System, uses a set of imported functions from a set of .dll’s (Dynamic-Link Library). Have you noticed that running an application for the first time takes more time than running it afterwards? That’s what Prefetch is used for. It monitors application execution usage pattern and caching the dlls and other data files and makes it available in memory in advance so they can be accessed quickly when needed hence speeding up application execution. Prefetch serves an additional value, for Digital Forensics investigators which it can be used to identify which applications were running on a Windows system (evidence of execution). It also includes other information such as the last 8 times an executable was run. This advantage has also an obvious limitation that is it gives only the last 8 times an application was run. However, utilizing the “USN Journal”, this limit can be overcome as the “$J” data stream stores changes for any file (including updates on “.pf” files) so it will store all changes occurred on prefetch records (.pf). By looking for “DataExtend|DataTruncation|Close” flags which are assigned in USN records for each time the prefetch file is updated which happens at each application execution, we can identify the dates/times for more number of executions for an application, ergo exceeding the 8 times limit imposed on the Prefetch.

To demonstrate this, we will try to parse the prefetch record for “conhost.exe” in a test machine using “PECmd.exe“ then parse the USN Journal and compare outputs.

Figure 13. Parsing the Windows prefetch records with “PECmd”

Now if we filter the results for “conhost.exe”, as show in below figure, we will get the last 8 times the application was executed including the last time it was run which was at “2022-10-25 10:37:03”.

Figure 14. The last 8 times “conhost.exe” was executed, extracted from its prefetch record

Now we will acquire the USN Journal, and enrich the output with The Master File Table and see how this can help us expand our knowledge of application execution using the prefetch for more than the last 8 times. We begin by filtering the results for the “.pf” file extension , “conhost.exe” file name, and for the “DataExtend|DataTruncation|Close” update reasons.

Figure 15. Output of the enriched USN Journal

As shown in the above figure we can see changes that occurred on the “.pf” file of the executable in question, with dates and times beyond the 8 records available within the “.pf” file itself. Here we see more than 54 records for the last 54 times the application was run, and reach the conclusion that it was lunched a month before the last execution date that we got from the prefetch record itself, which is at “2022-09-26 08:22:35”.

 

Conclusion

“$UsnJrnl” contains the change records of all files and folders in a volume. It has two main data steams which are “$J”, and “$MAX”. The “$J” data stream has a forensics value that help investigators gain more information about data within the file system and leverage that for advanced use-cases such as detecting deleted files, TimeStomping and extending the value of Prefetch in windows workstations. The value of the “$UsnJrnl” shrinks when conducting a big scale threat hunting in a big environment and extends when conducting an incident response on a contained set of windows machines.

  

References

❌
❌