You are browsing the archive for Reversing.

How to find new persistence tricks?

October 14, 2018 in Autostart (Persistence), Personal, Preaching, Reversing

Every once in a while people ask me how do I find all this stuff.

The TL;DR; answer is simple: curiosity + reading Microsoft documentation + other peoples’ research + applying some automation.

At first, it was really just some curiosities that I could not explain when I was less experienced in reversing e.g. the Visual Basic VBA Monitors. When you use Procmon a lot, some of the stuff you see in the logs eventually gets stuck in your head and becomes really familiar. Such was the case with the HKLM\SOFTWARE\Microsoft\VBA\Monitors key that I saw anytime I was analysing a VB application with Procmon. I could not explain it and was curious what it is for…. googling around didn’t bring any answers. Eventually I started analysing the actual code that triggers that behavior and that’s how Beyond good ol’ Run key, Part 6 was born…

Then there is obviously a number of them that was a result of manual, often annoyingly time-consuming code analysis. There were times where I couldn’t find anything new for a few months. Perhaps assumptions were wrong; perhaps we have already discovered it all… at least so I thought every once in a while…. But… then… they keep coming… not only from me, but also from others… And it’s hard to explain how it is even possible… For instance, the recent one is a perfect example of a situation where the random luck played a role a lot. While looking at some unrelated stuff inside the kernel32.dll I happened to spot the bit that was loading the callback DLLs. With so many people looking at kernel32.dll over the years I still find it amazing we find new stuff there all the time.

Many other cases were a result of a more deliberate research; for instance, many persistence mechanisms I described rely on the fact that some programs or components load a number of DLLs that are executed one by one after they are listed under a certain location in the Registry. Such activity needs to rely on Registry enumeration APIs. If you can find programs or DLLs that use these functions you will most likely find possible persistence mechanisms!

And then there are keywords e.g. ‘providers’, a very popular way to name a place in the Registry where a lot of plug-ins are loaded from. Example of possible enumerations for some keys that include the keyword ‘providers’ is shown below:

  • SYSTEM\CurrentControlSet\Control\Cryptography\Providers
  • System\CurrentControlSet\Control\SecurityProviders\SSI\Providers
  • SYSTEM\CurrentControlSet\Services\LanmanServer\ShareProviders
  • System\CurrentControlSet\Services\RemoteAccess\Accounting\Providers
  • System\CurrentControlSet\Services\RemoteAccess\Authentication\Providers
  • SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders
  • SYSTEM\CurrentControlSet\Services\WbioSrvc\Service Providers
  • SYSTEM\CurrentControlSet\Services\Winsock\Setup Migration\Providers
  • System\CurrentControlSet\Services\WinTrust\TrustProviders
  • System\CurrentControlSet\Services\WlanSvc\Parameters\ComInterfaceProviders
  • System\CurrentControlSet\Services\WlanSvc\Parameters\VendorSpecificIEProviders

I also mentioned Microsoft Documentation; it’s like a RFC for Windows programming. I have read a lot of it over the years, and every once in a while some of that old knowledge comes back to me. Ideas for tricks around DDE, WM_HTML_GETOBJECT  as well as the Propagate trick (SetProp) are result of my experience actually coding for Windows for more than 10 years. These (especially old, legacy) things stay with you and sometimes bring some really refreshing ideas. Not only for persistence tricks.

Then there are ‘magic’ APIs… if you read code and see references to ShellExecute, WinExec, CreateProcess, LoadLibrary, CoCreateInstance and their numerous variations and wrappers you will soon discover that the Windows ecosystem hardly re-uses code; or, more precisely, it does re-use a lot of it, but it also relies on lots of custom paths that are added to it. Lots of code snippets you come across look like a custom programming endeavor of the coder who wrote that part of the program just to test an idea. It’s actually a normal, even expected behavior in such a sea of code. But… quite frankly…. we really have to thank Microsoft Programmers for all the testing & debugging code and error messages/strings that are shipped with the OS. This helps a lot!

All of these unexpected and probably meant-private/for lab-only code paths provide a lot of interesting opportunities… both for persistence, and LOLBINs; anyone who just dares to look for it will eventually find something.

I am fascinated by it; the actual persistence bit is less important, even if on occasion the ‘novelty’ of some of these techniques may have the ‘wow’ factor ; the real pleasure for me is derived from these three things:

a) an opportunity to read lots of other peoples’ code and sharpen my reverse engineering skills

b) learn how the system works under the hood

c) being ahead of a curve with regards to forensic analysis

Actually, the a) and b) are equivalent… the c) is an obvious bit.

