This post was originally published on this site

This morning, I noticed specific sources "hunting" for vulnerabilities in URLs that I haven't noticed before. All of these URLs appear to be associated with diagnostic tools:

URL	Count	Vulnerability
/	1	(simple recon for index page)
/apply.cgi	20	CVE-2024-12856 Four-Faith router command injection
/cgi-bin/adv_ping.cgi	20	?
/cgi-bin/diagnostic.cgi	20	CVE-2013-7179 Seowon Intech WiMAX SWU-9100 mobile route
/cgi-bin/DiagnosticsMsg.cgi	20	?
/cgi-bin/ping.cgi	20
/cgi-bin/system_mgr.cgi	20
/cgi-bin/traceroute.cgi	20
/diag_ping.cgi	20	CVE-2020-8949 (maybe.. slightly different URL) Gocloud devices
/goform/diagTool	20	CVE-2024-48419 (maybe..) Edimax Routers
/goform/ping	20
/ping_test.cgi	20
/sys_diag.html	20

The naming of these URLs points to diagnostic tools. I was unable to find any specific vulnerabilities associated with many of the URLs, but the table above reflects those I found. But diagnostic tools often suffer from file inclusion and code execution vulnerabilities.

These tools will often call operating system commands directly, without properly separating user-provided arguments. Here is a sample vulnerability in a ping utility:

response = os.system("ping -c 1 -w2 " + hostname )

The above example is in Python. But most (all?) languages have something equivalent to "os.system" (often called "exec", "shell_exec", "process" …) Often, proper input validation and output encoding are used to prevent this vulnerability, but, in my opinion, there is a better approach that should always be used in addition to input validation, and I do not see it used much.

As with many other vulnerabilities, the root cause of command injection is the concatenation of user data and commands. Mixing control plane and data plane has been an issue since blue boxing and continues today with prompt injection. The real fix is to avoid this comingling of data and commands and instead properly separate them. Prepared statements in SQL are probably the best-known approach following this principle.

For OS command execution, we do have a very similar solution. The "system" command in your language will typically call the standard C function "exec" [1]. This family of function implements some meant to pass command line arguments: execv ("exec vector"). In addition to the command, it accepts an array of command-line arguments that are then passed to the command, properly separating the command from the arguments.

Python implements execv as part of the subprocess module:

response = subprocess.run("ping", "-c", 1, "-w", 2, hostname )

Using "subprocess.run" eliminates the possibility of command injection in this example.

For example, if you are using "google.com; ls" as a hostname, you get:

ping: cannot resolve google.com; ls: Unknown host

The entire string "google.com; ls" was used as a hostname, and the ";" no longer acted as a separator. Give it a try with other command injection strings, and you will see similar results.

There are a few cases where "execv" is not sufficient. Some operating system commands may execute additional commands passed on the command line. For example, tcpdump offers the "-z" option to execute a "postrotate command". But these cases are rare, and if you are running into them, you are back to proper input validation to use these specific command line options. In most cases, users cannot specify the command-line option itself but only the parameter; using the "execv" API will help.

A while ago, I also made a brief video with more details on preventing OS command injection: https://www.youtube.com/watch?v=7QDO3pZbum8. It also covers some of the issues around Windows, which implements different APIs.

 

[1] https://man7.org/linux/man-pages/man3/exec.3.html

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Introduction

This diary provides indicators from an Atomic MacOS (AMOS) stealer infection that I generated in my lab on July 31st, 2026.  This was distributed through a web page from getmacouscloud[.]com with instructions to paste text into a macOS Terminal window, supposedly for "macOS toolkit," but instead the text is a command to retrieve and install AMOS stealer malware.

Of note, I ran the text in the Terminal window twice, because I wanted to make sure I retrieved copies of files in the host's /tmp directory before entering the user account password.  This is why the initial infection traffic is repeated, and also likely why there are two different directories with the AMOS stealer malware persistent on my infected lab host.

