Before
- Trust the extension
- Flag unusual strings as malicious
- Install the package to inspect it
Module 4 of 17
Static Triage Across PE, ELF, Scripts, and Packages
Extract defensible facts from files and package metadata without executing the artifact.
Start here
Learning objectives
- Use hashes, file signatures, metadata, strings, imports, sections, symbols, and signatures as triage evidence.
- Recognize the high-level structure of PE and ELF files without treating a parser result as proof of intent.
- Review scripts and package metadata for authority, provenance, install behavior, permissions, and dependency risk.
- Produce a prioritized static-triage report with observations, hypotheses, confidence, limitations, and safe next actions.
After
- Verify identity and provenance
- Correlate structure with a trusted baseline
- Inspect packages without lifecycle execution
Triage Without Execution
Static triage asks what can be learned from bytes and metadata without running the artifact. Begin with provenance, file size, cryptographic hashes, declared type, and the signature in the bytes. A filename or extension is a user-controlled label; compare it with a trusted parser and record discrepancies.
Triage is prioritization, not a verdict. A network-related import can appear in a legitimate updater. High entropy can come from compression, encryption, media, or generated data. A valid signature can show that bytes were signed by an identity under a policy, but it cannot guarantee the signer intended every behavior or that the signing environment was uncompromised.
Use at least two independent observations before raising a strong hypothesis, and keep an alternative explanation. The output should guide the next authorised defensive action: verify provenance, compare with a known release, request a sandboxed behavior trace, isolate an affected build, or close the lead.
Read PE Structure at a High Level
The Portable Executable format is used for Windows executables and related object files. Static triage commonly examines the DOS and PE signatures, COFF header, optional header, section table, data directories, imports, exports, resources, debug information, and certificate table. These structures help an analyst describe how the file is organised and which operating-system services it may use.
Record parse errors and inconsistencies rather than forcing a result. Compare section names, permissions, raw and virtual sizes, entry-point location, declared subsystem, compilation metadata, imported libraries, and available symbols with a benign baseline built using the same toolchain. Timestamps and debug paths can be useful leads but may be missing, reproducible, altered, or inherited from the build environment.
This course uses metadata extracts and transparent source-built utilities only. It does not distribute unknown PE files or teach changes intended to hide structure, evade inspection, or bypass security controls.
Read ELF Structure at a High Level
The Executable and Linkable Format is common on Linux and other Unix-like systems. Start with the ELF identification bytes, class, byte order, machine architecture, object type, entry point, program-header table, and section-header table. Program headers describe the segments a loader uses; section headers organise linking and analysis information. They answer related but different questions.
Review requested interpreter, needed shared libraries, dynamic symbols, notes, build ID, relocation information, and segment permissions. Compare the artifact with a source-controlled, reproducible build when possible. A stripped binary has fewer symbols but is not inherently malicious; production binaries are often stripped for size or intellectual-property reasons.
As with PE, structure creates hypotheses. It does not establish operator intent. Document the parser, version, architecture assumptions, and any data the tool could not decode.
Review Scripts as Programs and Configuration
Scripts are readable, but readability is not the same as safety. Review interpreter selection, arguments, environment-variable use, filesystem scope, child-process creation, network destinations, privilege expectations, error handling, and cleanup. Follow data flow from inputs to sensitive operations. Do not run an unknown script merely because the source is visible.
Generated or minified scripts may require formatting to read. Preserve the original and record the formatter as a transformation. Treat encoded text as data until an authorised, non-executing decoder converts it into a new traceable derivative. The course uses short, harmless source fixtures and never includes persistence, credential access, propagation, command execution from remote input, destructive actions, or evasion behavior.
Treat Packages as Supply Chain Artifacts
A package is more than its main source file. Review registry identity, namespace, publisher, version history, integrity value, signatures or attestations, license, dependency graph, archive contents, lifecycle hooks, requested permissions, generated files, and differences from the source repository or previous release. Never install an untrusted package to inspect it.
Use the ecosystem's download-without-install capability only inside an authorised, isolated workflow, or rely on instructor-provided inert manifests in this course. Compare the lockfile and build provenance with the deployed artifact. Look for unexpected ownership changes, newly introduced scripts, unusual binary blobs, dependency confusion opportunities, and large unexplained diffs, but report them as review leads rather than proof of compromise.
Write a Prioritized Triage Report
A practical report begins with artifact identity and provenance, then lists observations grouped by confidence. For each notable feature, record the exact evidence, a benign explanation, a security-relevant explanation, and the safest next authorised action. Include parser failures and blind spots.
Prioritize by likely business effect and exposure, not by how unusual a string looks. A package lifecycle hook in a production deployment path may deserve faster containment than several suspicious-looking strings in an unused test fixture. Close with a clear decision: no further action, verify with owner, compare against a trusted build, collect specific telemetry, or escalate through incident response.
Suggested Study Plan (10 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 2h 6m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 45m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 45m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 3 hours | A static-triage report covering identity, provenance, PE and ELF structure, script behavior review, package differences, alternative explanations, limitations, priority, and safe next actions. |
| Knowledge check and review | 1h 24m | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: A harmless source-built utility has a high-entropy resource section and imports a networking library. Does static triage prove it is malicious?
Reveal the defensive reasoning
No. Entropy and imports are leads, not proof of behavior or intent. Record the exact observations, compare them with the declared source and a trusted build, consider benign explanations such as compressed resources or a standard runtime, and choose the next authorised evidence needed.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.
Real world
Where this shows up
- Comparing a deployed executable with an expected release artifact.
- Reviewing a dependency ownership change and new lifecycle hook before a build proceeds.
- Triaging an unexpected script in a container image or CI workspace.
Production notes
Keep these close
- Pin parser versions and preserve raw parser output alongside the analyst summary.
- Run file parsers in disposable, least-privileged workers because parsers also process untrusted input.
- Verify artifact signatures and provenance against an explicit trust policy, not merely their presence.
- Automate baseline comparisons, then retain human review for business context and ambiguous changes.
Common mistakes
What usually breaks
- Trusting the filename extension or reported MIME type without checking the bytes.
- Treating one string, import, entropy score, or unsigned file as proof of malware.
- Installing a package to discover what its lifecycle scripts do.
- Ignoring parser errors, stripped symbols, architecture, or toolchain differences.
Security risks
Threats to watch
- Vulnerable parsers can be attacked by malformed input and should be isolated.
- Package installation can run lifecycle behavior before a reviewer sees the source.
- A compromised signing or build identity can make a signature appear reassuring.
- Overconfident static conclusions can trigger unnecessary containment or miss runtime-only behavior.
Tradeoffs
Design choices you should be able to defend
Automated static scanning
Pros
- Fast and repeatable at build scale
- Good for baseline and policy checks
Cons
- Can miss context
- Parser and rule quality vary
- May create noisy findings
Manual evidence-led review
Pros
- Handles context and ambiguity
- Can connect findings to business exposure
Cons
- Slower
- Requires trained reviewers
- Harder to apply to every artifact
Think like an engineer
Questions to answer before shipping
- Which observation changes the risk decision, and which is merely unusual?
- What trusted baseline uses the same architecture and toolchain?
- Could this package be reviewed without installation or executing lifecycle hooks?
- Which parser failure or blind spot must be visible in the final conclusion?
Key terms
Vocabulary used in this module
PE
The Portable Executable family of formats used for Windows executables, libraries, and object files.
ELF
The Executable and Linkable Format used for executables, shared objects, relocatable objects, and core files on many Unix-like systems.
Import
A reference to a function or symbol expected from another library or module.
Entropy
A statistical measure of byte distribution that can suggest compression or encryption but does not establish intent.
Lifecycle hook
A command an ecosystem can run at defined package installation, build, or publication stages.
Exercises
Practice inside the lesson
Compare Trusted and Altered Static Fixtures
Triage inert PE, ELF, script, and package metadata and identify meaningful differences without executing or installing anything.
- Verify the hashes of the supplied text, JSON, source, PE-metadata, ELF-metadata, and package-manifest fixtures.
- Identify each fixture using its recorded byte signature or schema rather than its filename alone.
- Compare trusted and altered PE and ELF metadata, listing structure differences and at least one benign explanation for each.
- Review the harmless script source for inputs, file scope, child processes, destinations, privilege needs, error handling, and cleanup without running it.
- Compare package manifests and lockfile extracts for publisher, integrity, dependencies, lifecycle hooks, permissions, and release-history changes without installing a package.
- Rank the findings by evidence, exposure, and business impact; recommend the smallest safe next action for each high-priority lead.
Expected evidence
A static-triage report covering identity, provenance, PE and ELF structure, script behavior review, package differences, alternative explanations, limitations, priority, and safe next actions.
Assessment criteria
- File identity is based on verified manifests and structure rather than extensions alone.
- PE, ELF, script, and package observations are precise and traceable to supplied evidence.
- Suspicious indicators are treated as hypotheses with plausible benign alternatives.
- No artifact is executed, installed, uploaded, or replaced with an internet sample.
- Recommendations are proportional to exposure and business impact.
Course-owned resources
Teardown
- Delete temporary working copies.
- Retain only the written defensive analysis.
Recap
Key takeaways
- Static triage extracts facts and prioritizes next actions; it does not prove intent.
- PE program structures and ELF program headers answer loader questions, while sections support linking and analysis.
- Scripts require the same input, privilege, filesystem, process, and network review as compiled programs.
- Package identity includes publisher, integrity, dependency graph, hooks, provenance, and release history.
- Every unusual feature needs evidence, an alternative explanation, and a safe next step.
Related resources