16 replies to this topic

[tigo]

Posted on tr*forge in C/C++, i just converted to masm

 

write the code (api address, parameters) in remote process stack and execute from there

 

Please Login or Register to see this Hidden Content

 

Please Login or Register to see this Hidden Content

  5.65KB   51 downloads

Edited by tigo, 13 March 2015 - 12:44 PM.

[x58]

Alright, but this method is detected by hips?

[LeFF]

I'd rather just make a code, that creates a seperate bat file and calls it for self deletion... it is kind of embaracing if your code isn't detected at runtime, but when it comes to self-deletion you got fucked up, because you try to manipulate other process virtual memory... so I would say that this thing is impractical at least...

[Jochen]

It's allot of code for self deletion. Creating a hidden bat file that only exists for less then a second is more practical. And no need for so much API call's.

[tigo]

LeFF, on 14 Mar 2015 - 9:08 PM, said:

I'd rather just make a code, that creates a seperate bat file and calls it for self deletion... it is kind of embaracing if your code isn't detected at runtime, but when it comes to self-deletion you got fucked up, because you try to manipulate other process virtual memory... so I would say that this thing is impractical at least...

This is a alternative way used by ZeroAccess, Don't tell anything without testing it, even RUNPE also modifying other process memory and this code is better than the dropping the file in the hard disk

 

Quote

It's allot of code for self deletion

you think that these functions only for self deletion, can't we use these functions for other purpose?

 

Quote

this method is detected by hips? 

i didn't check with any antivirus

 

Edited by tigo, 15 March 2015 - 08:18 AM.

[tigo]

just checked, No alert from KIS 15.0.0.463

Edited by tigo, 15 March 2015 - 11:34 AM.

[x58]

tigo, on 15 Mar 2015 - 10:33 AM, said:

just checked, No alert from KIS 15.0.0.463

It's surprising.. Because it should be detected in fact, if Im not wrong. But anyways, cool to see it..

I mean at least one that really does translate some code and post it.

[LeFF]

Quote

This is a alternative way used by ZeroAccess, Don't tell anything without testing it, even RUNPE also modifying other process memory and this code is better than the dropping the file in the hard disk

sometimes I don't even need to test something to know if it will be detected or not... and btw in what way is this method better than using a seperate bat file? it is more complex, more unstable and it doesn't work with x64 processes... why is it better?

 

Quote

just checked, No alert from KIS 15.0.0.463

omfg! you'd better configure your antivirus software correctly and stop living in your magic world where no hips exists... it is detected at the very least by KAV (HEUR:Trojan.Win32.Generic), Comodo (TrojWare.Win32.Patcher.~dy002), Avira (TR/Hijacker.Gen)...

[tigo]

I don't want to argue again about these scantime detection on your end, you cannot make undetected from KIS on scantime even I have provided source code

 

Note: whoever want to check with KIS, just add an anti-emulator code which will bypass scantime detection (HEUR:Trojan.Win32.Generic) and compile it again

 

 

Edited by tigo, 15 March 2015 - 06:11 PM.

[LeFF]

so you didn't answer why you think that this method is better than old school bat-file method?

[r00tr]

very nice.. thanks hope i can use this someday 

[wootski]

Are you expecting to encounter lots of XP boxes still? You could launch Powershell with the necessary script as part of the commandline and avoid writing a .bat to disk.

[poison2012]

Would this work on 64bit?

[Jochen]

It works here ... Win7 x64

[poison2012]

This is strange, since c:\windows\system32\calc.exe is a 64 bit executable, so injection should not be working from 32 bit process. However it looks like that if you open calc.exe with a 32 bit process, the OS will "give you" the 32 bit version of calc.exe

[LeFF]

Quote

This is strange, since c:\windows\system32\calc.exe is a 64 bit executable, so injection should not be working from 32 bit process. However it looks like that if you open calc.exe with a 32 bit process, the OS will "give you" the 32 bit version of calc.exe

64-bit windows installation has 2 versions (32-bit and 64-bit) of many executables to support their WOW64 stuff... if process starts 'calc.exe' (without full path) it will be taken from system directory... for 64-bit process "C:\Windows\System32" is the system directory, for 32-bit process it is "C:\Windows\SysWOW64"... basically it only works because 32-bit process started in WOW64 layer creates and modifies a 32-bit calc.exe process...

[StalkerDz]

thank's