Images from the Infection

Shown above: Website with instructions to copy and paste text into a Terminal window, supposedly for a "macOS toolkit" but actually for malware.

Shown above: The malicious text pasted into a Terminal Window on a macOS host.

Shown above: Files from my infected host's /tmp directory, showing data stolen and other info for AMOS stealer.

Shown above: Examples of AMOS stealer persistent on my infected macOS host.

Shown above: Traffic from the AMOS stealer infection filtered in Wireshark.

Indicators of Compromise

Traffic leading to the getmacouscloud[.]com page on Friday 2026-07-31:

• hxxps[:]//macostruecloud[.]xyz/?h=2f9548d041648a8030c040ae0e1e530b&z=304
• macspheres[.]com – HTTPS traffic
• hxxps[:]//getmacouscloud[.]com/?FSSbmnNdviEDE5S?io=16vwsb0rgIiPNIgM

URL from the base64 text provided by getmacouscloud[.]com for the initial download:

• hxxps[:]//render65[.]com/curl/f5509695dd98a9732378e5256d6235415d64d92194459bb08525c7ce5991a0c9

URLs from extracted from the payload returned from the initial download:

• hxxps[:]//grove-89[.]com/api/metrics/run?event=pasted
• hxxps[:]//render65[.]com/2kqYRM0DCrnyJgoS4gVLl_FHJRRdTUhGCbjyuYwpZ6c/m1/update

AMOS stealer C2 traffic – HTTP POST requests over TCP port 80:

• hxxp[:]/188.166.78[.]138/api/metrics/run?event=started&stage=boot
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=init_session
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=messengers
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=credentials
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=browsers
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=wallets
• hxxp[:]/188.166.78[.]138/contact
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=resolve_auth
• hxxp[:]/188.166.78[.]138/api/metrics/run?event=stage&stage=local_data
• hxxp[:]/188.166.78[.]138/api/join/
• hxxp[:]/188.166.78[.]138/api/bots/device-info
• hxxp[:]/188.166.78[.]138/api/tasks/ack
• hxxp[:]/188.166.78[.]138/api/feed/register

AMOS stealer C2 traffic – examples of HTTP GET requests over TCP port 80:

• hxxp[:]/188.166.78[.]138/api/tasks/r3dqbX7fptIT-gXz–D_nw?v=2.1
• hxxp[:]/188.166.78[.]138/api/feed/items/49359f77ebb4ffd9a95568d27a8ff3e7

SHA-256 hash: b9ec3261d633c289e51c5fa8842af4350efe68446df39cb995de82e0941d0f3c

• File size: 1,973 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text
• File description: Initial file retrieved by malicious text in Terminal window

SHA-256 hash: 13b868b3ea8b492e7fbab1ca04535c53d0930650185b5a082cd59c1974689cd5

• File size: 1,227 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text, with very long lines (315)
• File description: Script extracted from a gzip-compressed file from base64 text in the above file

SHA-256 hash: 9f25ec533cb23d020e568fb771500d7776b1300f07119ad9d0876f4329ce22ab

• File size: 297,952 bytes
• File location: /tmp/helper
• File type: Mach-O universal binary with 2 architectures: x86_64 & arm64

SHA-256 hash: 0a03cf18de28017c0ea591dffc380a6b41fedd2acc3a39e901e58d9188c01836

• File size: 438,656 bytes
• File location: /Users/[username]/Library/Application Support/.com.apple.accountsd/AccountsHelper
• File type: Mach-O universal binary with 2 architectures: x86_64 & arm64

SHA-256 hash: 01a0d5332b09bb299f7784bf0d0c43c4199269ed6a0712377279eeb999847d20

• File size: 503,152 bytes
• File location: /Users/[username]/Library/Application Support/.com.apple.metadata.mds/mdworker_shared
• File type: Mach-O universal binary with 2 architectures: x86_64 & arm64

