avred icon indicating copy to clipboard operation
avred copied to clipboard

Defender detects file copy pasted, avred doesnt

Open muhyuddin opened this issue 1 year ago • 3 comments

AvRed logs show that file isnt detected by antivirus, but if i copy paste the executable onto AV machine it gets detected instantly. Any guidance ?

muhyuddin avatar Sep 08 '24 12:09 muhyuddin

Thats probably the AV emulator. Avred checks against/with AMSI, there may be more checks being done by the AV when actively on the system.

If what you scan is a shellcode loader, you can try adding an anti-AV-emulation technique. See my slides , 24-44.

dobin avatar Sep 09 '24 05:09 dobin

Thanks for help. Yes it is shellcode loader, i have added the anti-av techniques. It has been working great for a couple of months, now every av is detecting it in static analysis. I have tried garble, packers, even obfuscating function calls and AST.

Can you please guide me to some project or modifying AVRed where file should be scanned either if its detected by AMSI or not, really appreciate the details and working this project has.

muhyuddin avatar Sep 10 '24 15:09 muhyuddin

I recommend to add an anti-emulation to your loader, like from supermega

And i talked about it in My first and last shellcode loader, and blog article how edr works

dobin avatar Sep 11 '24 19:09 dobin

For future reference, I also ran into this issue today. In my case, it was because MDE Cloud Protection was detecting the file, while the local component did not detect it. Apparently when scanning through AMSI, the Cloud Protection detection was not triggered. Due to @dobin's comment, I first assumed that this was due to emulation-based detection. However, in the end, it was in fact a static signature in MDE Cloud Protection. I found the signature by performing a similar binary search to AVRed, but by dropping the files on disk instead of using AMSI.

For the future, it would be nice to be able to perform this approach using AVRed, but some major changes are necessary for this. The most important one would be that AVRed should be more async to be able to handle the long waiting times for detection (up to 5 minutes), I suspect that this would require a major change to the scanning approach.

JJK96 avatar May 28 '25 12:05 JJK96

I dont know what MDE Cloud Protection does, but its good. Seems to download more IOCs, depending on previous (there is no sending files to cloud).

Avred doesnt care how the scanning is performed actually - avred_server is just an oracle, saying yes/no (detected or not). Currently by sending the blob to the installed AV via AMSI.

It is possible to change avred-server to drop the file to disk, and then wait a bit to see if it gets removed by the AV (or even EDR) after a few seconds. This would make it AMSI independant. This was actually how avred-server worked initially, but it was unbearably slow - as in hours or days. The reducer algo in avred is not built for paralell operation. As its recursive and dependant on previous results, its also non-trivial to make it work more paralell, sadly.

dobin avatar Jun 08 '25 08:06 dobin

In my fork I have changed the algorithm to be more parallellizable, namely, by dividing the binary into more than two parts. If these parts can be scanned in parallel (by making avred more async) this will allow finding matches more quickly.

JJK96 avatar Jun 08 '25 11:06 JJK96

Nice commits!

And i was thinking: in recursive _scanDataPart(), each case where there are two _scanDataPart() invocations (like when both parts are detected), could just do both branches in a new thread at the same time. The longer the scan takes, the more branches it takes, the more paralell it would be.

dobin avatar Jun 08 '25 12:06 dobin

I would suggest using async to run the invocations in parallel instead of threads. Since the waiting time is almost 100% in the avred server. So first run all _scanDataPart invocations, and then wait until they are all complete.

JJK96 avatar Jun 08 '25 18:06 JJK96