Posted: Friday, October 2, 2026

foxdale.cc malware investigation: what the 04FB-fF PowerShell loader did, and what data was stolen

On a server I operate, an attacker left an obfuscated PowerShell file delivered through jsDelivr from a week-old GitHub account, 04FB-fF. I did not run it. I read both stages, the GitHub account, and the domain foxdale.cc. This is the full record of that investigation, including the one question people ask first: what data was stolen.

What was stolen, in one paragraph. The files do not contain stolen passwords, cookies, keys, wallet files, or a log of an upload. The first script only starts a hidden download. The second script only unpacks about 284 kilobytes of encrypted program code and starts it inside Microsoft Edge Update, or inside rundll32.exe if Edge Update is missing. I extracted every readable string from that encrypted program. There is no address, no password field, and no list of files. Public reporting, as of 2 October 2026, does not tie foxdale.cc or this file’s hash to a named stealer. If the hidden PowerShell never reached foxdale.cc, this chain took nothing. If it did start Edge Update or rundll32, the encrypted program ran, and every secret that lived on that server should be treated as exposed, because the sample itself does not show what that program collected.

What I found

The injected file has no real name. On disk it is 119-73c4846d6ec9. It is 2,575 lines of PowerShell. Almost every line is disposable arithmetic, fake branches, and comments that point at paths which do not exist. Those comments mention things like hidden webhooks and silent sockets. I checked them. They are bait, planted so a quick search looks busy and finds nothing useful.

The real behavior is at the end. The script locates 32-bit Windows PowerShell by wildcard, so the words for that program never sit in the file as plain text. It starts that program with no window. The hidden program is told to download a second script and run whatever comes back, in memory. Then the first script exits.

The download address is a hostname under foxdale.cc, path install.ps1. I later saved that second file locally as text and read it the same way: statically, without executing it.

The short version. This is a two-file chain. The first file is a disguised downloader. The second file unpacks an encrypted program and starts it inside Microsoft Edge Update, or inside rundll32.exe if Edge Update is not there. Neither file contains a list of stolen passwords. If the chain ran, the theft would have been done by that encrypted program, and this investigation cannot see inside it.

How I investigated

I treated both files as evidence, not as tools. I did not run them. I did not let the second script contact its author. The work was reading, cross-checking public records, and recovering only enough of the hidden text to name the next host and the next action.

I read the injected PowerShell from top to bottom and separated dead code from the one place a process is actually started.
I decoded the short strings that script assembles at the end: a web address, the program it launches, and the way that program is started. The surrounding thousands of lines never feed that launch.
I looked up the GitHub account embedded in the jsDelivr address the attacker used. jsDelivr is a normal content-delivery network. It will serve a file straight from a public GitHub repository. Attackers use it because the domain is widely trusted.
I checked the domain registration for foxdale.cc through the registrar’s public registration record.
I saved install.ps1 as a text file and unpacked its layers only far enough to see the final action. The last layer is encrypted machine code. It has no readable addresses, passwords, or file paths. I stopped there and did not execute it.

That limit matters. A write-up can describe what a loader is built to do. It cannot honestly claim a list of stolen files when the sample never recorded any.

The injected script

File 119-73c4846d6ec9 is about 238 kilobytes. Its SHA-256 is 6ecba8d846b8ceff6ad3bc5eba30f7428e7e34fa8cdbdd60ed099cef2acd5896.

The opening is a wall of functions with random names. Many of them return immediately unless a flag has already been set by a later loop. Other lines compare a variable to itself, which can never succeed, and then do nothing with the result. Mixed through this are comments that look like configuration paths. I opened those strings. They are not files on the server. They are noise.

Near the end, the script does four things I could verify by recovering the hidden strings:

It builds a web address that begins with https:// and ends at install.ps1 on a host under foxdale.cc.
It asks Windows for the 32-bit system directory and then resolves PowerShell there with wildcards. A search of the raw file for the program’s name does not hit, because the name is assembled and then expanded by the filesystem.
It starts that program with a hidden window, with no profile loaded, and with the execution policy bypassed.
The hidden program’s job is to download the address above and run the response. The loader then exits.

I am not pasting the original file, and I am not pasting a reversed script that can be run. 119-73c4846d6ec9 is malware. What follows is the behavior I recovered from the real lines, written so the action is visible without a copy that executes.

File: 119-73c4846d6ec9
Lines: 2,575. Size: about 238 KB.
Delivery, defanged: cdn.jsdelivr[.]net/gh/04FB-fF/c19e1173-a40b-4198-b705-b85466f6cde0/119-73c4846d6ec9

Recovered behavior, not a runnable copy:
1. Find 32-bit PowerShell under C:\Windows\SysWOW64
2. Start it with no window
3. Download hxxps://a611-ce4cac3252f6[.]foxdale[.]cc/install.ps1
4. Run whatever text comes back, in memory
5. Exit

This file does not open a password store.
The thousands of lines above this action are noise.

The real command avoids writing the usual download-and-run cmdlet names in full. It asks PowerShell to find commands by wildcard instead. That is an evasion choice. It is also the reason a defender should not rely on a simple text search for those cmdlet names.

I compared this shape with public reporting from early 2026. The delivery method — a brand-new GitHub account, a random repository name, and a pull through jsDelivr into hidden PowerShell — matches loaders used in ClearFake and ClickFix activity. Those campaigns often convince a person to paste a command, or they plant the command where a server will run it. I am not claiming this sample is that named group. I am saying the delivery kit looks the same. The file itself does not carry a signature that names an author.

Who published it

The jsDelivr path points at GitHub user 04FB-fF, user id 333444134. I opened the public profile and saved a screenshot. There is no name, no company, no location, no biography, and no followers. The account was created on 24 September 2026. GitHub itself only says “Joined last week.”

The hosting account as I captured it: four public repositories, a default picture, and a join date of last week.

The repository that holds this file is c19e1173-a40b-4198-b705-b85466f6cde0. It has one file, the loader, added in a commit on 1 October 2026 at 20:11 UTC. The commit message is only “Create 119-73c4846d6ec9”. The author line is 04FB-fF <e438e@lazy-park-keeper.com>. I searched that mailbox domain. It does not identify a person. It is a disposable identity reused on the account’s other commits.

The same account had four public repositories when I checked, all with random names, no description, and no stars:

Repository	What was in it
`c19e1173-a40b-4198-b705-b85466f6cde0`	This loader, about 238 KB, added 1 October 2026.
`3effbe0b-dc54-4919-a42c-0dc86dfc1122`	Another similarly sized script with a UUID-style filename.
`045D-C-Df-1907dC-F0Bc-8149-F6`	Emptied the same day. The last commit deletes a payload.
`9-029D-Fb4cA6-c476eD0-9E14-E-B`	Empty.

That pattern is a throwaway hosting account: create it, push a script, let a trusted CDN fetch it, delete the file when it is burned. I cannot attach the account to a real person from the public data. The obfuscation is generated. The variable names, the dead math, and the state-machine switches are the output of an automated crypter, not of someone typing a script by hand.

The domain it calls

foxdale.cc is a one-day-old redirect domain. It does not host a site of its own. The homepage sends visitors to https://apnews.com. The registrant is hidden behind a privacy service, and the machine that sends the redirect is hidden behind Cloudflare. The domain is one day older than the GitHub commit that calls it. The GitHub account is six days older than the domain. foxdale.com and foxdale.in are different sites on different infrastructure. Nothing in these records ties them to foxdale.cc.

Registration

I read the public registration record. The registry is Verisign for .cc, registry id 210306578_DOMAIN_CC-VRSN. The abuse contact is abuse@spaceship.com. A privacy contact form is at spaceship.com privacy contact for foxdale.cc.

Field	Value I recorded
Created	30 September 2026, 15:27 UTC
Nameservers changed	30 September 2026, 15:52 UTC, about 25 minutes later
Expires	30 September 2027
Registrar	Spaceship, Inc. (IANA 3862)
Status	clientTransferProhibited, still in the add period
DNSSEC	Unsigned
Registrant	Privacy service: WITHHELD FOR PRIVACY LLC, Lewes, Delaware. Name and email are redacted.

I sent the abuse report to abuse@spaceship.com and kept a copy of the message.

The report I sent to Spaceship: domain dates, the malicious host, the jsDelivr loader address, and the GitHub account.

Where the homepage goes

I followed the redirects instead of trusting the page title.

http://foxdale.cc returns 301 to https://foxdale.cc/.
https://foxdale.cc/ and https://www.foxdale.cc/ return 302 to https://apnews.com.
The redirect body is plain text: “Found. Redirecting to https://apnews.com.” The header X-Powered-By: Express means a Node.js application is generating it.
Cloudflare marks the response DYNAMIC, so it is generated on each request rather than stored as a static page.
An external fetch of the homepage landed on the Associated Press homepage.

Only the site root behaves that way. Paths such as /foo, /robots.txt, and /favicon.ico stop at a Cloudflare “Just a moment…” bot challenge and never reach the Express app. The malware host was not this front door. It was a separate name, a611-ce4cac3252f6.foxdale.cc, serving /install.ps1.

Pointing that front door at AP News does not mean the operator works with the Associated Press, and it does not mean the operator is in the United States. AP News is a US newsroom. The operator borrowed a trusted address the same way they borrowed jsDelivr and GitHub. I found no registration detail, profile, or commit that ties this account to AP News or to a US person.

DNS, and what Cloudflare hides

The nameservers are ben.ns.cloudflare.com and frida.ns.cloudflare.com. The SOA is ben.ns.cloudflare.com, admin mailbox dns.cloudflare.com, serial 2416344862. Authoritative answers over DNS-over-HTTPS:

Type	Value
A	`104.21.76.161`, `172.67.197.118`
AAAA	none
MX	none
TXT	none
CAA	none
CNAME	none on the apex

Those two addresses are Cloudflare’s proxy network (AS13335), not the machine running Express. The origin IP is not visible. The A records have a 300-second TTL. There is a wildcard: a made-up name, zz-not-real-9f3a.foxdale.cc, resolves to the same two Cloudflare addresses, as do www, mail, api, and the other common labels I checked. The zone also publishes an HTTPS record with HTTP/2, HTTP/3, and Encrypted Client Hello. The malware hostname rides that same wildcard. It does not need its own DNS record.

On the computer I investigated from, plain DNS queries for foxdale.cc sent to 1.1.1.1, 8.8.8.8, and 9.9.9.9 came back as 127.81.0.1 and 127.81.0.2. google.com was not rewritten. DNS-over-HTTPS returned the real Cloudflare addresses. Nothing was listening on those loopback addresses. That rewrite is on this machine or this network, not in the domain’s own DNS. After the first successful requests, TLS from this PC to the Cloudflare addresses started failing, and a browser tab ended on a connection error page. The redirect itself was already confirmed both locally and from an external fetch.

Timeline

24 Sep 2026. GitHub user 04FB-fF is created. Empty profile.
30 Sep 2026. foxdale.cc is registered at Spaceship at 15:27 UTC. Nameservers move to Cloudflare about 25 minutes later.
1 Oct 2026. The loader is committed to GitHub at 20:11 UTC. Another repository on the same account is emptied the same day.
2 Oct 2026. I investigated the injected copy, recovered the next host, and read the second script without running it.

The second script

I stored the downloaded install.ps1 as install.ps.txt. It is 64,672 lines and about 6.3 megabytes. A search of the raw file finds no web address. The text is the same idea as the first file, done more heavily: numbers that cancel out, branches that never run, and strings built one character at a time.

