Memory modification not detected?

[Guest]

[salmonela]

Q.E.D.

You're not running the JPG, per se, you're loading it into another application that may or may not have vulnerabilities. The flaw lies in the application, not the data file.

Ewen :-)

huh, yes, sorry for stupidity 
I guess then, there is noting to test,
aigle, please tell me what is on that picture (jpg), maybe guys from eq security while clicking on useless prompts...

[panic]

I should have added that a malicilously corrpted data file can act as a trigger to a vulnerability in an application and is therefore part of the overall problem, but is still not the root cause of the problem. The vulnerability of the application attempting to read the data file is the core of the problem.

Ewen :-)

[aigle]

Out of curiousity, how do you run a JPG?

It's not an executable extension and would merely call whatever app is registered to handle them.

Or do you mean that it is an EXE with a double extension of ".jpg.exe"?

Ewen :-)

I run it via cmd.exe.

[panic]

I run it via cmd.exe.

which passes the file extension to Windows which looks up the associated executable which is then called and loads the jpg you have "run" from the command line.

[aigle]

which passes the file extension to Windows which looks up the associated executable which is then called and loads the jpg you have "run" from the command line.

Hi, I am totaly novice but I believe running a spoofed jpg from command line does not open it in my default image viewer, it instead runs the the executable that is spoofed as jpg.

Am I right?

[panic]

When you say "spoofed as jpg", the only way I can think of is if the file you're referring to is called something like "filename.jpg.exe".

For display purposes, Windows, for reasons best known to itself, reads the filename up to the first period and then assumes the next chunk of characters up to the end of the filename (or up to the next period) is the file extension. In the example above, Windows reads "filename" as the name of the file and "jpg" as the file extension associated with "filename". This is why your jpg file appears with what I assume is an ACDSee file icon. For display purposes, Windows absolutely ignores the ".exe" that is after the ".jpg".

If the file is called "filename.jpg.exe", you would need to enter exactly that (including the double extension) to run it as an executable from the command line. If you ran "filename.jpg" it simply would be opened by whatever application your system has associated with JPGs.

LOL. Now I'm starting to have second thoughts on this.

When I get a spare moment, I'll double check all this, but I'm pretty sure I'm right. JPGs are not executable, only callable by an excutable.

As a test, can you run it again and while it is running, open Task Manager and see if you can see the JPG file listed.
If it is, I'll get out the bar-b-q and prepare to eat my good brown hat. 

Ewen :-)

[aigle]

Hi, it,s an executable and it has no double extension like jpg.exe etc. It,s extension jpg is wrong and its icon is also wrong. It,s an executable, all I can tel u. When u run it via commandline it executes and run in the task manager as an executable.

That,s all. I am sending u the link via PM. Run it via command line and see wat happens.

[panic]

Got it! It's not a double extension, it's a renamed EXE. If you look at the file header it's type is PE (program executable), regardless of what file extension is applied to the file.

It's a variant of the delph trojan. Nasty bit of work. If you rename it to a TXT file you can open it and read some of the junk in notepad.

Now, I'll go back and have a look at your original post. LOL

Cheers,
Ewen :-)

[aigle]

Any thing new about this?

Thanks

[aigle]

Bump!

[egemen]

Hi,

Attached are the D+ popups you can see when this malware is run. The critical popup is the second one i.e. the malware tries to run iexplore.exe.

After allowing this action, D+ will not ask for any memory modification attempts on an application by its parent because:

1 - The parent already obtained a handle to the child process i.e. this means it can fully control its child process without modifying its memory (there are many ways to do this)
2 - There are many other things it can do on the child process once it is allowed to execute it
3 - Legitimate applications such as explorer.exe do the same from time to time.

Egemen

[egemen]

Here is what i found testing this image.

First of all, yes it is opened in image viewer app upon double click (if explorer.exe is allowed to execute image viewer). All like Ewen said: Windows opens it under assigned app for *.jpg. No malicious actions are performed by our "image" in this case.

Next. Launching image from command line.
First of all here is what we get if we launch any normal image through cmd: first alert screenshot 1 if cmd.exe is not allowed to access service control manager, which we can safely block (service control manager is very serious permission and cmd.exe should not be allowed to access it unless special case; imo), then alert on screenshot 2, which we allow and image is opened in assigned viewer.

But if we launch our "image" from cmd here is what we get: first alert on screenshot 3, which is very suspicious as it says that "cmd.exe is trying to execute somename.jpg". In fact our "image" should be blocked at this stage.
But even if we allowed to execute somename.jpg, second alert on screenshot 4 appears. This activity even more suspicious as image (!) tries to execute iexplore.exe. It should be definitely blocked.

As you can see, such malware can be stopped by D+ if user answers accurately to alerts.
But answering to your original question, aigle, i don't know whether some memory modification is not intercepted by D+. I don't have EQSecure test results (step by step alert screenshots).

What i really got in my tests is that after alert on screenshot 4, IE is controled by our "image". Not sure if there should be alert that our "image" tries to perform additional actions to take control over IE (like accessing IE in memory or installing hook or...).   

Yep. Executing iexplore.exe is the key popup here and cant be missed.

[Yuriy]

Yep. Executing iexplore.exe is the key popup here and cant be missed.

I noticed your post after i posted mine. Mine was useless because of yours, that's why i almost immediately deleted it 

[Yuriy]

After allowing this action, D+ will not ask for any memory modification attempts on an application by its parent because:

1 - The parent already obtained a handle to the child process i.e. this means it can fully control its child process without modifying its memory (there are many ways to do this)
2 - There are many other things it can do on the child process once it is allowed to execute it
3 - Legitimate applications such as explorer.exe do the same from time to time.

Thanks Egemen
That explains everything i was thinking of during testing.

[aigle]

Hi,

Attached are the D+ popups you can see when this malware is run. The critical popup is the second one i.e. the malware tries to run iexplore.exe.

After allowing this action, D+ will not ask for any memory modification attempts on an application by its parent because:

1 - The parent already obtained a handle to the child process i.e. this means it can fully control its child process without modifying its memory (there are many ways to do this)
2 - There are many other things it can do on the child process once it is allowed to execute it
3 - Legitimate applications such as explorer.exe do the same from time to time.

Egemen

Hi egemen, thanks for you explanation. It,s clear now. 

goodbrazer! Thanks too.

[Tags:]