XR3X

Jump to content


Photo

[Masm]SelfDelete

source

  • You cannot start a new topic
  • Please log in to reply
16 replies to this topic

#1 tigo

tigo

    Member

  • Members +
  • 46 posts

Posted 13 March 2015 - 12:44 PM

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.

  • Hess, poison2012 and crackingdayz like this

#2 x58

x58

    Advanced

  • Administrators
  • 4,729 posts
Contributor

Posted 14 March 2015 - 08:08 PM

Alright, but this method is detected by hips?
Regards,


FAQ
Rules and Regulations
Supporting hackhound
-
Server status / Twitter
P2P blocklist

HackHound.org HackHound.co DarkMindz.iNFO
HackHood.co CodeCave.space



#3 LeFF

LeFF

    Expert

  • Moderator
  • 830 posts
Contributor

Posted 14 March 2015 - 10:08 PM

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, x58, Rottweiler and 1 other like this

#4 Jochen

Jochen

    Intermediate Member

  • Notorious
  • 149 posts
Contributor

Posted 14 March 2015 - 11:46 PM

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.


  • x58 likes this

#5 tigo

tigo

    Member

  • Members +
  • 46 posts

Posted 15 March 2015 - 08:13 AM

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

 

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?

 

this method is detected by hips? 

i didn't check with any antivirus

 


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


#6 tigo

tigo

    Member

  • Members +
  • 46 posts

Posted 15 March 2015 - 11:33 AM

just checked, No alert from KIS 15.0.0.463


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


#7 x58

x58

    Advanced

  • Administrators
  • 4,729 posts
Contributor

Posted 15 March 2015 - 12:57 PM

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.


Regards,


FAQ
Rules and Regulations
Supporting hackhound
-
Server status / Twitter
P2P blocklist

HackHound.org HackHound.co DarkMindz.iNFO
HackHood.co CodeCave.space



#8 LeFF

LeFF

    Expert

  • Moderator
  • 830 posts
Contributor

Posted 15 March 2015 - 05:46 PM

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?

 

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)...



#9 tigo

tigo

    Member

  • Members +
  • 46 posts

Posted 15 March 2015 - 06:10 PM

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.


#10 LeFF

LeFF

    Expert

  • Moderator
  • 830 posts
Contributor

Posted 15 March 2015 - 09:32 PM

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

#11 r00tr

r00tr

    Beginner

  • Members +
  • 25 posts

Posted 17 March 2015 - 08:45 AM

very nice.. thanks hope i can use this someday  ^_^


http://i.imgur.com/xLxhpXA.png


#12 wootski

wootski

    Beginner

  • Members +
  • 13 posts

Posted 23 May 2015 - 07:26 AM

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.

#13 poison2012

poison2012

    Member

  • Notorious
  • 90 posts

Posted 23 May 2015 - 10:16 AM

Would this work on 64bit?



#14 Jochen

Jochen

    Intermediate Member

  • Notorious
  • 149 posts
Contributor

Posted 23 May 2015 - 07:42 PM

It works here ... Win7 x64


  • poison2012 likes this

#15 poison2012

poison2012

    Member

  • Notorious
  • 90 posts

Posted 23 May 2015 - 08:36 PM

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



#16 LeFF

LeFF

    Expert

  • Moderator
  • 830 posts
Contributor

Posted 24 May 2015 - 04:06 PM

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...


  • Jochen, x58, poison2012 and 1 other like this

#17 StalkerDz

StalkerDz

    Beginner

  • Members +
  • 18 posts

Posted 13 July 2015 - 07:41 AM

thank's





Also tagged with one or more of these keywords: source