Re: [script] for AV evasion
@e3HQ67S, No - I did not experience such a life-pan heuristic on my testing machines with their AVs. I think it's more a question of the actual AV, which is in use.
@LHYX1, The greater question now is, how to put that code (or bind it to) a PDF or an image? I looked over your code a little and thought of implementing /windows/fileformat/adobe_pdf_embedded_exe as the eighth choice. Would it be OK with you, if I'd mod your code a little to publish it afterwards right here? (If I'll do it). That way, a binded PDF-File could be put out right after the encoding.
Re: [script] for AV evasion
Quote:
Originally Posted by
L21ZIFER
[FONT=Verdana]@e3HQ67S, No - I did not experience such a life-pan heuristic on my testing machines with their AVs. I think it's more a question of the actual AV, which is in use.
Just curious, which AV did you use to test?
Re: [script] for AV evasion
@L21ZIFER That's a great idea. Post your adjustments and I'll update the script. Then we'll put both our names on the script :)
I don't really think you can hide an exe file in an image though. You will need to find an exploit for something like this.
@e3HQ67S I know there are some advanced AV's that track every move the payload makes. They will execute it but ones you try to spawn a shell or whatever, they will popup a message that says: Hey this process shouldn't start cmd.exe as a new process. Comodo is an example of such an AV. I haven't found a way to bypass this yet. If you have any ideas please let us know :)
Re: [script] for AV evasion
Quote:
Originally Posted by
LHYX1
@e3HQ67S I know there are some advanced AV's that track every move the payload makes. They will execute it but ones you try to spawn a shell or whatever, they will popup a message that says: Hey this process shouldn't start cmd.exe as a new process. Comodo is an example of such an AV. I haven't found a way to bypass this yet. If you have any ideas please let us know :)
Yeah I'm kind of curious how heuristic engines differ by vendor. AVG's functions similar to how you describe Comodo working. And it's been driving me nuts trying to bypass it. Basically every behavior you'd want or need to do with a meterpreter shell sets off alarms. I'd also love to figure out how to get around these things, short of simply disabling them.
Re: [script] for AV evasion
@LHYX1,
I managed to implement the whole extension, but problem is, the PDF gets detected by every AV.
Re: [script] for AV evasion
@L21ZIFER It's probably the exploit itself that get's detected.
@e3HQ67S I think if you really want to bypass this, you will need to code your own payload or maybe if you could inject it into a trusted running process ?
I'll think about this.
Re: [script] for AV evasion
Re: [script] for AV evasion
@LHYX1, the edited version of your code works like this:
01. PDF Binder shows up as choice 8
02. The encoded backdoor.exe gets written as usual (in crypter.py)
03. The PDF Export question shows up, besides applet attack and apache attack (see crypter.py)
04. PDF gets binded with self-generated backdoor and exported.
And AVs don't buy it.
I lost the original edit I made on your code, but I have one (of my edited) code in backup.
So, before I put it out, I better test it in practice.
Re: [script] for AV evasion
hey LHYX1, I've been looking for a binder. Easy-binder is for windows and wine doesn't want to start it. Do you know of any for linux that are good?
1 Attachment(s)
Re: [script] for AV evasion
@LHYX,
here is my edited version of your code.
Here are the few coding-changes:
- - New attack form added to the menu
Code:
....
8) windows/fileformat/adobe_pdf_embedded_exe [+ 5)]
It will bind a PDF to the meterpreter/reverse_tcp backdoor (this backdoor will be generated right from crypter.py as before and is for that reason stealthy)
- - Right after the encoding-process the PDF gets binded to the .exe and needs an original PDF at /root/Desktop/original.pdf, this path is hard coded. I currently have no big Python-experience, I tried to make the original.pdf-path user-generated, but there were problems so I did it this way.
- - After the binding-process the embedded PDF gets moved to /root/Desktop. Again, hard coded.
As I mentioned it before, the final malicious PDF gets detected by AVs. That is a big problem and I didn't have enough time to work that out. But maybe it is only a little tweak.
