Macfinger ClickFix campaign
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:
- hxxps[:]//velvet-otter-glagceis[.]life/t.js?site=4f0529f47320472732961318d7d0dfd1
- hxxps[:]//velvet-otter-glagceis[.]life/t.4b1009ff6c3f.js
- hxxps[:]//velvet-otter-glagceis[.]life/ext-b.4f9db6afd06a.js
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
- hxxps[:]//velvet-otter-glagceis[.]life/collect
ClickFix text from the Macfinger domain, saved to a text file:
SHA-256 hash: 6606a5f18184b224a56c9cb658fa26f7fce45099da548a30a8db2c5f2c70377c
- File size: 581 bytes
Initial download:
SHA-256 hash: 9d87b41c2b29ccbeac851b98f1a7dce4ab4781fec0cbc55fa6f93a6299a3d564
- File size: 4,674 bytes
- File type: Bourne-Again shell script text executable, ASCII text, with very long lines
- File location: hxxps[:]//45.150.33[.]128/92961f75b259df2?force=1
Follow-up malware from the above shell script:
SHA-256 hash: b68cdb1b46502fbce67ce3f8110682936d06afd2116af096e30abd4c8376b6dc
- File size: 33,285,040 bytes
- File type: Mach-O 64-bit executable arm64
- File location: hxxps[:]//45.150.33[.]128/d4c8083a7d97?force=1
SHA-256 hash: 1a3765e8cb0055ec31693b8f82ce9744106dee08368259661600b072c6805af4
- File size: 34,118,904 bytes
- File type: Mach-O 64-bit executable x86_64
- File location: hxxps[:]//45.150.33[.]128/2286de55f9afd?force=1
Post-infection Traffic:
- 2026-09-21 23:12:58 UTC - hxxp[:]//45.150.33[.]128 - GET /92961f75b259df2?force=1
- 2026-09-21 23:12:59 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:12:59 UTC - hxxp[:]//45.150.33[.]128 - GET /d4c8083a7d97?force=1
- 2026-09-21 23:13:04 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:05 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:05 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:08 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:08 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:11 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:14 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:15 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:20 UTC - ipinfo[.]io - HTTPS traffic
- 2026-09-21 23:13:21 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:21 UTC - hxxp[:]//95.163.153[.]80:8133 - GET /api/shell/agent
- 2026-09-21 23:13:21 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:21 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:22 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:22 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:23 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:23 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:23 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:24 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:26 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:30 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:30 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:30 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:30 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/credentials
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- 2026-09-21 23:13:31 UTC - hxxp[:]//95.163.153[.]80:8133 - POST /api/t
- And so on...
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
The Truth about GET and HTTP Standards
On Friday, Xavier talked about the newly introduced HTTP Query method. This new method was introduced to allow "GET" requests that include a body. The main reason for this was that GET requests typically do not contain a body. But what if they do?
The HTTP RFCs had "issues" defining this properly. RFC2616, which originally defined HTTP 1.1, stated in section 4.3:
A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests.
And the GET specification never discussed message bodies.
This was somewhat reworded in the newer version, RFC 7231, section 4.3.2:
??????A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
I did a quick check of a couple of common web servers I had handy, to see what would happen:
Apache
For this test, I ran Apache 2.4.68 on a Mac. It happily accepted a body with a GET request:
% nc -c localhost 8080 GET /cgi-bin/test-cgi HTTP/1.1 Host: localhost Content-Length: 6 TEST HTTP/1.1 200 OK Date: Tue, 22 Sep 2026 14:39:17 GMT Server: Apache/2.4.68 (Unix) Transfer-Encoding: chunked Content-Type: text/plain; charset=iso-8859-1 18a CGI/1.0 test script report: [some details omited] CONTENT_LENGTH = 6 BODY = TEST
The data was collected using a slightly modified version of the standard "test-cgi" script. The body was received just fine, and a 200 status was returned.
NGINX
% nc -c 10.128.1.11 80
GET /cgi-bin/test-cgi HTTP/1.1
Host: localhost
Content-Length: 6
TESTHTTP/1.1 301 Moved Permanently
Server: nginx
The request still did not trigger an error. But the body was ignored. The server started sending the response as soon as it received the headers. The body was ignored.
Python
A simple Python web server (python -m http.server 8000) appears to behave just like NGINX. The body is ignored, but a response is sent back, and the status code is 200.
Node
Node also ignores the Content-Length header and processes the request without error.
lighthttpd
lighttpd/1.4.74 will return a 400 error and refuse to process the request.
Java/Tomcat
Tomcat ignores the Content-Length header but returns a 200 response.
Do you have any web servers to test to see how they respond to a GET request with a body?
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments