Unit 1: Introduction and Static Malware Analysis - Subjective Questions

Malware is software or code intentionally designed to compromise the confidentiality, integrity, or availability of a computer system, network, or data.

Major characteristics:

• Malicious intent: Performs actions that are unauthorized or harmful.
• Stealth: May conceal its files, processes, registry entries, or network traffic.
• Persistence: Attempts to remain active after reboot through services, startup entries, or scheduled tasks.
• Propagation: Some malware spreads through networks, removable media, email, or software vulnerabilities.
• Command and control: Advanced malware may communicate with an external server for instructions.
• Evasion: It may use packing, encryption, anti-debugging, or anti-virtual-machine techniques.

Common objectives:

• Stealing credentials or confidential information
• Damaging or encrypting files
• Monitoring user activity
• Disrupting services
• Gaining unauthorized remote access
• Using compromised systems for spam, cryptomining, or distributed denial-of-service attacks

Major types of malware include:

• Virus: Attaches itself to a legitimate file and spreads when the infected file is executed.
• Worm: Self-replicates and spreads automatically across networks without requiring a host file.
• Trojan horse: Pretends to be legitimate software while performing malicious activities.
• Ransomware: Encrypts files or locks systems and demands payment for restoration.
• Spyware: Secretly monitors users and collects information such as credentials or browsing activity.
• Adware: Displays unwanted advertisements and may track user behavior.
• Rootkit: Hides malicious files, processes, or system modifications and provides privileged access.
• Backdoor: Creates a hidden method of bypassing normal authentication.
• Bot or botnet malware: Converts an infected system into a remotely controlled node.
• Keylogger: Records keystrokes to capture passwords and other sensitive information.
• Fileless malware: Operates mainly in memory and uses legitimate tools such as PowerShell.

The categories may overlap; for example, a Trojan may install spyware and create a backdoor.

Malware analysis is the systematic examination of suspicious software to determine its structure, functionality, origin indicators, and potential impact.

Objectives:

• Determine whether a file is malicious.
• Identify the malware family and variant.
• Understand malicious capabilities and system changes.
• Discover indicators of compromise such as hashes, domains, IP addresses, mutexes, and file paths.
• Identify persistence, propagation, and evasion techniques.
• Support incident containment, eradication, and recovery.

Importance in cyber defence:

• Helps security teams create detection rules and signatures.
• Supports threat intelligence and attribution efforts.
• Reveals compromised assets and related attack infrastructure.
• Assists in assessing the severity and scope of an incident.
• Enables organizations to improve preventive controls.

Thus, malware analysis converts a suspicious sample into actionable information for incident response and long-term defence.

Key distinction: Static analysis studies what a sample appears capable of doing, while dynamic analysis observes what it actually does during a particular execution. Hybrid analysis correlates both forms of evidence.

A basic static malware analysis workflow includes the following steps:

1. Preserve the sample: Work on a copy, record its source, and restrict access.
2. Create fingerprints: Calculate cryptographic hashes such as MD5, SHA-1, and SHA-256.
3. Determine file type: Inspect magic bytes, headers, metadata, and file structure rather than trusting the extension.
4. Perform reputation checks: Search approved internal or external databases using the hash.
5. Use multiple anti-virus engines: Compare vendor detections and family labels cautiously.
6. Extract strings: Review ASCII and Unicode strings for URLs, commands, paths, errors, and configuration data.
7. Check for obfuscation: Examine entropy, unusual sections, import tables, overlays, and packer signatures.
8. Inspect the PE header: Study sections, timestamps, entry point, imports, exports, resources, and subsystem information.
9. Compare and classify: Correlate indicators with known samples or malware families.
10. Document findings: Record tools, hashes, observations, confidence levels, and recommended defensive actions.

The sample must not be executed during static analysis.

An analyst should determine file type using internal structure rather than relying only on the filename extension.

Methods include:

• Magic bytes: Inspect the initial bytes for known signatures. For example, Windows PE files usually begin with MZ.
• Header structure: Verify whether expected headers and fields exist at valid offsets.
• File identification tools: Use tools such as file, TrID, Detect It Easy, or hex editors.
• MIME information: Compare the detected MIME type with the claimed type.
• Internal content: Look for strings, metadata, resources, or structures associated with a particular format.
• Extension comparison: Compare the detected type with the displayed extension and investigate mismatches.
• Container inspection: Examine archives, Office documents, PDFs, and installers for embedded files.

For example, a file named report.pdf may begin with MZ, indicating that it is actually a Windows executable disguised with a PDF extension.

A file extension is only part of the filename and can be changed without modifying the actual contents of the file. Attackers exploit this weakness to deceive users and security personnel.

Examples:

• invoice.pdf.exe may appear as invoice.pdf when known extensions are hidden.
• A PE executable may be renamed from .exe to .jpg or .pdf.
• A script may use a misleading extension while being launched by an interpreter.
• A malicious Office document may contain macros or embedded executable objects.
• A polyglot file may satisfy the structural requirements of more than one file format.

Reliable verification requires:

• Checking magic bytes
• Parsing the file header
• Comparing MIME and extension information
• Using multiple file-identification tools
• Inspecting embedded content

Therefore, the extension is a useful clue but not authoritative evidence of file type.

Malware fingerprinting is the process of producing identifying characteristics that can be used to recognize, track, and compare a malware sample.

Cryptographic hashes:

• A hash function converts file content into a fixed-length digest.
• Common algorithms include MD5, SHA-1, and SHA-256.
• Identical files normally produce identical hash values.
• A small change in the file produces a substantially different cryptographic hash.

Uses in malware analysis:

• Confirming sample integrity
• Identifying exact duplicates
• Searching malware repositories and reputation services
• Creating indicators of compromise
• Correlating evidence among analysts and organizations
• Maintaining chain-of-custody records

Limitations:

• A one-byte modification creates a different hash.
• Cryptographic hashes do not reveal behavioral similarity.
• MD5 and SHA-1 have known collision weaknesses and should not be relied upon as the sole integrity mechanism.

SHA-256 is commonly preferred for reliable sample identification.

Cryptographic hashes are suitable for confirming that two files are byte-for-byte identical. However, attackers can modify metadata or add insignificant bytes to create a new hash.

Fuzzy hashes divide or summarize file content in a way that allows approximate comparison. They can help group polymorphic samples, modified binaries, or malware versions that share substantial content.

Limitations of fuzzy hashing:

• Results depend on file size and structure.
• Packed samples may produce misleading comparisons.
• A similarity score is not proof that two files belong to the same malware family.

Analysts should combine both methods with PE features, strings, imports, and behavioral evidence.

Multiple anti-virus scanning submits or checks a sample against several detection engines to obtain broader detection coverage.

Advantages:

• Different vendors use different signatures and heuristics.
• A recently discovered sample may be detected by only a few engines.
• Detection names can provide clues about malware type or family.
• The detection ratio can help prioritize suspicious samples.
• Results may reveal whether a sample is widespread or previously known.

Limitations:

• Vendor labels are often inconsistent.
• A high detection count does not explain complete malware behavior.
• False positives and false negatives are possible.
• A zero-detection result does not prove that a file is safe.
• Public uploads may disclose confidential samples to vendors or other parties.
• Attackers may test malware against the same services to improve evasion.

Therefore, multiple-engine results should be treated as supporting evidence and correlated with static and dynamic analysis.

String extraction identifies sequences of readable characters stored in a binary without executing it.

Process:

1. Extract both ASCII and Unicode strings.
2. Apply an appropriate minimum length to reduce noise.
3. Search for meaningful patterns and group related strings.
4. Record relevant indicators and verify their context.

Strings may reveal:

• URLs, domains, IP addresses, and email addresses
• File and directory paths
• Registry keys and values
• API or DLL names
• Shell commands and PowerShell statements
• Mutex names and service names
• Error messages and debugging information
• User-agent strings
• Campaign identifiers or configuration data
• References to encryption or persistence mechanisms

Caution: Strings can be encrypted, encoded, generated at runtime, or deliberately planted as false clues. Therefore, extracted strings should be validated using header inspection, disassembly, or dynamic behavior.