—
Bradley Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I was asked for help with a problem similar to the following.

Here is a ZIP file, analyzed with zipdump.py:

The filename you see, is in Simplified Chinese:

zipdump.py relies on the zipfile or pyzipper Python modules to parse the given ZIP file, and have the metadata (filenames and comments) decoded correctly.

If this ZIP file would be corrupt or malformed, so that it can not be parsed by these Python modules, then you can still try to use zipdump -f option to locate individual ZIP records:

As I don't know which encoding has been used for the metadata (filenames and comments), I display the filename as a Python byte string and not as a string. If the filename is simple ASCII, it will be readable (like the extension .vir here), but if it is utf-8, for example Simplified Chinese, then you'll just see hexadecimal values.

And that is why I added a new option: –metadata_encoding. With this new option, you can specify a codec, that will be used to convert bytes into strings when option -f is used. Like this:

So here I use codec utf-8, because the filename is encoded in utf-8. How do I know this? Well, in the ZIP specification, the metadata is either ASCII (CP437 to be precise) or UTF-8 encoded. So when you check the flags, you'll know which encoding to use:

 

Flag 0x0800 means that encoding utf-8 is used. I've also added a feature that decodes the flag bits into readable text, as can be seen in the screenshot above.

If you specify another codec, like latin, for this specific ZIP file, the filenames will be decoded incorrectly:

Option –metadata_encoding can also be used when you don't use option -f, however, module pyzipper does not support this (there's a PR) and in module zipfile the flags take precedence.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

[This is a Guest Diary by Adam Cann, an ISC intern as part of the SANS.edu BACS program]

Introduction

Most of what an internet-facing SSH honeypot records is noise. Endless password guessing, and bots that log in, immediately pull down a payload, and move on. On 27 June 2026 my honeypot caught something quieter, and to me more interesting. A bot logged in as root, ran a careful survey of the machine's hardware, and then disconnected without downloading or running anything at all. No malware, no persistence, no second stage.

At first glance that looks like a failed or pointless attack. It is not. The bot was doing something deliberate: grading the target before deciding whether to send a payload on it. This post walks through what it collected, why the pattern points to cryptomining, and why a session that drops nothing still deserves a defender's attention.

The Sensor and The Session

My honeypot is a DShield sensor built on a Raspberry Pi 4, running the Cowrie SSH honeypot on an internet-facing address. Cowrie presents a convincing fake Linux shell, accepts logins with weak passwords, and records every command an attacker runs along with connection metadata such as the source IP and the SSH client fingerprint.

The session itself was brief. A bot from 91.92.40.13 connected to the SSH service, logged in as root with the password 123123 on the first attempt, ran two commands, and disconnected after about eight seconds. Two details stood out right away: the SSH client identified itself as a Go program (SSH-2.0-Go) rather than a normal client, and the whole visit lasted only seconds. Both point to automation, not a person at a keyboard.

Figure 1. The recon session, condensed. The bot inventories the hardware and checks for root, then leaves without dropping a file.

What The Bot Collected

Instead of the usual download-and-run one-liner, this bot ran a hardware survey. It gathered the operating system and kernel version, the CPU architecture, the number of CPU cores, and the CPU model. It then used lspci to look for a graphics card, searching specifically for NVIDIA. It read system uptime, listed recent logins with last, and printed everything as labeled fields (UNAME, ARCH, CPUS, CPU_MODEL, GPU, LAST). That labeled format is exactly how an automated bot packages a victim's specifications so it can parse them and make a decision.

A second command then checked whether the machine has more than 1 GB of RAM, reading /proc/meminfo and comparing against 1,048,576 KB. It ran that check through sudo -S, feeding the same password back in to test whether it could elevate to full root privileges without a prompt.

