Question

The idea is quite simple, i.e try to not follow the standard. For example to inject some thing to Firefox, malware need to know that the name of process is 'firefox.exe' or to inject some thing in internet explorer, malware need to know that process is 'iexplorer.exe'. But if Firefox or internet explorer do not follow that convention then it will be hard. Idea is to put a logic to change the name of process. For this the real 'firefox.exe' is replaced with our 'firefox.exe' file. This duplicate file is just a startup , the real Firefox executable is renamed to some `random string.exe'. When system triggers 'firefox.exe', this will open our 'firefox.exe' executable. This executable will in-turn open the real Firefox exectable as 'random string.exe' and also set the dummy process information using the 'SetProcessInformation' API. Using 'SetProcessInformation' we will set false location of the executable so malware is not able to find the real process based on the location.

Can any body suggest how feasible it is (provided SetProcessInformation can set false process location)?

Was it helpful?

Solution

Its probably not worth the trouble.

An attacker just needs a handle to the process, and if you rename the exe you just make it a tiny bit more difficult, but not that much. For example simply monitoring the processes that open the firefox history database or any process that does a DNS lookup for the firefox update server would be good enough for that. Or just MD5 summing all the exes and having a set of known binary images.

Basically if you have some code that can inject DLLs or code into foreign processes you have already lost control of the system.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top