File and Hash Threat Intel

You might encounter a suspicious file, such as Setup.exe, and must get as much context about it as possible. Human-readable strings, such as filepaths, are the earliest heuristics available to an analyst. When alone, they do not prove maliciousness but can reveal attacker tradecraft patterns when viewed with scepticism.

Filepath Analysis

File paths and names are like crime scene clues, revealing attacker behaviour. Attackers may use different disk locations to hide their actions and reduce visibility. For example:

• C:\ (System drive) can be a common target for persistence mechanisms.
• C:\Users\Public profile can enable cross-user access of detonated adversary tools.
• C:\Users\Public\Public Downloads provides a high-traffic directory that would often evade strict monitoring.

Additionally, adversaries may utilise other malware staging patterns such as:

• Utilising temporary directories such as C:\Windows\Temp\ for ephemeral payloads.
• Placing payloads in writable system paths, such as C:\ProgramData\ for stealth persistence.

Filename Heuristic Indicators

Attackers are also known to modify filenames to escape detection through implementing various types of heuristic indicators, including:

• Double extensions - An example of this would be invoice.pdf.exe, which leverages default Windows settings that hide file extensions.

• System binary impersonation - A filename such as scvhost.exe abuses the user's familiarity with core system processes. Defenders should include legitimate locations for system processes in an allowlist, rather than standalone filenames.

• High-entropy Strings – A filename such as jh8F21.exe suggests automated packing or polymorphic generation, which is commonly used in a high-churn phishing operation.

• Masquerading - Filenames such as backup-2300.exe can blend with routine files, thus leveraging on reduced suspicion. Another example is a single character substitution, which can bypass detection while looking visually legitimate to an unsuspecting employee.

SOC analysts should become aware of these heuristic techniques and always flag and investigate alerts with these characteristics.

We've identified suspicious heuristics from the sample files through path and name analysis. The analysis is not conclusive, as attackers constantly rename files. We can tie the names back to the same binary through cryptographic fingerprinting through its file hash, especially SHA256 and MD5 hashes. File hashes uniquely identify files and malware, regardless of name changes. Attackers constantly rename their malware; hashes always provide an immutable and actionable way to identify it.

It is advisable to work with potentially malicious binaries in a separate, isolated environment.

We can generate and verify our file hash using the following commands:

      Command prompt: certutil -hashfile bl0gger.exe SHA256

PowerShell: Get-Filehash -Algorithm SHA256 bl0gger.exe
    

      ubuntu@tryhackme$ sha256sum bl0gger.exe
    

A few pointers as analysts when dealing with hashes:

• Store the hashes in lowercase to avoid needless differences.
• Hash what matters in your investigation. For example, if the malware lives inside a zip file, hash both the archive and the extracted binary.
• Do not leave plain strings without the context of where and when you encountered them.
• Any byte change will change the resulting hash.

Analysis With VirusTotal

Using VirusTotal, we can obtain information about our file using the SHA256 hash. Navigate to the website, enter the hash in the search and observe the file's detection details.

There are several items from the search results that would be worth taking note of. These include:

• Detection score: This represents a crowdsourced security verdict from various vendors displayed as a ratio. The higher the number, the higher the confidence threat.
• Threat labels and categories: These are vendor-specific classifications of the threat, which help confirm the threat's attribution among vendors.
• Detection rules: These are the technical signatures used by AV engines to identify threats. Typical classifications are YARA rules, Heuristic patterns, and behavioural triggers.
• Properties: This is where the core metadata about the file is found, including the file type, size, and compiled timestamp.
• Contained domains and IPs: This information covers the malware's network infrastructure.
• Contained files: This section details any files embedded or dropped during the malware's execution.

We can break down the process above into granular steps that ensure VirusTotal becomes a tactical threat intelligence platform for the SOC to pivot towards actionable defence measures.

Cross-Reference With MalwareBazaar

As the name suggests, MalwareBazaar is an all-in-one malware collection and analysis database. The project supports the following features:

• Malware Samples Upload: Security analysts can upload their malware samples for analysis and build the intelligence database. This can be done through the browser or an API.
• Malware Hunting: Hunting for malware samples is possible through various elements, such as :
  • Malware Family tagging: You will find files classified by their malware families. An example of this use is a file with only 5/70 detections on VirusTotal, but tagged as #IcedID in MalwareBazaar, should be treated as malicious.
  • YARA rule integration: Many submissions will include rules that detect related samples. As an analyst, you should take note of these rules to be added to the EDR/SIEM for future hunting.
  • Campaign attribution: Tags such as #TA551, which belong to a threat actor group, help link observed incidents to known adversaries. This can help identify coordinated attacks against an environment.
  • Sample Availability: Malware samples are available for download and analysis. Reanalysing samples in a sandbox is best practice, which we shall cover in the next task.

