Lab 12 — Malware Analysis Fundamentals

Mission Information

Item	Details
Lab	12
Lab Name	Malware Analysis Fundamentals
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	Isolated Malware Analysis Lab
Primary System	CYSA-ANALYST
Primary Tools	file, SHA-256, strings, ExifTool, FLOSS, PEStudio/PE analysis tools, CyberChef, Threat Intelligence
Skills	Malware Triage, Static Analysis, File Identification, Hashing, Strings Analysis, PE Analysis, IOC Extraction, Threat Intelligence

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

During the phishing investigation from Lab 11, the SOC identified a suspicious attachment.

The message attempted to convince the recipient to open a file presented as a legitimate business document.

The attachment has now been isolated and submitted to you for analysis.

Your SOC needs answers:

What is the file?

Is the extension trustworthy?

What is its cryptographic hash?

Does threat intelligence recognize it?

Does it contain suspicious strings?

Does it reference suspicious domains or IP addresses?

Does it appear capable of network communication?

What Windows APIs does it reference?

What indicators should the SOC search for?

Should the sample be escalated for deeper analysis?

You will perform static malware triage.

You will not execute the suspicious sample during this mission.

Mission Objective: Safely examine a suspicious file using static-analysis techniques and determine whether available evidence supports a benign, suspicious, potentially unwanted, or malicious classification.

Mission Safety Rules

This mission involves suspicious-file analysis.

Follow these rules throughout the lab:

• use only instructor-provided or intentionally safe training samples

• perform analysis inside an isolated lab environment

• do not use production systems

• do not double-click suspicious executables

• do not execute unknown files

• do not enable macros

• do not upload confidential organizational samples to public services

• take snapshots before advanced malware-analysis exercises

• keep suspicious files separate from normal personal files

• do not connect a malware-analysis VM to production networks

For this mission:

STATIC ANALYSIS ONLY

Mission Objectives

By completing this lab, you will be able to:

• explain malware-analysis objectives

• distinguish static and dynamic analysis

• prepare a safe analysis workspace

• preserve suspicious-file evidence

• calculate cryptographic hashes

• verify file types

• identify extension mismatches

• inspect basic metadata

• extract readable strings

• identify suspicious strings

• understand executable-file fundamentals

• inspect PE headers

• inspect imported libraries

• identify suspicious Windows API references

• recognize packing indicators

• extract domains, URLs, IP addresses, and filenames

• enrich hashes and indicators using threat intelligence

• build an IOC inventory

• develop a malware hypothesis

• document analyst findings

1. What Is Malware Analysis?

Malware analysis is the process of examining suspicious software to understand:

What it is
What it may do
How it may operate
Which indicators it creates
How defenders can detect it
How responders should handle it

Malware analysis supports:

SOC Investigation
Incident Response
Threat Hunting
Detection Engineering
Digital Forensics
Threat Intelligence

2. Malware Analysis Levels

Malware investigation commonly includes several approaches.

Static Analysis

Examine a file without executing it.

Examples:

File Type
Hashes
Metadata
Strings
PE Headers
Imports
Embedded Resources
Indicators

Dynamic Analysis

Execute the sample inside a controlled environment and observe:

Processes
Files
Registry
Network Connections
DNS
Services
Persistence
Memory

Code Analysis

Examine program logic through:

Disassembly
Decompilation
Debugging

This lab focuses primarily on:

Static Analysis

3. Why Begin with Static Analysis?

Static analysis provides useful information without intentionally executing the suspicious program.

A typical workflow is:

Suspicious File
      ↓
Preserve Evidence
      ↓
Calculate Hash
      ↓
Identify File Type
      ↓
Inspect Metadata
      ↓
Extract Strings
      ↓
Inspect PE Structure
      ↓
Inspect Imports
      ↓
Extract IOCs
      ↓
Threat Intelligence
      ↓
Assessment

4. Prepare the Analysis Environment

Use your isolated:

CYSA-ANALYST

VM.

Before analysis:

Take VM Snapshot
Disable Shared Folders if unnecessary
Disable Clipboard Sharing if unnecessary
Confirm Analysis Directory
Verify Network Configuration

