Latest Comments
"I feel it with you guys. These irritating interruptions on privacy MUST be stopped. It is a ..."
by Jan Wilmans | Dec 2, 2008 7:11 PM
 
"My AVG WILL NOT UPDATE"
by James Downs | Dec 2, 2008 5:58 AM
 
"Concerned man's comments seem to intimate that if I'm using agents all will be well but the ..."
by Werner K | Nov 26, 2008 8:36 PM
 
"That will enhance Microsoft Office system, including SharePoint - good platform for enterprise ..."
by SGE | Nov 25, 2008 3:29 PM
 
"how many users allow per session? because the digital persona password manager allows only 10 ..."
by Daniel | Nov 25, 2008 12:14 AM

Hackers prevent research on malicious code

  • Email a Friend
  • Print Page
By Dan Raywood
Sep 18, 2008 12:41 PM
Tags: Hackers | prevent | research | on | malicious | code
Cybercriminals are randomizing content served from malicious web pages so that they can prevent security researchers from doing proper analysis.

According to Websense Security Labs, malware tracking is becoming more difficult because IP addresses and user-agents are being tracked rigorously and often, when pages are served, the content is randomized.

Following analysis of malicious Flash files, the company investigated a situation where upon receiving a (Shockwave Flash File) SWF-linked URL in an email and clicking it, a user was automatically redirected to a spam web site.

However, when GNU's Wget utility was used to fetch the page, a “403 forbidden” response was received.

Websense researchers initially thought that either the attackers had blacklisted the location or that they had checked all the HTTP header attributes.

After a cookie was set, it seemed as though the transaction was being conducted. That is, as though a user clicked on the SWF file as opposed to visiting the page with a simulated browser (Wget).

On a blog entry, Websense researcher Stephan Chenette wrote: “In order to verify this, I wrote a quick PERL script. First, I put all the headers a server would expect if a user were to click on the SWF file and be directed to the spam website. I received a ‘200 OK' server response with the spam content.

“I then tried to verify that the server was looking at the HTTP REFERER, but was surprised to see that the response was the same with or without the correct REFERER. After playing with the headers for a few minutes, I noticed that it was simply looking at the user-agent. If the user-agent was Wget, it returned ‘403 Forbidden.'

Carl Leonard, security research manager at Websense, added: “On further analysis it showed that when using the Wget content retrieval tool the malware author was looking for the use of Wget and so delivered a failure. The malware author [coded to] see the person trying to access it and decide whether or not to present them with the malware.”

See original article on scmagazineus.com

Secure Computing Magazine

 
Ads by Google
Thoughts on this article? Add a comment below.
Be the first to comment on this article.

Report this comment as offensive:

   * Indicates information we require to process your submission.

Name: *
Email: *
Reason for offense: *
Your report will not be displayed.  
Name:
*
 
Email:
(will not be displayed)
*
 
Comment:
(HTML not permitted)
*
 
Validation
*

Enter the code you see below:

 

 
 
 
 
 
Tripwire - Click here to win an iTouch
 
 
Biometrics & Forensics Whitepapers