sshoney · ssh honeypot telemetry

This is an ELF 64-bit little-endian x86-64 Linux executable, dynamically linked against glibc and libpam, with no obvious section headers reported by file; the ELF header says it is not stripped, but the missing section headers suggest the binary may be malformed or intentionally altered. The string set is partly informative rather than pure noise, showing PAM- and user-account-related symbols and cgo/runtime artifacts such as crosscall_amd64 and x_cgo_mmap, which strongly suggests a Go-based program that interfaces with PAM. Given the basename “sshd” and the presence of login/authentication strings, it plausibly masquerades as an SSH daemon or credential-handling tool, but that role is only inferred from the static evidence.

This is an ELF 64-bit little-endian x86-64 Linux executable, dynamically linked against glibc/pthread and libpam, with the file output noting missing section headers, which often indicates a deliberately modified or packed binary even though the ELF header itself is not stripped. The low first-4KB entropy suggests the start of the file is not heavily encrypted, but the tiny printable-string sample is dominated by runtime/library symbols and cgo/PAM-related names rather than clear application text, so the strings do not give a strong behavioral picture. Based on the filename “sshd” and the presence of PAM and Go/cgo symbols, it plausibly masquerades as an SSH daemon or login-related component, but that family/role inference is not certain from static evidence alone.

This is a stripped 64-bit little-endian ELF executable for x86-64 Linux, dynamically linked against glibc and libpam-related libraries, so the platform and architecture are certain from the header. The very large size, low first-block entropy, and Go/cgo-style symbols such as `crosscall_amd64`, `x_cgo_mmap`, and `_cgo_*` suggest a Go-built binary rather than a packed payload, though it is definitely stripped. The path name `sshd` is only an inference hint, but combined with PAM and account-related symbols like `mygetpwnam_r`, `mygetgrouplist`, and `pam_chauthtok`, it plausibly belongs to an SSH/login-related tool or backdoor component that interacts with system authentication.

This is a small ASCII Bash installer/dropper script for Linux, not an ELF binary: the shebang is /bin/bash and file(1) identifies it as a Bourne-Again shell script. The strings show it enumerates writable directories, skips noexec mounts, creates a hidden random filename, writes out architecture-specific payloads such as redtail.$ARCH, and then marks them executable and runs them with an ssh argument, which is consistent with a self-installing loader for a RedTail/Mirai-like botnet component. The entropy is moderate and the strings are highly readable, so this does not look packed or obfuscated.

This is a 64-bit little-endian ELF executable for x86-64 Linux, and the header says it is statically linked; the lack of a section header and the high first-4KB entropy (7.73) suggest it is packed or otherwise heavily obfuscated. The binary is not marked stripped in the provided header data, but the printable strings in the sample are mostly short, low-information fragments rather than clear API names or commands, so they do not strongly expose behavior. Based on the filename redtail.x86_64, it may belong to the Redtail/Mirai-like IoT malware ecosystem, but that attribution is only a filename-level inference rather than something confirmed by the static fields here.

This is a 64-bit little-endian ELF executable for the RISC-V architecture, statically linked and reported by file(1) as having no section header. The high first-page entropy and the mostly noisy printable strings suggest the binary is likely packed or otherwise obfuscated, so the visible strings do not support a confident behavior summary beyond that. It is stripped according to the provided header data, and the name “redtail.riscv” may hint at a specific malware build or variant, but that attribution is only a filename-level inference from the evidence given.

This is a 32-bit little-endian ELF executable for Linux on Intel i386, and the static linking plus missing section headers indicate a stripped, self-contained binary. The entropy of the first 4 KB is fairly high and the printable strings are mostly sparse, noisy-looking fragments, which is consistent with either packing or heavy obfuscation rather than a text-rich program. Given the filename `redtail.i686`, it plausibly belongs to the RedTail/Mirai-style IoT malware ecosystem, but that family attribution is only an inference from the path rather than something proven by the static metadata.

This is a 64-bit little-endian ELF executable for Linux on AArch64, statically linked and lacking section headers, which is consistent with a stripped or post-processed binary. The first 4 KB have relatively high entropy and the sampled printable strings are mostly short, seemingly random fragments, so the file may be packed or otherwise obfuscated rather than containing obvious cleartext behavior indicators. Based on the filename alone, “redtail.arm8,” it may be a Redtail/Mirai-like ARM botnet sample, but that family attribution is only a tentative inference from the path, not something established by the static metadata.

This is an ELF 32-bit little-endian ARM EABI5 Linux executable, statically linked and stripped of section headers, so it targets ARM GNU/Linux systems and is likely meant to be self-contained. The high first-4KB entropy and mostly low-value printable strings suggest it may be packed or otherwise obfuscated, with the visible strings looking more like code/data noise than clear plaintext behavior. The original name `redtail.arm7` is only a hint, but it plausibly places the sample in the Redtail/Mirai-style IoT malware space rather than identifying it with certainty.

This is a small ASCII Bourne-Again shell script for Linux x86-64 environments, as shown by the bash shebang and the `file` identification; it is not an ELF binary and there is no evidence here of packing or stripping, just a straightforward text script with moderate entropy. The visible commands suggest a cleanup/removal routine aimed at weakening persistence and stopping a miner or bot, including `systemctl stop/disable c3pool_miner` and `bot.service`, plus edits to cron locations, shell startup files, and temporary directories. The `grep -vE` filters for `wget`, `curl`, `/dev/tcp`, `nc`, `bash -i`, `sh -i`, and `base64 -d` indicate it is likely trying to remove common shell-based download or reverse-shell persistence artifacts rather than containing such payloads itself.

not yet analysed