For suspicious samples requiring deeper analysis, a dedicated malware-analysis VM is preferable.

5. Create the Investigation Workspace

Create:

mkdir -p ~/CySA-Lab/Investigations/LAB12/{Samples,Hashes,Strings,Metadata,IOCs,Screenshots,Findings}

Create investigation notes:

touch ~/CySA-Lab/Investigations/LAB12/investigation-notes.md

Use:

Investigation ID:
LAB12-MALWARE-001

6. Preserve the Original Sample

Place the instructor-provided sample inside:

~/CySA-Lab/Investigations/LAB12/Samples/

Example:

suspicious-sample.bin

Do not rename the original unless required by your lab instructions.

Create a working copy:

cp suspicious-sample.bin suspicious-sample-working.bin

The workflow should remain:

Original Sample
      ↓
Preserved
      ↓
Working Copy
      ↓
Analysis

7. Record Initial Evidence

Record:

Original Filename
File Size
Source
Date Received
Analyst
Investigation ID

Check file size:

ls -lh suspicious-sample.bin

Example evidence table:

Field	Value
Investigation	LAB12-MALWARE-001
Filename	suspicious-sample.bin
Size	<record>
Source	Phishing Investigation
Status	Quarantined
Execution	Not Performed

8. Calculate SHA-256

Run:

sha256sum suspicious-sample.bin

Store the result:

sha256sum suspicious-sample.bin > ../Hashes/sha256.txt

Record:

SHA-256:
<hash>

SHA-256 becomes one of your primary file indicators.

9. Calculate Additional Hashes

For comparison with threat-intelligence sources, you may also calculate:

md5sum suspicious-sample.bin

and:

sha1sum suspicious-sample.bin

Record:

MD5
SHA-1
SHA-256

Prefer SHA-256 for modern IOC tracking.

10. Why Hashes Matter

A cryptographic hash acts like a file fingerprint.

Conceptually:

File
 ↓
Hash Algorithm
 ↓
Unique-Looking Digest

Analysts use hashes to:

Identify Samples
Compare Files
Search Threat Intelligence
Track Malware
Create Detection Indicators
Verify Evidence Integrity

A hash alone does not explain malware behavior.

11. Verify the File Type

Never trust the filename extension.

Run:

file suspicious-sample.bin

Possible output might indicate:

PE32 executable
PDF document
ZIP archive
Microsoft Office document
ELF executable
ASCII text

Compare:

Filename Extension
        vs
Actual File Type

12. Investigate Extension Mismatch

Suppose the attachment is named:

Invoice.pdf

but file reports:

PE32 executable

This is a major warning sign.

Attackers may use misleading filenames such as:

Invoice.pdf.exe
Report.docx.scr
Payment.jpg.exe
Resume.pdf.lnk

13. Understand File Signatures

Operating systems and analysis tools can identify files using characteristic byte sequences.

These are often called:

Magic Bytes

Examples include signatures associated with:

PE Executables
PDF
ZIP
PNG
JPEG

This is generally more reliable than trusting the filename extension.

14. Inspect the Beginning of the File

Use:

xxd -l 64 suspicious-sample.bin

For a Windows PE executable, you may observe:

4d 5a

which corresponds to:

MZ

This is a common DOS-header signature found in Windows PE files.

15. Inspect Metadata

If ExifTool is installed:

exiftool suspicious-sample.bin

Review available metadata such as:

File Type
File Size
Timestamps
Architecture
Compiler Information
Version Information
Product Name
Company Name

Treat metadata as evidence that can potentially be manipulated.

16. Save Metadata

Run:

exiftool suspicious-sample.bin > ../Metadata/exiftool.txt

This preserves the output for your report.

17. Look for Suspicious Metadata

Potentially interesting findings include:

Missing company information
Unexpected product name
Unusual timestamps
Internal filenames
Debug paths
Suspicious version strings
Mismatch between claimed application and metadata

No single metadata anomaly proves malicious intent.

18. Extract ASCII Strings

Run:

strings suspicious-sample.bin > ../Strings/ascii-strings.txt

Review:

less ../Strings/ascii-strings.txt

Search for meaningful text.

19. What Can Strings Reveal?

Strings may expose:

