Outpost vs. Leak Tests

_anvil!!!!

Way to go, i knew you had it all down pack!

 

Hi Max,

great news!
Now SSM can really block the injection into explorer.exe _and_ the browser (the both 'important parts', which it missed before .)

Still two more (little) things, Max:
1. when GOD2 tries to inject itself into the browser, SSM does only show the browser's filename (e.g. opera.exe) in the alert box, but nor its symbol, neither the whole pathname (which would be normal)... although not a real prob, there might perhaps still be a little glitch...
2. as I mentioned above, SSM doesn't really block the injection of the keylog.dll into explorer.exe - the dll is always loaded into explorer.exe, no matter if you block it, or not. In spite of that, the keylogging function does _not_ work, when you chose to block it. Again no real prob, but still...

Well, after all another confirmation for me to carry on using SSM.

Now, we still have to fix this problem in L'n'S - if there is a problem... Ph33r_?!

 

Hey _anvil

You didn’t need me to confirm this, you absolutely on the correct path.
But like I said what I had mentioned was accurate, just didn’t apply at a global scale…

Regards,

 

_anvil

I'm not familar enough with this "GOD 2" thing. When it injects code into a browser? And what browser should be opened (should it?) (I have 2 Operas and 1 IE. Opera 6.0 seems to be default, while the 7.0 is the on I use )

Anyway it appears to be a full-path-extraction problem...

#2. SSM really blocks DLL injection, if you answer "no" in this dialog:
(sorry for Russian. Here SSM asks about creating a remote thread)
http://duesouth.webm.ru/tmp/1.gif

After, I have checked explorer using "TaskInfo 2003" and noticed no "keylogger.dll" in explorer.exe
http://duesouth.webm.ru/tmp/2.gif

Perhaps you should terminate/start explorer again (since a malicious thread still exists in it)?

 

_anvil, thanks for the help with this.
When there is a weakness in a program, it is always a good thing to help the author make it right.

 

@Max

I'll try to reconstruct, what GOD2 does (in my understanding), and where SSM has little probs:

1. copies and starts exe-file (e.g. 'god2.exe'; is then autostarted with windows) in win-dir, and copies two dll-files ('keylog.dll' and 'log-sender.dll') in sys-dir.

2. injects itself (without dll) in 'explorer.exe'; 'explorer.exe' now is 'hijacked' (-> see Max's first pic; SSM has no prob to block this. ), and 'god2.exe' from win-dir does _not_ run anylonger at that moment (so you don't see any trojan process!)

3. the hijacked 'explorer.exe' then injects 'keylog.dll' in itself(!?), so that all keystrokes are stored in a 'log.txt' in win-dir (this is the point, when SSM partly fails: 'keylog.dll' is _always_ loaded in 'explorer.exe', even if SSM tries to block it... still, keylogging will only work, if SSM allows it)

4. GOD2 does not start the (default-)browser itself, but waits until the user does it. After the browser is started, 'explorer.exe' starts 'god2.exe' from win-dir (again), and 'god2.exe' creates remote thread in browser and injects 'log-sender.dll' in it (here, SSM has the prob with missing browser symbol and pathname.)
The 'hijacked' browser then sends the filled 'log.txt' to specified mail adress.

I think, that's it. Hope it helps.

Ah, and yes, 'explorer.exe' obviously has to be terminated/restarted to be 'cleared' of the trojan code...

 

Hi _anvil,

Not quite, use Advanced Process Manipulation from DiamondsCS to unload the DLL. Have a look at this software, it's pretty cool.

Regards,

Patrice

 

Hi Patrice,

I have already used APM (and other tools) to find out, what GOD2 actually does. Nice app indeed.

But in this case, APM wouldn't help. Look, what I wrote above: "2. injects itself (without dll) in 'explorer.exe' "
So _this_ part is obviously not "dll-injection", but direct "code-injection."

Anyway, if you unload the "keylog.dll" from explorer.exe with APM, the explorer will crash and then restart - so after all, it _will_ be cleared.

 

Ah, o.k. now I got what you meant!

Nice work by the way!

Regards,

Patrice

 

_anvil
I still have to say, that when you block code injection, your shell is NOT hijacked, and DLL is NOT loaded at all. Have you checked your "HKLM\...\Run" registry key? Perhaps there is a malicious entry left?

