Completely replace thread injection signature

[kevross33]

The current CreateRemoteThread type signature seems to never detect code injection. I have been writing various signatures (in other pull requests) and while these signatures are still experimental they highlight code injection sequences and anomalies without description end to end each process i.e must have this and that. For instance manipulating memory of a non-child process is its own signature, writing into other processes etc.

Now for this one I opted for 2 signatures. First is the CreateRemoteThread signature which tries to find non-child process injection and the other being QueueApcThread technique which cannot be non-child process so i basically did if it is doing this to another process. Currently the existing signature cannot match this properly because it relies on the handle not being 0xFFFFFFFF but this API does not have that anyway. This may cause FPs but so far so good.

Now as I said these signatures are experimental and I am not sure if the child process stuff is properly behaving how I hope but they seem to do well together in highlighting all kinds of process manipulation and injection so they are on their way.

Also it is worth noting other APIs if not hooked should be looked at for threat manipulation include:

• SetThreadContext
• SuspendThread
• CreateToolhelp32Snapshot
• Thread32First
• OpenThread

There are probably others too but it would be interesting if flagging manipulating thread of another process could be highlighted; I am not sure how this will work though given sometimes it is more threads that are covered in the APIs making it hard to work out which process it is manipulating but generally messing with threads or memory of another process is a sign of injection

[kevross33]

IcedID Trojan: 335713d29730e2d531b08f0765b21724

Dridex: 2eaf243bad4b1c22089e7654524f0e5a

Alternative Dridex injection: dbf96ab40b728c12951d317642fbd9da

[kevross33]

Dridex be887724519f65c593159ebb0449810d ResumeThread Sig

[kevross33]

[jbremer]

Merged, thanks! We're going to evaluate the various hashes at a later point.