Malware News
15.1K subscribers
1.63K photos
7 videos
130 files
7.97K links
The latest NEWS about malwares, DFIR, hacking, security issues, thoughts and ...

Partner channel: @cveNotify

For ads: https://telega.io/c/malwr
Download Telegram
Handheld Computer/Controller
πŸ—£0ne-autumn-leaf

THE HACKPAD
πŸ‘€Savvasun

Terminator 2. ATM scene. My favorite.
πŸ‘€eltoro3333

Sick
πŸ‘€cosmicleanie


πŸŽ–@malwr
New network security scanner tool released by Google!
πŸ—£frrossty

So, will all my vulnerabilities and weak creds be available on the Google, nicely indexed, after using it?
πŸ‘€ptzxc68

I'm surprised a new tool was written in Java. I definitely would have expected Go instead of Java for a new security tool from Google.
πŸ‘€abluedinosaur

this only checks for four known admin panels and weak creds.

great idea, but it needs ways more plugins to be useful
πŸ‘€Snoo-92683


πŸŽ–@malwr
Best solution for unpacking most of the packed samples in a large dataset of malware statically
I have a large dataset of malware samples that are packed with variety of packers, and i need to unpack as many as possible (I want to build a machine learning model and this is my dataset)

i guess one way of unpacking the packed samples is first detecting the packer with the help of Peid or die with scripting and then call the appropriate unpacker like UPX, Aspack, ... unpackers

but the problem is the list of packers is too large and there are so many different unpackers and such


so what is the best solution to this? if you had a large dataset of malware how would you go about of unpacking the most possible (obviously we can't unpack all of them, but the more the better)

any open source project for this problem or any other solution?

and I also obviously don't care about samples that are packed with a custom packer/crypter since i doubt there is any easy static solution to that.
πŸ—£BitDrill

I’d suggest checking out https://www.unpac.me/
πŸ‘€jershmagersh


πŸŽ–@malwr
How to actually do memory forensics in the real world?
I get it, you use probably use volatility like most do. But do you have any success with volatility on systems with like 128GB of RAM?

Yes, volatility works great on this 4GB images or training images. But in reality I keep getting issues with Vol, in where it crashes or basically takes forever (6h for an imageinfo without result).

This program is also single-core written and only takes 1 from the 16 available cores (AMD Ryzen 3950x) and hardly stresses the storage (NVME RAID).

So my question basically is, what do you guys use to perform forensics on large (64GB+) memory images.
πŸ—£tankton

as far as i have noticed few people use volatility live for it's lack of speed...

i have seen and used redline, kape, or commercial products like xways
πŸ‘€sai_ismyname

Check out Memtriage by u/gleeda \- https://github.com/gleeda/memtriage


Its great for these types of scenarios as its intended to be run live rather than on images. It gives you most of the plugins you'd likely want to run with volitity as well.
πŸ‘€toliver38

Does it have to be Live ? I mean you can find traces in other places (Prefetch, Event logs, Reg,...).

You can also use KAPE ( https://github.com/EricZimmerman/KapeFiles ) to do live response and collect artifacts or use a collection of scripts like Winterfell ( https://github.com/yasser-alghamdi/winterfell )

GRR and Velociraptor are pretty good alternatives too ( https://github.com/google/grr & https://github.com/Velocidex/velociraptor )

The truth is i only use VOL for training never used it in production (i am lazy :D )
πŸ‘€hilo25


πŸŽ–@malwr
Fuzzing FastCGI With AFL-Fuzz
πŸ—£MoneyWaveSal

>FastCGI is written in C/C++.

FastCGI is a protocol. It isn't written in anything but maybe BNF or similar syntax description languages.
πŸ‘€Taladar

Can someone explain to me why a fuzzer was used instead of manually reverse engineering it? The protocol seems small and simple.

Wouldn't reverse engineering be better for this?
And a fuzzer better for big programs?
πŸ‘€SombraSec

A bit of a tease at the end with found 31 items and not even mentioning if they were
1. Possible to do remotely - some parameters are not accessible by an attacker
2. We (or looked) exploitable

Looking forward to a follow up article
πŸ‘€rathaus


πŸŽ–@malwr