Makeself Self-Extracting Archive

What Makeself Archives Are

A Makeself self-extracting archive is a shell-based delivery package that unpacks itself and can execute a chosen command after extraction. That makes it convenient for software distribution, but it also means the archive blends installation logic, payload delivery, and execution in one file, which can be abused to disguise malware as a normal installer.

How Makeself Archives Behave at Runtime

At runtime, the archive typically performs three steps: it validates the shell wrapper, extracts its contents to a location on disk, and then launches the post-extraction command if one is configured. That design is operationally simple, but it also creates a trusted execution path that users may follow without inspecting the contents.

Because the wrapper is just shell code, the archive can be modified to change what is extracted, where it is written, or what runs afterward. The security question is not only whether the payload is malicious, but whether the surrounding installer logic is being used to hide that behaviour from defenders and users.

Why Makeself Archives Are Attractive to Attackers

Attackers value this format because it can look like a routine software installer while still carrying arbitrary payloads and launch instructions. That can reduce user suspicion, help malware reach execution, and make the file appear consistent with legitimate deployment activity.

The format can also carry useful metadata about how it was built, including paths, timestamps, and packaging intent. In incident response, those details can help distinguish a repackaged internal installer from an opportunistic malicious bundle, or reveal clues about the build environment that produced it.

For defenders, the key point is that the archive format itself is not the problem, the problem is that it collapses trust, delivery, and execution into a single object that is easy to distribute and hard to inspect quickly.

How to Assess Exposure and Investigate Makeself Files

Exposure starts with file provenance. If a Makeself archive appears on endpoints, download locations, email attachments, software repositories, or build artifacts, organisations should verify where it came from, whether it matches an expected software release, and whether any user or automation actually launched it.

Inspection should focus on the wrapper script, embedded filenames, extraction path, and any command that runs after unpacking. The archive should be treated as executable content, not as a passive compressed file, because the post-extraction step is where the security risk often becomes real.

When possible, compare the file hash, embedded metadata, and surrounding delivery context against the vendor or internal release process. If the archive is unexpected, internet-delivered, or delivered outside a normal software channel, assume the runtime command path deserves deeper scrutiny.

What Makeself Archives Mean for Security Operations

From a defensive standpoint, Makeself archives sit in the overlap between software distribution and malware delivery, so they deserve both endpoint and content-focused controls. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because file integrity, configuration control, and execution monitoring are all relevant to how these archives are handled.

MITRE ATT&CK Enterprise Matrix helps frame the behaviour if a Makeself archive is used as an initial access or malware delivery mechanism, while SLSA is useful when the archive appears in software delivery pipelines and provenance matters.

CIS Benchmarks are relevant where organisations need baseline hardening on hosts that may receive or execute these packages, especially when downloaded installers are part of normal operations.

Risk and Threat Considerations

Makeself archives create a practical risk because the file can look legitimate while still containing an executable payload and a built-in post-extraction action. That combination makes social engineering easier and increases the chance that a user or automated process will run untrusted code before it is properly reviewed.

Failure mechanism: The archive’s shell wrapper is treated as a normal installer, so the extraction and launch steps execute with the trust granted to software delivery rather than the scrutiny usually applied to scripts.

Impact: Attackers can deliver malware, establish code execution, and hide malicious behaviour inside a package that also contains useful metadata for staging, delivery, or environment reconnaissance.

Practitioner Guidance

What to watch for: Treat unexpected Makeself files as executable artefacts, not as benign archives. The most important judgement is whether the file originated from a trusted release path and whether its embedded launch command matches what the vendor or internal build process would normally produce.

Governance implication: Organisations should require provenance checks for self-extracting installers and define whether these packages are permitted in software distribution, endpoint deployment, and user-driven installation workflows. If they are allowed, the approval path should account for both the archive contents and the command that runs after extraction.

Practitioner takeaway: The safest mental model is that a Makeself archive is a script-driven installer with embedded payload delivery, so it deserves the same review discipline you would apply to any other executable from an untrusted source.

Related resources from NHI Mgmt Group

• How should teams secure a self-hosted document archive that contains personal records?
• What are the signs that a self-hosted records archive is too exposed?
• Self-Decrypting Archive
• What is the difference between self-service administration and safe delegated control?