BTW: the source code of GOD 2 is available, so if you want - you can inspect it (if you haven't done it already, of course)

 

Can someone please tell me where you find all this information about GOD 2

 

Hello _anvil,

Well seen and great job : I did not look as I saw there were no phoneing home.
tnx,

 

@Max

Yes, if you block GOD2 at step 2 (see my post above), then there is no problem at all - no hijacking, no keylogging, no mail.
But if you let GOD2 "through" at step 2, then SSM will not block the injection of 'keylog.dll' at step 3 properly (at least on my PC) - again: not a real prob, but perhaps a hint to another tiny glitch in SSM...

Yes, I already noticed that just today. I will take a look, but unfortunately, I am not coding expert...

 

Well, _anvil, now I see what do you mean. But I don't think that there is something wrong, because when you allow code-injection, explorer begins to make things on its own. In this case it (being infected) decides to load library keylog.dll. Since loading library is a normal activity of each process, SSM don't monitor it (you can imagine how many libraries MS Office or Adobe's products loads into themselves)

Of course, it's a nice thing - to watch wich libraries are loaded into processes, but SSM even now is too annoying for most of the users. Asking them to classify libraries will make SSM finally unusable. So I don't see obvious solution

 

Hi Paul,

no problem, I have already found it!

Regards,

Patrice

 

@Max

Yes, I had similar thoughts as you. And of course, SSM should not monitor all the dll's, an app loads into itself.
(well, it could perhaps show the dll's in its process viewer... later )

But then I wonder why SSM detects in this case, that explorer.exe wants to attach a dll (to itself.) It seems to be different to a 'normal' dll loading procedure...

But after all, it shouldn't be much of a concern, since the result speaks for SSM, anyway.

 

_anvil,

I redid the test with GOD 2 and I'm surprised a little bit. The first time GOD 2 came through (Look'n'Stop) didn't react. But as soon as I unloaded keylog.dll with APM and explorer.exe crashed, as you told me, Look'n'Stop gave an alert. From this time on, Look'n'Stop always gave an alert, that the explorer.exe has changed...

So I hope this clears things up! Nevertheless this GOD 2 is a beauty of a nastie! Countermeasures are untertaken, mails to several support sites (DiamondsCS, NAV, F-Secure, KAV,...) are under way.

Best regards,

Patrice

 

>_anvil,

Yes, I think that DLL listing functions will be included in the next release. BTW: SSM already can load/unload DLLs, so it's a kind-of-routine to make a thing like DiamondCS's "Advanced Process Manipulation"

You are right, SSM detects the case, when Explorer not simply loads DLL into itself, but when it want's this DLL to be loaded in almost every process in your system

 

@Patrice

Hmm, interesting... and a bit strange, because it is not the 'explorer.exe' which injects a dll in the browser to hijack it, but the 'god2.exe' from win-dir.
If L'n'S would detect this correctly, the alert should sound different, I think.

So, I don't know, what L'n'S exactly 'detects' and alerts here...


@Max

Yes, that makes sense.
Looking forward to the next release of SSM.

 

Hey _anvil

I may be mistaking but assuming GOD2.exe is the name which user pre-defines, upon Execution of GOD2.exe it copies itself into %WINDIR% and creates keylog.dll (assuming on user pre-defines) into %WINDIR%, GOD2.exe Executable also injects that into the Explorer.exe Process. In Addition it creates log-send.dll (again, assuming on user pre-defines) in %WINDIR% which gets called by the keylog.dll to send its Log File and so forth via E-mail, also the Log.txt (…) which gets created into %WINDIR%. GOD2.exe also places itself into Current Users Start-up Group which injects keylog.dll into Explorer.exe Process upon Windows booting…

GOD2.exe only runs long enough to insert its DLL module (keylog.dll) into Explorer.exe process, keylog.dll checks for user-predefined Log size in KB and if matches calls the log-send.dll which sends the Log and whatever via E-mail.

Look ‘n’ Stop does not have DLL Module Filtering yet, until then these methods using DLL Modules will be undetectable by Look ‘n’ Stop Personal Firewall.

Regards,
Phant0m``

 

>Patrice
" From this time on, Look'n'Stop always gave an alert, that the explorer.exe has changed..."

OKay, and what about this test: httx://mc.webm.ru/copycat.exe?

URL changed - those who want to perform this test: revert the URL to "http". No offense, Rabbit - Forum Admin

 

Hmmm on Windows XP Pro there was no Look ‘n’ Stop Alert indicating any changes to Explorer.exe file.

 

Max,

what the hack is that!? Do you have any additional information about this tool? TDS-3 gave me an alert about it... I will test it and come back with the results.

Cheers,

Patrice

 

>
"TDS-3 gave me an alert about it"

Wow . I'll try TDS3

Actually it's a simple proggie (written by myself), wich injects it's code into application you select. I can provide a source code if you worried about TDS3 alert. The only problem I've noticed, is that process you will select to hack may crash, if you will perform this test twice. It will not affect on stability of your system and of course will not do anything bad.