Injection on Steroids: Code-less Code Injections and 0-Day Techniques

tldr; You’ll find the talk deck embedded within this post.

The relevant code is posted on Github –

The folks at BSides were also kind enough to publish the video of our talk –


BSides LV last week, August 4th & 5th, was awesome! We don’t have a count on the exact number of attendees, but it did seem to approach the 1000 figure. Already at 10:00am there were no more walk-ins.

This was our first BSides and we were fortunate enough to be accepted to present: “Injection on Steroids: Code-less Code Injections and 0-Day Techniques”.

Talk Abstract

Most nefarious activities carried out by malware – such as running code in Internet Explorer in an attempt to steal passwords, hijack sessions, or conduct Man-in-the-Browser fraud- require code injection.

Two types of code injection techniques exist – those that originate from user-mode and those from kernel-mode. User injection techniques are more popular as they are simpler to implement and don’t require elevated privileges. Yet, most of them are easy to detect. On the other hand, less than a handful of kernel injection techniques are known today. Although these techniques are more complex to implement, they are super-stealthy, flying under the radar of most defense solutions.

It is the malware authors’ goal to implement easy code injection while ensuring that the injection remains stealthy.

In this talk, we discuss known-yet-complex and less documented code injection techniques. We further expose additional new user- and kernel-mode injection techniques. One of these techniques we’ve coined as “code-less code injection” since, as opposed to other known injection techniques, does not require adding code to the injected process. We also reveal an additional kernel-mode code injection which is a variation to the technique used by the AVs. However, as we demonstrate, malwares can actually simplify this process.


Here’s our full deck of the talk:



I’d like to thank the BSides volunteers for videotaping the whole talk-


We’ve released the code via Github so you can grab it here –


  • caspian

    not working in 64bit! crash explorer process in “SetWindowLongPtr(hShellTrayWnd, 0, (LONG_PTR)MaliciousCTrayObj);”
    but 32 bit working

    • Udi Yavo

      The 64-bit code is working for Windows 7 SP1. To make it work for other Windows versions change the index number of fnINSTRINGNULL callback function.
      For example, in Windows 8.1 the index is 0x1b.

    • Udi Yavo

      The code works in Windows 7 sp1. To make it run in other windows versions change the index number of fnINSTRINGNULL callback function.
      For example, in Windows 8.1 the index number is 0x1b.

      • Matt DeVenge

        How would you find the different index numbers for various versions? I have trouble finding the proper documentation/references.

        • Udi Yavo

          It’s funny, when I wrote the code and the previous comment I didn’t even try to run it on other systems. I assumed that since the callback indices may change across versions this one will change too. For example, the index of __ClientLoadLibrary, which I used in “One-Bit To Rule Them All”, changes across versions. It seems that index 0x1b works for all the 64-bit versions I tried (Windows 7 SP1, Windows 8.1, Windows 10).

          Generally, in order to know the index of some user callback all you need to do is look for the function in USER32!apfnDispatch array and calculate the index. If you need to write code that needs be cross-platform and the index of the function you need is inconsistent the common solutions are to check OS version and choose accordingly or to create some signature for the function.