> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/admin-guide/32/runtime-defense/incident-types/suspicious-binary.md). # Suspicious binary A suspicious binary incident indicates that a suspicious binary was written to the file system. The binary is either incompatible with the system architecture or the ELF header was manipulated to hinder analysis. These indicators are common signs of malware. ## Investigation The first indicator of a suspicious binary would be that the binary is incompatible with the system architecture. Attackers use automated tools frequently to download multiple binaries of different architectures when the target architecture is not known. Process *curl* downloading an ARM binary, for example, strongly indicates a breach had taken place. The following incident shows that the process *curl* downloaded the ELF file */dropbear-arm-32*, which is incompatible with the system architecture.
suspicious binary incident
The second indicator of a suspicious binary would be ELF headers with non-typical content. This indicates that the binary might have been compiled by attacking tools or otherwise hindered to avoid detection. The following incident shows that the ELF file *upx* was written to the file system and is suspected as malicious. Its ELF header indicates using anti-analysis techniques to modify the file.
suspicious binary incident2
When triggered in a container, the suspicious binary incident indicates an attacker has access to writing or modifying files in the container and might have gained full code execution in the container. Therefore, for investigating this incident you must first determine the source of the file write call. The process that called the file write is likely malicious. You should further investigate how this process gained execution. Review the forensics date for the container/host, other entries in the Incident Explorer, and audits from the source, looking for unusual process execution, hijacked processes, and explicit execution of commands. ## Mitigation A full mitigation strategy for this incident begins by resolving the issues that allowed the attacker to write or modify the file. Ensure that compliance benchmarks are appropriately applied to the affected resources. For example, if the critical file systems in the host are mounted read-only, it will be more difficult for an attacker to change system files and configurations to their advantage. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/admin-guide/32/runtime-defense/incident-types/suspicious-binary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.