For an experiment, I created a script [1] that parses and send the TTY logs collected from actors or bots activity that run various commands after they successfully login the DShield sensor. Those TTY logs are sent daily at the end of each day to the DShield SIEM [2] to be correlated with all the data.
Sometimes I have to smile, or my interest is triggered, when I review new User Agent Strings in the honeypot logs.
Like when I see an "authorized" scan:
Or when I'm owned for the umpteenth time:
I regularly see URLs or email addresses for when you want to know more, or get in touch, with the persons behind a scanner:
(around the end of this list, you'll see the Belarus email address we wrote about recently)
Many variants of masscan:
Even a KGB variant.
As you can guess, "scan" is a popular word to include in your UAS:
And some wordplays are thrown in:
And they do not shy away from discrediting:
Sometime complete lists of User Agent Strings are used: the scanner will select a new UAS for each request. They don't always sanitize these list, as you can see with these weird "User Agent Strings":
These lines actually appear in this repository of User Agent Strings, to separate them in groups:
And because of a lack of quality control, these separator lines also get used as UAS in a request.
Of course, there are also attempts to exploit the parsing of a User Agent String. Shellshock may be more than 10 years old, I still see it in User Agent Strings:
And sometimes I think: "Huh, are they scanning for this too?". Like the last one:
Scanning for servers that stream GPS correction data via the NTRIP protocol (a NTRIP header was also included in this request).
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.
YARA-X's 1.21.0 release brings 5 improvements and 4 bugfixes.
One improvement is allowing stdin for CLI option –scan-list.
This allows one to generate a list of folders to scan, and pass it via a pipe. Like this example (Windows) to scan all folders with "sample" in their name:
dir /s /b /a:d c:*samples* | yr.exe scan --scan-list - rules.yara
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.
Threat Actors do not always use top-notch techniques or very complex malware to perform their attacks. Sometimes, they just abuse of existing applications…
I received a very simple phishing email:
From: contact@mejuri[.]com To: <redacted> Subject: EFT Wire Transfer Paid Invoice Receipt Dear Customer, Payment of $5745.65 was Received. Please click here to view your Order Information in PDF If this charge wasn't authorized by you, contact our customer service to cancel and receive an immediate refund. Digitally Yours, Customer Support: +1(332)638474823
“Click here” is a link pointing to:
hxxps://thelittlecupandsaucer[.]com[.]au/ScreenConnect.ClientSetup.exe
This email passed all the basic security controls. The link points to a real PE file. Today this attack vector will be blocked by browsers because downloaded an executable is suspicious!
The PE file was unknown on VT so I did a quick analysis of it. It’s a legit application: a ScreenConnect[1] client preconfigured to call-back a test account operated by the Attacker. Here is the configuration extracted from the PE file:
|
Parameter |
Value |
|
Relay (h) |
instance-v2e3e2-relay.screenconnect.com |
|
Port (p) |
443 |
|
Instance ID |
v2e3e2 (ConnectWise-hosted cloud) |
|
Instance key (k) |
RSA-2048 public key, blob SHA256 16b1cec1…9b00ead7 |
The PE is signed by ConnectWise, LLC (DigiCert G4 Code Signing CA1). The Authenticode digest matches the signed digest exactly. There's no overlay and nothing appended to or injected into the certificate table, so the signed-but-tampered config trick isn't used here.
Such tools are a gold mine for attackers because they are easy to deploy and trusted by most used! The list of “RMM” (Remote Monitoring and Management) tools is huge. Here is a brief list of the well-known ones;
If you want a better overview, check LOLRMM project [2] that maintains a list similar to the LOLBAS project!
[1] https://www.screenconnect.com
[2] https://lolrmm.io
Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Starting yesterday, our sensors picked up a small number of scans for "wordfence-waf.php". This particular script is used by Wordfence, a solution to protect WordPress sites. During the Wordfence install, the wordpress-waf.php file will be created in the site's root directory [1].
The requests themselves are unremarkable, not including any headers like User-Agent. Just the bare minimum "Host" header, which is the IP address of the targeted site.
The file does not include any secrets or configuration parameters, but it includes other scripts intended to run before any WordPress code to assist with Wordfence's integration. My best guess is that attackers may attempt to enumerate Wordfence-protected sites to limit detection. Wordfence collects intelligence from the sites it protects and often publishes information about newly detected attacks. This, in turn, "burns" exploit techniques, as other sites will not be able to protect themselves as well.
Another possible option is that these scans attempt to bypass Wordfence. By using the IP address instead of the hostname, the attacker may attempt to identify Wordfence-protected sites that are directly reachable. This could be used to bypass Wordfence protection and expose sites that rely on it to delays in patching. Web application firewalls and "virtual patching" are only temporary fixes; please follow Wordfence's guidance on preventing the bypassing of its protection. But wordfence-waf.php is part of the "Extended Protection" feature, which is designed to help prevent this type of bypass.
[1] https://www.wordfence.com/help/firewall/optimizing-the-firewall/
—
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.
Apple today released patches for all of its operating systems. However, only patches for older branches include a security fix. The vulnerability being addressed in iOS 26, macOS 26 and macOS 15 is already being exploited. iOS and macOS 27 are not affected. Today's update for the current "27" branch does not address security issues, but fixes some functional issues that got caught after the release two weeks ago. A 27.1 version was also expected to support the new foldable iPhone and will likely include specific features geared to the soon to be available device.
Introduction
My previous post on Macfinger ClickFix was two days ago, and this campaign remains active. The more I look into the malware delivered by this campaign, the more I believe it is not a variant of Atomic macOS (AMOS) Stealer as originally reported. There are too many differences between what I've documented with recent AMOS Stealer activity and what I'm now seeing with this malware. The data collection and method of exfiltration is different between these two malware families. The persistence mechanism is different. Finally, AMOS Stealer uses an installer with a combined arm64/x86_64 architecture, but this malware uses either an arm64 or an x86_64 Mach-O binary depending on the architecture of the victim's host. There are too many differences with this malware.
The malware delivered by Macfinger ClickFix is indeed an information stealer. I just don't know what to call it.
In an attempt to find out, this diary examines an infection from the Macfinger ClickFix campaign on Thursday, 2026-09-24. This infection was on a physical host running macOS 27.0 (Golden Gate).
Shown above: Example of a fake CAPTCHA/verification page generated in the Macfinger ClickFix campaign.
The Macfinder Domain and ClickFix Text
On Thursday 2026-09-24, the Macfinder domain for the fake verification page was hollow-badger-moasfraum[.]life. The clipboard-injected text was similar to what I reported in my previous diary, and I pasted it into a Terminal window.
Shown above: Clipboard-injected text from the Macfinger ClickFix campaign pasted in a Terminal window.
I saw the same message in my Terminal window after running the ClickFix text as the message noted in the Ransom-ISAC blog.
Shown above: Terminal window after running the ClickFix text.
Loader Activity
The ClickFix text retrieved a loader from hxxp[:]//45.131.215[.]56/8031e818c7a46?force=1. This loader is a shell script, and it saves a binary under the user's /Library/Caches/com.apple.securityd/ directory as com.apple.periodic.
If com.apple.periodic already exists and is running, the script will kill that running process.
Shown above: The initial downloaded shell script showing a location of a binary.
The script checks the system's architecture using uname -m and will download the appropriate payload depending on the architecture. Apple silicon is arm64, while systems using an Intel processor are x86_64. The corresponding URLs are:
Shown above: A later section of the downloaded shell script showing URLs for the follow-up malware.
A string of base64 text shown in the above image translates to a URL for the C2 server: hxxp[:]//95.163.153[.]80:8133/api/t
Post-Infection C2 Traffic
The post-infection C2 traffic on Thursday 2026-09-24 went a different IP address than I reported in my previous diary. But the URL patterns remained the same.
Shown above: Traffic from the infection filtered in Wireshark.
After retreiving the Mach-O binary, the infected macOS host reported to the C2 server that the download from the arm64 URL was good.
Shown above: The infected host reporting to the C2 server.
The infected host also reported to the server when the malware was exexuted (exec_start) and if it ran successfully (exec_ok). Then through more POST requests to the same /api/t URL, the infected host started reporting more information, and I started seeing the User-Agent string as Go-http-client/1.1.
Shown above: More traffic to the C2 server.
For C2-traffic, the biggest difference I've seen from AMOS Stealer is that this stealer uses websocket traffic.
Shown above: Request to switch protocol to websocket traffic.
In addition to websocket traffic, the infected host continued to send other HTTP POST requests. The next three images show an example of data exfiltration consisting of two HTTP requests in a single TCP stream.
These POST requests for data exfiltration used /api/credentials in the URL.
Shown above: Start of one of the HTTP POST requests for data exfiltration.
Shown above: End of one of the HTTP POST requests for data exfiltration.
Shown above: Follow-up HTTP POST request in the same TCP stream reporting "upload_session_ok."
Before exfiltrating various types of data, my infected macOS host asked to allow access to different folders and applications.
Permissions Requested By the Malware
The following images show the pop-ups I saw on my infected macOS host for access to various applications and folders.
Shown above: The first two access request pop-ups on my infected macOS host.
Shown above: The next four access request pop-ups on my infected macOS host.
The last pop-up requests were for my administrator password and my macOS Keychain password. The pop-up for the macOS Keychain password would not accept the administrator password, and I had not set up a separate password for it on the macOS host.
Shown above: The final pop-ups on my infected macOS host for passwords.
The pop-up messages were:
Persistent Malware
A copy of the malware binary was made persistent through the following .plist file:
The above .plist file runs a copy of the Mach-O binary at:
Notably, copies of the Mach-O binary were different from each other. They had slightly different file sizes and different SHA-256 hashes.
They all appear to be copies of the same binary but with some relatively slight differences from each other.
Indicators of Compromise
SHA-256 hash: c6da028e0a8a25a35efa28ba508a556d1b53d1e61113c0aaebf31a49a5668912
Description: Shell script loader from 45.131.215[.]56
SHA-256 hash: 457ed02b0a63ccf872e8459c91e2d1d6844a75414358849333f518cc538055b7
Description: x86_64 Mach-O binary from 45.131.215[.]56
SHA-256 hash: 5a2242b862ef52fe7a08af596198412a7676c948bcd64a25ce5d2e6d4b35c6fb
Description: arm64 Mach-O binary from 45.131.215[.]56
SHA-256 hash: 3e26e006210ed398f98c090e9f1c982e76b3b73f1ce3e04ee1bf8d45c56e1a89
Description: arm64 Mach-O binary first saved to disk com.apple.periodic
SHA-256 hash: 4a5952849232691849ed900609d7ff271ce296fe3cee4a81b58c28f2839fb5b6
Description: Persistent arm64 Mach-O binary SoftwareUpdate.bin
Location of files retrieved from the infected macOS host:
Macfinder ClickFix domain:
Malware hosting URLs:
Post-infection C2 URLs:
Final Words
As noted earlier, I don't think the malware is a variant of AMOS Stealer. However, I still don't know what to call it, and I could still be wrong. I suspect people more experienced with macOS malware can confirm what, exactly, this malware from the Macfinder ClickFix campaign is.
A packet capture (pcap) of the infection traffic and copies of the associated malware are available here.
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.
Yesterday, we received a phishing email with an interesting link. At first sight, it looks like garbage, but every piece of it has been carefully crafted to confuse basic security controls. Here is the defanged link:
hxxps://YKZjqa7A@gynd--[.]koncar-hr[.]com/handlers@isc.sans.edu
Let's break it down…
The first trick is the old "userinfo" field. According to RFC 3986[1], everything between the scheme and an "@" inside the authority is treated as credentials ("user:password@host"). Browsers silently ignore it, but it has two advantages for the attacker. The random string ("YKZjqa7A") makes every URL unique, which defeats exact-match blocklists and URL reputation lookups. It probably also acts as a tracking token per victim or campaign. As a side effect, the whole thing now looks like an email address to any tool that doesn't parse URLs strictly.
The second trick is the hostname itself: "gynd–.koncar-hr.com". Per the classic hostname rules (RFC 952/1123[2]), a label can't start or end with a hyphen. DNS doesn't care, and browsers happily resolve and visit it. However, strict validators, regex-based URL extractors, and some link-rewriting or sandboxing solutions may consider it invalid and simply skip it. A URL that is never extracted is never scanned. The random subdomain also suggests wildcard DNS, so each victim gets a brand-new hostname that no blocklist knows. The parent domain is a lookalike of the legitimate "koncar.hr" (a Croatian industrial group), with the ccTLD turned into a hyphenated ".com".
The last trick is the victim's email address, appended in the path. This is common with phishing kits: the page reads the path, pre-fills the login form with the victim's address, and sometimes adapts the branding to the email domain. There is another benefit, though. A poorly written parser that splits the string on the last "@" will conclude that the host is "isc.sans.edu", the recipient's own trusted domain! Per the WHATWG[3] URL standard, the authority ends at the first "/", so the browser correctly connects to the attacker's server.
The result is a single string that tells three different stories. A naive filter sees two email addresses or a link to your own domain. A strict validator sees an invalid hostname and drops it. The browser sees a perfectly valid URL and takes the victim straight to the phishing page. Attackers aren't exploiting a vulnerability here but the differences between parsers.
Tip: If you want to hunt for this kind of link, look for URLs with more than one "@", hostname labels starting or ending with a hyphen, and paths containing the recipient's own email address.
[1] https://www.rfc-editor.org/info/rfc3986/
[2] https://www.rfc-editor.org/info/rfc952/
[3] https://url.spec.whatwg.org
Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Introduction
I've found several legitimate websites with injected script for a campaign using the ClickFix social engineering technique. This particular ClickFix campaign was documented earlier this month on the Ransom-ISAC Blog, but it doesn't appear to have a nickname yet. Since this campaign is targeting macOS environments through a fingerprinting process, I'm calling it the "Macfinger ClickFix" campaign. No, this is not related to the MacFinger utility from decades ago. Instead, think of the movie Goldfinger, but with macOS malware and the internet instead of James Bond and Miss Galore.
Shown above: An image I created to represent the Macfinger ClickFix campaign.
Today's diary presents indicators from the Macfinger ClickFix campaign that I saw on Tuesday, 2026-09-22.
Images From the Infection
Shown above: First part of the Macfinger injected script in a page from a legitimate website.
Shown above: Second part of the Macfinger injected script in a page from a legitimate website.
Shown above: Fake bot protection page caused by the injected Macfinger script.
Shown above: ClickFix instructions from fake verification pop-up caused by the injected Macfinger script.
While displaying the fake bot protection page with the verification instructions, the Macfinger domain receives frequent POST requests from the victim host. These report information on the user and track the user actions. Here's an example of a POST request through HTTPS traffic after the user has clicked on the page. In this case, the user abandoned the page without following the instructions.
Shown above: POST request over HTTPS to the Macfinger domain reporting the user information.
I had tested one of the Macfinger-infected sites on Monday, 2026-09-21 which had the same post-infection traffic that I saw the next day on Tuesday, 2026-09-22. The image below shows an example of the infection traffic, with the malware files retrieved from 45.150.33[.]128 and the post-infection C2 traffic on 95.163.153[.]80 over TCP port 8133.
Shown above: Traffic from an infection filtered in Wireshark.
Indicators of Compromise
The following are indicators from Tuesday, 2026-09-22.
Traffic to the Macfinger domain:
ClickFix text from the Macfinger domain, saved to a text file:
SHA-256 hash: 6606a5f18184b224a56c9cb658fa26f7fce45099da548a30a8db2c5f2c70377c
Initial download:
SHA-256 hash: 9d87b41c2b29ccbeac851b98f1a7dce4ab4781fec0cbc55fa6f93a6299a3d564
Follow-up malware from the above shell script:
SHA-256 hash: b68cdb1b46502fbce67ce3f8110682936d06afd2116af096e30abd4c8376b6dc
SHA-256 hash: 1a3765e8cb0055ec31693b8f82ce9744106dee08368259661600b072c6805af4
Post-infection Traffic:
Final Words
The Ransom-ISAC article on this activity calls the final malware a variant of Atomic macOS (AMOS) Stealer. The indictors I found here don't fully align with the AMOS Stealer activity I've previously reported from a different (non-ClickFix) campaign, so this is a different variant than the AMOS Stealer I've looked into.
For mitigation and protection against Macfinger and other ClickFix campaigns, see guidance from the Microsoft Security Blog.
Macfinger ClickFix seems like a fairly widespread campaign, but I haven't found much about it because 1) it seems relatively new and 2) it's only targeting macOS hosts.
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.
