I've been trolling the DbgHelp forums for a while and came across their StackWalk64 function, which one can use to not only enumerate the threads in a given process, but also figure out where the threads originated (which module, etc). For instance, a lot of anti-hack routines load a DLL that creates an infinite loop thread within the dll module that does a simple CRC check or a IsDebuggerPresent check, among other things. If you use something like Process Explorer and suspend/kill the thread, the anti-hack goes away. However, to find out which thread to kill/suspend, it's extremely helpful to know the start address. For instance, if you look at the start address and it says like xProtect.dll+0x1800, you know that's a thread started by the xProtect module and, therefore, to suspend it.
Anyway, if it wouldn't be too difficult to add this ability to LSS, it'd be extremely useful; I could write a few anti-anti-hack routines for a couple of games I know of right off the bat. Hell, you might even be able to write this into a plugin/library kind of thing where you can add different module+offset threads to automatically suspend upon opening a process or even opening MHS (loop through open processes, check to see if any anti-hack threads that user has added to their library exist, suspend them, then load MHS main window... tones down your detectability).
Just a thought