Unable to detect ghosttasks

[j-wsy]

Hi, love the tool.

I have a vm with a working ghosttask loaded (restarted and all that, and confirmed the ghosttask is functioning). I can see it in my regedit \tasks, and I can see it doesn't have a SD, as expected. I can see it doing the action I made it do.

Running the latest PersistenceSniper v1.16.0, I can't seem to detect it. I see a bunch of other false-positives, so the tool itself is working, but no output relating to ghosttask.

[j-wsy]

[j-wsy]

Here's another example using a ghosttask named "April1", on a separate clean vm. Could not detect using Find-AllPersistence.

Am I doing something wrong/do I need to do anything else?

[last-byte]

Hey there, solid copy. I’ll investigate it right away and fix it in the next minor release.

[j-wsy]

thanks, looking forward to it.

[daniele777]

Malware is fake amsi provider?

[strassi]

@j-wsy

How did you create the ghost task. Some tools are creating ghosttask by deleting the SD (security descriptor) for the task, which hides it for every user.

But some tooling might preserve the SD value, which causes the persistencesniper script to fail finding the task. Persistence Sniper seems to check if the SD is missing. https://github.com/last-byte/PersistenceSniper/blob/6687a26250a3577a0f4c709cbf7c29191a5ad1e8/PersistenceSniper/PersistenceSniper.psm1#L1907

Can you confirm of having a SD for your ghosttask? You have to search in the "Tree" Key for the specific ghost task.

[j-wsy]

Hi @strassi I understand what you mean, though I have some questions.

In green highlight, it shows the GhostTask "demo" with a \TaskCache\Tree\ SD. This was created via the method on https://github.com/netero1010/GhostTask - under "Example 1". Understandably after reading the PersistenceSniper source code, this would fail the boolean: if ($null -eq $taskSD).

In netero1010's project, it describes the code as "Creates scheduled tasks with a restrictive security descriptor, making them invisible to all users."

It seems then that a GhostTask isn't about a missing SD, but something within the SD that permits/denies visibility. So perhaps hunting for a missing SD is not right, but I don't have a better idea at the moment.

As a side note, I want to point out that if you follow the GhostTask's Id (in yellow highlight) and view it under \TaskCache\Tasks (rather than TaskCache\Tree), it has no SecurityDescriptor. This is what I was referring to at the start of this thread, but I'm not sure if this is different to "SD". I do observe that other legit Ids can be missing SecurityDescriptor too, so perhaps it's just not the same. Regardless, once again a lack of an SD doesn't seem to imply a malicious GhostTask...

[strassi]

A possible workaround would be the detection of the used SD of the tool. The very restrictive permissions of GhostTask look like this: https://github.com/netero1010/GhostTask/blob/7db8cd4120328a80e27e220785a8546bb1a4ed28/GhostTask.c#L769

[last-byte]

This should be fixed in 1.16.1 which I just released and seems to catch the use case :) @j-wsy @strassi

[j-wsy]

Awesome, thanks @last-byte

It does work on the ghosttask I set up above using https://github.com/netero1010/GhostTask.

I have a question though:

It looks like you added maliciousSD and it's comparing it to the SD (if there is one) of the suspected ghosttask. Where did you get this maliciousSD base64 encode from, and is this a hardcode value specific to the ghosttask SD in https://github.com/netero1010/GhostTask/blob/main/GhostTask.c#L769?

It looks like that specific line ConvertStringSecurityDescriptorToSecurityDescriptorA("O:BAG:SYD:", 1, &pSd, &sdLength); is what generates the ghosttask SD data (https://learn.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format), and the D: part I think makes it restrictive?

If we made a slight change to the unicode/hex of the SD, I guess it would bypass detection?

edit: realised thats what strassi was talking about haha sorry

[last-byte]

Yes, the encoded base64 is the SD that's generated by GhostTask, but I'll look into your suggestion as it makes sense only to look for that specific part potentially.

[last-byte]

To add to that, I'll check and see which part of the SD is mandatory so that manipulation attempts of the SD do not result in evasion.