Following only the instruction that actually runs, I found three layers.

Layer one: hide a script from scanning

The file ends by rebuilding a short command and using it to run a decoded block. The decoding is there so Windows’ script scanner does not see the next script as plain text. I recovered that next script in memory for reading. I did not save it as something that can be launched.

Layer two: a small loader with no useful names in clear text

The recovered script turns off error display, then holds one large encoded blob. A short set of functions unpacks that blob into bytes. It then looks at the running PowerShell process, finds kernel32 and if needed kernelbase, and locates a handful of system functions by a hash of each name rather than by the name itself. Again, the names are not written in the file.

From the way those functions are called, the behavior is specific:

It builds a path to MicrosoftEdgeUpdate.exe under the 32-bit Program Files directory, splitting the folder names so they are not one contiguous string. If that file is missing, it falls back to 32-bit rundll32.exe.
It starts the chosen program suspended, so the program exists but has not begun normal work.
It allocates memory in that process, marked executable, and writes in the unpacked bytes. That buffer is about 284 kilobytes.
It queues that code on the suspended thread, waits a random fraction of a second, and resumes the thread.
If setup fails, it terminates the process it started. Either way it closes the handles and wipes the buffer it was holding.

The result is that the malicious program runs inside a process whose name is Edge Update or rundll32. There is no new executable dropped under a suspicious filename for this step. The loader itself is the suspicious parent: PowerShell, hidden, started from the 32-bit Windows directory.

Same limit as the first file: install.ps.txt is not copied below, and neither is the unpacked script. Those copies would run. This is the action they perform.

File: install.ps1, saved locally as install.ps.txt
Lines: 64,672. Size: 6,300,886 bytes.
No website address appears in the raw text.

Recovered behavior, not a runnable copy:
1. Rebuild a hidden script so a scanner does not see it as plain text
2. Unpack about 284,229 bytes of encrypted program code
3. Try to start MicrosoftEdgeUpdate.exe from
   C:\Program Files (x86)\Microsoft\EdgeUpdate\
4. If that file is missing, start
   C:\Windows\SysWOW64\rundll32.exe
5. Start the chosen program paused, before it does normal work
6. Place the encrypted program inside that process and let it continue
7. If setup fails, close the program it started
8. Wipe the buffer it was holding

The inner 284 KB has no readable website, password, browser path, or file list.
This script does not itself show what was stolen.

Layer three: encrypted code with nothing readable

I unpacked the blob the second script injects. The first bytes are machine code, not a normal Windows application with a readable header. I extracted every run of readable text, including text stored as wide characters. The longest fragments are about a dozen characters and they are garbage. There is no URL, no password field, no wallet name, no browser profile path, and no command.

So the second file’s visible purpose is delivery and camouflage. The program that would collect data, open a remote session, or do both is still encrypted. Identifying that inner program would mean executing it or breaking an encryption layer I chose not to attack. I am not going to publish a decoder for it.

What they hacked, and what data was stolen

I went through both files looking for a haul. I searched the raw text and the unpacked layers for passwords, cookies, wallet names, browser profile paths, SSH keys, cloud tokens, mailboxes, screenshots, and any upload of a directory listing. None of that is in the samples. There is no victim list and no captured secret.

What the attacker did, as far as these files prove, is this:

They created GitHub user 04FB-fF on 24 September 2026 and, on 1 October 2026, published a 2,575-line PowerShell loader, about 238 kilobytes, GitHub size 237,900 bytes.
They registered foxdale.cc on 30 September 2026 and pointed the homepage at the Associated Press site, while the real payload lived on a random hostname under the same domain.
They arranged for that loader to be fetched through jsDelivr, a normal content network that pulls public GitHub files. On the server, the script was the injected file 119-73c4846d6ec9.
If that file runs, it starts 32-bit PowerShell with no window, from C:\Windows\SysWOW64, and tells it to download install.ps1 and run the response in memory. The loader then exits. It does not itself read a password store.
If install.ps1 runs, it hides a second script from plain-text scanning, unpacks about 284 kilobytes of encrypted machine code (284,229 bytes in the copy I measured), and starts that code inside MicrosoftEdgeUpdate.exe or rundll32.exe. The second file is 64,672 lines and 6,300,886 bytes. A search of the raw file finds no web address. The unpacked program has no readable text.