An analyst should classify and correlate extracted strings instead of treating every readable value as proof of malicious activity.

Interpretation approach:

• Group strings into categories such as network, filesystem, registry, process, and user-interface indicators.
• Identify Windows API names that suggest capabilities such as injection, networking, persistence, or cryptography.
• Decode common representations such as Base64, hexadecimal text, or URL encoding when justified.
• Compare domains, paths, mutexes, and commands with threat intelligence.
• Locate the corresponding string references in disassembly to determine how they are used.

Limitations:

• Packed or encrypted files may expose very few useful strings.
• Unicode or custom encodings may be missed by basic tools.
• Strings may be constructed dynamically during execution.
• Compilers and libraries introduce many benign strings.
• Attackers can insert decoy indicators.
• A listed API name does not prove that the related function is executed.

String analysis is therefore an effective triage method, but its findings require contextual verification.

File obfuscation is the deliberate transformation of code or data to make analysis and detection more difficult while preserving malicious functionality.

Common techniques:

• Executable packing
• Encryption or encoding of strings and configuration data
• Control-flow obfuscation
• API hashing or dynamic API resolution
• Insertion of junk instructions
• Compression and runtime unpacking
• Renaming or hiding sections

Indicators of packing or encryption:

• Very few readable strings
• High entropy in one or more sections
• Unusual section names such as those associated with known packers
• A small or suspicious import table containing functions such as LoadLibrary and GetProcAddress
• Entry point located in an unusual section
• Sections with suspicious permissions, such as writable and executable access
• A large overlay or inconsistent raw and virtual sizes
• Packer signatures detected by identification tools

No single indicator proves packing; analysts should combine several structural observations.

Entropy measures the uncertainty or randomness of byte values in data. For byte-oriented file analysis, Shannon entropy can be expressed as:

where is the probability of byte value .

Interpretation:

• Entropy near indicates highly repetitive data.
• Entropy approaching bits per byte indicates highly random-looking data.
• Compressed or encrypted sections often have comparatively high entropy.

Use in malware analysis:

• Calculate entropy for the whole file and individual PE sections.
• Compare sections to identify unusual concentrations of random-looking bytes.
• Correlate high entropy with other indicators such as few imports, limited strings, or abnormal entry points.

Limitations:

• Legitimate compressed resources can have high entropy.
• Some packers deliberately lower entropy to evade detection.
• High entropy cannot distinguish reliably between compression and encryption.

Thus, entropy is a heuristic indicator rather than conclusive proof of malicious obfuscation.

The Portable Executable, or PE, format is used by Windows executables, DLLs, and related binary files.

Main components:

• DOS header: Starts with the MZ signature and contains a pointer to the PE header.
• DOS stub: Usually displays a compatibility message when run under DOS.
• PE signature: Identifies the beginning of the PE structure.
• COFF file header: Contains machine type, number of sections, timestamp, and characteristics.
• Optional header: Stores the entry point, image base, subsystem, alignment values, image size, and data directories.
• Section table: Describes sections, their addresses, sizes, and permissions.
• Data directories: Point to structures such as imports, exports, resources, relocations, and certificates.

Significance:

• Reveals architecture and expected execution environment.
• Helps locate executable code and the entry point.
• Identifies imported capabilities.
• Exposes unusual permissions, malformed values, and structural inconsistencies.
• Provides evidence of packing, tampering, or masquerading.

Suspicious PE header anomalies include:

• Invalid or unusual timestamp: It may be zero, set in the future, or deliberately forged.
• Abnormal entry point: The entry point may lie outside normal code sections or inside a packed section.
• Unusual image base: It may conflict with expected values or indicate custom loading behavior.
• Inconsistent sizes: Raw size, virtual size, image size, or header size may not agree.
• Strange section names: Names may be random, blank, misleading, or associated with known packers.
• Dangerous permissions: A section may be readable, writable, and executable simultaneously.
• Unexpected subsystem: A supposed command-line utility may claim a graphical subsystem, or vice versa.
• Sparse imports: Very few imports may indicate runtime API resolution.
• Malformed data directories: Import, relocation, or resource directory values may be invalid or hidden.
• Large overlay: Additional data may exist beyond the declared PE image.

These anomalies are indicators, not proof. Legitimate protectors, installers, and compilers may also create unusual PE structures.

The import table lists external libraries and functions that a PE file expects to use. The export table lists functions that a binary, especially a DLL, makes available to other programs.

Capability clues from imports:

• File operations: Functions for creating, reading, writing, or deleting files
• Registry operations: Functions that may create persistence or modify configuration
• Networking: Socket, HTTP, DNS, and Internet-related APIs
• Process manipulation: Functions used to create processes, open processes, or allocate remote memory
• Dynamic resolution: LoadLibrary and GetProcAddress may indicate runtime API loading
• Cryptography: Encryption and hashing APIs may support ransomware or protected communication
• Service management: Service-related APIs may indicate persistence

Exports may reveal:

• DLL entry points used by loaders
• Plugin-style functionality
• Misleading or absent names
• Functions invoked through tools such as rundll32

Limitations: Imports indicate possible capabilities, not confirmed behavior. Malware may resolve APIs dynamically, use direct system calls, or include unused functions.

PE sections organize code and data within a Windows binary. Common legitimate sections include:

• .text for executable code
• .data for initialized writable data
• .rdata for read-only data
• .rsrc for resources
• .reloc for relocation information

Suspicious characteristics:

• Random, blank, misleading, or packer-related section names
• Very high entropy indicating compression or encryption
• Writable and executable permissions on the same section
• Entry point located in a resource or data section
• Large difference between raw size and virtual size
• Sections that overlap or point outside the file
• Executable code hidden in .rsrc or another non-code section
• An unusually small code section combined with a large high-entropy section
• Excessive numbers of sections or malformed alignment

Analysts should compare section names, entropy, permissions, sizes, and entry-point location. A suspicious section is a lead for further investigation rather than conclusive evidence of malware.

Malware comparison and classification identify shared characteristics that may indicate common code, functionality, infrastructure, or origin.

Comparison features:

• Exact cryptographic hashes
• Fuzzy-hash similarity
• PE metadata and section structure
• Import and export patterns
• Strings, file paths, mutexes, and registry keys
• Embedded resources and configuration formats
• Code sequences, function hashes, and compiler artifacts
• Domains, IP addresses, certificates, and user-agent strings
• Packing and obfuscation methods
• Dynamic behaviors such as persistence and process injection

Classification process:

1. Extract reliable features from each sample.
2. Normalize features to reduce irrelevant differences.
3. Compare the features with known malware collections.
4. Group samples with significant structural or behavioral similarity.
5. Assign a malware family only when sufficient evidence exists.
6. Record the confidence level and supporting evidence.

Vendor names should not be accepted blindly because naming conventions differ. Classification is strongest when static, behavioral, and threat-intelligence evidence agree.

Interpretation of findings:

• The MZ signature indicates that the sample is probably a Windows PE file.
• High entropy suggests compressed or encrypted content.
• Read-write-execute permissions are suspicious because unpacked code may be written and executed in the same region.
• A very small import table may indicate that the sample resolves APIs dynamically.
• Few readable strings are consistent with packing or string encryption.
• An entry point inside the high-entropy section strongly suggests a runtime unpacking stub.

Likely assessment:
The file is probably packed or otherwise obfuscated. These indicators increase suspicion but do not independently prove that the file is malicious.

Recommended next steps:

1. Calculate and record SHA-256 and other hashes.
2. Verify the PE structure and inspect all section sizes and permissions.
3. Check the hash in approved reputation databases.
4. Scan with multiple anti-virus engines while considering confidentiality.
5. Use packer-identification tools and search for known packer signatures.
6. Inspect imports, resources, overlays, and embedded files.
7. Search for encoded strings and dynamically resolved API hashes.
8. Execute only in an isolated sandbox if dynamic analysis is authorized.
9. Capture the unpacked memory image and reconstruct imports when possible.
10. Compare the unpacked sample with known malware families and document confidence levels.