[BUG] Website download link got hacked #595

Activity

1. LiMiSi23

   added

   bugSomething isn't workingSomething isn't working

   on Aug 8, 2026
2. wunanc commented on Aug 13, 2026

   

   wunanc

   on Aug 13, 2026

   More actions

   I’m absolutely furious.

   Last night, I searched for this software on Bing and opened what I repeatedly verified to be the official website. After convincing myself it was legitimate, I clicked the download button at the bottom of the page. Since I believed I was on the official site, I followed the download instructions without any hesitation. Unfortunately, I didn’t pay attention to the address bar at the time and didn’t realize the download page was actually fake.

   It wasn’t until I entered my Mac login password that I realized I had just executed malware. I immediately disconnected my Mac from the Internet, launched Codex in Restricted Mode, set the reasoning level to the highest setting, and started dealing with the malware. After about half an hour, I finally managed to contain it and terminate all of its processes.

   With Codex’s help, I extracted three malware samples. Here are the VirusTotal links:

   • Sample 1: https://www.virustotal.com/gui/file/bea0c323310d5f0ea6fe59ff336de17c7a84c83ea7e9eae4461b480fa1b200ce?nocache=1
   • Sample 2: https://www.virustotal.com/gui/file/6006327d42b84cfeba5777b8b5ec6a654dd2002531929d41876ae0038edeeea4?nocache=1
   • Sample 3: https://www.virustotal.com/gui/file/314324caa4017fe3702e090a68895cdb98f000ec55a7cee63cddbfde571c2e63?nocache=1

   Seriously, these samples came at a high cost. They cost me valuable personal data and a significant number of Codex tokens. I hope they’re useful.

   And to the people behind this malware: screw you.

   One more thing: this issue has been open for five days. Why hasn’t it been fixed yet? How can this still be left unresolved? This puts more users at risk every day, and I honestly find that extremely irresponsible.
   

   😕React with 😕4Reacted by 深远, Nisura Indisa, wunanc and Kush Namdev
3. nisuraaa commented on Aug 26, 2026

   

   nisuraaa

   on Aug 26, 2026

   More actions

   I caught myself before entering the system password but still decided to wipe all my devices in my network.

   The fact that it's still hacked after 2 weeks is just unbelievable

   😕React with 😕1Reacted by wunanc
4. wunanc commented on Aug 26, 2026

   

   wunanc

   on Aug 26, 2026

   More actions

   I caught myself before entering the system password but still decided to wipe all my devices in my network.

   The fact that it's still hacked after 2 weeks is just unbelievable

   What? Can the malware still compromise the system after wiping the drive? What should I do then? I wiped mine as well, and I even went as far as entering the password?!
5. nisuraaa commented on Aug 27, 2026

   

   nisuraaa

   on Aug 27, 2026

   More actions

   I caught myself before entering the system password but still decided to wipe all my devices in my network.
   The fact that it's still hacked after 2 weeks is just unbelievable

   What? Can the malware still compromise the system after wiping the drive? What should I do then? I wiped mine as well, and I even went as far as entering the password?!

   It is unlikely it survives a full erase of the drive. I'd be worried about the sessions stealing.
6. wunanc commented on Aug 27, 2026

   

   wunanc

   on Aug 27, 2026

   More actions

   I caught myself before entering the system password but still decided to wipe all my devices in my network.
   The fact that it's still hacked after 2 weeks is just unbelievable

   What? Can the malware still compromise the system after wiping the drive? What should I do then? I wiped mine as well, and I even went as far as entering the password?!

   It is unlikely it survives a full erase of the drive. I'd be worried about the sessions stealing.

   It shouldn't be able to spread over the network, right? I had an AI analyze it, and it said there are just two programs that keep each other alive in a loop on the infected device.
7. diverqent commented on Aug 27, 2026

   

   diverqent

   on Aug 27, 2026

   More actions

   @nisuraaa @wunanc First of all, I’m sorry to hear this happened to both of you. However, if the website you used was https://pearcleaner.com/, this unfortunately isn’t a bug, as that is not the official website and never has been.
   The official website is https://itsalin.com/appInfo/?id=pearcleaner. From there, the download link for Pearcleaner points to this official GitHub repository.
   It has been known for some time that the former website is fake and spreads malware. See this Reddit thread for more information and discussion. @alienator88 is aware of the situation and has since added a warning about it to the README here on GitHub.
8. delahondes commented on Aug 31, 2026

   

   delahondes

   on Aug 31, 2026

   More actions

   Just for other users, as the website is still active here is an update:

   Second case, 25 Aug 2026 — infrastructure has rotated, and the payload now persists as root

   IT admin here; one of our users was hit and I spent a day on the forensics. The June PSA covers the basics, so I'll only post what's changed — because two of the checks circulating publicly would have told our user he was clean.

   All domains have rotated; the kit hasn't. June used filemapleshare.com / pine-1.com / pearl91.com. Ours used href.li → nexload.site/?js=download&user=1066 → fileteapulsezone.com/apph3?enHash= → facetecho7.com, beaconing to loom-20.com/api/metrics/run?event=pasted. Three generations in ten weeks, but the beacon path, the /update endpoint, the BuildID header and /tmp/helper are byte-identical. So domain blocklists don't help. The only stable node is pearcleaner.com, still live and still ranking.

   Correction 1 — the shared history grep misses this variant. It looks for pine-1|filemapleshare|openssl base64 -d -A|/tmp/helper. Ours used base64 -D (capital D) and none of those hosts, so it returns nothing on a machine that was definitely infected. Also check both histories — our user's login shell was bash, so .zsh_history was empty and everything was in .bash_history. Use:

   grep -nEi 'base64 -[dD]|openssl base64 -d|curl -fsS?L? .*\| *(z|ba)sh' \
        ~/.zsh_history ~/.bash_history 2>/dev/null

   Correction 2 — "smash and grab, doesn't persist" is false for the August payload. The advice says look for LaunchAgents with "random or gibberish names". We found two root LaunchDaemons running for six days:

   /Library/LaunchDaemons/com.apple.accountsd.helper.plist
   /Library/LaunchDaemons/com.apple.metadata.mds.worker.plist
   

   Nothing gibberish. Each runs an infinite bash loop (sleep 5) re-injecting a binary into the logged-in GUI session — the context needed for cookies, session tokens and keychain. Payloads sat in hidden folders in ~/Library/Application Support/ (.com.apple.accountsd, .com.apple.metadata.mds, .com.apple.airport), all ad-hoc signed, TeamIdentifier=not set. One component had no launchd entry at all and replaced itself five days in, so it had a live update channel. Consistent with stage 3 being pulled from an /update endpoint: the loader is stable, the stealer is swapped at will. What was analysed in June is not what shipped in August.

   Detection rules that survive variant changes (all read-only — and yes, I know the irony of posting Terminal commands here; read each line first):

   # 1. A com.apple.* launchd job outside /System/ is NEVER Apple's.
   #    SIP makes /System/Library/LaunchDaemons unwritable, so attackers must use /Library.
   ls -la /Library/LaunchDaemons/com.apple.* /Library/LaunchAgents/com.apple.* \
          ~/Library/LaunchAgents/com.apple.* 2>/dev/null
   
   # 2. Hidden directories in Application Support — legitimate apps don't hide.
   find ~/Library/Application\ Support -maxdepth 1 -name '.*' -type d 2>/dev/null
   
   # 3. Ad-hoc-signed executables in your home folder. Real software has a Developer ID.
   find ~/Library/Application\ Support -maxdepth 3 -type f -perm +111 2>/dev/null |
   while read -r f; do
     codesign -dv "$f" 2>&1 | grep -q 'TeamIdentifier=not set' && echo "AD-HOC: $f"
   done
   
   # 4. "enHash=" is the lure page's fingerprint across all known variants.
   for p in "$HOME/Library/Application Support/Google/Chrome/"*/History; do
     cp "$p" /tmp/hc.db 2>/dev/null || continue
     sqlite3 /tmp/hc.db "select datetime(last_visit_time/1000000-11644473600,'unixepoch','localtime'), url
       from urls where url like '%enHash=%' or url like '%pearcleaner.com%';" 2>/dev/null
   done; rm -f /tmp/hc.db

   If you find persistence: unload before you kill. KeepAlive plus the sleep 5 loop means killing processes first is useless — they respawn.

   cat /Library/LaunchDaemons/com.apple.<name>.plist        # confirm it's fake first
   sudo launchctl bootout system /Library/LaunchDaemons/com.apple.<name>.plist
   mkdir -p ~/Desktop/malware-evidence
   sudo mv /Library/LaunchDaemons/com.apple.<name>.plist ~/Desktop/malware-evidence/
   
   # CAREFUL: mdworker_shared is also a genuine Apple process.
   # Kill only what runs from your HOME folder, never from /System.
   ps aux | grep "$HOME/Library/Application Support/\." | grep -v grep   # then kill -9 <pid>
   
   mv ~/Library/Application\ Support/.com.apple.* ~/Desktop/malware-evidence/
   chmod -R a-x ~/Desktop/malware-evidence/.com.apple.*

   Keep that folder, don't delete it, don't execute anything in it.

   Credentials: the existing advice is right — rotate from a clean device, and log out all sessions everywhere, because a stolen session cookie is never asked for a second factor. Three things it omits: OAuth grants to third-party apps survive both password changes and session revocation (check myaccount.google.com/permissions, plus mailbox forwarding rules); developer secrets are targeted too (~/.ssh/, ~/.aws/credentials, ~/.docker/config.json, ~/.npmrc, .env files, GitHub PATs and deploy keys); and password reuse is what turns one infected Mac into many compromised accounts — in our case the password typed into the fake prompt was also a KeePass master password, and it sat in cleartext in one of the malware's own config files.

   August indicators (expect these to rotate again; the four rules above won't):

   pearcleaner.com  nexload.site  fileteapulsezone.com  facetecho7.com  loom-20.com
   BuildID: AgJGHyPCxkQe8fSmXAZ_9pipNmyQpc91mrE_16mO9uO8CHk
   loader self-ID: ron00hmm v2.15.5     dropped: /tmp/helper
   
   7948c722d4d2eef4ca0c33ad580c456fea7d5c6489bec68c14fdf3fa40f42e86  AccountsHelper
   06c1ce1a1c19b0df642984a0f85679cfe40a91e9df0c7b2421b210f28733dc82  mdworker_shared
   94a1f42cc5c7eab17b00c19887d6f4fa83f57a6c5c02f05d245030424eea4f0b  cksyncd (packed Go)
   

   No macOS vulnerability is involved — a fully patched Mac behaves identically. The user typed their own password into a prompt and sudo did its job.

   One analysis note in case anyone recovers a loader: the payload blobs are AES-128-CTR, and the key is derived partly from an innocuous-looking environment variable set in the pasted one-liner — so you can't decrypt it without the exact command from shell history. Happy to share the deobfuscated stage 2 or the decryption script.