Why This Work Matters#
Malware analysis is not only about identifying that a file is malicious. A useful analyst needs to understand what evidence supports that conclusion.
This course helped build a repeatable workflow for asking practical questions:
- What kind of file is this?
- Is the file packed or obfuscated?
- What strings or imports are visible?
- Does the executable make changes to the registry or file system?
- Does it attempt network activity?
- Does it create processes or launch other applications?
- Does it behave differently under a debugger?
- What artifacts could help identify similar behavior later?
- What information is safe to report publicly?
Those questions are directly relevant to cybersecurity analyst work, malware triage, detection engineering, incident response, endpoint investigation, and security operations.
Portfolio-Safe Publishing Approach#
Security note: This page summarizes academic malware-analysis work without publishing raw malware samples, exact exploit steps, full crackme solutions, sensitive screenshots, private academic files, or operational instructions that could be misused.
The goal is to show technical depth without exposing:
- malware binaries
- raw executable hashes
- exact compromised infrastructure details
- complete patching or bypass walkthroughs
- full crackme solutions
- private screenshots
- private academic submissions
- instructor-provided files
- lab environment details that should remain private
Instead, the work is presented as:
- sanitized workflows
- tool usage summaries
- analysis categories
- behavioral observations
- lessons learned
- skill evidence
- portfolio-safe technical outcomes
Analysis Workflow#
Initial Triage#
Reviewed file types, hashes, content types, host artifacts, and basic indicators to understand what suspicious files were present and what systems or hosts were involved.
Triage
Static Analysis#
Used tools such as strings, PEiD, VirusTotal, UPX, and FLOSS to review readable strings, packed executable behavior, file metadata, compiler hints, imported functions, and decoded strings.
Static Analysis
Dynamic Analysis#
Observed behavior in a controlled lab environment using tools such as Process Explorer, Process Monitor, and RegShot to identify process behavior, registry modifications, file writes, and network activity.
Dynamic Analysis
Reverse Engineering#
Used IDA Pro, Ghidra, and Binary Ninja concepts to locate main functions, interpret strings, review imports, follow control flow, and reason about malware behavior at a lower level.
Reverse Engineering
Behavioral Interpretation#
Mapped observed technical evidence to practical behavior such as persistence attempts, registry modification, file creation, process spawning, debugger-aware logic, keylogging indicators, and user-impacting actions.
Behavior Mapping
Reporting#
Converted technical findings into concise analysis summaries, focusing on what was observed, what it suggested, and what could be used as safe detection or investigation context.
Reporting
Lab Collection Summary#
Malware Triage and Indicators#
Early work focused on identifying downloaded file types, reviewing unique hashes, identifying potentially malicious files, and connecting host artifacts to a suspicious web event.
Initial Triage
Packed Executable Review#
Static analysis work included identifying a packed executable, unpacking it in a controlled lab context, comparing visible strings before and after unpacking, and reviewing how unpacking changed the analysis surface.
UPX + PEiD
Strings and FLOSS Analysis#
The labs used readable strings, decoded strings, and stack-string extraction to identify meaningful clues that were not obvious from a basic file review.
String Analysis
Preliminary Dynamic Analysis#
Dynamic-analysis work included process review, registry monitoring, file-write observation, and comparison of system state before and after execution in a controlled environment.
ProcMon + RegShot
Disassembly and Control Flow#
Later labs used IDA Pro and Ghidra to locate main functions, inspect strings, interpret branching behavior, review imported functions, and connect code-level observations to executable behavior.
IDA + Ghidra
Anti-Debugging Awareness#
In this lab I worked on areas such as debugger-aware behavior, including analysis of a program path that changed when debugger detection logic was present.
Anti-Debugging
Keylogging Indicators#
One advanced static-analysis lab involved identifying suspicious hook-related behavior and reasoning about how the executable could capture user input or persist in a system context.
Keylogging Indicators
Binary Analysis Tooling#
A team project explored Binary Ninja as a reverse-engineering and binary-analysis platform, including system requirements, installation flow, user interface concepts, disassembly/decompilation features, debugger support, and plugin/API capabilities.
Binary Ninja
Tools and Techniques Used#
| Area | Tools / Concepts |
|---|---|
| File triage | File type review, hash comparison, suspicious file grouping |
| Reputation review | VirusTotal-style detection review and threat-label interpretation |
| PE inspection | PEiD, entry point review, subsystem review, section review |
| Unpacking | UPX identification and unpacking in a lab context |
| String analysis | strings, FLOSS, decoded strings, stack-string review |
| Dynamic analysis | Process Explorer, Process Monitor, RegShot, clean snapshot comparison |
| Reverse engineering | IDA Pro, Ghidra, Binary Ninja concepts |
| Windows behavior | registry activity, file writes, process creation, imported API review |
| Debugging awareness | debugger detection logic and alternate execution paths |
| Reporting | portfolio-safe behavioral summary and analysis conclusions |
Technical Themes#
Static Analysis#
Static analysis helped identify what could be learned without running the executable.
This included reviewing:
- readable strings
- imported libraries
- PE metadata
- entry points
- packed versus unpacked state
- visible and decoded strings
- likely behavioral clues
- compiler and subsystem information
The important lesson was that static analysis often gives direction, but not complete proof. It can suggest behavior, but dynamic analysis or deeper reverse engineering may be needed to confirm what the program actually does.
Dynamic Analysis#
Dynamic analysis helped connect executable behavior to real system changes.
The labs included controlled observation of:
- process behavior
- registry modification
- file creation and file writes
- lack of observed network traffic in some samples
- before-and-after system state comparison
- user-impacting executable behavior
This reinforced the difference between what a file appears capable of doing and what it actually does when executed in a monitored environment.
Reverse Engineering#
IDA Pro and Ghidra were used to reason about executable behavior at a lower level.
The work included:
- locating main functions
- following control flow
- searching for meaningful strings
- reviewing imported APIs
- interpreting conditional logic
- connecting disassembly/decompiler output to real behavior
- comparing findings across tools
This was one of the strongest parts of the course because it connected malware behavior to the underlying program structure.
Anti-Debugging and Analyst Friction#
One lab introduced debugger-aware behavior.
The key lesson was that malware analysis can be affected by whether the sample detects analysis tooling. Debugger-aware logic can change execution paths, throw exceptions, terminate behavior, or mislead an analyst.
From a portfolio standpoint, this is useful because it shows awareness that malware analysis is adversarial. The sample is not always passive; it may behave differently when it detects observation.
Keylogging and User-Input Risk#
One advanced lab involved suspicious input-capture behavior.
The analysis focused on hook-related indicators, persistence-related behavior, and how a malicious executable could capture keystrokes or monitor user activity.
The portfolio-safe lesson is that keylogger analysis requires connecting multiple signals:
- imported Windows APIs
- hook-related strings
- process behavior
- persistence indicators
- file or registry artifacts
- analyst interpretation of program purpose
Binary Ninja Tool Research#
The course also included a team project on Binary Ninja.
The project covered Binary Ninja as a multi-function binary-analysis platform with capabilities such as:
- disassembly
- decompilation
- debugging
- graph-based code navigation
- cross-reference review
- intermediate language views
- plugin support
- API-driven automation
- patching and binary triage features
My portion of the project focused on installation and system requirements, including supported operating systems, resource requirements, download/setup considerations, and opening files for analysis.
Capability-to-Evidence Map#
What I Learned#
This course strengthened my understanding of how malware analysis is built from layers of evidence.
The biggest lessons were:
- static analysis gives clues, not always certainty
- packed executables can hide important strings and behavior
- unpacking can significantly change the visibility of a sample
- dynamic analysis helps confirm real system impact
- registry and file-system activity can reveal persistence or behavior that strings alone do not explain
- imported APIs can suggest behavior, but must be interpreted carefully
- disassembly and decompilation help connect observed behavior back to code structure
- anti-debugging behavior can change what an analyst sees
- binary analysis tools have different strengths, workflows, and learning curves
- malware reporting should be useful without exposing dangerous operational detail
Why This Supports My Portfolio#
This lab collection supports cybersecurity analyst, security operations, vulnerability management, incident response, and malware-analysis-aligned roles because it demonstrates the ability to:
- investigate suspicious files
- use multiple analysis tools
- connect static and dynamic findings
- interpret Windows behavior
- reason about malware capabilities
- write concise technical findings
- protect sensitive details when publishing work
- explain technical behavior in a recruiter-friendly and security-conscious way
It also complements my ServiceNow SecOps and Vulnerability Response focus. Vulnerability management and security operations are stronger when an analyst understands how malicious code behaves after exploitation or initial execution.
Portfolio-Safe Redaction Notes#
This page intentionally excludes:
- raw malware samples
- exact executable files
- full crackme solution steps
- private screenshots
- full lab submissions
- detailed patching instructions
- sensitive hashes or infrastructure details
- instructor-provided files
- step-by-step misuse instructions
The page keeps the emphasis on analysis method, tool exposure, reasoning process, and professional lessons learned.
Related Portfolio Areas#
Security Operations#
The labs connect directly to security operations work because they involve triage, evidence review, behavior analysis, and reporting.
SOC-Relevant
Malware Analysis#
The course provided hands-on exposure to malware triage, packed executables, dynamic behavior, and reverse-engineering workflow.
Malware Analysis
Reverse Engineering#
IDA Pro, Ghidra, and Binary Ninja concepts helped connect low-level code structure to executable behavior.
Reverse Engineering
Portfolio-Safe Publishing#
The case study demonstrates how sensitive academic malware work can be summarized without exposing raw samples or full solutions.
Security First
Next Steps#
This collection could be expanded later with:
- sanitized malware-analysis workflow diagrams
- a static-versus-dynamic analysis comparison table
- a safe reverse-engineering tool comparison
- a malware triage checklist
- a detection-engineering note based on behavioral indicators
- additional portfolio-safe lessons from crackme exercises
For now, this page serves as the main public summary of the CYBER 366 Malware Analytics lab collection.