If you think of the books like Windows Internals, or The Art of Memory Forensics, the majority of the information that the authors rely on is a result of direct or indirect contact with the actual system internals (and these guys did it a lot). There is no magic wand. Yes, there are source leaks, there are ex-MS programmers becoming researchers who had an access to the source at some stage and for some time can leverage their privileged position, but I’d say that majority of the discoveries presented at conferences over last 30 years, as well in books and written on the blogs is relying on the work of all these poor reversing souls sitting and digging in the OS code all the time. Some of them even become famous and get hired by Microsoft :).

Many developers curse unpredictable behavior of some APIs, complain about the way things work, yet often are unable to pinpoint the exact reason for a certain behavior so that the root case can be analyzed. In my eyes, an ability to dig into code of others, whether the source is available or not, is the core skill of any programmer, and… perhaps even information security professional. None of the reversing, forensic, vulnerability research tools would exist w/o this ‘poke around in other people’s code’ branch.

So… if you want to find new persistence tricks… pick up any code you think has a potential, start digging, and actually discover how things work under the hood. Or at least 0,000001% of it. And no, whatever you find, you don’t need to blog about these new persistence discoveries at all – get out of my lawn! 😉

Kernel hacking tool you might have never heard of – XueTR/PCHunter

April 20, 2018 in Reversing, Tips & Tricks

It is a good habit to keep your eyes open and monitor the updates to your favorite tools. I do it ‘religiously’ and comb the internet for the updates every once in a while. I know that some of these tools are never executed on my host machine, but they deliver an extremely unique and valuable interpretation of the system internals that I can act upon so I always want to have the latest, the best.

You definitely used Sysinternals tools, including the Process Explorer, and the Rootkit Revealer. You might have heard, or used GMER.  Same for the RKU. Same for the Kernel Detective.

At least three of these tools were amazingly popular in the first decade of this century as they allowed to poke around things that other tools could only dream of. They were really ahead of a curve as they allowed to access the system in a nearly forensically-sound manner, unhook kernel and user mode hooks, scan the whole memory for badness and overall, really help to deal with a lot of nasty code from those days… One couldn’t imagine a manual system repair of a system infected with a rootkit w/o one of these tools…

Now it’s 2018, and Windows 10 is out there.

What tools can we use?

Most of the aforementioned tools are kaput.

There is some light though…

Enter Process Hacker
– a  much better tool than Process Explorer.
I love Process Hacker and am really happy that it works on Win 10 pretty well.

While the official build is 2.39 and is 2 years old, there is a ‘nightly’ build you can always try to play with:

The last build, as of this post writing, is 3.0.1424 and is from 18/April/2018.

Yay! Go and get it!

Now… the one I want to talk about though is XueTR/PCHunter.

I bet you never heard of it.

I have recently discovered that the author released a new version (in March 2018). The current version is 1.53 and according to the blog post it was tested with Win10 (16299).

Mind you. This is after 5 years of a hiatus on his blog, so this is great news that the author picked up and updated the tool.

Now… before we begin – please note that the free version of PcHunter works on 32- and 64- bit Windows 10, and can’t be used commercially. This is explained in the About tab:

With that out of the way, we can explore the main interface.

When you execute the main 64-bit .exe (PCHunter64.exe) you will be presented with this UI:

The interface is (not a surprise) similar to GMER/RKU and to Kernel Detective.

There is a bunch of tabs we can browse through and which explore the Windows 10 internals in details:

  • List of processes
  • Kernel Modules
  • Kernel ‘Stuff’
    • Notify routines (e.g. these that notify the driver about a new process being created)
    • Filter
    • DPC Timer
    • Worker thread
    • Hal
    • Wdf
    • File System
    • System Debug
    • Object Hijack
    • Direct IO
    • GDT
  • Ring0 Hooks (including IRP+inline)
    • SSDT
    • ShadowSSDT
    • FSD
    • Keyboard
    • I804prt
    • Mouse
    • Partmgr
    • Disk
    • Atapi
    • Acpi
    • Scsi
    • Kernel Hook
    • Object Type
    • IDT
  • Ring3 Hooks
    • Message Hooks
    • Process Hook
    • KernelCallbackTable
  • Network
    • Port
    • Tcpip
    • Nsiproxy
    • Tdx
    • Ndis Handler
    • IE Plugin
    • IE Shell
    • SPI
    • Hosts file
  • Registry (browser)
  • File (system browser)
  • Startup Info
    • Startup
    • Services
    • Scheduled task
  • Other
    • File Association
    • IFEO (Image File Execution Options)
    • IME/TIP
    • Firewall Rule
    • User Name
    • Other (additional tools)
  • Examination (forensic-like report)
  • Setting
  • About

I am not going to include more screenshots. Download. Test. Make up your mind.

I think the tool is pretty cool and worth at least checking.