Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

Frankenstein Virus

Comments

  • Registered Users, Registered Users 2 Posts: 126 ✭✭infodox


    So this "virus" self assembles using ROP gadgets? Interesting concept, but I kind of have a hard time seeing the reasoning - if I can execute code on your box, I can execute code on your box!


  • Closed Accounts Posts: 1,455 ✭✭✭RUCKING FETARD


    infodox wrote: »
    So this "virus" self assembles using ROP gadgets? Interesting concept, but I kind of have a hard time seeing the reasoning - if I can execute code on your box, I can execute code on your box!
    Harder to spot.

    Look at this one, infects Virtual Machines.


  • Registered Users, Registered Users 2 Posts: 1,726 ✭✭✭gerryk


    Sounds like an academoc proof of concept rather than an actual practical attack vector.
    Harder to spot.

    Not really. The core code will be the same anyhow, unless it uses some kind of polymorphism, which, in and of itself is not a new technique.
    Look at this one, infects Virtual Machines.

    Hardly a big deal. All that's happening here is if vmdk files are found, an attempt to mount them and copy the code to them is made.

    Not sure what is meant by this statement (FTA):
    "When attackers detect a virtual-machine instance, they (typically) turn themselves off," he said. "This is a case where the position is totally switched around. They want to run in the virtual machine."


  • Registered Users, Registered Users 2 Posts: 126 ✭✭infodox


    gerryk - Most malware refuses to run in a VM. If it is in a VM, it shuts down. It is a way of screwing with malware researchers and hampering analysis of the stuff, same thing with anti debugging techniques (I have seen samples that actually exploit DoS vulns in OllyDBG before).

    The one that injects itself into VM images... Because targets of LE surveillance often think doing their illicit/activist activities inside a VM is "safer" because Vmware offers FDE for VM's and you can just shred the VMDK. Nothing unusual for commercial spyware, and it has long been said it was possible. I remember someone released a PoC a while back. Also, injection into a VM is unimpressive. Call me when the malware can make the VM to Host* jump and I will worry a little :P

    The use of ROP gadgets to form malware, while theoretically interesting, has no real practical value as you would still need an executable to kick off the whole process, and at that point you may as well just write a bloody decent packer and use netwire/meterpreter/$(Trojan Of Choice) - less effort and same result - AV evasion.

    *Immunity released an exploit before that could do this on certain versions of Vmware running on Windows. Long since patched, it exploited graphics bugs.


  • Registered Users, Registered Users 2 Posts: 1,691 ✭✭✭JimmyCrackCorn


    Its Polymorphic code meets return orientated programming.

    Really like it as a smart way to hide routines...

    It is however very achedemic and in practice would be a little more difficult to build something with a long life expectancy but not impossible...


  • Advertisement
  • Registered Users, Registered Users 2 Posts: 4,676 ✭✭✭Gavin


    Looks interesting, if done right, it could be very difficult to detect - remains in memory, reuses clean code, potential FP risk. If it came in as a worm through shellcode ala SQL slammer, it could be quite effective.


Advertisement