URLs
Domains
IP Addresses
Filenames
Registry Paths
Commands
User-Agent Strings
Error Messages
API Names
Mutex Names
Debug Paths
PowerShell Commands
Executable Names

Example:

https://example.invalid/update
cmd.exe
powershell.exe
Software\Microsoft\Windows\CurrentVersion\Run

These would justify additional investigation.

20. Search for URLs

Run:

grep -Ei 'https?://' ../Strings/ascii-strings.txt

Record suspicious results in:

../IOCs/urls.txt

For example:

grep -Eio 'https?://[^ "]+' ../Strings/ascii-strings.txt > ../IOCs/urls.txt

Review the output manually.

21. Search for Domain-Like Strings

You may search strings for domain patterns.

For example:

grep -Eio '[A-Za-z0-9.-]+\.[A-Za-z]{2,}' ../Strings/ascii-strings.txt

Expect false positives.

Manual validation is required.

22. Search for IP Addresses

Use:

grep -Eo '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b' ../Strings/ascii-strings.txt

Again, validate the results.

Not every IP-like string is necessarily a real network indicator.

23. Search for Windows Paths

Search:

grep -Ei 'C:\\|Windows\\|AppData|ProgramData|Temp' ../Strings/ascii-strings.txt

Potential paths may indicate:

Dropped Files
Configuration Locations
Persistence Locations
Temporary Storage

24. Search for Registry References

Search:

grep -Ei 'HKEY_|HKCU|HKLM|CurrentVersion|Run\\|RunOnce' ../Strings/ascii-strings.txt

Interesting references may indicate possible registry interaction.

Static strings alone do not prove the program actually modifies those keys.

25. Search for Command Interpreters

Search:

grep -Ei 'cmd\.exe|powershell|wscript|cscript|rundll32|regsvr32' ../Strings/ascii-strings.txt

These executables have legitimate uses.

Their presence becomes more interesting when combined with additional evidence.

26. Search for Networking Indicators

Search:

grep -Ei 'http|https|User-Agent|socket|connect|InternetOpen|WinHttp|WinInet' ../Strings/ascii-strings.txt

These may suggest network-related capabilities.

Again:

Capability ≠ Confirmed Behavior

27. Extract Unicode Strings

Windows executables often contain UTF-16LE strings.

If supported by your strings implementation:

strings -el suspicious-sample.bin > ../Strings/unicode-strings.txt

Review:

less ../Strings/unicode-strings.txt

You may find indicators absent from normal ASCII output.

28. Use FLOSS for Enhanced String Extraction

If FLOSS is available:

floss suspicious-sample.bin

FLOSS can help recover:

Static Strings
Stack Strings
Decoded Strings
Tight Strings

This is useful when malware attempts to hide useful text.

Save output:

floss suspicious-sample.bin > ../Strings/floss-output.txt

29. Understand String Obfuscation

Malware authors may hide indicators through:

Encoding
Encryption
Stack Strings
String Construction
Packing
Character Substitution

Therefore:

No suspicious strings

does not necessarily mean:

File is benign

30. Determine Whether the File Is a PE

If file identifies:

PE32

or:

PE32+

the sample uses the Windows Portable Executable format.

PE files include:

DOS Header
PE Header
Optional Header
Section Table
Sections
Import Table
Export Table
Resources

31. Understand Basic PE Structure

Conceptually:

+---------------------+
| DOS Header          |
+---------------------+
| PE Header           |
+---------------------+
| Optional Header     |
+---------------------+
| Section Table       |
+---------------------+
| .text               |
+---------------------+
| .data               |
+---------------------+
| .rdata              |
+---------------------+
| .rsrc               |
+---------------------+

Section names vary between programs.

32. Inspect the PE with a Static Analysis Tool

If using a Windows analysis VM, open the sample in a tool such as PEStudio.

Do not execute it.

Review:

Architecture
Compilation Timestamp
Entry Point
Sections
Imports
Libraries
Strings
Indicators
Resources
Entropy

Capture the findings.

33. Investigate PE Sections

Common section names include:

.text
.data
.rdata
.rsrc
.reloc

Suspicious samples may contain:

Unusual section names
Very high entropy
Unexpected permissions
Large packed sections
Few recognizable sections

These are indicators requiring further investigation.

34. Understand Entropy

Entropy can help identify data that appears highly compressed or encrypted.

Conceptually:

Normal Structured Data
      ↓
Lower / Moderate Entropy

versus:

Compressed / Encrypted Data
      ↓
Higher Entropy

High entropy does not automatically mean malware.

Legitimate software can also contain compressed or encrypted data.

35. Investigate Imported Libraries

Windows executables commonly import libraries such as:

kernel32.dll
user32.dll
advapi32.dll
ws2_32.dll
wininet.dll
winhttp.dll
shell32.dll

The imported libraries can provide clues about program capabilities.

36. Investigate API Imports

Potentially interesting API categories include:

Process Operations

CreateProcess
OpenProcess
TerminateProcess

File Operations

CreateFile
WriteFile
DeleteFile

Registry Operations

RegOpenKey
RegSetValue
RegCreateKey

Networking

connect
socket
InternetOpen
InternetConnect
WinHttpOpen

Memory Operations

VirtualAlloc
VirtualProtect

These APIs also appear in legitimate software.

Interpret them in combination.

37. Understand Capability Analysis

Suppose a sample imports:

InternetOpen
InternetConnect
CreateFile
WriteFile
RegSetValue

A reasonable hypothesis could be:

Potential Network Communication
        +
Potential File Creation
        +
Potential Registry Modification

Do not state:

The malware definitely performs all these actions.

Static analysis reveals potential capability—not necessarily executed behavior.

38. Identify Suspicious API Combinations

Certain combinations may justify deeper investigation.

For example:

OpenProcess
VirtualAllocEx
WriteProcessMemory
CreateRemoteThread

may be associated with process-injection techniques.

But the analyst must still validate behavior through additional evidence.

39. Investigate Embedded Resources

PE resources may contain:

Icons
Dialogs
Configuration
Embedded Executables
Compressed Data
Images
Version Information

Suspicious files may embed secondary payloads.

Do not extract and execute embedded content.

40. Look for Packing Indicators

Possible packing indicators include:

High Entropy
Very Few Imports
Unusual Section Names
Small Import Table
Known Packer Signatures
Large Compressed Section

Packing is not automatically malicious.

Legitimate software may also use packers.

41. Search for Known Packer Names

Depending on the sample, strings or static tools may identify:

UPX

or another packer.

If identified, record:

Possible Packing:
Yes / No / Unknown

Do not attempt unpacking unless the exercise specifically requires it.

42. Extract Potential IOCs

Create IOC categories:

File Hashes
Domains
URLs
IP Addresses
Filenames
Registry Paths
Mutexes
User-Agent Strings
Email Indicators

Store findings under:

~/CySA-Lab/Investigations/LAB12/IOCs/

43. Build the IOC Inventory

Create:

Type	Indicator	Source	Confidence
SHA-256	<hash>	Sample	High
Domain	example[.]invalid	Strings	Medium
URL	hxxps://example[.]invalid/a	Strings	Medium
IP	192[.]0[.]2[.]50	Strings	Medium
Registry	HKCU\...\Run	Strings	Low/Medium
Filename	update.exe	Strings	Medium

Confidence represents how strongly the indicator is associated with the sample.

44. Defang Network Indicators

For documentation, convert:

https://example.invalid

to:

hxxps://example[.]invalid

And:

192.0.2.50

to:

192[.]0[.]2[.]50

This helps prevent accidental interaction with malicious infrastructure.

45. Perform Hash Reputation Analysis

Search the sample’s:

SHA-256

using an approved threat-intelligence or malware-reputation service.

Possible outcomes:

Known Malicious
Known Benign
Previously Observed
Unknown

Record:

Detection Count
Classification
Malware Family if available
First Seen
Last Seen
Relevant Tags

46. Do Not Upload Sensitive Samples

Prefer:

Hash Lookup

before:

File Upload

For organizational investigations, uploading an unknown internal file to a public service may disclose sensitive information.

Follow organizational policy.

47. Investigate Domain Reputation

For extracted domains, investigate:

Reputation
Historical Observations
Malware Associations
Phishing Associations
DNS Context

