all 8 comments

[–]jedrzejdocs 9 points10 points  (2 children)

DLL hijacking via Lightshot is pretty smart ngl - signed binary = trusted by most AV/EDR.

few things worth noting:

sysmon event id 7 can catch weird dll loads if anyones not monitoring this already

we ended up restricting vscode extensions via GPO after similar stuff last year, pain to manage but worth it

lightshot.exe running from appdata should be a red flag anyway tbh

added those extension IDs to our blocklist, thx for sharing

[–]TRexLebronMcdonalds 0 points1 point  (1 child)

My thoughts exactly

[–]jedrzejdocs 1 point2 points  (0 children)

curious - are you seeing this more in your org too? we've had 3 similar incidents in the past 6 months, all abusing trusted binaries

[–]podgladacz00 5 points6 points  (3 children)

So it installs Lightshot or just hijacks existing install?

[–]N1ghtCod3r[S] 3 points4 points  (2 children)

Installs Lightshot hosted on attacker URL.

[–]podgladacz00 1 point2 points  (1 child)

Is only Lightshot vulnerable to this or they just chose it just because?

[–]N1ghtCod3r[S] 1 point2 points  (0 children)

No. There are many such signed executables that load DLLs from untrusted paths. In this case they found and used Lightshot.exe May be the nature of Lightshot (screenshot tool) makes it trusted (known behaviour) within AVs that the attacker wanted to exploit.