That is remote code execution dressed up as a Microsoft process. It is not, in the evidence I have, a finished theft with names of files or accounts. Loaders shipped this way in other public cases are often followed by an information stealer or a remote-access tool. That is context from other incidents. It is not a finding from this server, and I am not going to guess a family name the sample does not support.

Two outcomes are possible, and only the server’s own logs can tell them apart:

If the hidden PowerShell never started, or it could not reach foxdale.cc, this chain stole nothing. The file was present. The theft did not happen.
If PowerShell did start Edge Update or rundll32, the encrypted program ran with the rights of that process. I cannot see what it took. The safe assumption is that anything that process could read should be treated as exposed: passwords, API keys, tokens, private keys, and files on that server. Rotate them from a different computer.

The checks are PowerShell logs, process creation for a hidden 32-bit powershell.exe under SysWOW64, a child MicrosoftEdgeUpdate.exe or rundll32.exe, and a DNS or proxy request for a611-ce4cac3252f6.foxdale.cc or for the jsDelivr path of user 04FB-fF.

Indicators

These are the values I would block, search for, and hand to a registrar. Dots and the scheme are written so they are not live links.

Kind	Value
Domain	`foxdale[.]cc`
Payload host	`a611-ce4cac3252f6[.]foxdale[.]cc`
Payload path	`/install.ps1`
Stage-one delivery	`cdn.jsdelivr[.]net/gh/04FB-fF/c19e1173-a40b-4198-b705-b85466f6cde0/119-73c4846d6ec9`
GitHub account	`04FB-fF` (id 333444134), created 2026-09-24
Commit identity	`e438e@lazy-park-keeper[.]com`
Stage-one SHA-256	`6ecba8d846b8ceff6ad3bc5eba30f7428e7e34fa8cdbdd60ed099cef2acd5896`
Stage-one size	2,575 lines; about 238 KB; GitHub object size 237,900 bytes
GitHub commit	`ad1b2194a9f30df099b615ac03c0dcaf905ba957`, 1 October 2026, 20:11 UTC, message “Create 119-73c4846d6ec9”
Stage-two file	`install.ps1`, 64,672 lines, 6,300,886 bytes
Code injected into Edge Update or rundll32	About 284 KB (284,229 bytes), encrypted, no readable strings
Related repo still holding a similar script when checked	`04FB-fF/3effbe0b-dc54-4919-a42c-0dc86dfc1122`, file `4a49f8d9-ab3a-49a6-83c8-7e58bfb8fe1e`, about 219 KB
Repo emptied the same day	`04FB-fF/045D-C-Df-1907dC-F0Bc-8149-F6`, last commit deletes `8cC1-45Bb-FBD`
Homepage redirect	`http://foxdale[.]cc` 301 to HTTPS, then 302 to https://apnews.com, header `X-Powered-By: Express`
Cloudflare answers	`104.21.76.161`, `172.67.197.118` (AS13335). Origin IP hidden.
Registry id	`210306578_DOMAIN_CC-VRSN`
Processes to hunt	Hidden 32-bit PowerShell from `SysWOW64`, then `MicrosoftEdgeUpdate.exe` or `rundll32.exe`

What to do if you see this

If the chain ran on a computer you administer:

Remove that computer from the network, or at least stop it from opening new outbound connections.
Block foxdale[.]cc and the jsDelivr path for 04FB-fF.
Search process and PowerShell logs for the hidden 32-bit host and for a child Edge Update or rundll32.
Look for scheduled tasks, Run keys, new services, and new local users created at the same time.
Rotate every secret that was stored on that computer. Do the rotation from a machine that did not run the script.
Report GitHub user 04FB-fF as malware hosting. Report foxdale[.]cc to abuse@spaceship.com, and to Cloudflare if the nameservers are still theirs.

If you only have the file and the logs show no child process and no request to that domain, the script was present and did not complete. Keep the file for the report. Do not run it to “see what happens.”

What this article is not. It is not a reconstruction of the crypter, not a copy of the encrypted program, and not proof of a named criminal. It is the record of one server, two files, and the public registration data around them, examined on 2 October 2026 without executing the malware.

Registration data from Spaceship’s public RDAP record for foxdale.cc. GitHub metadata from the public API for user 04FB-fF. Both malware files were read locally and were not executed.

Summary

Read on 2 October 2026. Neither file was executed. A script is only a list of instructions for the computer.

Point	Finding
First file	`119-73c4846d6ec9`, about 2,575 lines. Most of it is fake comments. It does not open a password.
Where it came from	GitHub account `04FB-fF`, opened 24 September 2026. No name, address, or photo. Delivered through jsDelivr: `cdn.jsdelivr[.]net/gh/04FB-fF/c19e1173-a40b-4198-b705-b85466f6cde0/119-73c4846d6ec9`
What the first file does	Starts hidden 32-bit PowerShell, downloads `hxxps://a611-ce4cac3252f6[.]foxdale[.]cc/install.ps1`, runs that text in memory, then exits.
Second file	`install.ps1`, saved as `install.ps.txt`. About 64,672 lines and 6.3 MB. No website address in the raw text. It does not read a password either.
What the second file runs	First choice: `MicrosoftEdgeUpdate.exe` in `C:\Program Files (x86)\Microsoft\EdgeUpdate\`. If that is missing: `rundll32.exe` in `C:\Windows\SysWOW64\`.
How it hides	Starts that program paused, puts about 284 KB of encrypted code inside it, then lets it continue. If setup fails, it closes the program. No new suspicious file is saved to disk.
Inside the 284 KB	No website, password, browser name, or file list. The sample shows where the code hides. It does not show what was collected.
Domain	`foxdale.cc`, registered 30 September 2026. Buyer hidden. Nameservers `ben.ns.cloudflare.com` and `frida.ns.cloudflare.com`. Homepage redirects to https://apnews.com with header `X-Powered-By: Express`. That is camouflage, not a link to the Associated Press or the United States. `foxdale.com` and `foxdale.in` are unrelated.
Report sent	abuse@spaceship.com. Privacy form: spaceship.com/domains/whois/contact/?d=foxdale.cc

What was stolen

If this happened	Then
Hidden PowerShell never ran, or it never reached `foxdale.cc`	Nothing was stolen. The file was only present.
Edge Update or `rundll32` did start	Treat passwords, keys, and files on that server as exposed. The sample does not name which ones. Change them from a different, clean computer.

Download ANSNEW APP For Ads Free Experiences!

✖

Yamin Hossain Shohan

Software Engineer, Researcher & Digital Creator

I’m a researcher, software engineer and digital creator focused on applying technology and creative problem-solving to build useful tools, explore new ideas and create engaging digital content.

Copyright Disclaimer

✖

All the information is published in good faith and for general information purpose only. We does not make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on ansnew.com is strictly at your own risk. We will not be liable for any losses and/or damages in connection with the use of our website. Please read our complete disclaimer. And we do not hold any copyright over the article multimedia materials. All credit goes to the respective owner/creator of the pictures, audios and videos. We also accept no liability for any links to other URLs which appear on our website. If you are a copyright owner or an agent thereof, and you believe that any material available on our services infringes your copyrights, then you may submit a written copyright infringement notification using the contact details