Record relevant findings.

48. Investigate IP Reputation

For suspicious IP addresses, review:

Reputation
Hosting Context
Previous Malicious Activity
Associated Domains
Observed Malware

Do not classify an IP solely because it belongs to cloud or hosting infrastructure.

49. Correlate Indicators

Suppose static analysis identifies:

SHA-256
   ↓
Known Malware Family

and strings identify:

Domain A
IP B

and threat intelligence shows:

Domain A → malicious
IP B → associated with same campaign

Confidence increases because independent evidence agrees.

50. Search the SIEM for Extracted IOCs

Return to your SIEM.

Search for:

SHA-256
Domain
IP Address
Filename
URL

depending on available telemetry.

Potential data sources include:

Zeek
Suricata
DNS
Endpoint Logs
Proxy Logs
EDR

51. Search for the Suspicious Domain

If the sample contains:

example[.]invalid

search your SIEM for the non-defanged form within the controlled environment.

Determine:

Which endpoint queried it?
When?
How often?
Did a network connection follow?

52. Search for the Suspicious IP

Search:

<IOC IP>

Review:

Source Host
Destination
Port
Timestamp
Protocol

This can connect static malware findings to enterprise telemetry.

53. Search for the File Hash

If endpoint security telemetry includes hashes, search:

SHA-256

Determine:

Which hosts contain or executed the file?

In this lab, execution should not occur.

In a real incident, this search helps determine scope.

54. Correlate with the Phishing Investigation

The investigation may now evolve:

Phishing Email
      ↓
Suspicious Attachment
      ↓
SHA-256
      ↓
Static Analysis
      ↓
Embedded Domain
      ↓
Threat Intelligence
      ↓
SIEM Search

This demonstrates how separate SOC investigations connect.

55. Build the Evidence Chain

Example:

08:45
Phishing Email Delivered

08:46
Attachment Received

08:50
Attachment Submitted to SOC

09:00
SHA-256 Calculated

09:05
Static Analysis Identifies Domain

09:10
Threat Intelligence Identifies Suspicious Reputation

09:15
SIEM Search Identifies Related Endpoint Activity

Your actual timeline will depend on your lab evidence.

56. Develop an Initial Malware Hypothesis

Based on static evidence, create a hypothesis.

Example:

The sample is a Windows PE executable disguised as a document.

Static analysis identified networking-related APIs and an embedded external domain.

Threat-intelligence enrichment indicates the file hash or related infrastructure has suspicious associations.

The sample should therefore be treated as potentially malicious pending deeper behavioral analysis.

Notice the wording:

Potentially
Appears
Suggests
Consistent With

Avoid claiming unobserved behavior as fact.

57. Distinguish Evidence from Inference

Example:

Evidence

File is PE32.
SHA-256 is X.
String contains domain Y.
WinInet APIs are imported.

Inference

The sample may communicate over the network.

Not Yet Confirmed

The sample connects to domain Y when executed.

This distinction is essential in professional malware reporting.

58. Determine Whether Dynamic Analysis Is Required

Ask:

Are important strings hidden?

Is the file packed?

Is behavior unclear?

Does static analysis reveal suspicious capabilities?

Do we need to observe network behavior?

Do we need to determine persistence?

Do we need to observe child processes?

If yes:

Escalate to Controlled Dynamic Analysis

Do not execute the sample casually.

59. Assign Malware Triage Classification

Possible classifications:

Benign
Potentially Unwanted
Suspicious
Likely Malicious
Known Malicious
Inconclusive

Your classification should reflect available evidence.

60. Assign Confidence

Use:

Low Confidence
Medium Confidence
High Confidence

Example:

Classification:
Likely Malicious

Confidence:
Medium

Reason:
Static indicators are suspicious, but behavioral execution has not yet been observed.

61. Map Potential Behavior to MITRE ATT&CK

Only map behaviors supported by evidence.

Potential examples may include:

Command and Scripting Interpreter
Ingress Tool Transfer
Application Layer Protocol
Modify Registry
Process Injection

Do not map techniques merely because they are common malware behaviors.

62. Build a Malware Triage Table

Category	Finding	Assessment
File Type	PE32	Executable
Extension	.pdf claimed	Mismatch
SHA-256	<hash>	IOC
Strings	External domain	Suspicious
Imports	Networking APIs	Network capability
Registry References	Run key	Persistence hypothesis
Packing	Possible	Requires review
Reputation	Suspicious	Supporting evidence
Execution	Not performed	Static analysis only

63. Mission Challenge — Suspicious Attachment Triage

Your SOC provides a suspicious attachment recovered from the phishing investigation.

Using only static-analysis techniques, determine:

1. What is the original filename?

2. What is the actual file type?

3. Does the extension match the file?

4. What is the SHA-256?

5. What are the MD5 and SHA-1 values?

6. What metadata is available?

7. Are suspicious strings present?

8. Are URLs embedded?

9. Are domains embedded?

10. Are IP addresses embedded?

11. Are suspicious filenames present?

12. Are registry references present?

13. Are command interpreters referenced?

14. Is the sample a PE file?

15. What architecture does it use?

16. What sections are present?

17. Are any sections unusual?

18. Is entropy suspicious?

19. Which libraries are imported?

20. Which APIs are noteworthy?

21. Does the sample appear packed?

22. What potential capabilities are visible?

23. What does hash reputation indicate?

24. What does infrastructure reputation indicate?

25. Are extracted indicators present in the SIEM?

26. What is your classification?

27. What is your confidence?

28. Is deeper dynamic analysis required?

64. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB12/investigation-notes.md

Use:

# LAB12 Malware Analysis

## Investigation ID

LAB12-MALWARE-001

## Sample Information

- Original Filename:
- File Size:
- Source:
- Actual File Type:

## Hashes

- MD5:
- SHA-1:
- SHA-256:

## Metadata

Document relevant metadata.

## Strings Analysis

Document:
- URLs
- domains
- IP addresses
- filenames
- commands
- registry references
- unusual strings

## PE Analysis

Document:
- architecture
- entry point
- sections
- entropy
- imported libraries
- noteworthy APIs
- resources
- packing indicators

## Potential Capabilities

Document only capabilities supported by static evidence.

## Indicators of Compromise

Document:
- hashes
- domains
- IP addresses
- URLs
- filenames
- registry indicators

## Threat Intelligence

Document reputation findings.

## SIEM Correlation

Document whether extracted indicators appear elsewhere in the environment.

## Classification

Benign / Potentially Unwanted / Suspicious / Likely Malicious / Known Malicious / Inconclusive

## Confidence

Low / Medium / High

## Dynamic Analysis Required?

Yes / No

Explain why.

## Analyst Assessment

Summarize findings.

## Recommended Actions

Document next steps.

65. Example Analyst Findings

A simulated assessment might resemble:

Investigation:
LAB12-MALWARE-001

Original Filename:
Invoice.pdf

Actual File Type:
Windows PE Executable

Extension:
Misleading

Static Analysis:
Suspicious strings and networking-related imports identified.

Network Indicators:
External domain identified within the sample.

Registry Indicators:
Potential persistence-related registry reference identified.

Threat Intelligence:
Sample hash or associated infrastructure exhibited suspicious reputation.

Execution:
Not performed.

Assessment:
Static evidence is consistent with a potentially malicious Windows executable delivered using a misleading filename.

Classification:
Likely Malicious

Confidence:
Medium

Recommendation:
Quarantine the sample, search enterprise telemetry for extracted indicators, block confirmed malicious indicators according to policy, and escalate the sample for controlled dynamic analysis.

66. Recommended Response Actions

For a suspicious or malicious sample, possible defensive actions include:

Preserve Sample
Maintain Quarantine
Search Hash Across Endpoints
Search Domains Across DNS Logs
Search IPs Across Network Telemetry
Search URLs Across Proxy Logs
Identify Additional Recipients
Block Confirmed Malicious Indicators
Investigate Potential Execution
Review Parent / Child Processes
Investigate Persistence
Isolate Affected Endpoint if Required
Escalate for Dynamic Analysis
Update Detection Rules
Document Findings

Actions should follow organizational policy.

67. Evidence to Capture

Capture:

01-sample-inventory.png
02-sha256.png
03-file-type.png
04-magic-bytes.png
05-metadata.png
06-ascii-strings.png
07-unicode-strings.png
08-url-extraction.png
09-domain-extraction.png
10-ip-extraction.png
11-registry-strings.png
12-command-strings.png
13-pe-overview.png
14-pe-sections.png
15-pe-imports.png
16-suspicious-apis.png
17-entropy.png
18-packing-indicators.png
19-threat-intelligence.png
20-ioc-inventory.png
21-siem-ioc-search.png
22-malware-triage-table.png
23-analyst-assessment.png

68. Validation Checklist

• Malware-analysis safety rules were reviewed

• Isolated analysis environment was used

• Original sample was preserved

• Working copy was created

• File size was documented

• MD5 was calculated

• SHA-1 was calculated

• SHA-256 was calculated

• Actual file type was identified

• Filename extension was compared with file type

• Magic bytes were inspected

• Metadata was collected

• ASCII strings were extracted

• Unicode strings were reviewed

• URLs were searched

• Domains were searched

• IP addresses were searched

• File paths were reviewed

• Registry references were reviewed

• Command-interpreter references were reviewed

• Networking indicators were reviewed

• PE structure was understood

• PE sections were reviewed

• Imported libraries were reviewed

• Noteworthy APIs were identified

• Entropy was considered

• Packing indicators were reviewed

• IOC inventory was created

• Network indicators were defanged for reporting

• Hash reputation was investigated

• Domain/IP reputation was investigated

• SIEM was searched for extracted IOCs

• Evidence was distinguished from inference

• Malware hypothesis was documented

• Classification was assigned

• Confidence was assigned

• Need for dynamic analysis was determined

• Evidence screenshots were captured

69. Mission Review

In this mission, you moved from investigating the delivery mechanism to investigating the suspicious file itself.

The investigation evolved from:

Phishing Email
      ↓
Suspicious Attachment

into:

Suspicious File
      ↓
Preserve Evidence
      ↓
Hashing
      ↓
File Identification
      ↓
Metadata
      ↓
Strings
      ↓
PE Analysis
      ↓
Imports
      ↓
IOC Extraction
      ↓
Threat Intelligence
      ↓
SIEM Correlation
      ↓
Malware Assessment

The critical lesson is:

Static analysis helps analysts understand what a suspicious file may be capable of without intentionally executing it.

But you must also remember:

Static Evidence
      ≠
Observed Runtime Behavior

A strong malware analyst separates:

What We Observed
      ↓
What We Can Infer
      ↓
What Still Requires Validation

Skills Developed

After completing this mission, you should be able to:

• safely triage suspicious files

• preserve malware evidence

• calculate and use cryptographic hashes

• identify actual file types

• detect misleading extensions

• inspect file metadata

• extract ASCII and Unicode strings

• identify network indicators

• identify registry indicators

• understand PE structure

• analyze PE sections

• inspect imported libraries

• recognize noteworthy Windows APIs

• identify potential packing indicators

• extract and organize IOCs

• enrich indicators with threat intelligence

• correlate malware IOCs with SIEM telemetry

• distinguish capability from observed behavior

• classify suspicious samples

• determine when deeper analysis is required

• produce structured malware-analysis findings

What’s Next?

Lab 13 — Endpoint Malware Investigation

You have now statically analyzed a suspicious file.

The next question is:

Did it execute on an endpoint, and what happened afterward?

In the next mission, you will shift from sample-focused analysis to endpoint-focused investigation.

You will investigate:

• suspicious process execution

• parent-child process relationships

• process command lines

• file creation

• suspicious directories

• persistence indicators

• registry activity

• scheduled tasks

• services

• PowerShell activity

• network connections

• DNS activity

• file hashes

• IOC pivoting

• process timelines

• evidence correlation

• containment decisions

The investigation progresses from:

Suspicious Sample
      ↓
Static Analysis
      ↓
Potential Capabilities

to:

Endpoint Telemetry
      ↓
Process Execution
      ↓
System Changes
      ↓
Network Activity
      ↓
Persistence
      ↓
Incident Scope

➡️ Next: Lab 13 — Endpoint Malware Investigation