The tell is the combination. A denial-of-service botnet does not care about your graphics card. Counting CPU cores, reading the CPU model, hunting specifically for an NVIDIA GPU, and gating on a minimum amount of RAM is the profile of cryptomining or resource-hijacking triage. Miners are only worth deploying on machines with enough compute, so this operator measures the machine first and, presumably, only delivers a miner to hosts that clear the bar. The sudo step tells the bot whether it can take full control before it commits.

Figure 2. The recon-first model. The attacker grades the host, then decides whether a payload is worth delivering

Two Very Different Bots, One Weak Password

This is a good place to show why client fingerprinting matters. Earlier in the same month my honeypot logged a completely different SSH campaign: a loader that logs in, downloads an ELF binary from an attacker server using a curl, wget, and /dev/tcp fallback chain, and joins a denial-of-service botnet. It rotated through several source IPs and command-and-control servers, but its HASSH client fingerprint stayed constant, which let me tie the instances together as one campaign. The mining recon bot has a different client and a different HASSH, which tells me it is a separate actor, not the same campaign changing tactics.

Table 1. Two distinct actors seen on the same honeypot, separated by their client fingerprints.

What Is The Damage?

The question this session answers is simple: when a login runs only discovery commands and leaves without dropping anything, is it harmless? The answer is no. A recon-only session is often the first half of a two-stage attack. The operator grades the host now and returns with a tailored payload later, or hands the target to a second tool. Treating no-payload sessions as background noise means missing the casing that precedes the break-in.

This matters because defenders and honeypot operators naturally prioritize sessions that drop files, since those are obviously malicious. Sessions that only look around are easy to dismiss. This example shows that discovery activity can be a valuable early warning, and that a client fingerprint like HASSH can connect quiet reconnaissance to a later, louder payload even when the attacker changes IP addresses.

Who benefits from knowing this? SOC analysts triaging SSH activity, honeypot and DShield sensor operators, and administrators of any internet-facing Linux or cloud host. Anyone running a system with a weak or default SSH password is a candidate for exactly this kind of grading, and the mitigations below are the same ones that stop the noisier attacks too.

How To Protect Against It

• Use strong passwords. The entire attack starts with a guessable root password. Long, unique credentials stop it at the front door.
• Disable root SSH login and prefer keys. Set PermitRootLogin no and use key-based authentication. This also defeats the sudo -S password-reuse trick.
• Rate-limit logins. fail2ban or equivalent blocks an address after repeated attempts.
• Limit exposure. Do not expose SSH to the whole internet. Restrict it to a VPN or known addresses where possible.
• Alert on bulk hardware discovery. A login that reads CPU model, hunts for an NVIDIA GPU, and checks /proc/meminfo against a size threshold is unusual and worth flagging. Pivot on the HASSH to find related sessions.
• Watch for the follow-up. If a host passes this grading, a later session may deliver a miner. Monitor for sustained CPU or GPU usage and unexpected connections to mining pools.

Indicators

Source IP: 91.92.40.13 (VirusTotal: 11 malicious, 5 suspicious; ASN 197170 TechTies Inc., 91.92.40.0/24, Netherlands)
SSH client: SSH-2.0-Go
HASSH: 2ec37a7cc8daf20b10e1ad6221061ca5
Credentials used: root / 123123
Behavior: bulk hardware survey (CPU cores and model, NVIDIA GPU search, uptime, last), a /proc/meminfo check for more than 1 GB RAM, and a sudo -S privilege test

Conclusion

The most memorable activity in a honeypot is not always the session that drops malware. This one dropped nothing, and that was the point. It logged in, priced out the hardware, checked whether it could get root, and left, almost certainly to decide whether the machine was worth mining on. For defenders, the lesson is to give recon-only sessions the same curiosity the attacker gave your hardware, and to use client fingerprints to connect the quiet grading to the loud payload that may follow.

[1] https://en.wikipedia.org/wiki/Fail2ban
[2] https://github.com/DShield-ISC/dshield
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.