MalwareBazaar is a great tool for an analysis workflow that would be used to cross-reference VirusTotal results. One thing to be aware of is the tool's search syntax, which uses specific tags. For example, to search by SHA256 hash, the syntax is sha256:<file_hash>.

Dynamic Analysis for SOC

Static properties such as hashes, strings, and sections tell you identity. To understand the impact of malicious files, you need to execute them safely in a controlled environment. Sandboxes provide a disposable VM instrumented to capture every process, registry write, and network packet associated with the malware being investigated.

Security analysts will use sandboxes to do three things:

• Confirm execution - if nothing happens, your alert might be a decoy.
• Extract runtime IOCs - domains, mutexes, dropped payloads, feed hunts and detections.
• Map to ATT&CK - most sandboxes auto‑label behaviour with technique IDs, fast‑tracking your report.

As an L1 analyst, you would use the sandboxes' lookup features to quickly identify information about an obtained hash, while senior analysts would perform the other sophisticated tasks.

Sandboxing Tools

The most widely used tools for detonating wild malware are Hybrid Analysis and Joe Sandbox, each with its distinct application:

• Hybrid Analysis (HA) focuses on behaviour trees and a clean MITRE ATT&CK heatmap. It is suitable for a fast executive summary.
• Joe Sandbox (JS): goes deep, covering system calls, strings, and memory dumps. Great for reverse engineers and detection engineers.

Analysing Hybrid Analysis Report

When we search using the file hash and analyse the generated report from Hybrid Analysis, we can confirm that the file is malicious, with a threat score of 100/100.

We are also provided with information about the file's risk behaviour and the ATT&CK Techniques the threat actor observed using.

Additionally, we can gather all the file details and information that would inform our threat intelligence report. These details are vital to threat reporting for internal and external purposes, from file compositions to imports, processes called, and network connections.

Sandboxing Limitations

While sandboxing is a powerful tool for malware analysis, it has critical limitations that SOC analysts must account for when performing threat intelligence. Blindly trusting sandbox results can lead to false negatives, missed detections, or incorrect conclusions.

These limitations include, but are not limited to, the following:

1. Sandbox Evasion Techniques

   Threat actors would design their payloads to detect and evade sandboxes, leading to false negatives. Some of the common evasion tactics used include:

   • Environment Awareness Checks: Malware checks for signs of virtualised/sandboxed environments
   • Anti-Debugging & Anti-Sandboxing Tricks: Malware conducts debugger detection and checks for unique hardware IDs.
2. Limited Execution Time & Coverage

   Most sandboxes terminate analysis after 2-5 minutes, which means multi-stage malware may not fully execute. Additionally, time-delayed attacks will evade detection. As previously covered, this would mean cross-referencing other threat intelligence resources.

3. Encrypted & Obfuscated Traffic

   Many sandboxes cannot decrypt SSL/TLS traffic, leading to blind spots. This may result in HTTPS C2 Traffic appearing with no payload visibility or the malware utilising DNS tunnelling to hide data in DNS queries

4. Fileless & Living-off-the-Land (LotL) Malware

   Some threats never touch disk, bypassing traditional sandbox analysis by employing PowerShell Attacks and WMI Persistence.

Practice

Now that we have looked at gathering threat intelligence through looking at file attributes, you will now have the opportunity to investigate a suspected file Challenge.bin.sample.

Congratulations on completing the room! Threat intelligence is integral to an SOC workflow that enriches unknown binaries encountered by threat alerts.

Key Takeaways

• Validate evidence before analysis: confirm you have the exact binaries and hashes.
• Analyse filepaths and filenames for quick context: Unusual storage locations, trusted software directories, and naming tricks highlight items that warrant deeper review.
• Generate hashes early to pivot into external or internal knowledge bases.
• Observe runtime behaviour in a controlled environment to confirm intent, extract network and persistence indicators, and map activity to recognised attack techniques.
• Translate findings into a brief that lists indicators by type, summarises behaviour and provides proportionate recommendations supported by evidence.