CYBER 366: Malware Analytics & Reverse Engineering Lab Collection

Malware Analytics & Reverse Engineering

Project Summary

#

Overview

#

CYBER 366 focused on understanding how malware behaves and how analysts investigate it safely.

The labs combined static analysis, dynamic analysis, reverse engineering, and behavioral monitoring techniques to help determine:

• what a program does
• how it executes
• what artifacts it creates
• how it interacts with the operating system
• how it attempts to hide itself
• how analysts can identify suspicious behavior

The emphasis was not on writing malware.

The emphasis was on understanding malicious software well enough to investigate, detect, document, and respond to it.

Why This Project Matters

#

Malware analysis sits at the intersection of several cybersecurity disciplines:

• security operations
• incident response
• digital forensics
• threat hunting
• reverse engineering
• endpoint security
• detection engineering

This project demonstrates how an analyst can move beyond simple alerts and begin understanding what suspicious software is actually doing.

That process improves:

• investigation quality
• incident response effectiveness
• detection logic
• threat intelligence
• reporting accuracy

It is one of the strongest technical-analysis pages in the portfolio.

Portfolio-Safe Publishing Approach

#

This page excludes:

• malware binaries
• challenge executables
• hashes
• unpacked malware samples
• screenshots
• reverse-engineering screenshots
• challenge answers
• lab solutions
• code samples
• detailed bypass instructions

Instead, it focuses on:

• workflow
• methodology
• analyst reasoning
• tool usage
• professional relevance
• investigation process

Malware Analysis Workflow

#

Static Analysis Evidence

#

The static-analysis work focused on understanding executable characteristics without execution.

Areas reviewed included:

• PE structure
• executable metadata
• imported functions
• embedded strings
• encoded strings
• stack strings
• packers
• UPX-protected binaries
• file indicators
• suspicious APIs

The objective was to gather intelligence before allowing execution.

Dynamic Analysis Evidence

#

Dynamic-analysis labs focused on observing runtime behavior.

Areas reviewed included:

• process creation
• registry modification
• file-system activity
• persistence behavior
• child-process relationships
• execution flow
• suspicious runtime actions
• environmental awareness

This allowed static findings to be validated against observed behavior.

Reverse Engineering Evidence

#

The reverse-engineering work introduced:

• IDA Pro
• Ghidra
• Binary Ninja
• disassembly concepts
• decompilation concepts
• control-flow analysis
• imported API review
• function analysis
• malware logic interpretation

The purpose was not to become a professional malware developer.

The purpose was to understand how malware works internally and how analysts can investigate it.

Packed Malware and Obfuscation

#

Several labs involved packed or obfuscated executables.

Topics included:

• UPX
• executable packing
• unpacking workflows
• hidden strings
• encoded content
• anti-analysis techniques
• analyst evasion concepts

These topics reinforced that malware often attempts to conceal its behavior.

Runtime Monitoring Evidence

#

Behavior monitoring included tools such as:

• ProcMon
• RegShot
• Process Explorer

These tools helped identify:

• registry changes
• file creation
• process activity
• parent-child process relationships
• persistence indicators
• suspicious behavior patterns

This is often where static analysis and dynamic analysis begin to converge.

Capability-to-Evidence Map

#

Professional Lessons Learned

#

The strongest lessons from CYBER 366 were:

• malware should be analyzed systematically
• static and dynamic analysis complement each other
• runtime behavior often reveals more than strings alone
• reverse engineering improves understanding of suspicious software
• malware frequently uses obfuscation and packing
• analyst workflows matter more than individual tools
• documentation is critical
• investigation quality depends on methodology
• malware analysis supports broader incident response efforts

Professional Relevance

#

This page is especially relevant for:

• cybersecurity analyst roles
• security operations
• incident response
• malware analysis
• threat investigation
• digital forensics support
• detection engineering discussions

The value of this project is not simply tool exposure.

The value is demonstrating a structured approach to investigating unknown or suspicious software.

Difference from Other Portfolio Pages

#

CYBER 440 focuses on incident response.

IST 454 focuses on forensic acquisition and evidence handling.

CYBER 366 focuses on malware behavior and reverse engineering.

Together these pages form a strong investigation-oriented evidence path.

Related Portfolio Areas

#

Next Steps

#

Potential future additions include:

• malware analysis workflow diagrams
• malware family classification notes
• detection engineering concepts
• analyst reporting templates
• YARA and IOC discussion pages
• malware-to-incident-response workflow mapping

For now, this page serves as the primary portfolio-safe summary of my CYBER 366 malware analytics and reverse-engineering work.